Hi all,
I have recently been looking in to xml based messaging, outside of asmx web services and I was wondering what peoples opinions were on service method signatures.
Take WSE 2 Xml messaging, should all my service methods take just one parameter, the xml message or could they be 'stongly' typed like asmx webservices?
Take Indigo, does the same apply for it's service method signatures? Sorry if this is obvious but I haven't looked at Indigo that much!!
Back to the present, am I right in saying that to define a service using wse2 it has to be hand crafted, unlike asmx web services where it seems a lot of it is done for you?
I have loads of other questions but perhaps these will come out in a different thread, or later in this one ![]()
Thanks for your help.
-
-
Hey gravy
i'm not an expert in this area but the way i understand it, the best way to prepare for indigo is to continue describing your webservies through wsdl, and thinking of them as containing method calls, returning and taking rich object parameters. You still probably want to consider the methods stateless etc, as i think request / response is still going to be the dominant pattern...
i believe many indigo services will be invoked by attributing the application methods ( much like the WebMethod attribute in .net 1.1 ), so much of it will be declarative, and should layer into the exisitng class-oriented model just fine..
-
I would try to enforce method signatures that create a "chunked" interface vs. a "chatty" interface.
So I'd strive for method sigs that look like this:
service.AddCustomer(CustomerObject customer);
-
I agree.
The reason I asked the question was because of the fairly recent MSDN article on messaging with WSE 2. http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/html/wsemessaging.asp
In here it talked about using SoapService and SoapClient derived classes and passing SoapEnvelope classes between sender and receiver. However, I've just read the article again and near the botton it does say that you can use any XmlSerializable object instead of the SoapEnvelope and the base classes will serialize the soap body in to you class for free.
The thing that interested my about the wse2 messaging was the fact that you're not tied to IIS anymore for the host, also it is possible to have real two way (peer to peer) conversations. And of course you can use it over HTTP, TCP and in-proc.
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.