Service Oriented Architecture - Part 1
By Samudra Gupta
Sun Corporation
Introduction
In recent times, more and more organizations are implementing IT systems across different departments. The challenge is to find a solution that is extendible, flexible and fits well with the existing legacy systems. Replacing legacy systems to cope with the new architecture is not only costly but also introduces risk of malfunctioning. In this context, the traditional software architectures proves ineffective in providing the right level of cost effective and extendible Information systems across the organization boundaries. Service Oriented Architecture (S0A) provides a relatively cheap and more cost-effective solution addressing these problems and challenges. Although, it is not a new concept, with the advent of recent platform-independent programs and platform-neutral data models, SOA needs some fresh attention. In this installment, we will examine the anatomy of a Service Oriented Architecture and develop an understanding of how to implement SOA in an architectural level.
Why do we need SOA?
One important factor in imbibing a new model of Software Architecture is the ever-changing business model. Modern day business constantly needs to adapt to new customer bases. The ability to quickly adapt to the new customer base and new business partners is the key to success. Sharing IT systems with other organizations is a new trend in the business. For example, businesses like online auctions are opening their systems to third party organization in an effort to better reach their customer base. In this context, Service Oriented Architecture offers benefit and cost-effectiveness to the business. The process of adapting to the changing business model is not an easy task. There are many legacy systems, which are difficult to make available to the new business partners. These legacy systems might need to change to support the new business functions and integrate to the newly developed IT systems or integrate to the IT systems of its partners'. The complexity of the whole thing is what makes it a constant challenge to organizations.
Imagine a government department has some legacy Sales Tax management system which interacts with the legacy Trader Management system. Suddenly, the government needs to incorporate a new Green House tax. Now the new Green House Tax system will also interact with the legacy Trader Information system and also affect the existing Sales Tax for the Traders who are paying Green House Tax, In essence, because of the introduction of the new Green House Tax system, both the legacy systems need to be readjusted to deal with the new type of Traders and Tax information. This is costly as all the existing legacy systems will have to be modified and will need to be re-tested.
This sort of complexity scenarios can be resolved by adopting SOA. Services are defined as a set of well-defined interfaces, which are generic in nature. Services also define a schema for the input to be supplied to the Service by its consumer. The inherent nature of SOA is that Services work with an extendible Schema and thereby can cope with various different types of entities that the Service is dealing with. For example, a Customer Management system works with a XML based data passed into it and it is capable of processing any type of Customer without needing to know the difference between a Corporate Customer and a Household Customer. This aspect of SOA resolves the above mentioned complexity scenario without having to change.
Essentially, Services operate as an independent entity. An Organizational IT system is composed of a collection of Services. Each of these Services can evolve and change in its own right.
Another example might be, a bank. Imagine that several areas of banking applications will deal with the current balance of an existing customer. More than often, the “get current balance” functionality is repeated in various application softwares written within a banking environment. This gives rise to a redundant programming scenario. The focus should be towards finding this sort of common, reusable functionality and implement them as a service, so that all banking applications can reuse the service as and when necessary.
We have briefly discussed the case for SOA. We have seen that SOA is mostly driven by the business model of an organization. The real benefit lies in the reduced cost to fit into changing and reusable business model. Now let us try to define what do we mean by a “Service”.
What is a Service?
A Service is an implementation of a well-defined business functionality that operates independent of the state of any other Service defined within the system. Services have a well- defined set of interfaces and operate through a pre-defined contract between the client of the Service and the Service itself.
A Service can be of various nature. A Business service may mean “getAccountBalance”. A business Transaction Service may mean something like “makeCreditCardPayment”. A system Service may offer some operations like “deleteAFile”.
In Service Oriented Architecture, the system operates as a collection of services. Each Service may interact with various other Services to accomplish a certain task. The operation of one Service might be a combination of several low level functions. In that case, these low level functions are NOT considered Services.
How to Identify Services
Technically, you can make any piece of functionality as a Service, but doing so will make the organizational IT systems cluttered and complicated to maintain. The advantage is in keeping the Services as a set of well-organized functionalities. Services must represent a tangible Business concept. For example, getAccountBalance() is a tangible business process but convertStringToNumber() is not an identifiable business concept and therefore is not a candidate for a Service.
The process of identifying potential Services is by no means an easy task. At this stage, I have seen many organizations get carried away by the available technologies forgetting that the technology should not drive the Business. Although, identifying Services is a series of organization-wide analysis, certain analysis patterns can be applied to find out the potential services. Here are some things to consider when deciding.
Analyses a certain part of the organizational business process and decompose them into several smaller business process. For example, Order Processing System of an organization can be decomposed into smaller business processes such as checkInventory(), processPayment(), updateInventory() etc.
Identify if any of the smaller business processes are re- used or can potentially be reused in other organizational business process. For example, checkInventory() can also be used by the Stock Management application within the organization. The reusable business processes are strong candidates for operating as Services.
Draft the required inputs to these business processes and define what the specific outputs they must produce. Attention must be paid to keep these inputs and outputs generic so that the Service remains reusable and are capable of providing Service to changing business models. For example, processPayment() service at present might only accept check payment but should be flexible enough to support Card payment in order to support changing business needs. Hence, the input to the processPayment() Service must be defined in a generic fashion. We will discuss more about Service Specification in part 2 of this article.
Identify, if these Business processes are already implemented as an IT system within the organization. If yes, then analyses the Business critical factor for all the existing applications to identify which ones need to be converted to SOA. For example, if a clothes retailer no longer accepts refund/exchange of goods, we do not need to consider to look into Refund/Exchange application.
Identify, what Services operate together, what are the dependencies between various Services.
Find out, if the Services will be used only internally or will be opened to external consumers also. This will have impact on the definition of the Services.
Identify, whether the Services operate in a synchronous or asynchronous manner. What is the permissible response time for the Services?
These are guidelines from my experience in working in the industry with quite a few organizations, where we successfully provided SOA based solutions. By no means is this list complete and I do not believe that there can ever be a complete set of formulas for identifying the correct set and subset of Services to be implemented. It is always an ongoing process as new requirements keep on coming in. But the gist of the story is that one needs great attention to identify the sets of Services that are to be deployed within the organization.
Technology and Patience
I know I talk a lot about the background here, but, one thing I have learned from my mistakes is not to rush into technology. In order to be effective in our execution we must correctly identify the Business processes and the Business requirements. Only then can we make a decision on what technology will work best. Then, we draw a set of Service specifications. We measure the specifications against the infrastructural constraints of the organization in concern. A simple case may be that if most of the IT application in a specific organization is already written using Visual Basic, then we need to pause before we propose a Java based solution. Remember, any technology is capable of producing a Business solution and switching technology means extra costs, which may need to be justified. So please be patient until next part of this article, where we take a step towards the technology.
Conclusion
In the first part of this series, we have layed out a case for the Service Oriented Architecture, defined what Service actually means and discussed few guidelines about identifying Services. We have also warned about the danger in rushing to technology too early in the process of SOA implementation. In the next part of this article, we will talk about the Service specification and take a step towards available lava based technologies to implement Service Oriented Architecture.
Next month, we will talk about Service Specification and available technology and in the final part, we will discuss the most popular technology for SOA—Web Services.
?
?
?
?
Service Oriented Architecture - Part 2
By Samudra Gupta
Introduction
In part 1 of this article, we analyzed the need for Service Oriented Architecture (SOA) in today's ever changing business model. Experience shows that before we decide on a technology, careful thinking and analysis is required to arrive at the correct level of granularity and appropriate Service definitions. Development teams need to be focused on what we are trying to achieve and adapting any one technology does not guarantee success in achieving the goal. We outlined a few general guidelines in the analysis stage of the process and laid out a path for identifying Services. In part 2, we will concentrate more on the technical aspects of Service Oriented Architecture and finally will reach a framework for implementing Service Oriented Architecture.
The SOA objectives
Technically, the foremost concept to understand is what we are trying to achieve with SOA. At the very bottom, SOA relies on basic units of application software, which automates one or more pre-defined business processes. In a simplistic scenario, the goal is to make these basic application units accessible to the client and also for these basic application units to talk to each other in a technology-neutral manner. In a more complex scenario, the goal is to sustain these basic application components and just change the underlying technology for improved efficiency. For example, one organization might have a CustomerManagement?application component. The component offers some Services and the Insurance Department and the Marketing Department of the organization make use of the CustomerManagement. Now for improved efficiency, we must be able to migrate the CustomerManagement component to EJB without affecting the client of this component or event, we should be able to convert this component to a .NET component even though the client to this component is written using a different technology, Java per say.
Keeping these issues in mind, implementing SOA demands the following features:
Technology Independence: The Consumer of a Service component is completely independent of the technology of the Provider component and vice-versa.
Life-cycle Independence: Each of the Provider and Consumer Service components should be able to operate in a separate life- cycle.
Loose Coupling: The Service Consumer Component must define its specification independent of the Service Provider Component. The responsibility of aligning the two specifications is up to the Assembler component, which bridges the gap between two worlds.
Invokable interfaces: The Service interfaces must be invokable either locally or remotely. At the architecture level, we don’t really care how the interface is invoked.
Communication Protocol: A Service must be invokable by variety of protocol. The choice of protocol must not restrict the behavior of the Service. Binding to a specific protocol must take place at run-time/deployment-time, and not at the design or development time.
How to arrive at such solution
In the Part 1 of this series, we have defined Services as software application units that provide a distinct and atomic business process. Services do operate independent of the technology involved in the Consumer and the Service provider itself.
Although it is a new and novel concept to introduce the inter- operability of application units in a technology neutral way, the basic building of SOA relies on some of the proven methodologies such as Component Based Development. The Components do exist as the basic unit of the application performing a certain business operation itself or by collaborating with other components. What is unique to the SOA is how these components are invoked and also how the components interact with each other.
In my opinion, having a sound Component based design helps any organization to newly implement or even migrate towards SOA in a smooth transition. In the following sections, we will elaborate on the concepts of Component Based Development and how it can be used alongside Service Oriented Architecture (SOA). Often we use the term SOA and Web Service interchangeably, which is not strictly correct. Web Service is one implementation of SOA wherein SOA really means a set of technology, which enables us to develop business functions as Components which can be invoked and used in a technology independent fashion.
The Process
In the previous article of this series, we have outlined guidelines on identifying the reusable business processes across the organizations boundary. The outcome of this process can lead to the basic building blocks or Components that co-exist within an organization and perform one or more business operations.
Component Specification: In a technology neutral way like UML define the business functions. This must be technology independent. This just specifies what the interfaces are that the Component offers and what the Component dependencies are.
Interface Definition: Translation of the Functional Specification in a target platform language in a technology neutral way. For example, the interfaces can be elaborated using UML and translated into a programming language of choice such as Java.
Service Specification: Subscribing to 1..* functional interfaces. Services can collate multiple Component interfaces to provide a coarse-grained Service Definition. Again, this needs to be technology neutral.
Service Discovery and Registry: A mechanism for Registering Services to a registry. The Consumers use a Service Discovery mechanism and access the Services by looking up in the registry.
Technology binding: Consumer Components are inherently technology independent. We need to plug-in a technology binding mechanism to use a certain kind of interface exposed by the Service provider and its runtime instance technology. For example, we need to plug-in a technology layer into the Service Consumer to access a Service by using EJB or by using Web Service mechanism as is appropriate. We will elaborate on this later in this article.
The following small example will clear the clouds. Let us assume that in a company we are to write a Payroll Management System which manages the Employee payroll records and posts the pay- slips to their home addresses using the Address manager component. Also there is another Component which looks after the employee welfare and sends out a gift check on the anniversary or birthdays of employees.
The component specification of the above components can be shown as in Figure-1.
Figure-1 The Component Specification
Let us consider that we might want to offer a Service at a higher level called the EmployeeService which can subscribe to both the Payroll Management and Welfare Management interfaces. The Service Definition for the EmployeeService might look like the following in Figure-2.
Figure-2 The Service Specification
The interface definitions are still technology independent but can be translated in to a specific programming language such as Java. For example, the interface definition for the EmployeeService can look like the following in Java (Listing - 1). We have omitted the data type references from the diagram for simplicity
public interface IEmployeeManger {
?? void sendPayslip(IEmployee employee, IDocument payslip)
?????????????????
?????? throws EmployeeNotFoundException,
ServiceUnavailableException;
?
?? void sendGiftCheck(IEmployee employee, IDocument check) throw
?EmployeeNotFoundException,ServiceUnavailableException;
}
?
Listing-1 the interface definition(there were two line breaks added to make it fit the page)
Note: The Exceptions listed above are very much application specific exceptions and avoid any technology specific exceptions.
The Glues
So far we have defined the EmployeeService and its interfaces. We have seen that this interface definition is totally technology neutral. However, at deployment time we may decide to one or more instances of this Service supporting different communication protocol. There is no restriction that the same Service cannot offer more than one invocation protocol. Rather, in different situations it is more appropriate to offer multiple protocol support to provide service to different Consumers.
So far we had the Consumer component and the Service Component being specified and implemented in isolation. But there must be something in the middle to glue these two together. We discuss the missing bits as follows:
Technology
In OO concept, the great thing about interface concept is that multiple implementations of the same interface can co-exist. Binding to any particular implementation can happen at run-time or compile-time. Dynamic binding at runtime offers greater flexibility to switch between implementations based on context. For example, an AddressManager Component can be invoked remotely using Web Service based on XML-SOAP protocol or also can be invoked as a Pure Java component or EJB when it is invoked locally.
It is a good design pattern to separate the technology layer form the actual business logic and business operations. The business operations can be implemented as a standard Java class. The technology layer is solely responsible to implement the technology logic and infrastructural service calls. For example, in EJB technology, the technology layer will consist of the EJBs, which will interact with the container to manage transactions etc. However, the actual business logic may be delegated to another standard Java class.
Service Discovery and Registry
When a Service interface is implemented using a specific technology, the Service needs to publish itself to a registry for the Consumers to lookup and use the Service. This is implemented as another separate layer called Service Access Layer. This layer is responsible for looking up Services using certain lookup mechanism. For an EJB, this layer might perform a JNDI lookup and for Web Service this layer might use a Web Service Registry lookup.
Where Happens the Mapping
So far we have said that the Service consumer and the Service provider specification are independent of each other. This also meant that the data represented in both these domains can also be different. So there needs to be a mechanism to align these two worlds. An ideal place for this mapping to happen is the Service Access Layer. This layer can receive the data object from the Service consumer and then use the Service provider Transfer object to map data. Also this layer can convert any Exceptions generated into an appropriate one that is understood and defined in the Service consumer specification.
Who Implements the Layers, the Responsibilities
We have seen that layering the application based on separation of concern is a good way to achieve the loose-coupling between the Service consumer and the Service provider. We have identified the layers within Components carrying out different roles and responsibilities. Looking at the full picture, we can thus assign the responsibilities to the Service consumer and to the Service Provider.
Figure 3 The overall picture
The Service Provider component is responsible for providing all the above mentioned layers. A mistake often made is to make the Service Access layer as part of the Consumer, which creates a tight-coupling between the Consumer and the Provider in terms of technology.
Conclusion
In this article, we have examined the technical aspects of the Service Oriented Architecture (SOA) and its root in Component Based Development (CBD). One of the biggest mistakes in the world of SOA is that they are identified with Web Services. But it is to be stressed that Web Service is one form of SOA. If we do not design our Components carefully, we will end-up with a solution which is tightly coupled with Web Services technology. In the future, it will then be a big change to move towards another technology such as Web Service. This sort of situation defies the very basic goal of SOA that we should be able to write Consumer and Provider Components irrespective of technology used in either of them.
In the next part of this series, we will develop a Web service example based on the Component concept discussed in there. Please feel free to discuss and let me know your ideas on this. Thanks.
Benoy Jose is a web developer with over six years of experience in J2EE and Microsoft technologies. He is a Sun Certified programmer and enjoys writing technical and non-technical articles for various magazines.