In the previous article we discussed some of the challenges and requirements that lead to the evolution of Services-oriented architecture. Here we’ll try to implement a primitive SOA using a very basic scenario and will see how it solved some of the problems which we discussed previously and eventually what further requirements sprung from its implementation.
Before that lets define SOA in most basic terms. A Services-Oriented Architecture
is an architecturewhich is services oriented, simple! But what is architecture and what is a service? Architecture is something (which if you ask some experienced guy would say is very important) which defines different components of a system and how they relate and interact with each other. An architecture gives an overview of the system, ie how it would (or does) look like and what are its constituents, apart from that its purpose is to reduce unused parts of the system and reduce dependencies between components. An architecture which is services-oriented means that the basic building blocks of that architecture are services ie, within this architecture all functions are defined as independent services.
Now, what do we mean by a service?
A service is a well-defined software interface that describes a collection of operations that are invokable. It either provides some information or facilitates a change to business data from one valid and consistent state to another ( ie, perform a business function).
1) Ideally this collection of operations should form either of the three: a business function, a business transaction (a set of business functions with some flow logic between them) or a system function.
2) The interfaces are invokable; that means, at an architectural level, it is irrelevant whether a) they are local (within the system) or remote (external to the immediate system), b) what interconnection scheme or protocol is used to invoke it, or what infrastructure components are required to make the connection.
(Note that we are not talking about web service or enterprise service right now.)
Apart from the above definition, a service should also have certain attributes which are not necessary but are considered good practices(by those experienced guys). These are:
1) A service should be independent and self contained. Lets understand this with an example:
Requestor: What is Bruce’s Checking Account Number?
Provider: X dollars.
Requestor: What is his credit limit?
Provider: ??
The second question by the requestor is notself contained it requires context of its previous request(s). Now a provider may or may not be able to answer such question depending upon whether it maintains states of requestor or not.
Now in the context of a service statelessness means that it should not maintain or rely on states of other services to provide its own service.
2) The binding from the service requester to the service provider should be loosely coupled. This means that the service requester has no knowledge of the technical details of the provider’s implementation, such as the programming language, application platform, and so forth. The service requester should invoke operations by using messages -- a request message and the response message-- rather than through the use of APIs or file formats. ( This would be an important pointer when we’ll define web services)
3) The service’s granularity and the service’s purpose must have some synergy. For example if the service is intended to be consumed from external sources then a coarse grained is recommended; whereas fine-grained interfaces should be used inside the enterprise. This is an important design point which differentiates between an application service and an enterprise service, we will discuss it later.
Note that at this time we are not bothered about whether it is a web service or an enterprise service or something else, we don’t even know what they are.
Lets now try to implement a simple services-oriented architecture for the integration scenario that we discussed previously, here we have existing applications a) built for specific business needs, b) concentrated in functionality, c) on heterogeneous platforms and these d) are not resilient.
All these applications are integrated using interfaces; we want to make this system more flexible to changes and want to add new functionality quickly. So here our approach would be to build services using existing functionalities in a bottom-up fashion (bottom-up means building services first and then orchestrating them into applications and/or business processes).
There are other approaches too to implement SOA, like in a top down manner where business processes are modelled using some tools (like Business Process Platform) and then the services are created to cater them. Other approaches like Data-driven,where services are used only to exchange data between applications, and Message driven, where the purpose is just to have systems integrate, communicate, over standard, non-proprietary protocols, could also be used. We’ll discuss these approaches in different discussion but for now our focus is to build services on existing functionalities in a bottom-up manner.
The first step is breaking down these separate applications into smaller, self contained, reusable and independent (not entirely) pieces and call them services. If the applications are strongly cohesive (within themselves) then first we need to modularize them using object oriented techniques or using some compiler based tools (easier said, but basically we are doomed).
These modules then must now be wrapped with metadata that describes a) interface of the service b) what to expect from this service c) how applications can bind with these services and d) where they will be executed.
So we have several services but if there is large number of invocation of these services then we can end up with an architecture that is fragile and inflexible, if service consumers and providers communicate using point-to-point “spaghetti” style connections. Somehow we need to encapsulate these connections by means of a mediator.
For that lets add the architectural concept of the Service Bus, and a flow manager to connect the services and provide a path for service requests. The Service Bus is not a tool, but an architectural best practice for implementing a service-oriented architecture. It establishes a messaging bus that combines messaging infrastructure with message transformation (assuming that service invocations are message based) and content-based routing in a layer that is between service consumers and providers. The main aim of Service Bus is to provide virtualization of the underlying resources, allowing the business logic to be developed and managed independently of the infrastructure, network, and provision of services. Note that resources in this Service Bus are also modeled as services that offer one or more business operations (this is like a fractal design).We’ll not discuss about this in detail here.
This is our starting point for implementing a services-oriented application framework. (service consumers are not shown in this diagram)
The purpose of flow manager is to process a (already) defined execution sequence, or service flow, that will invoke the required services in the proper sequence to produce the final result. The Business Process Execution Language, or BPEL,(and now BPEL4WS) is an example of such a technology for defining a process as a set of service invocations. The flow manager is responsible for (in technical terms) service choreography or orchestration. Together the service bus and flow manager hides the service invocations, their execution flow and underlying infrastructure from the service request.
Having said that the flow manager processes the defined execution sequence, or service flow, we need some procedure that a) defines what services constitute the application and b) what should be their flow. For this purpose lets add another component to this architecture namely, application configuration. Finally we need one more component to virtualize the input output to the application. The input output should source neutral and in a well defined format (that the application understands). So that, for example, the addition of an Internet connection to a bank application with an already existing ATM access should be transparent to the application logic. That is to say that by virtualizing the input and output, the application is loosely coupled to the external sources that are using it.
Also we need to address some cross-application issues like Quality of services, security etc. For that we have added an application management component to our architecture.
This forms a primitive implementation of services-oriented application architecture. It transforms an application into a service coordinator that represents user functionality and service providers (actual services) that implement the functionality. While the coordinator tends to be unique to a particular application (or a customer or a composite application), a service can be reused and shared by multiple composite applications.
Lets summarize this architecture, the big box is our application formed by orchestrating different services. The application configuration component describes the structure of the application in terms of services and their flow. The I/O processing and control block provides source neutral and format neutral data to the application. The actual flow of service invocations at runtime is managed by the flow manager and the service bus encapsulate the infrastructure that is there to make the actual call to each service in a message-driven (request messages and response messages) manner. The application management block takes care of the horizontal (cross-application) issues like quality of service, authorizations and maintainability. Finally it should be noted that the actual functionality is still provided by the existing or legacy systems.
Now coming back to our services , while defining them we said that a service should be invokable in the sense that it is irrelevant whether a)they are local (within the system) or remote (external to the immediate system), b)what interconnection scheme or protocol is used to invoke it, or what infrastructure components are required to make the connection. Then we said that typically(not necessarily) a service should be invoked using messages rather than through the use of APIs or file formats. There is one problem with these services, there is no standard or should I say there is no open standard, that could be used by any service requestor on any platform to invoke these services. This is where web services come into picture. Also we assumed that the service requestor (or the client application) is aware of the service, however in case where external applications need to be integrated this might not be the case, therefore we need some mechanism to make client application aware of our services. Web services fulfill this criteria as well.
Web services are services (above definition) that are self-describing, areprocessed using messages (note that we are using the term ‘processed’ and not ‘invoked’) and use open standards for their processing.
1) Self-describing: web services expose their metadata (in the form of standard format) that describes a) the service’s purpose b) its interface and c) how it should be invoked.
2) Web services are processed, this includes a) publishing of the service interface b) discovery of service by client applications and c) actual invocation of the service. The publishing and discovery mechanism are there so that the client application be aware of external services.
3) Invoked using messages: Web services are invoked using standard messages in the form of WSDL files. Both the request and the response are in form of these messages.
4) Open standards: Standard is the keyword here. Web services use open internet standards for all their processing (ie, publishing, discovery and binding).These standards are platform-neutral making them accessible to the client application no matter what software system it uses or what is its underlying platform. Thus they provide a standard vocabulary to the communicating applications and/or components.
We’ll not discuss the technical details of web services here, refer to Web Services and Service Oriented Architecture for Smarties and Web Services - Enterprise Services for more details. In SAP’s context, there are tool (and wizards) using which creating a web service out of an EJB or a Function Module is just a matter of few mouse clicks. These tools generate all the metadata that is required. However we still should educate ourselves with the technical details of a WSDL document and SOAP messages.
In SAP’s context we have two more terms for services namely, Enterprise service and Application services (actually there are more, like entity services, external services but they are specific to CAF, Composite Application Framework).
Enterprise services are web services (above definition) , generally they are composite services, which perform some business functionality that is composed of tightly-coupled services. One example of a tightly-coupled business service is a customer swiping a debit card into a card reader, accepting a debit amount, specifying the amount of cash back, and receiving confirmation for automatic debit from his account.
One definition that I found quite useful goes like:
“Enterprise services are Web services that provide enterprise-level business functionality. They may range from very simple lookup services (like finding a company’s location or product offerings) to more complex and composite services — but what they have in common is that they’re highly integrated into your process or application Typically enterprise services are high-level components that take more granular Web services and aggregate them into reusable elements with business value.” Refer When Does a Web Service Become an Enterprise Service? For more details.
From a developers perspective it is like saying enterprise services are simply web services which can be composite in nature. Still its important to know the distinction between the two; lets look into our sales example. We want to provide a service for creating sales order. In a simple implementation we can create a web service which creates a sales order in the database, however this process may lead to the following:
- Check inventory/warehouse for the availability of product/material
- Update the inventory if product/material is available
- Otherwise send a production order/or create a product plan.
The question is should we include these activities in one composite service(the enterprise service) or not? I think a business analyst can give a better answer than a developer, since the fact that whether these services need to be tightly or loosely-coupled may depend on how the client application is implementing the business scenario.
So to sum up we should say that an enterprise service:
-Should be coarse grained (but not just for the sake of it) and provide someenterprise-level business functionality
- It should have other qualities that are expected from a business service like quality, robustness, maintainability and all the other Sales’ terms .
So far in this discussion, integration has been confined to application integration via components ( which are there in existing and legacy systems) based services, however in an enterprise we have several other consideration too, for example:
Business processes in which customers, vendors, partners and employee are involved, it could be difficult to provide personalized and role-based UI and data access, considering the heterogeneous IT environment. Integration at the end-user interface is concerned with how the complete set of applications and services a given user accesses are integrated to provide a usable and consistent interface.
Application connectivity is concerned with all types of connectivity that the architecture must support. At one level, this means things such as synchronous and asynchronous communications (for example synchronous and asynchronous service invocations), routing, distribution of data, and protocol converters. On another level, it also relates to the virtualization of input and output, or sources and sinks, as we saw in our implementation of SOA. Here the problem is the fundamental way data moves in and out of, and within, the framework that implements the architecture.
Process integration is concerned with the development of computing processes that map to and provide solutions for business processes, a)integration of applications into processes and composite applications, and b) integrating processes with other processes. Integration of applications into processes might include applications within the enterprise, or might involve invocation of applications or services in remote systems, like those of a business partner. Likewise, process-level integration might involve the integration of whole processes, not just individual services, from external sources as well.
Information integration is the process of providing a consistent access to all the data in the enterprise, by all the applications that need it, in whatever form they need it, without being restricted by the format, source, or location of the data. Often the key concept is the virtualization of the data, which might involve the development of a data bus from which data is requested using standard services or interfaces by all applications within the enterprise. Thus the data can be presented to the application regardless of whether it came from a spreadsheet, a native file, an SQL or DL/I database, or an in-memory data store. The format of the data in its database store should be hidden from applications. The location of the data is also transparent to the application; since it is provided by a common service, it is the responsibility of the access service to retrieve the data, locally or remotely, not the application, and then present the data in the requested format.
Lastly, one of the requirements for the application development environment must be that it takes into account all the styles and levels of integration that might be implemented within the enterprise, and provide for their development and deployment. The development environment must include (and enforce) a methodology that clearly prescribes how services and components are designed and built in order to facilitate reuse, eliminate redundancy, and simplify testing, deployment, and maintenance.
In the next article of this series we’ll try to explore how SAP NetWeaver answers these requirements.
1 Comment
