SOA What?
In short, Service-oriented Architecture, SOA is a set of architectural guidelines and design concepts for distributed system. It introduces the idea of wrapping a system's functionalities into groups of components. These components will be treated as groups of resources. Once discovered and consumed, these components can then provide sevices and deliver business values to consumers (users). SOA does not apply only to software, but an entire IT system. Planning and designing processes for supporting infrastructure must be included since the early stage of development life cycle.
Some important ground rules
- Service components are reusable, regardless of platform the system is implemented
- Service components are highly modularized
- Service-oriented system maintains compliance to both common and industry-specific standards
- Service components are highly-discoverable resources on network
These ground rules are abstract guiding principles that define high-level characteristic of service-oriented system. I will discuss them further and providing technical details in the next entries.
Service, service, and more services!
So, what the heck is this "service" I'm talking about? Is it just a function in an application? Or is it all of functions available in the system? IMHO, the easiest way to wrap your mind around the concept of service is to think of it as a unit of work in a business process. Now, if you look at a business process as something that, upon completion, will output result. You can then think of each of a business process's services as specific tasks required to deliver that end result. For example, if you are building an airline system and one of your business process is to allow customers to purchase tickets online. Then "verifying flight", "check seats availability", "book seats", "verify credit card" would be examples of services.
Well, things like reusability and modularization don't sound like something new to me, why is there such a big buzz about it ?
It's true that concepts of modularized, resulable, highly encapsulated components/objects have been around for decades, since inception of Object-oriented architecture (OOA). On the surface, some would be misled to think of SOA as a replacement for OOA. Actually, SOA can be considered an architectural evolution rather than a revolution of previous IT system patterns and best practies. Another point to note is that SOA focuses on high-level design of the system while OOA is most often applied to application design.
There are quite a lot of good reasons why SOA has generated such a big buzz in the industry. First, SOA offers solutions to decades-old problems. One is that services being consumable cross-platform. Ideally, if you adopt and apply service-oriented design principles, your service components can be consumed by clients from other platforms.
Another benefits of SOA can be agility and flexibility it can bring to enterprise IT system. It's quite common to see large scale system becomes monolithic and highly complex from adding layers upon layers of dependencies. At the heart of SOA is well-designed service components. Dependencies between components are minimized. Scope and boundary of services are explicit. Each service is highly autonomous. System administrators and developers can then build a system and business workflow by composing these components together. Moreover, if there is a change in business process, rule, or a need for an extended functionality, only directly related service components would be affected. As long as you keep service interfaces consistent, the rest of the system would continue to work. Maintenance cost can be reduced greatly. In short, being agile, any changes to a business process can be implemented and deployed in a timely manner. Being flexible, you can roll out new features or modify process and workflow behavior with ease.
Yeah now I get it. But why should I care?
As an IT manager, CIO
Theoretically, SOA can greatly reduce cost and increase return on IT investment. Migrating your existing system to SOA isn't an easy task. Apart from additional investment, you will need to understand that adopting SOA is not like buying a product, it's rather like embracing a shift in paradigm. There has been widespread adoption of SOA around the world. Various approaches are taken by major players in the IT industry to get a foothold on SOA bandwagon. Oracle and BEA integrate SOA into their development tools, like JDeveloper, Oracle SOA 10g Suite, and BEA AquaLogic. Microsoft, though the late comer, introduced Windows Communication Foundation (WCF) to its .NET stacks. Sun would educate customers, help them understand SOA, then move onto development frameworks.
As a system architect and admin
Although service-oriented system would still look pretty much like N-Tier system, designing additional layers can be quite a challenge. Some activites are decomposing business process, building domain model, integrating additional application layers, and extending existing system infrastructure. Another important area of concern would be the security.
SOA, in its nature, rely heavily on remoting and messaging protocols, XML, and on-the-wire communication. You will also need to understand web services protocols like WS-*, REST, and other industry standards. Int is also important to really understand value of SOA, what kind of problems it can solve, and scenarios that it would be better to apply other technologies. I will come backt o discuss this topic in detail in the next entries.
As a developer and student
A whole slew of cool things to learn from web services, WSDL, SOAP, messaging protocols, industry standards, BPEL, and other vendor specific implementation detail. Technical things aside, under SOA development methodologies, developers would become more involved in the bueiness side. You will have to understand business domain and requirements, security model of the enterprise, policies and rules. For students, make sure you take a course on UML and information system design =).
This entry focuses on introduction to the concept of SOA and why it matters from a very abstract view. In the upcoming entries, I will discuss more specific patterns and anti-patterns of developing service-oriented system.
