Geeks With Blogs
I'd Rather Be Coding Jay Glynn thinking out loud.

There's been a lot of discussion on SOA lately. Two topics in particular have been turning around in my mind, web services and what to return. I go for a bike ride on most mornings and this moring some thoughts on this started to come together some time around mile 5. The two subjects are actually relatated and this is the part that I wasn't seeing at first.

First, in order to called SOA, some would have you believe that the only way to implement this is by using web services. I think this is a very narrow minded view on what a service can be. Web services are certainly an easy way to implement a SOA. But it certainly is not the only way. We have a gateway product the sits in front of our host system. This host system is running a 20+ year old policy admin system that is developed in COBOL and assembler. This gateway product translates a call from the client side to a CICS program that can then run and do virtually anything. When I write code against this product I interact with it as if it were a stored procedure. That is the syntax that I use. Now I consider this to be a service oriented architecture. Does this adhere to the 4 tenets of SOA:

  • Boundaries are explicit
  • Services are autonomous
  • Services share schema nad contract, not class
  • Service compatibility determined based on policy

I think that you could make an argument on all of them. The gateway serves as the service provider to a couple of million lines of COBOL. The same procedure calls have been made by multiple programming languages in several different types of applications. Not a single web service to be found. Could we put web services in front of this? Sure but why would we? What would that accomplish? Another layer of abstraction isn't always a good thing.

The other thing that keeps bouncing around in my head is what should be returned. This is much more difficult. In the example that I just layed out, the return is different depending on what called it. The layer of abstraction in this case is ODBC. I think that this will always be the case. There is no correct answer on what should or should not be returned. SOA is ultimately about integration. Otherwise why bother. So depending on what you want to integrate would depend on what you want to return. If you want ultimate flexibility you would have to return a deliminated text file of data. Almost any type of system or environment can at least read and parse this (even our 20+ year old policy admin system). The next step would be XML, the next would be XML with some type of schema. Next up the ladder would be XML in a SOAP or WSE package. Finally you get to return typed objects. As each step up the ladder occurs a limitation is placed on what can take advantage of the service. Now I have skipped several different types of data structures that can be returned, but I think the point is made. This is why I think you have to be very careful when laying out any new system. Implementing a bunch of web services and then standing back and saying your doing SOA is wrong and potentially dangerous. And this is where the two subjects tie together. If you use only web services for the service layer then you could be making it more difficult for some to consume the service. Returning a serialized .NET business object or even worse a dataset makes this service less useable to someone using VB6 to consume it. Yes it is only XML, but have looked at the XML that is spit out in those situations? And the point is to make the service easy to use.

The point of all this rambling is that caution should be used in implementing a service oriented architecture. If integration is not a requirement, then architect the application in the best way to solve the stated business requirement. Don't wrap everything up in a web service unless there is a specific need for a web service. If an integration layer is part of the requirement, then it should architected as that, an integration layer. Don't let the intergration drive to much of tha application architecture or else the original business requirement will suffer. Having a service oriented architecture is worthless if the business processes underneath the services do not accomplish the desired effect.

Posted on Friday, June 18, 2004 12:59 PM Architecture | Back to top

Copyright © Jay Glynn | Powered by: