A rootin', tootin' new article entitled "Using Complex Types in Web Services", written by Balaji Loganathan , appears in the latest issue of the JavaRanch Journal. You kin check out that there article here. Y'all have anything to say about it? Say it right in this thread!
Noticed that RPC style service was used - seems to be the easy way out of some (at times) difficult issues surrounding current web service implementations.
Web services best practices is moving away from RPC and towards doc/literal to allow better compatability with non-Java clients. In fact, Axis2 is about ready for it's 1.0 release (currently at 0.95) and the entire premise of Axis2 is to provide more support for doc/literal and to meet industry standards better than previously with RPC.
As a developer who is just finishing a project which exposes a Java-based service to .Net consumers/clients, I found that the many quick-n-easy tutorials of RPC services returning simple types seemed to do Java developers more of an injustice rather than helping...to provide examples of services which are compatible with Java clients rather than any clients seems to set the beginning developers up for failure shortly down the road whent their help desk phone rings saying "a new .Net company can't digest our service...now what?" and the beaming-proudly-just-a-minute-ago developer is totally lost.
I think more articles focusing on current standards for web servcies are better suited to JavaRanch readers/memebers...
As a developer who is just finishing a project which exposes a Java-based service to .Net consumers/clients, I found that the many quick-n-easy tutorials of RPC services returning simple types seemed to do Java developers more of an injustice rather than helping................ .................beginning developers up for failure shortly down the road whent their help desk phone rings saying "a new .Net company can't digest our service...now what?" and the beaming-proudly-just-a-minute-ago developer is totally lost.
No. It is not correct. Many Java based SOAP implementations can still interoperate with .NET, PHP, C++ clients for both simple and complex types. Ofcourse I should not expect my .NET client to understand Vector/Hashmap. Using a RPC based Java webservice doesn't mean that you are locking yourself to java clients. For instance axis 1.3 based rpc webservices were fully interoperable with .NET clients. My article shows the screen shots of a .NET client accessing complex type webservice. Security: With little extra efforts i have also tested axis1.3 + WSS4J to interoperate with .NET + WSE.
If i can my meet my client requirements in RPC style then I will go for RPC style only. While the way forward is doc/literal, it took Axis team more than 4years to comeup with a proper doc/literal based SOAP implementation. Still today the axis2 is beta only.
So what do you see as the main sticking points that are forcing this move? Are people giving up on the basic SOAP premise or what? Bill
No. It just means that the focus of today�s SOAP is quite different from the original "Simple Object Access Protocol" which introduced RPC/encoded. Today�s SOAP focuses on specifying extensible rules for ferrying XML documents (potentially) over multiple SOAP-intermediaries and what to do in the face of failure. Now admittedly this is overkill for most point-to-point transmissions of XML documents as the REST movement is quick to point out. However the SOAP and WSDL specifications readily lent themselves to tooling (with mixed results) which explains their current prevalent role in XML over HTTP transmission. SOAP's complexity is necessary to support SOA as defined by IBM: An enterprise-scale IT architecture for linking resources on demand. They are talking about dynamically (in effect on a whim) reconfiguring how a business' services interact. (A SOAP client doesn't care whether the node it's sending the message to is actually a SOAP intermediary or the SOAP receiver.) No wonder they are warning that the business must
establish hype-free SOA value propositions which can be accomplished by identifying and describing how SOA addresses client-specific pain points or business challenges.
The ultimate question is: How many businesses need to "link resources on demand" to "address client-specific pain points or business challenges"? Please lets not go through the early days of the EJB architecture again (only this time under the banner of SOA) that addressed the needs of a specific niche of customers but failed to address the needs of the majority of corporate and institutional infrastructures.
RPC style Web Services are currently overused � they are prone to become instances of the "Tiny Service", "Client Completes Service", and/or "Fine-Grained/Chatty Web Service" anti-patterns. Parts of EJB attracted excessive criticism because some developers insisted on exposing class/object level interfaces with a technology that was designed to expose component level interfaces � there was a failure to appreciate the appropriate level of granularity. The same thing seems to be happening to RPC style Web Services and Web Services in general may draw excessive criticism as a result. In some cases the use of RPC style Web Services is appropriate but I suspect that in many cases RPC style Web Services just don�t "accomplish enough" to warrant the serialize-to-XML/envelope-in-SOAP/client-handler-chain/server-handler-chain/extract-from-SOAP/deserialize-from-XML overhead � however the current generation of tools makes it deceptively convenient (rather than just using something like Hessian or Burlap). Web services are called "services" for a reason, their granularity is supposed to be coarser than the component-level, both of which are supposed to be coarser than the class/object level.
this is a message, and
it�s in XML, because wanting to take your code and seamlessly turning it into objects and back again, [�] that�s just not going to work. It�s not going to happen.
Leaving aside the overuse and/or overemphasis of RPC, it is still easily possible to pass along XML. In the Java space, that's the difference between using SAAJ, which is pretty close to transferring raw XML, and using JAX_RPC, which has the whole overhead of RPC. That way the WS infrastructure can do more of the XML handling (on both sides) without having to know what it is transporting.
I'm totally with Peer in wondering where the business value for the masses comes from in some of these scenarios. That's why it makes a lot sense to me that the adoption curve of, or even just the interest in, WS standards dropped off dramatically before reaching things like UDDI and BPEL. Those make sense only if there is a lot of public WS infrastucture all over the place, and I don't see that happening (yet?). [ April 25, 2006: Message edited by: Ulf Dittmer ]