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

This was discussed at great length at TechEd this year. The one thing that I came away with is that nobody can agree on what the definition should be. Don't get me wrong, I actually think that this is a good thing. SOA should not be a defined, standards based “thing”. Once it reaches that point it will become less useful and more restrictive.

In an earlier post I outlined an architecture that we are using. Some would look at this as being a SOA based architecture, a viewpoint that I tend to agree with. Some would say that SOA can only be based on web services. That adds the restriction that doesn't need to be there. At this stage of the game SOA should be looked at as more of a style of architecture then as an actual implementation.

Another topic of discussion during the week is do you design in SOA from the start on all of your systems. My answer is absolutely not! The architecture I referred to before was created based on a business model that I knew already existed. There were integration issues already present. SOA's strength (and main purpose) is integration. If the system that your developing has no plans or needs for integration, then it probably will not benefit you to implement an SOA style of architecture. A classic client-server architecture is still a valid option in many situations. You can still build your logical layers (presentation, business and data access) in a client-server architecture. You can always build the integration (SOA) layer later if and when it is needed. The main reason for this is that the API you would design for SOA would (and should) be different then the API you would normally design for a web or client app. It would be a mistake to make the design of the system suffer for something that you don't know will happen and if it does happen what will the requirements be.

Posted on Wednesday, June 2, 2004 8:41 AM Architecture | Back to top

Copyright © Jay Glynn | Powered by: