Recently, a SOA blogger (
www.service-architecture.blogspot.com) asked his readers to post a definition of SOA without using the words Service, Oriented or Architecture. Not too many people responded. The blogger himself wrote, “Its (sic) a way of modelling (sic)
what a business does, then understanding
who it works with and
why the business works with those external parties and the different parts of itself.” Another respondent, quoting from ZapThink, wrote “An approach to organizing IT resources to better meet the changing needs of the business.” As you can see defining SOA is difficult, even by professionals in the industry.
Benefits
But while questions linger on how to exactly describe SOA, or even how to create a set of best practices, there are tangibles associated. The benefits of working in SOA are widely documented. Let us spend some time reviewing the benefits of this architectural design plan and deployment methodology. In Part 2, we’ll look at some of its challenges.
- Quick Creation and Deployment of New Applications
-
This means there is no need to reinvent the wheel. For example, there is already an order processing system in place taking orders for books. Tomorrow, the company is going to add a new line of business. The company can use the same order processing system for the new product line.
- SOA Adapters
-
Adapters place a SOA layer/wrapper on top of a legacy system. Perhaps you have an old Windows System communicating with a new Windows System. They may speak different languages. With SOA adapters you have an intermediary that speaks both languages and helps process requests.
- It is Platform Agnostic
-
All type of technologies can speak to one another. Let's say the client is using a Windows application, but your order processing is a SOA-flavored UNIX application – it does not matter. All of these technologies are allowed to communicate in this architecture.
- Transparent Replacement
-
If something needs to be replaced it does not affect all of the components' modularity. The service provider can be fixed or changed without changing the client. Most of the time, there might be a need to make minor modification at the client side. In theory you can replace them without touching rest of the system. For example, maybe you do not like Google's service - switch to Yahoo (this is an example where client side may need some modification). Or, perhaps there is a major bug that needs to be fixed in the order processing system (this is an example where the client side may not need any change).
Look for part 2 in our next edition...