The following excerpt from Business Rules Management and Service Oriented Architecture: A Pattern Language is printed with permission from Wiley Press. Copyright 2007. Click here to access the complete
Chapter 2.
SOA and business rules
Service oriented architecture is an architectural concept in software design that emphasizes the use of combined services to support business requirements. In SOA, resources are made available to service consumers in the network as independent artifacts that are accessed in a standardized way. Many
definitions of SOA identify it with the use of web services using standards such as SOAP (originally Simple Object Access Protocol) and WSDL (Web Services Description Language – pronounced wuhzdle). However, it is possible to implement SOA using any service-based technology. Though built on similar principles, SOA is not coextensive with web services, the latter being a collection of technologies and standards, such as SOAP and XML. The notion of SOA is quite independent of any specific technology.
Critical to this notion of services is their loosely coupled character; service interfaces are independent of their implementations. Application developers or system integrators can build applications by composing one or more services without having to know the services' underlying implementations. For example, a service can be implemented either in a .NET or J2EE environment, and the application consuming the service can even run on a different platform or be written in a different language.
Consider, for example, someone enquiring about the parts needed to construct a floggle and their costs. The service might respond with something like 'You need six widgets @ 6p and one 6 mm toggle @ £1.20. The total cost is £1.56. All items are currently in stock.'
The service meets the need of this type of customer well, but it should be clear that there are at least three underlying services, concerned with bills of materials, pricing and stock. It is almost certainly more flexible to implement these services as separate components and aggregate them into higher level services like the one described.
We can note three further features of SOA:
- SOA services have self-describing interfaces in platform-independent documents. In the case of web services, these documents are presented in XML, and WSDL is the standard used to describe the services.
- SOA services communicate with messages using a formally defined language. Consumers and providers of services typically exist in heterogeneous environments, and consumers communicate with the least possible knowledge about their provider. Messages between services can be viewed as if they were business documents. In the case of web services, communication is via XML schemata (also called XSD).
- Ideally, SOA services are maintained in a registry that acts as a directory listing. Applications can then look up the services needed in the registry and invoke them as required. In the case of web services, Universal Description, Definition, and Integration (UDDI) is the standard used for service registry definition.
Each SOA service may have a quality of service (QoS) associated with it. Typical QoS elements include security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services. However, more business-oriented service level agreements can also be important. Consider a financial pricing service that gives current stock prices based on current trading in the market. There are two components that implement the same service interface. One is from Reuters – a well-established and reputable vendor – and the other is supplied by Honest John's Prices Inc. Do you care which implementation you take? Of course you do, if reliability is an issue. But SOA is implementation independent, so you shouldn't have to care. The solution is to include a QoS factor in the service interface that measures the 'reputation' of the supplier. Of course, when the services are provided in house the quality may be inferred, and these considerations do not apply.
Service oriented architecture structures software systems in the following style:
- Distributed enterprise application servers provide a collection of services (or transactions).
- By various incentives (which may include quarterly bonuses), developers are encouraged to build systems using this collection of services to supply most of the functions of new applications; roughly speaking we assemble new applications by plugging together existing services.
- These units of transaction can be relocated, load-balanced, replaced, security-applied, etc.
One of the ideas behind component based development is to scale up the object oriented philosophy of encapsulation, interfaces and polymorphism to the component level – a component is just a big object, designed and developed with the same care and attention given to identifying classes, their responsibilities and their collaborations. This approach can be further extended to a service oriented system by dividing the system into a set of components, each of which supplies a set of business services. Done intelligently, this leads to the system being built from a set of loosely connected components, many of which are ripe for reuse, or even better – sharing.
Because of the nature of components, we can try and factor other decisions into their design as well as just responsibilities and collaborations. If we try for a layered architecture (always a good idea) at the lowest level we can identify components that supply business utility services. These components supply utility services that are useful across a family of businesses. For example an address book, a catalogue, or a component that deals with interest rates. This type of component encapsulates few or no business rules, and can be categorized as being 'function-like'. By function-like we mean that they behave as a look-up table might, indexed by a key, or as a mathematical function – a particular inputwill (nearly) always supply the same answer. A key such as zip code and building number should yield a unique address. A book catalogue should, for a given ISBN, produce the details of the relevant book, and such details do (or should) not change. For interest rate calculations, given a period, interest rate and principle amount; the result should not change (a real interest rate calculator component would not be that simple, but the principle remains the same). These components are, by their nature, very stable and should be reusable within a particular business area. This type of component extends the old idea of a FORTRAN code library, but brings it up-to-date.
