Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Service Oriented Architecture (SOA) was one of the emerging buzz-phrases of 2003. This article provides you with a quick look at the principles behind SOA and the benefits it gives you so you can begin an analysis of whether or not SOA is in your future.
SOA is linked to the concept of Web services. Web services can be thought of as a consumer-provider relationship on the Web. The Web service consumer makes a request to the provider and the provider responds. In most instances on the Web now, Web services are accomplished through XML. Each service provider publishes a definition of the service that includes (among other things) the necessary input and provided output for the service to work.
At its simplest, SOA is just designing your architecture to best work in a Web service environment, based on the consumer-provider model. The key to a true SOA approach is separating the services layer of the architecture completely from the other layers of the architecture. The services layer sits between the consumer and the business objects that the provider gives access to, so that the consumer isn’t interfacing directly with the business objects.
The practical effect of this service layer separation is that the consumer doesn’t need to know any details of the business objects. For example, the consumer doesn’t need to know the language the business logic is written in. The service definition is provided in XML and the consumer interacts with the XML, not with the underlying business language or database.
There are many immediate benefits from this abstraction layer including that any consumer who can work with XML (and that essentially means any business today) can work with your service, not just those who work with your language. Another benefit is that, as you make adjustments to your business logic, those can be transparent to anyone consuming your service.
The absolute core requirement to make a service-oriented architecture work is to attain true separation of this services layer from any other layer. The services layer needs to be the “black-box:” As long as the consumer provides the right XML input, they don’t need to know anything about your business objects, server, or language to get the right output. And, conversely, the output you provide should be completely independent of the presentation layer. Your consumers need to be able to use your output on any platform that supports the XML.
With this brief SOA definition in hand, you should now be ready to read more technical details about SOA. Here are a few good articles to start with:
And, it’s important to know that SOA is not a new concept. But, as Web services gain momentum, particularly as Sun, Microsoft, IBM, and other industry giants tout Web services, SOA is a natural extension of their push. You can read what each of these vendors has to say about service oriented architecture, with tie-ins to their own specific visions centered around their platforms of course at:
- Microsoft: Secure, Reliable, Transacted Web Services: Architecture and Composition
- IBM: Migrating to a service-oriented architecture, Part 1
Jim Minatel is a freelance writer for Developer.com in addition to working with Wiley and WROX publishing.
# # #
