File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services and the fly likes New Article: Using Complex Types in Web Services Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "New Article: Using Complex Types in Web Services" Watch "New Article: Using Complex Types in Web Services" New topic
Author

New Article: Using Complex Types in Web Services

Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

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!


[Jess in Action][AskingGoodQuestions]
Thomas Hatley
Greenhorn

Joined: Aug 29, 2004
Posts: 2
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...
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12784
    
    5
Web services best practices is moving away from RPC and towards doc/literal

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
Balaji Loganathan
author and deputy
Bartender

Joined: Jul 13, 2001
Posts: 3150
Originally posted by Thomas Hatley:

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.


Spritle Software Blogs
Balaji Loganathan
author and deputy
Bartender

Joined: Jul 13, 2001
Posts: 3150
BTW, Welcome to Javaranch Thomas
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by William Brogden:

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.

When interoperability is a concern, dematerializing objects on one end and rematerializing them in a compatible manner on the other end is a pipe-dream because platforms can be very different. Hence the move towards document/literal � no platform should have any problem with XML-text - what they do with it is their business. (This doesn�t mean you shouldn't consider your clients � if your "service" serves (mainly) JavaScript clients maybe your should be serializing to JSON instead of/in addition to XML).
Ted Neward:

  • 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.

  • Ulf Dittmer
    Marshal

    Joined: Mar 22, 2005
    Posts: 41843
        
      63
    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 ]

    Ping & DNS - my free Android networking tools app
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: New Article: Using Complex Types in Web Services