I’d like to start a discussion around Web Services architecture specifically around SOAP RPC versus Document/Literal and SOA. We are just getting started with Web Services and also SOA.

Seems like folks overall are leaning towards Document/Literal as far as SOAP goes. Standard arguments seem to center around loose coupling, abstraction etc. As Mark C has pointed out, Document/Literal also brings some more complexity into the picture.

I’m doing some prototyping with a generic webMethods web service that allows external clients to initiate transactions/flow within webMethods. I’m doing it two ways, one with RPC and one with Doc/Literal. The RPC version takes a single xmlstring as input and returns a single xmlstring as output. The xmlstring contains a valid xmldocument defined within webMethods. The generic publishing service simply queries the header information within the xmldocument to determine which document to publish and whether it is a request/reply or simply publish. It then returns a response with a xmldocument to the calling client. In a sense it is a proxy service that determines routing information, maintains persistent, logs etc.

The Doc/literal version does pretty much the same thing. The difference being the way the service gets invoke via the namespace setup. The client still has to send a formatted xmldocument with control information in it. But no direct method call.

Discussion Point - It seems that both provide the same level of abstraction and loose coupling. But does it really? Opinions please.

The second item is SOA. Specifically, service proxies that coordinate the web services. Seems to me that webMethods naturally does this well without having to build the transaction management, audit logging, reliability, persistent into a hand coded services layer like in .Net or a J2EE app. Opinions? Has anyone done this in a real implementation?

Thanks for the feedback.

markg

Good discussion topic and probably very timely. I know we have been exploring the various message styles when looking at web services. There is actually a hybrid in this space called doc/literal wrapped. It’s essentially doc/literal with the method listed as the first element of the message, hence the wrapped concept.

While you listed your example as RPC it is, as you put it, a generic proxy. Most usage of RPC has been to invoke a specific method to perform a specific purpose. The parameter elements become the method signature with a return of a single element or an object structure that is eventually marshalled as an XML structure.

Where the complexity enters is when the input structure has several optional elements in the parameter list, which is feasible within XML. At that point you can end up with several method signatures to deal with. This is where doc/literal with a generic method makes more sense, allowing you to process the XML document programmatically.

So, in answer to your question, RPC probably introduces more coupling since you are more closely bound by the interface. However, sometimes this level of coupling is necessary in a true SOA.

The second point of your post involved SOA. Let the games begin! I’ve found that if you asked 5 people about SOA you can get 5 different answers today. During a recent discussion of SOA at a conference the issue for true implementation involved the evolution of the alphabet soup of standards. I firmly believe this is critical in implementing an SOA. Otherwise, you end up with a proprietary solution for the SOA. Security is a prime example. WS-Security provides a great framework for authentication of web service messages that is not bound to a protocol like HTTP. As the standards evolve they will see their way into the products, like webMethods and J2EE and .Net.

Good info Randy. I find that the Simple in SOAP is very subjective. I have found so far that it is easier to create an abstract generic proxy using RPC than Doc/Literal. Some of that of course is due to my lack of knowledge. Some is due to the webMethods implementation of it, which makes it a bit harder than it should be in my opinion.

This is still a very immature technology or set of standards. After playing around with .Net, webSphere and webMethods, I ran into a lot of interoperability issues. I wonder how well this technology will be adopted overall. Everyone says they support the standards but then you find that their individual interpretation may be a little off. I could see where a lot of development time could be spent troubleshooting interoperability issues.

SOA is even more complex in my opinion. It sounds good on the service. But it seems it would take a large amount of effort to pull it off in such a way that the touted benefits can be achieved. This would typically take a more mature development organization with solid management support. I think eventually when the kinks are worked out that this concept holds promise, I just not convinced it is ready at this time. But I’m still learning.

Most of our experience has been in the J2EE and .Net space for web services so I’m just getting into what webMethods has to offer within the toolset. I’m sure that whatever is there now will evolve due to the merger with TME. I’m curious to see what new architecture is planned with regard to Glue and Fabric. More to come on that I’m sure.

Interoperability is an interesting topic with regards to web services. In reality that’s the cool sales point for web services since it allows heterogeneous platforms to interface with each other through a neutral protocol, if only it were truly neutral. So, to address that challenge another group has been formed to work out the issues of interoperability - the Web Services Interoperability group otherwise known as WS-I. Many of the technology providers are key members of this group formed to review the specifications and publish “profiles” dictating the best usage of the specs for interoperability. You can check out their site at www.ws-i.org. Guidance I heard from an industry expert was that unless you are really needing a specification, you should wait until WS-I publishes a profile addressing the specification. A good example of WS-I’s recommendations is the prohibition of the use of encoding. WS-I advocates literal over encoding.

SOA is the next “holy grail” of the distributed computing environment. What it truly means is still being defined but it’s great for rebranding your product line and giving it new life. Now, with my cynicism aside, there is virtue in developing an SOA within your environment. If anything, use it to manage the plethora of web services you develop. If left unchecked, web services could wind up overcoming your environment with no method of control or management.