SOA Tips-Prefer Use of Document/Literal Rather than RPC

SOA-Tips

Prefer ‘document’ encoding and ‘literal’ use over other types for interoperability. Services exposed using Document style encoding with Literal use are better-suited for coarse-grained interactions and better represent the data exchanged. They provide the ability to validate the XML data if the XML Schema is available. You could specify XSL transforms to Transform messages using XSLT easily. Document style encoding with Literal use provides better performance than other encoding/use styles. Since the service interface in the WSDL clearly defines the types of documents expected, it makes it easy for the consumer to develop clients for the service.

Service-Orientation is totally different from either Object-Orientation or Component-Orientation

When we think about setting up a web community through a web-site, we do not think of it as exposing a Java class. We have some important business/organizational goal. We have a community of users we are trying to approach through the web-site. We work hard to conceptually get the idea of the web-site exposed in a way that is very practical for a broad range of users. We try to make it very simple and painless so that the user community we are trying to grow is able to approach it and get some value out of it. We hope that a user community materializes to make our investment practical. That is exactly what we need to think about from a service perspective when we are trying to expose services.

What is a Service

A Service is NOT some plumbing to put up a Java class with some getters and setters on the net. A Service IS a 24×7 commitment to expose some core business functionality up as a network resource that we are trying to share either inside of the business, or across the business boundary. That is the reason d’ etre for the service and the reason we are making the investment – it is not cheap, and it is not about exposing a Java class on the net – its a significant business functionality commitment. The fact that there might be an EJB under the covers that happens to be the entry point with some annotations on it is secondary, just as a servlet might be behind the web-site. When thinking about services, if you are thinking of putting up a Java class on the net then boy you have the wrong model in your head! A Service is NOT a Java class or a new way to share libraries.

Business-documents are the core building-blocks of a Service

You can think of business-documents as the core building blocks for building a Service for any e-Business vertical like Finance, Retail, Banking, Insurance, Health-Care, or Telecommunications, etc. When you are constructing the content for the business document, often, you have a wrapper which describes the business purpose, followed by the business data that’s embedded in the document that supports that purpose. So for e.g., if you have an Employee (a noun) creation/update (i.e., verbs) document, you have a wrapper around that data describing the business action (a verb) you are taking, and based on the data you may be able to surmise if its a new (creation) or update entry or you may have to mark that explicitly in the data itself. You can compose this up and you are doing this independent of this somewhat goofy procedure name idea that is in WSDL. You just get into the document and create it like you would any other business document while capturing in a reasonably self-describing way what it is your trying to accomplish – not from a procedural perspective, but from a business document perspective. That is the way to reason about what it is you are doing. If you do that, the reason you use Document style encoding with Literal use is so that you don’t get yet more crap into the message that is putting this weird operation name element into your perfectly valid business document. Therefore other forms of encoding – like RPC – just gets in the way`of creating perfectly legal business-documents. You have a self-defining business document that contains nouns and verbs. Each verb can be quite complicated – it isn’t a procedure name or an operation name – it is some description of a core business action.

RPC based services are stumbling-blocks rather than building-blocks

It is only when you start looking at at it from a kind of Java code-first perspective that you get confused. You do not think of business documents in Java. In Java, you’re thinking of function names and so forth and it has nothing to do with business integration. However, unfortunately, it is only when the people who are dreaming this up start thinking about the remote procedure call thing, they get all confused and we have to deal with the resulting kind of mish-mash of stuff.

So if you stick with the business document perspective, then you’ve got it. People know how to evolve business documents, they do not know how to evolve some weird operation name element inside their perfectly legal business documents.