SOA What, Why, Constraints?
What is SOA?
SOA is the acronym for Service Oriented Architecture. It is an architectural design pattern by which several guiding principles determine the nature of the design.
SOA states that every component of a system should be a service, and the system should be composed of several loosely-coupled services. In this context,
- A service is a unit of a program that serves a business process.
- A loosely-coupled service means that these services should be independent of each other, so that a change in one of them should not affect any other services.
Therefore, SOA is neither a specific technology, nor a specific language.
SOA is just a blueprint, or a system design approach.
SOA is an architecture model that aims to enhance the efficiency, agility, and productivity of an enterprise system.
The key concepts of SOA are services, high interoperability and loose coupling.
Without SOA, every application is a bundled, tightly coupled solution. The client-side application is often compiled and deployed along with the server-side applications, making it impossible to quickly change anything on the server side.
Now, with SOA, the remote objects are truly treated as remote objects. The client applications are no longer objects; they are services.
In SOA, client application is unaware of how the service is implemented, or of the signature that should be used when interacting with those services. The client application interacts with these services by exchanging messages.
Let us elaborate in a practical scenario; say an organization have many different applications, such as order management systems, accounts receivable systems, and customer relationship management systems. Each application has been designed and developed by different people using different tools and technologies at different times, and to serve different purposes.
Now there may be no standard common ways to communicate. In this scenario, traditionally EAI is used. Enterprise Application Integration (EAI) is the process of linking these applications and others in order to realize financial and operational competitive advantages.
But there is a difference in EAI and SOA, EAI attempts to connect legacy applications without modifying any of the applications, while SOA is a fresh approach to solve the same problem.Why SOA?
Question arises that why do we need SOA?
The answer is in one word, agility.
Business process is a dynamic process. Thus it requires a change frequently. The IT department has to respond more quickly and cost-effectively to those changes. In a traditional architecture, all components are bundled together with each other. Thus, even a small change to one component requires a change in a number of other components. Those components are to be recompiled and redeployed. Quality assurance (QA) effort is also huge for any code changes. The processes of gathering requirements, designing, development, QA, and deployment are too long for businesses to wait for, and become actual bottlenecks.
Basic unit of SOA is a service. These services are building blocks that business users can use to define their own processes. Services are designed and implemented in a way so that they can serve different purposes or processes, and not just specific ones.
In SOA services are also designed and implemented so that they are loosely coupled, and independent of one another. A change to one service does not affect any other service. Also, the deployment of a new service does not affect any existing service. This greatly eases release management and makes agility possible.
What are constraints in implementing SOA?
There are three key elements or constraints, what have to be evaluated to implement SOA. The constraints are:
- People
People in the organization must be ready to adopt SOA. - Process
- Organization must know the processes that the SOA approach will include, including the definition, scope, and priority
- Technology
Organization should choose the right technology to implement it
It is always people and processes take precedence over technology in an SOA implementation.
There are many SOA approaches. At certain degrees, traditional technologies such as CORBA, RPC, DCOM, or some modern technologies like IBM Web Sphere MQ, Java RMI, and .NET Remoting could all be categorized as service-oriented, and can be used to implement SOA for one organization.
But all of these technologies have limitations, such as language or platform specifications, complexity of implementation, or the ability to support binary transports only. But there is a problem with these approaches is that the server-side applications are tightly coupled with the client-side applications, which is against the SOA principle.
With the emergence of web service technologies, SOA becomes a reality. Further due to an increase in network bandwidth, and given the maturity of web service standards such as WS-Security, and WS-Atomic Transaction, an SOA back-end can now be implemented as a real system.
|