SOA stands for Service Oriented Architecture whose goal is to achieve loose coupling between components in web services. What does this mean, loose coupling, how does it symbolize re-usability in advance.
Suppose you go to a restaurant and place your order, suppose to the waiter, then waiter will note it and present it to the cookers in the kitchen, or the procedure may be slightly different if you place the order to the counter after paying the bill where in this case counter will notify cookers or waiters about the requirement and after a while waiter will ask you to come and get your order. What is the scenario behind these two approaches. The ways you order the foods may be different but result will be same though your procedure differs.
What is the relationship with above scenario with SOA. Before going to that, first understand the actors and methodologies in above situation. The service is what you get from the restaurant and you are consumer while restaurant becomes the service provider.
When you go to pay the bill, you can pay it using your credit card or what ever paying methodologies. If restaurant is kind of a big one, then they might have such stuff. When they are going to hire you, they have to make a connection with other existing systems for the purpose of hiring in your credit card but which are out of its (restaurant) scope. So they are asking another service from another external system and after moving few successful steps, you will be returned your card. Above is a practical scenario where services are integrated with each other as a working set and executed one by one.
I have illustrated general architecture of SOA in below diagram
When comparing this architecture with above example, you can see the SOA work flow as a genera services such as serving foods, billing payments, placing orders and etc. So in SOA services are something like the classes you write using programming languages such as java, .NET or CORBA in which functions are written to fulfill tasks when they are invoked. Those functions implies the services i mentioned above.
Service Broker is something like tiering services to form a process. When you want to make an order, you have to call for a waiter, whose task is to assign it to a cooker, simply aware the person who is responsible for relevant duty. So there you know you must tell it to waiter and waiter knows he must tell it to cooker likewise having read the work flow, services are taken from SOA registry and ties them all together. This is the task of service broker.
SOA supervisor is some one who is responsible for ensuring that services do not have any issues. It simply deals with performance issues, think when you place an order but it takes too much time to serve, then these type of failures can be handled by SOA supervisor.
Now i will show you the real time definitions of above major components of SOA architecture.
- SOA Registry
is like a reference database of services. It describes what each services do, where are they located and how can they communicate. It’s a central reference of meta-data for services.
- SOA Service Broker
reads the work flow and takes services from the SOA registry and ties them together. Service brokers are normally middleware like EAI (Enterprise application Integration) products. You can get a list of decent EAI from Sun, Microsoft, and IBM etc.
- SOA Work Flow
allows us to define work flow using the services in SOA registry. We will read more about BPM in the further questions.
Why we use SOA.
You want to play a VCD, what you do is insert it into VCD rom and watch it, what else you can do . You can insert it into your VCD player at home or in your car too instead of insert in it into your computer VCD rom. Right. Where ever you insert it, you can still play the songs and watch the video. All the ways you use will provide you the same video hearing and watching capabilities, but meanwhile there may be some issues in QoS. Anyway how simple it is, isn’t it. But in real world, OO concept role is vey miserable though . So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems.
Concept is why we use some one else to do our tasks, it is because they are experts. Consuming a service is usually cheaper and more effective than doing the work ourselves. Most of us are smart enough to realize that we are not smart enough to be expert in everything. The same rule applies to building software systems.
How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints:
A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.
Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.
Just think about power adapters which you have to carry with you when yo are moving from place to place. It is because you know that when you are in somewhere else, you have to plug it to the correct outlet as there are many of varying sizes and shapes of plugs in different countries. What can you do to over come this problem which is known as a artificial dependency.
Interfaces are required to use things we use for fulfilling day to day stuff. When there are multiple interfaces, it is hard to adapt in order to suite them all. An interface needs to prescribe system behavior, and this is very difficult to implement correctly across different platforms and languages. Remote interfaces are also the slowest part of most distributed applications. Instead of building new interfaces for each application, it makes sense to reuse a few generic ones for all applications.
Since it is used few generic interfaces, we have to specify application specific semantics in messages. We can send any kind of message over our interface without considering its contents. That is what WSDL does in web services. It exposes your published service to others through WSDL (XML file) which allows all of others to read it as it is common for any one in anywhere in the world (predefined standard). But there are a few rules to follow before we can say that an architecture is service oriented.
First, the messages must be descriptive, rather than instructive, because the service provider is responsible for solving the problem. This is like going to a restaurant: you tell your waiter what you would like to order and your preferences but you don't tell their cook how to cook your dish step by step.
Second, service providers will be unable to understand your request if your messages are not written in a format, structure, and vocabulary that is understood by all parties. Limiting the vocabulary and structure of messages is a necessity for any efficient communication. The more restricted a message is, the easier it is to understand the message, although it comes at the expense of reduced extensibility.
Third,extensibility is vitally important. It is not difficult to understand why. The world is an ever-changing place and so is any environment in which a software system lives. Those changes demand corresponding changes in the software system, service consumers, providers, and the messages they exchange. If messages are not extensible, consumers and providers will be locked into one particular version of a service. Despite the importance of extensibility, it has been traditionally overlooked. At best, it was regarded simply as a good practice rather than something fundamental. Restriction and extensibility are deeply entwined. You need both, and increasing one comes at the expense of reducing the other. The trick is to have a right balance.
Fourth, an SOA must have a mechanism that enables a consumer to discover a service provider under the context of a service sought by the consumer. The mechanism can be really flexible, and it does not have to be a centralized registry.
Now it is better us to move to the aspect of theory in SOA. SOA stands for three terminologies
- Contract (WHAT) – SOAP
This is an kind of agreement between two or mor partiesTechnically it defines parameters and return values for a method
- Address (WHERE) – UDDI
Indicates where we can find the services, if you can remember above diagram, there is a registry called SOA registry which stors all ervices in it, so that consumers can get services from it.
- Binding (HOW) – WSDL
How others can communicate with your services. SOA services should be able to describe themselves. ‘WSDL’ determines ‘how’ can access the services.