Practical Advice for SOA Implementers

Posted by Boris Lublinsky on Dec 16, 2009

Sections

Operations & Infrastructure,

Enterprise Architecture,

Development,

Architecture & Design

Topics

Governance ,

REST ,

Web Services ,

Architecture ,

Design ,

SOA ,

Data Access ,

ESB

In his new blog post, "Advice To Organisations Embarking On SOA Today", Ganesh Prasad gives an advice, based on his several years of experience, on how to approach a major SOA initiative:

... don't let the lack of grandeur in this approach worry you. Complexity impresses the novice, but results are what ultimately impress all.

Ganesh’s approach covers the following major points:

• Keep your eye on the goal. SOA is not about integration or introducing a new technology that will simplify connecting the existing systems. It is about:

  ...simplifying the components of your enterprise and making them easy to understand and connect to... So keep simplicity at the back of your mind all the time, and don't confuse it with expediency, which is the path of least resistance. Simplification could take some effort.

• Understand data. Service interoperability requires "semantic" data model for their interaction. Ganesh points out that "the" canonical data model is typically too high-level and abstract for the practical use. Instead, he suggests splitting enterprise data into several logical domains and defining dictionaries for these domains.

  All services exposed out of these logical domains should use these definitions and it is the responsibility of service consumers from other domains to understand them. Processes that combine services crossing such domains should perform their own mapping between similar data elements. This is not as bad as it sounds because only a subset of data elements managed by a domain is exposed through its service interface.... Don't look to [build] a single canonical data model. That's a wild goose chase, so don't even start.

• Choose the right middleware. In Ganesh’s opinion, in the majority of cases, HTTP is the most appropriate middleware for SOA implementations. He suggests avoiding usage of message queues unless it is absolutely required and points out that an HTTP-based communication pattern backed up by databases typically provides a simpler solution.

  HTTP is quite a universal protocol to use as the logical infrastructural element for your SOA.ESBs, Service Directories and other "governance" components are often only required to manage the complexity that they themselves introduce. It's amazing what you can achieve with a farm of simple web servers and a database, and still keep things simple and understandable.

• Choose the right service implementation approach. Ganesh considers SOAP-based Web Services to be, for the most part, "vendor-provided" propaganda and recommends to avoid it as much as possible. He suggests using REST instead :

  REST is in fact a valid way to do SOA and can usually help to deliver solutions at much lower cost and complexity. The hard part about doing REST is finding good people who can think that way.

• Choose the right Data Contract definition. When it comes to a formal definition of domain models, Ganesh suggests that a "standard" XML approach is heavyweight and cumbersome. He instead suggests taking a closer look at JSON schema proposal

  Already, there are JSON Schema libraries in many high-level languages such as Java. It should be possible to define data contracts with as much rigor as with XML, but at a much lower level of complexity... instead of going down the XML rabbit-hole, start with JSON anyway, and incorporate JSON Schema as it matures. You will find this works especially well in combination with REST.

• Solve the SOA simplicity Paradox. Although the main driving factor behind SOA is simplification of the enterprise architecture, the reality of the typical SOA implementation, according to Ganesh, involves making integration complex through usage of heavyweight approaches and then introducing tools to manage this complexity.

  Of course, if you're politically inclined, you will bask in the prestige of a hefty budget and a large team, and can declare victory anyway on the basis of the number of services and processes you have delivered. But if you want to be really successful at delivering SOA (i.e., making your business more agile and able to operate on a sustainably lower cost basis) while keeping your burn rate low along that journey, you would do well to look at boring, unimpressive and even anticlimactic approaches and technologies such as the ones I've listed above. Give the big vendors a wide berth. You don't need to buy technology (beyond the web servers and databases you already have). You certainly don't need to buy complex technology, which is what the vendors all want to sell you.

Prasad's post addresses many issues which are encountered during a typical SOA implementation. It also appears to dismiss existing, oft-used solutions to the problems encountered in favour of newer approaches. This leads to a question: when is it better to understand and improve upon an existing solution, and when is it better to dismiss the existing solution and try a new approach? Is newer always better?

1. Back to top

   Rest vs SOAP

   by Kevin Grainer

   I have to call the bluff on rest. I'm actually a huge fan and I have used rest in a couple of projects. In fact, the paradigm is definitely better and more simple. The big problem with rest is who supports it? If someone says they would like to call your service from program X, guess what they will be looking for? Soap. It's unfortunate, but that's the way it is right now. I fought the tide for a while, but honestly wsdl works, as bad as it is. Someone can take your wsdl and use a random program to invoke your service, because all the vendors jumped on the wsdl/soap bandwagon. Maybe something will change in the future.

   Reply

2. Back to top

   Re: Rest vs SOAP

   by Jean-Jacques Dubray

   Kevin:
   
   could you remind me again what does REST bring for X-to-server communication where X is not a browser? I must be missing something. Could you explain what "better" means, how about "simple"? Let's take real scenario where a "service" (are there "services" in REST?) changes here and there every 6 to 12 months? What will change in the future? Do you really think we'll never need contracts? validation? Asynchrony? Bi-directional interfaces? Assemblies?
   
   What a waste.
   
   JJ-

   Reply

3. Back to top

   Re: Rest vs SOAP

   by Kevin Grainer

   Yes if there was a way to build a wsdl type of document to describe the contracts for rest it would be much more useful. I think there is something called WADL that is supposed to do it, but I haven't checked it out. Maybe someone on infoq has used rest with WADL?
   
   HTML 5 is supposed to handle communication threads now so if your primary client is the browser then you can mimic some of the soap MEPs there. I find that XML is very bloated for communication where JSON or google's rpc format is much more optimized in terms of space requirements. Using JSON or another similar format seems to be the standard from the web browser side . I agree that for system to system communication behind a company firewall that soap is not broken and is probably the best choice in the current market.

   Reply

4. Back to top

   Re: Rest vs SOAP

   by Kevin Grainer

   By simple I mean that I can send you a single url that is my service. For example:
   
   myrestserver/rest/objects/1
   
   This can be built to return a random java object as json. This is very simple from the web browser side since we can convert a JSON string into a Javascript object which can be manipulated and displayed. Please tell me how easy it would be to do that with a soap web service? I assure you it's much more complicated.

   Reply

• Older >