I have https://mysite/myservice.asmx which is consumed fine with Flashbuilder. When i ported it to https://mysite/myservice.svc, and generate proxy objects, flash proxy objects fails to call any operations. I guess, during web service call, operation contracts are got by https://mysite/myservice.asmx?op=myOp, but in WCF, https://mysite/myservice.svc?op=myOp gives disco file reference. Is there anything done it? Has anyone called WCF from Flex?
It depends on the WCF Config that you have setup, if you provide that I may be able to answer better, but for now try to access the WSDL from https://mysite/myservice.svc?wsdl
Related
We need to expose some services (i.e. AddressValidatorService, CustomerFinderService) that currently reside in an ASP.NET application to other applications within our organization. Exposing these services via WCF seems like a natural fit, but I don't see any best-practices for how to pull these common services into a WCF wrapper in such a way that my existing ASP.NET application can continue to use them with minimal code changes and/or awareness that the service they are consuming is no longer in-process.
I'm especially looking for recommendations on how to structure the existing ASP.NET solution and whether to host our new WCF in the same solution or in some new shared WCF solution referenced by both our ASP.NET application and external callers.
Also, is it bad practice to simply promote the DTOs currently only consumed in-process via ASP.NET to full fledged data contracts or is it preferable to create duplicate DTOs that are explicitly decorated with [DataContract]? The latter seems like a maintenance nightmare.
To answer your second question:
Also, is it bad practice to simply promote the DTOs currently only consumed in-process via ASP.NET to full fledged data contracts or is it preferable to create duplicate DTOs that are explicitly decorated with [DataContract]? The latter seems like a maintenance nightmare.
It is considered a bad practice to expose your business model as WCF contracts. So if your DTOs are replicas of your domain model then it would be a strict no-no, because
1. any change in the model would directly effect the contracts and hence all the clients using it
2. you would be exposing your business "know-how" to the outside world.
The latter can tend to get difficult for any evolving system, but then you have various open source tools (like AutoMapper) that ease your mapping nighmares.
You can convert an existing project to WCF, then continue to use it in-process by using a project reference. It can then be consumed by an eternal source using the WCF client. A WCF client converts the class name from ClassName to ClassNameClient when consumed over WCF, but the class will function pretty much the same.
For example:
MyClass obj = new MyClass();
obj.DoSomething(withData);
Would become:
MyClassClient obj = new MyClassClient();
obj.DoSomething(withData);
You would publish the WCF project to some endpoint, like address.example.com, then use a service reference to the endpoint to reference the code, like a project reference, in your other projects.
Note that while the externally referencing projects would not be impacted by the change or know that the data is going over the network, if you have chatty calls to the project in question, it will definitely take a performance hit. You may want to consolidate related methods into single methods to save on round-tripping.
If these are exposed as static page services, there's no magic wrapper -- you're going to need to move code to a standalone service implementation class and put a .svc file in front of it. (Or use WCF4 fileless activation, or a service factory, but that's getting a bit away from the core question here.)
If these are exposed as ASMX, you can actually put an ASMX facade in front of a WCF service class and get basic HTTP/XML/ASMX responses as you would from your legacy ASMX webservices. You an expose that same WCF service class through standard WCF configuration for non-legacy consumers.
Finally, you can expose any WCF service as basicHTTP with serviceMetadata + httpGetEnabled, and you'll get a service endpoint usable by legacy consumers of an ASMX service.
http://msdn.microsoft.com/en-us/library/ms751433.aspx
I would like to pass an arrayList of objects to a servlet from a java program.
Can some one please tell me, how this can be done.
Look at this link they describe the process ind detail
http://www2.sys-con.com/ITSG/virtualcd/java/archives/0309/darby/index.html
Please note that if you are going to serialize objects back and forth that the compiled version must be in sync on both the client and the server or you will get errors. I would recommend converting your objects to either XML or JSON and then reading them from that on the server side. That way if you client and server code get out of sync it will still work.
For the client I would recommend Apache's HttpClient (or whatever they have renamed it to)
Have you considered using a web service framework for this instead of coding a naked servlet? The whole business might be about 10 lines of code using, for example, an Apache CXF JAX-RS service and client. If the objects are complex, you might want to use a full SOAP service.
Since Flashbuilder does not support WCF over https, i am considering to use weborb remoting as alternative, but not really sure how flash is going to know weborb location, if they are sitting on different servers. Looked at destination, source fields, but not really find a field called url in remoteObject in Flex. Has anyone done similar things?
I know this is an old question, but thought I'd answer it anyway. You can expose your WCF services to remoting clients (Flash, Flex) via WebORB. WebORB supports both self-host and IIS-hosted WCF services. Here are links to instructions for both models.
Self-hosted: http://www.themidnightcoders.com/fileadmin/docs/dotnet/v4/guide/index.html?standalone_wcf_services.htm
IIS-hosted: http://www.themidnightcoders.com/fileadmin/docs/dotnet/v4/guide/index.html?iis_hosted_wcf_services.htm
Both documents address your questions. Here is an example of one approach:
Invoking Self-Hosted Service From Flex/AIR
Flex and AIR clients can use the RemoteObject API to invoke methods on self-hosted WCF services which use the AMF endpoint. There are two approaches for invoking self-hosted WCF service. The first approach requires less code, but creates a dependency on configuration files declaring destinations and channels (the files located in WEB-INF/flex). The second approach does not have any dependencies on the configuration files, but results in a few additional lines of code.Consider the examples of the API below:
Approach 1 (with dependency on configuration files):
var remoteObject:RemoteObject = new RemoteObject("GenericDestination");
remoteObject.endpoint = "http://localhost:8000/WCFAMFExample/amf"
remoteObject.GetQuote.addEventListener( ResultEvent.RESULT, gotResult );
remoteObject.GetQuote.addEventListener( FaultEvent.FAULT, gotError );
remoteObject.GetQuote( "name" );
The endpoint URL uniquely identifies the WCF service. Notice the /amf at the end of the URL, it is required for the AMF endpoint. With the approach demonstrated above, the destination name in the RemoteObject constructor is required however it is not used. As a result, for the code to work, the Flex/AIR application must be compiled with additional compile argument:
-services "C:\Program Files\WebORB for .NET\4.0\web-inf\flex\services-config.xml"
I hope this helps.
K
I'm working on a web service that uses ASP.NET security model (i.e. with AspNetCompatibilityRequirements set to allowed). Like many others, I got an error saying the Anonymous access is required because the mexHttpBinding requires it and the only way to get around it is to remove the mex endpoint from each service as described here:
WCF - Windows authentication - Security settings require Anonymous
I thought by removing mex endpoint I will no longer able to generate WSDL or add a reference to the service from Visual Studio but to my surprise everything still works. I quickly googled the "mex binding" but most web sites just say it's for "Metadata Exchange" without going into too much detail on what it actually does.
Can anyone tell me what's the side effect of removing the mex binding?
If your WCF service does not expose service metadata, you cannot add a service reference to it, neither from within Visual Studio (Add Service Reference), nor will another client be able to interrogate your service for its methods and the data it needs.
Removing Metadata Exchange (mex) basically renders the service "invisible", almost - a potential caller must find out some other way (e.g. by being supplied with a WSDL file, or by getting a class library assembly with a client he can use) about what the service can do, and how.
This might be okay for high risk environment, but most of the time, being able to interrogate the service and have it describe itself via metadata is something you want to have enabled. That's really one of the main advantages of a SOAP based service - by virtue of metadata, it can describe itself, its operations, all the data structures needed. That feature is used to make it really easy to call that service - you just point to the mex endpoint, and you can find out all you need to know about that service.
Without the metadata exchange, you won't be able to use svcutil.exe to automatically generate the proxy classes.
I am aware of Web Services and WCF but I have generic question with services.
I have a ASP.NET MVC Application which does some basic functionality. I just have a controller in which I am passing it the records and serializing the information to XML using XML Serializer. Then I return this information to the browser and it displays me the XML i got from the Controller Action. So I get the XML representation of my Class(Database Object) in XML and I am to give the URL of this application to the client and access and pull the information.
Is this a Service then?
I mean in the end all the Clients need is the Xml representation through services also right? I am not that experienced and probably being very silly but please help me out...if I provide xml this way to the client is that a Service? Or is there something I need to understand here?
Don't let all the buzz about "web services" fool you; the basic idea behind a web service is very, very simple. It is simply a matter of providing data in response to a request over standard web transport protocols (i.e., HTTP/HTTPS). Everything else (XML, SOAP, WSDL, etc.) is just layered technology to augment the basic functionality of a service. REST-based services are very basically the simplest services that you can build--they are built on the core HTTP/S transport protocol and not much else.
The main differentiator between a service and traditional web site is that a service is data-focussed rather than presentation-focussed; that is, services typically are not concerned with how data is formatted and displayed (that is up to the client), but rather what data is returned. So...you are delivering XML data over HTTP? Check. You have a service. Congratulations!
Yes, it is a service, returning an XML resource. Also it seems that it is accessible throught standard HTTP verbs such as GET, so one might assume it is RESTful. The difference with a standard SOAP XML service is that you don't have a WSDL that describes it, so you might need to provide a good documentation to clients wishing to consume your service.