Service-Oriented Architecture (SOA) is fundamentally a loosely coupled computing paradigm and has become a key ingredient of modern business applications and IT infrastructure. Now accepted quite widely by user communities and heavily backed by major software vendors such as Oracle, IBM, SAP, and Microsoft, SOA tools and practices are maturing fast. Since this book is focused on teaching how to use a SOA-enabling tool set, and not on deep exploration of SOA philosophies and methodologies, we will only briefly go over some of the essential aspects of SOA in a refresher style so as to provide you with a reasonable context. Much of the content in this chapter will serve as general background information on SOA and can be useful for overall practice of SOA. In what is to follow, we touch upon what SOA and its essential constituent services are, and why one should one even bother about SOA. We recount how the basics of SOA have evolved and the direction it is headed. We conclude the chapter with an introductory treatise on Service Component Architecture (SCA), as familiarity with SCA concepts is helpful in appreciating the workings of Oracle SOA Suite 11g tool set.
SOA is an architectural framework for software design that works around the concept of services. In our day-to-day life, we take the concept of services as a given: if we are sick, we seek the service of a doctor, if a faucet is leaking in our home, we rely on a plumber's service to get that fixed, our children's education depends on the services of teachers, and so on. While services span nearly all the things imaginable, they exhibit a rather simple interaction pattern. When a consumer makes a request to the provider for something to be done, the provider provides a service by executing that request. At a high level, services in SOA would be quite similar to those in our daily lives. Of course, in SOA, the consumers and providers would be some computer applications and the service would be a suitable unit of business or technical functionality that is digitally accomplished. SOA is about working with such services. It is the architectural component of a bigger philosophy, the so-called service orientation, and its adoption has a multi-fold impact on an organization in the way it builds and leverages IT assets for ultimate business benefit. SOA impacts, for example:
Enterprise architecture: The embellishment of standard enterprise architecture by components specific to handling and management of services, for example, service orchestrator for composition of business processes or composite applications using services, service bus for service request mediation and protocol and format translations, service portfolios, and repositories for service asset management, service repositories, and registries for service look-ups, service security, policy, and quality-of-service management components, and so on. (The following figure shows some of the essential elements of SOA.)
For a successful SOA adoption, you need to attend to each of the above aspects, which are not all technology related. This is the reason why you may hear remarks like "SOA is not only technology" or "You cannot buy SOA off-the-shelf". While we acknowledge this comprehensive approach to successful SOA adoption, and Oracle's SOA Methodology delves into details of how SOA may be adopted in a comprehensive manner, in this book, we have chosen to keep our focus on the implementation aspects of SOA solutions.
SOA definitions: Over the years, many definitions have been proposed for SOA. These definitions are similar in many aspects but have some differences. As an example, we offer two such definitions:
Per Gartner, "Service Oriented Architecture (SOA) is a client-server software design approach in which an application consists of software services and software service consumers (also known as clients or service requesters). SOA differs from the more general client/server model in its definitive emphasis in loose coupling between software components, and in its use of separately standing interfaces."
Per Object Management Group's SOA Special Interest Group, "Service Oriented Architecture is an architecture style for a community of providers and consumers of services to achieve mutual value that (i) allows participants in the communities to work together with minimal co-dependence or technology dependence, (ii) specifies the contracts to which organizations, people and technologies must adhere in order to participate in the community, (iii) provides for business value and business processes to be realized by the community, and (iv) allows for a variety of technology to be used to facilitate interactions within the community."
The following figure shows the key focus areas for a comprehensive and successful SOA adoption:
A service in SOA is basically an encapsulation of data and business logic. A service consists of an interface, has an implementation, and exhibits certain pre-defined behavior. The service interface defines a set of operations, which portrays its capabilities; operations are the things that a service can do. The provider of the service offers one or more contracts based on the interface and behavior details, and is responsible for creating a service implementation capable of fulfilling such contract(s). The consumer of the service is only concerned with the contract for use of this service. The service functionalities may be derived from diverse sources, for example, databases, legacy applications, packaged enterprise applications, or bespoke applications developed in traditional programming environments like C/C++, Java, or .Net. Mature technologies and tools exist today that can easily package and expose these functionalities as services. A wide variety of service consumers are possible, for example, composite applications, user interaction modules, or business-to-business gateways. Service and IT infrastructures bridge service consumers and the providers and provide mechanisms to apply adequate security and other policies (see the following figure for a high-level SOA Reference Architecture schematic, ref. Oracle SOA Methodology).
It is worthwhile to point out that the concept of service packaging is quite general. A service can utilize other services along with suitable composition mechanism, for example, using declarative orchestration or some procedural code.
Services are often classified, that is, type designations are assigned to services, in order to be able to specify best practices for their implementation and management. There are many strategies for service classification. One classification approach relies on what the service encapsulates, and accordingly we have (adapted from: SOA Principles of Service Design by Thomas Erl, Prentice Hall):
Entity services: These services package corporate/business entities such as customer, account, employee, contract, and so on, and provide access to underlying data elements via the basic data access operations like create, read, update, and delete, collectively called the CRUD operations, plus a few others and some logic calculations based on the attributes of the entity. Entity services are generally business process agnostic, for example, data services providing access to data in packaged applications.
Task services: These services perform a portion or all of some business process or activity and in turn may access functionalities of various entity or other task services. A payment update action involving updates to several entities such as customer and account is an example of a task service. Task services often represent sub-processes of higher-level business processes.
Utility services: These are helper services to entity and task services providing connectivity to applications (for example, connector services), access to security infrastructure (for example, directory services), or other generic utilitarian activities like logging.
Utility services are typically technical or infrastructural in nature while entity and task services usually carry business semantics. Utility and entity services are, generally speaking, more reusable than task services.
As a general rule, when scoping capabilities of services, do not mix business process/application specific and agnostic functionalities—doing so is likely to hinder re-use and composability of services.
Cost reduction for IT application development via service reuse, and for IT operations via well-defined services-based operations layers
Increased business agility, that is, reduction in time-to-market of a company's offering by speeding up creation of new or modification of existing IT applications and business processes by composing and assembling applications from existing assets as opposed to building from scratch
Change resilience, that is, ability of higher-level applications and processes to remain insulated from changes in lower or backend applications, for example, a customer order management process not being affected by the introduction of a new order fulfillment system
Location transparency: This refers to the ability of a service consumer to be able to invoke a service regardless of its actual location in the network; this also assumes the discoverability property (described above) and that the consumer has the right to access the service. Often, the idea of service virtualization, where the consumer simply calls a logical service while a suitable SOA-enabling runtime infrastructure component, commonly a service bus, maps this logical service call to a physical service, also relates to location transparency.
Autonomy: Services, within the bounds of their contracts that they make with their resource providers and contracts that they offer to their consumers, need to be self-contained as far as their execution is concerned; this implies that services must manage their own dependencies on other services or contributing applications.
State management: Services need to handle their own state management per their contract. While it is highly desirable that services be stateless, stateful implementations may be unavoidable in certain cases.
Reusability: A service should package information and business logic in a manner that, where and when applicable, multiple consumers should be able to use it as a shared resource either directly or via composition.
Composability: Services should be easily composable from other services and technical functionalities, and should be able to participate easily in other higher-level functionalities, such as a composite service or a composite business application.
Some of the statements above have been influenced by a recent multi-part discussion series, Evolution of principles of Service Orientation by Michael Poulin (see: http://www.ebizq.net/blogs/service_oriented/2009/02/evolution_of_principles_of_service_orientation_part_1.php) on SOA principles described in Thomas Erl's books on SOA.
It should be pointed out that the above properties, while quite distinct in their own right, are not always mutually exclusive. Also, when making design considerations for a service, business requirement-driven pragmatic trade-offs that prioritize importance of these properties can be expected. Note also that if a composite application is built out of component services and other functionalities like business rules, and so on, with the intention of packaging and exposing this application as a service, then this composite application becomes subject to the above set of disciplines.
The ability of an organization to follow SOA disciplines routinely depends on the SOA maturity of the organization. Based on its business needs, and by following a suitable SOA maturity model, an organization can create an SOA adoption roadmap to attain higher SOA maturity over a period of time.
Services are like mini applications and have distinct life cycle stages and corresponding owners. Usually triggered by some business or operational requirement, candidate services are put forth, some of which then, via an appropriate governance process, may be selected for implementation. A candidate service that is targeted for implementation will go through the usual life cycle stages of analysis and design before building, testing, and deployment. However, services, much like applications, are versioned. Versioning can be quite a useful strategy in managing evolution of services and in limiting the unwanted impact of changes introduced in the services. New service versions are released as additional capabilities are added in order to accommodate the needs of newer service consumers. SOA providers would support multiple service versions simultaneously, just like commercial packaged applications, and existing consumers using older versions of the services would be able to continue operating without being forced to change over to the latest version.
There is no doubt that businesses have benefited from information technologies and have moved into the so-called digital age. Still, there are some commonly prevailing complaints: "IT is too complex", "IT is too expensive", and "IT is too slow". The main reason for increased attention to SOA these days is the expectation that by exposing and leveraging the existing IT assets as services, SOA will help simplify IT applications development and operations, and will help businesses gain significant cost advantages and agility. Interestingly, SOA is not the first time that the industry tried to enhance the business benefit of IT.
Alexander Pasik of Gartrner coined the term "SOA" in 1994. Yefim B. Natis and Roy W. Schulte of Gartner published the first report on SOA in 1996.
Elements of the SOA paradigm have been in the making for nearly three decades. The present day service-oriented computing has its roots in computing models like modular programming, client-server computing, object-oriented programming, component-based and model-based developments, and in distributed computing technologies like Distributed Computing Environment with remote procedure calls and Distributed File Systems (DCE/RPC/DFS), Message-Oriented Middleware (MOM), Object Request Brokers (ORBs). Contemporary SOA also leverages tremendous advancements of the last decade in LAN- and WAN-based computing and in the Internet technologies.
Unlike many of the technologies of the past, modern SOA utilizes technology and vendor neutral standards like XML, HTTP, and Web Services (WS-*) that are heavily backed by all leading software vendors. This has now led to a much stronger acceptance of SOA as compared to similar technologies and styles that preceded it. With the introduction of Enterprise Service Bus (ESB) products, it has become much easier to mediate service requests and to build shared services infrastructure layers on top of IT assets. These service infrastructure layers can effectively support higher-level composite applications like business processes and portals while insulating them from changes below the service layer, and thus facilitating application rationalization and legacy modernization.
Simple Object Access Protocol (SOAP) based Web Services (WS) have gained major popularity in SOA implementation, and this book follows this trend. However, it is possible to use other technologies to implement SOA as long as the basic principles of SOA are adhered to.
With essential philosophies and practices demystified, SOA is now becoming the foundation of many mission-critical applications—this drastically increases the performance, scalability, reliability, and policy enforcement requirements of SOA solutions. Services layers are often the building blocks on which agile business processes rest. Many real-life applications require handling of events and it is becoming important for SOA-enabling infrastructures to be able to accommodate event handling and processing alongside services. Services are also being seen as key ingredients in shared computing environments such Software-as-a-Service (SaaS) or cloud computing. Does this level of industry acceptance of SOA mean that we have attained SOA nirvana? The answer, of course, is No, or at least, Not Yet! Part of the reason is the increase in complexity as the SOA solutions are aimed at non-trivial and mission-critical applications. The complexity, at least as it relates to implementation of the solutions, mainly arises from the fact that to build such applications, you not only have to access and orchestrate services, but also, as in tiered compositions, orchestrate the orchestration of services, or include human workflow features like approvals and manual exception handling, or use business rules to add flexible decision making. In such cases, multiple development environments with corresponding technologies, metadata, and runtime engines would be necessary.
The developers would have to deal with these different development environments and would have to integrate the individual components themselves. The operations people would have to deal with the nuances of such custom integration of integration components for deployment, monitoring, and management. This complexity eats into the potential SOA benefits by significantly increasing the activity costs for SOA solutions.
Therefore, what is needed is a service platform where the design-time elements of all the necessary tools are available in one Integrated Development Environment (IDE), where such complex solutions can be composed easily out of the necessary components with drag-and-drop type simplicity, and from where the composed solution can be deployed and managed as one unit. From a technical perspective, emergence of such service platforms is the key to the next generation of SOA-enabling infrastructures. Of course, some guiding disciplines would be required to create such a platform. The recently proposed technology and vendor neutral Service Component Architecture (SCA) specification, that is backed by most of the leading software vendors concerned with SOA, is an important step in that direction. As we will see throughout this book, Oracle SOA Suite 11g leverages SCA in order to deliver such a service platform.
One of the definitions of composition, as per the Merriam-Webster dictionary, is a product of mixing or combining various elements or ingredients. Services are often put together by combining functionalities from a variety of sources. Services are also combined together, in the spirit of service reuse, to create higher-level services termed composite services. Of course, composition in SOA does not only involve leveraging services or other functionalities from applications, but also could include conditional executions, message or payload format transformations, embedding human tasks, or business rules. Standard programming languages or scripts like Java, C++, C#, PHP, and so on could be used to accomplish such compositions. However, beyond trivial use cases, this strategy often renders the composition too rigid and difficult to understand, to maintain, and to change. Declarative composition tools, in particular the ones based on open standards, for example, a Business Process Execution Language (BPEL) orchestrator, have helped alleviate this composition problem to some extent. However, for more general compositions, there existed a strong need for a more powerful discipline that could handle a wider variety of contributing elements, such as disparate metadata and implementation technologies, yet would be relatively simple to work with.
In the following figures, you can see schematics of an SCA "Composite" and "Component", respectively (ref. www.osoa.org):
In recent years, as a result of collaboration among the leading software vendors involved in SOA enabling tools, the Service Component Architecture (SCA) specification set has emerged as a suitable discipline that is capable of handling very general composition tasks and can facilitate easy deployment and monitoring of the end result of the composition, also known as a composite (see: www.osoa.org). SCA specifications allow creation of composite services using a variety of technologies such as Java, C/C++, PHP, XML, and BPEL, offer extensions for platform-specific technologies, facilitate various communication technologies such as JMS, HTTP, SOAP, and REST, and provide for ways to attach policies and to make the composite easily configurable. This mix-and-match of technologies and functionalities is kept track of using the SCA Assembly specification, and is accomplished by creating a sort of global deployment descriptor that is rendered in XML and describes all of the artifacts that are used to build a composite service and how they are related to each other. The key features of the SCA Assembly model (see preceding figures) are:
Composite: A composite is the highest-level description of a composite service, and is expressed using XML. The rest of the SCA assembly artifacts are included within a composite description. A composite encapsulates a set of business functions, which can be exposed through services (see below). Also, a composite can leverage functionalities offered by others via references (see below).
Component: Components are the basic units of construction for a composite. Similar to composites, component functionalities can be exposed through services (see below), and components could leverage functionalities offered by others via references (see below). Some of the component-level services and references can be pushed out (or promoted in SCA terminology) to the composite level, of which the component is a part. Component configurations refer to some specific implementation, for example, a BPEL process or a Java class file. Components also have configurable properties, some of which can be made available at the composite level as well.
Services and References: These are the SCA mechanisms for communications into and out of components and composites (see earlier). For a composite, these are essentially a combination of interfaces (for example, Java interface or WSDL PortType) and bindings (for example, JMS, Web Services, JCA, and so on).
Wire: Wires in SCA are connections that link together services, components, and references. Wires are used to indicate to the runtime platform how to route messages between the network layer and the pieces of business logic that are used to implement the composite service.
The preceding description was meant for you to get a quick idea of SCA and the concept of composites. These and the other features will be further touched upon in this book as they come up in connection with the use of Oracle SOA Suite 11g tools. Should you be interested in all the published details of the various aspects of SCA, you can download them for free from www.osoa.org. Note also that there are other specifications within the SCA body of specifications besides the Assembly Model described here—these are focused on aspects of components and composites other than their assembly. For example, non-functional or operational requirements for SCA composites and components are handled by the SCA Policy Framework.
SCA 1.0 specifications completed incubation in February 2007 and were published on www.osoa.org. The authors that included Oracle announced their intent to submit the specification to OASIS for advancement through its open standards process. Additionally, a new member section, the Open Composite Services Architecture (oasis-opencsa.org) was created in OASIS to coordinate several Technical Committees (for example, Assembly, Bindings, Policy, Java, C-C++, BPEL, and so on) to process these specifications.
Design-time and run-time tools for SOA-based applications could utilize these SCA specifications and concepts to create what we have called a service platform that would facilitate the whole life cycle of such applications. With such a platform, a developer would not have to go in and out of multiple development environments in order to design the various components of a service-oriented business application, and would not have to then create custom integrations of these disparate technology components. There would be common metadata pertaining to all the elements of the composed solution and it would minimize the effort and errors during deployment and migrations, and for editing the solution to introduce changes. Such a platform would also allow easy tracing of transactions through the solution composites and would provide for uniform exception handling. Thus, such a platform would afford increased business agility, higher developer productivity and lower operational cost. As you will learn in the remainder of this book and will experience by doing the suggested tutorials in this book, Oracle SOA Suite 11g is indeed such a platform based on SCA specifications, and at the time of this writing and to the knowledge of the authors, the most advanced and complete commercial implementation of SCA.
SOA is a software design paradigm based on the principle of loose coupling. The basic building elements of SOA are services that provide access to and processing of business logic and data. XML and Web Services have become a popular choice for implementing SOA-based solutions. SOA has been receiving a lot of attention in recent years due to its potential for reducing a variety of IT costs as well as for increasing business agility. SCA specifications have emerged as a suitable discipline for creating highly productive SOA development environments. Oracle SOA Suite 11g, which you will be working with in rest of this book, leverages SCA heavily to provide a unified service platform for creation, deployment, testing, management, and monitoring of SOA-based composite business applications.