Figure 1 - Link
An Approach to Service Oriented Architecture the foundation for any application architecture that should be considered today is going to be of a service oriented or (SOA) based. Figure 1 Service Oriented Architecture consumed by a User Interface Layer Service orientation is about four aspects, as shown above – where is the service (example are URL of the web service, how do you bind with it (what protocol – HTTP etc) and what contract (request response, one way etc.) and what behaviour (is the communication transactional or reliable usually in the metadata of the message) and the message that is expecting at a very high level. A corresponding client side proxy will abstract the UI layer (as an example) from knowing how to communicate with the business layer.
The client side service agent creates an instance of the server side proxy or the API layer object in this case and will pass the message the API layer request of it. Any response that it will pass to the client side proxy is then passed back to the UI layer. A Service Oriented Architecture (SOA) is a form of distributed systems architecture that is typically characterized by the following properties: Logical view: The service is an abstracted, logical view of actual programs, databases, business processes, etc., defined in terms of what it does, typically carrying out a business-level operation. Message orientation: The service is formally defined in terms of the messages exchanged between provider agents and requester agents, and not the properties of the agents themselves. The internal structure of an agent, including features such as its implementation language, process structure and even database structure, are deliberately abstracted away in the SOA: using the SOA discipline one does not and should not need to know how an agent implementing a service is constructed. A key benefit of this concerns so-called legacy systems is the customized code that was invested that truly made the business unique and compelling to the marketplace - ROEI is a new term that is increasing popular to reflect this - Return on Existing Investments for those of you not familiar with this term.
By avoiding any knowledge of the internal structure of an agent, one can incorporate any software component or application that can be "wrapped" in message handling code that allows it to adhere to the formal service definition. Description orientation: A service is described by machine-processable meta data. The description supports the public nature of the SOA: only those details that are exposed to the public and important for the use of the service should be included in the description. The semantics of a service should be documented, either directly or indirectly, by its description. Granularity: Services tend to use a small number of operations with relatively large and complex messages. Network orientation: Services tend to be oriented toward use over a network, though this is not an absolute requirement. Platform neutral: Messages are sent in a platform-neutral, standardized format delivered through the interfaces. XML is the most obvious format that meets this constraint The Figure depicts how each business component will be exposed by a services API layer that will act as a server side proxy to any client that will consume the tracking service. Services are coarse grained and are message based. The tracking service interface layer will in effect abstract who the consumer of these services are. Any other application that would need to call Tracking services for example from their application layer will simply create their own service agent and instantiate an instance of this service API layer. Note the separation of the user interface layer with a service agent present in the UI layer.
At the application layer the tracking service business components themselves access data by two means: · Data agents which access stored procedures from a database – in this case a tracking database · Service agents which access various web services or service APIs that provide data · If needed a message broker (message bus) EAI model may be used here if a business has such technology available in the future. This will avoid point to point connections from various middle tier services and create a more manageable application. Service Agents and its importance in SOA Business components are the engines of applications because they contain the logic to make the application work. In addition, business components know where to find information, whether it comes from a back-end database or from an external data source. In classic Windows-based n-tier architecture, we are used to thinking of business components as self-sufficient. But sometimes business components need to retrieve information from external sources in order to do their work. In SOA terms, sometimes business components need to call external services. The service agent is responsible for managing communications between a business object and an external service.
Service agents are extremely important because they simplify the amount of work that a business object has to do when it needs to use an external service. A service agent is a locally installed assembly that provides a well-known interface to the business object. Service agents do the manual legwork of communicating with external services and implementing whatever infrastructure is required to do so. This is useful for two important reasons: Business objects do not have to implement the infrastructure that is required to communicate with an external service. Instead, they communicate their requests to a local assembly (the service agent) using a mutually understood interface. Business objects avoid the maintenance work that is required to keep service interactions up to date. For example, if an external Web service interface changes, the service agent takes care of updating its proxy class and reworking the code implementation as needed.
The business object can continue to communicate with the service agent in the same manner, even as the underlying communication details change. A travel analogy to describe the role that service agents play. If you are traveling to India and your friend is fluent in both English and Hindi, but is too lazy to read the guidebook and has no idea what to see in the city. Since you only speak English, but you read the guidebook cover to cover, and you know that the Taj Mahal cannot be missed … if only you knew how to get there from your hotel. So you need to ask directions, but cannot communicate with the locals. Your friend can ask for directions, but needs to know from you where you are trying to go. The analogy is hopefully clear! You are the business component, your friend is the service agent, and the friendly locals act as the external service API.