The Service Architecture

  • The Service Architecture

    I've seen a lot of writing the last few months on the services, or SOA, architecture from various sources. Actually I've seen a lot written about it before then, but I've tended to dismiss it as buzzword hype. Just another way to develop applications that's really not much different from the way things were done before.

    But as I dig into it more, I think I may have been a touch hasty. This interview with Amazon's CTO is very interesting in how Amazon has developed their systems. From the interview, apparently the "gateway page" for Amazon, which I'm assuming is the home page, his between 100 and 150 services to construct the page. Since that page has grown more and more complicated, I can believe it, but still that's a lot of calls with the volume of hits that it must get.

    I like the philosophy at Amazon, in that the model is for various components to provide services for consumption and keep the data behind a "hardened interface". They also seem to do whatever works, not worrying about using a particular technology or methodology. In fact they make teams responsible for their service and as long as they can ensure the service is available, they are getting the job done.

    And they seem to view the application as the thing that needs to be available, not the OS, the network, the middleware, or anything else. It's a philosophy that works well in principle as long as the individuals responsible for maintaining it don't build systems that cannot evolve.

    SQL Server 2005, with the Service Broker built in, seems to be tailored to bringing this type of functionality to other systems. The trick is doing it securely and maintaining the "hardened interface" when the database is responsible for so many things.

    Steve Jones

  • Yeah SOA is great. It seems like it is most fitting in a fairly large scale though, as it adds layers of complexity and infrastructure.

    Hopefully WS/SOA will get a little more commoditized soon which will allow it to be used on smaller scale projects.

     

  • In theory it all makes a lot of sense, but I believe that in practice it may only be worth the effort for large organisations that have a very clear single core business.

    SOA assumes a very strong central IT architecture for the major services, and the authority to enforce its use. With the constant merger and acquisition activity, newly acquired outfits may need a lot of work to integrate with a different SOA.

    It will be interesting to see how the companies that are currently investing in heavyweight SOA will handle new versions or even new business models. That's when we will see how robust and versatile it all is.

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply