As we know we don't have to take service reference or no proxy require at client side to talk to REST service. but the question is how come the client would know what object to send to service, as client doesn't have object schema, if it has to send serialised object XML/JSON what should be the object schema???
Assuming from the tags in your question that you are using WCF, you can place your service and data CONTRACTS (not service implementations) in a shared assembly that your client application(s) and service depend on.
If your client is making a non-SOAP call (to a "webHttpBinding" endpoint), you can manually serialise the appropriate data contract to POST to the server using a DataContractSerializer.
If you need to post XML from a client where you don't have access to a DataContractSerializer (a non .NET client), you need to construct the input by hand. So at the very least, you would need to serialise your data contract and use the result as documentation for constructing the input message by hand from the client.
RESTful "get" requests are like fetching resources based on identifiers so you would normally not need to serialise or construct by hand some complex XML or json structure.
Please also note that not all non-SOAP services are RESTful.
Related
I have a Visual Studio Solution in which a WCF server is contained; the service is defined as an interface using the ServiceContract attribute. The service is finally hostes via an instance of ServiceHost using HttpBinding, which is the intended behaviour.
In the same solution, there is a client; currently the hosted service is consumed by starting the server manually and generating a proxy class using "Add Service Reference", which can be updated as soon as the server is running.
While this works in the sense that the outcome is as desired, I wonder if it is possible to remove the manual start of the server to update the service reference in the client. Is it possible to build the client by just sharing the DataContract attributed interface between server and client without actually running the server and importing the service definition manually in the client? If yes, how can it be done?
Another way is to use svcutil to generate proxy, but even that require WSDL metadata to generate proxy and that is usually available by starting service, you can save it once from the running server and you can use that to generate proxy without starting server later on.
see different options http://www.codeproject.com/Articles/33297/WCF-Proxy-Generation-Options
I personally like hand crafted client as I have better control on code/error handling and I can use shared DTOs from common dll.
Yes, you can use a common data contract, shared between the client(s) and host, to maintain the interface between both sides. That's what I do with this big data sync WS built on BasicHttpBinding.
In a nutshell, I have a host project, with a service contract and the functioning/processing code, referencing a very small project (and DLL) containing only the data contract class definition; just class, constructor, variables and in/out parameters.
That same small project containing the data contract is also referenced by a client-side project that handles all of the interaction between our client programs and the Sync WS. We actually have every web service call (from the simplest Ping() function to the most complicated RetryFileUpload() function) running through that data contract. All the string-based parameters and binary data is passed through the data contract class, then seriailized or deserialized on the receiving end.
Having said that, this approach only works when you have .NET code on both the client and host. We also have Android and iOS clients that are forced to emulate this behavior ... which isn't a big deal, obviously. But this is the approach we took.
We are building a C# Windows Service to host a WCF service integrated with a legacy C++ backend that will service requests made to the WCF service.
Is it possible to construct the C# front-end so that it accepts a minimum SOAP request (possibly a default query in the envelope) and then pass the entire SOAP message (or at least the XML contents of the envelope) to the C++ backend for interpretation so that the details of the interface don't have to be duplicated in C# or exposed to clients of the service (which would know which requests are available and the data structures required for each)?
We would also need to be able to construct partial XML in the C++ backend which the C# front-end would then insert into a SOAP envelope to make the response.
Is it sensible to target using SOAP for this or would it simplify things to use a simpler XML structure (home-grown or alternate standard) that can be passed in its entirety to the backend where the entire response would be constructed?
Thanks for reading, any advice welcomed :)
we have a legacy middleware application and we want to implement WCF Adapter for it. lets say for the time being we would only be consuming WCF service. the middleware is capable of processing XML messages. we would like to get the message xml from middleware, forward it to WCF client. after getting the response we would like to reply the middleware with the response xml.
following are few of our concerns that we would like to be looked into.
we should be able to send raw xml instead of object based WCF invocation
upon receiving the xml after all the layers of WCF (this is important since the validations of xml itself should already be performed according to contract) we will be forwarding it to middleware.
our middleware implements classical webservices but there are various concerns with the datacontract serializer. one of those is object references. as we can already see that the reference of the object is kept by using id attribute in xml element. how could we catter that. are there any further things that we may consider for data contract serializer.
Middleware is concerned about the original message itself. we would like other message related properties like SOAP, WS-Security etc be handled by WCF proxy itself.
Does anyone has any idea how Biztalk adapter for WCF works
any feedback would be appreciated.
1) What you're looking for is known as POX (Plain Old XML). WCF supports this using the WebHttpBinding. Here's a good starting point.
It's not strictly speaking "raw XML" because WCF decides what to send, but what comes out is a plain XML document rather then a SOAP message. If you can't get WCF to send what you want even with something like POX, then it might make more sense to skip WCF for that component and simply open a socket to your middleware layer and send the XML directly. In that case you really can send exactly what the legacy middleware app expects. WCF could still handle the client-facing connections.
2) If you have a WCF service facing the client, WCF will parse the client message and give you some kind of object in your code (depending on the service contract). At that point it's up to your WCF service code to either use another WCF connection to contact the middleware, or as I mentioned open a socket and send the necessary request. But stripping off the WCF "stuff" is done for you before your service method will start.
4) That should be no problem. WCF and your code will handle that before sending anything to the middleware.
Hope that helps a bit. :)
We have a web service that provides auto insurance quotes and a company that provides an insurance agency management system would like to use the web service for thier client but they want to pass the web service raw xml instead of using the wsdl to create a port, the object the service expects and calling the web method.
The web service has performed flawlessly by creating an object like so
com.insurance.quotesvc.AgencyQuote service = new com.insurance.quotesvc.AgencyQuote();
com.insurance.quotesvc.QuotePortType port = service.getQuotePortType();
com.insurance.quotesvc.schemas.request.ACORD parameter = null;
Then create initialize the request object with the other objects that make up the response.
parameter = factory.createACORD();
parameter.setSignonRq(signOn);
parameter.setInsurancesSvcRq(svcRq);
And send the request to the web service.
com.insurance.quotesvc.schemas.response.ACORD result = null;
result = port.requestQuote(parameter);
By doing that I am able to easily marshall the request and the result into an xml file and do with them as I wish.
So if a client was to send the web service via an http post as raw xml inside of a soap envelope. Would the web service be able to handle the xml without any changes being made to the web service or would there need to be changes made to the web service in order for it to handle a request of that type?
The web service is a JAX_WS and we currently have both Java and C# clients consuming the web service using the method described above but now there is another client who wants to send raw xml inside of a soap envelope instead of creating the objects. I feel pretty sure that they will be making the call to the web service using vb.
I'm sure I'm missing something obvious but it is eluding me at the moment and any help is greatly appreciated.
I think you'd need separate URLs to handle this situation. You'd still map your WSDL and its endpoint as you're doing. But then you'd need to configure a second, separate URL that would have a servlet that accepted an encoded XML stream from the HTTP POST and dealt with that separately.
In theory, it should be possible to hand-build XML that is indistinguishable from the XML that is created by a conventional WS client.
In practice, getting this right in all of the edge cases could be rather difficult. And if they (the clients who send raw XML to your service) get it wrong, they are liable to get a lot of obscure errors ... and you may need to help them with diagnosing these errors.
In the worst case, malformed messages might impact on your system's performance. But one would hope that the WS middleware layers and your application are hardened against the effects of malformed requests.
In short, #duffymo's approach of creating a second API is less risk for you, though the cost is more up-front work for you. But the simplest approach would be to just say "No!".
Should be no problem since your wsdltojava and wsdltocsharp will just do that for you behind the scenes. As long as they follow the contract set out by the WSDL.
But it is a lot of work doing it manualy and completely unneccesary since there is also a wsdltovb thing which should be eassier for them. ANd they have to do it all over again when you change something on your side.
They are just reinventing the wheel.
I've got a simple WCF Web service that uses basicHttpBinding to make it SOAP 1.1 compliant. When called with a WSDL-derived proxy (by setting a service or Web reference), the service works great.
A business partner wants to call the service directly with the SOAP XML. I know how to provide that XML, but I'm not sure how to process the XML when the business partner submits the request.
Am I making this harder than I need to? Will the XML request call the service as though it were called through the proxy and will the response naturally make the request happy? Or do I need to do something extra to process the XML request and then hand something (what?) off to my service?
I know there are some similar questions on SO, but they all seem to deal with the issue of getting the XML, not processing it.
It should be sufficient to just send the raw SOAP message to the endpoint URL of the service. The WSDL-derived proxy just generates the SOAP from your objects and manages connection handling and transport (probably HTTP) details.
It might be possible that you need to add a SOAPAction HTTP header, depending on the service.
If you intercept the communication between your WSDL-derived proxy and the servcie (e.g. using TCPmon), you will see the SOAP message and the used HTTP headers.