The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

I have not done any SOA development yet. I’ve just been reading and hearing a lot about it. I’m reading the Enterprise SOA e-book at ACM.org now (my first on SOA; so far it is a very good book) and I just want to share some of my SOA views.

I think the Service Oriented Architecture (SOA) holds great promise. The key word is “holds” because, as of now, I think we mostly have a lot of hype surrounding it. There is too much hype and not too much actual implementation, because SOA has some issues that need to be adressed/resolved. There are certainly bits and pieces actually being developed, but that’s not really service oriented architecture.

The potential of SOA is there. It enables reuse in dimensions never seen before. It enables the usage of different technologies. It gives you the ability to bring old technologies/projects back to life.

What I see happening is that you have a project that provides some functionality that you would like to reuse. Instead of putting this functionality inside your project (as a dependend project) you make it a service. This does not couple you with the project as before. And the project that you are dependent upon has its own life. It can change the DB, it can change the language it is implemented in, and a lot more. One thing that does not change is its public face, the API, the service contract. This really is exciting.

I think there are two very big problems, though. First, the complexity. It is still very complex to actually develop the self standing services. We have so many different techniques, and they do not really like to talk to each other easily. I am still lost in the midst of all the available technologies. I think that’s changing and I hope a clear, easy to develop/understand standard will appear.

The second problem is speed. Calling a service is a network call. In the traditional way, where you have a dependent project, it is a regular function call. The difference in speed in the two is huge, I don’t know the details but I’d guess a service call is at least 100 times slower. To mitigate this issue, good caching is needed. In this case, the service calls would be cached on the client. This way, only the first call for each service parameter values would incur the call expense. Not too bad. Certainly possible. But this just adds more complexity.

SOA promise is certainly there. It will happen. Probably in the next couple of years, in the next decade. There are still major issues with it, as I see it. But the major obstacles in my mind are complexity and speed.

Related Posts