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.
Related
I am wondering how to process responds from WCF RESTful service in a right way. For example, service could throw new WebFaultException(HttpStatusCode.Unauthorized);. But how can I get a particular reason of this respond and process it on client? I know that I could use WebFaultException<T> and extend exception with some data describing details. But what if client is written in native C++ or php... The whole idea is to interact with the service from console application (could be written using a huge set of languages) via HTTP/HTTPS and query some data.
The output is available in two forms JSON and XML, and handling error would depend on how it is being structred in the response.
you make like to have a look at this.
Look I'm concerning about what is faster/best about consuming a WebService who is within the same WebSite/WebApplication.
Imagine I have a 20 pages and 1 WebService in the same WebSite..
In each page I have to consume everything from the WebService...
But my concern is how it should be consumed? I should add the webreference of my WebService who is in the same website and use everything with the proxy generation of that Webservice.. or I should instantiate directly the WebService like a normal Class and consume the methods?
I know (or I think) that the best practice is to consume it like a webService for the SOA especifications and have the WebService in another website in my solution.
But my reasoning says that consuming a WebService needs http protocols who makes a request through this protocol, and a webservice serialize the response...
An important thing to remark I guess, is that the webmethods of My WebService can return several records /information /data, so the serialization step could be a problem or a performance issue.
I'm looking for the best way of doing this.
Should I move the WebService to another Site and consume it in my pages? even though the performance will be affected? or I should not? if yes, how much? it will cost ? or the impact is not significant?
If I should move the WebService does it affect if I consume it like http:// localhost .. instead of ... 192.168.1.1, or a web domain than localhost? is it the same or does it affect in something?
Thanks in advance for your help.
But my reasoning says that consuming a WebService needs http protocols
who makes a request through this protocol, and a webservice serialize
the response...
Your reasoning is absolutely correct. If you are inside the same project there's no need to waste CPU cycles in useless HTTP requests. You could directly invoke the same repository layer that your web service methods already uses. You could still expose the web service using an interoperable format (such as SOAP) if you need non .NET clients to consume it, otherwise I don't think it's really necessary. Actually why did you develop a web service on the first place? I guess you had some expectations about future consumers? The rule of thumb is to always encapsulate a reusable service domain logic into a service layer and then depending on who needs to consume it, either directly use the assembly in which you implemented this functionality (if we are talking about .NET clients) or if you need interoperability, it's pretty trivial to use WCF to expose this service layer using interoprable protocols.
But if you are interested in the exact figures, don't hesitate to perform some load tests and compare the response times between a direct .NET method call directly from within your cinsuming web application and an HTTP request using an interoperable protocol.
Remark: WebReference clients are deprecated now. You should use a ServiceReference instead if you decide to invoke your service throughout a network connection.
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. :)
I have a very simple entity framework (.edmx) file, and a .svc rest service.
Everything works fine for CRUD operations.
I have many databases thats shares the exactly same schema.
My next step is to let the client pass inn a parameter that could be the connection string or some other value identifying the user so that the service serves data from the correct database.
Now, the only parameter is the uri for the ServiceRoot
I see in the datamodel that I can pass inn a connection string, but how can i do this from the client without making many service files.
I am assuming you are using WCF Data Services to expose the edmx file. I am no expert in this toolset but I suspect the only direct way is to create a service for each database.
This is a great question and it is a scenario that I hope will be addressed in the future WCF HTTP stack.
In the meanwhile, there is some positive news. I have experimented in the past with creating a large number of service hosts (around 1000) and my experimentation showed that it was quite efficient to start up and did not consume large amounts of RAM. The key is to create the service hosts in code rather than via the config files. Obviously, you don't want to be hand writing an XML config file with thousands of service entries in it!
It may not be the ideal solution but I believe it would work.
If you're using WCF Data Services you should be able to pass the information identifying the data source to use in the HTTP request. Either as a custom option in the URL or as a custom HTTP header (I would probably use the custom header as it's much easier to work with from the client).
Depending on the way you host the service you should be able to access the headers of the request on the server. You can use the ASP.NET way to do this (static variables), or you can hook into the processing pipeline of the WCF Data Services which should allow you to access those headers as well.
I am trying to use a SOAP Web Service provided by a third party. I am having trouble getting the service to work correctly in .NET 3.5. I have added it as a web reference and all seems to go well. Problem is when I call the service all I get returned is a NULL object. I have worked with the provider and there service appears to be working correctly. He did mention:
"We are using Axis2 Document/Literal and support SOAP 1 and 2."
I am not exactly sure what that means as I am a semi-newbie to using Web Services. Do I need to change some configuration parameters or something in .NET to get this service to work correctly?
From my experience, web service interoperability isn't the magic it claims to be. Especially, between .NET and Java.
Axis2 is a Java web service "engine"
Document/Literal is a style of writing a WSDL that results in a special SOAP appearance
SOAP 1 and 2 (you probably know) the message format and specific versions thereof
all I get returned is a NULL object
Is not much to start with, could you provide more information?
I would recommend, that you try to intercept the exchanged SOAP messages (you can use tcpmon) and check if they are valid. You would probably get an exception if the remote service can't handle your request so I guess your client as some trouble parsing the response. Additionally, you can use soapUI to generate example request to see what a valid request should look like.
Doc/lit (and at least SOAP 1) ought to work with WCF, but I'm not sure how the legacy (pre-.NET 3.0) web service client deals with that.
Did you, in Visual Studio, add a web reference or a service reference? If you added a web reference, you are not using WCF, which may be the reason it's not working. If this is the case, you should delete the web reference and see if adding a service reference instead helps.
It sounds like the proxy that you have generated (via add web reference) is not de-serializing the xml into the type you expect.
As wierob suggests the first thing I would do is trace the messages that you send to the service and the response you receive - that way you can examine the xml you can check that the proxy is creating a suitable request message and see whether the response does contain data that is not being de-serialized into the object you expect
As well as tcpmon you could use fiddler (from microsoft) to trace the traffic or the simplest would be to switch on the message tracing in WCF to log the request and response to files which could then you examined in the service trace viewer tool
With these kind of interoperability issues I find the best thing is to look at the message "on the wire" first - you may then have to tweak the wsdl so that the proxy gets generated correctly or hand craft the proxy yourself
If you post the wsdl and your proxy that might give us a clue as to the issues