The Oracle SOA Suite is a large and complex piece of software. In this chapter we will provide a roadmap for your use of the SOA Suite. After a review of the basic principles of SOA we will look at how the SOA Suite provides support for those principles through its many different components. Following this journey through the components of SOA Suite, we will introduce Oracle JDeveloper as the primary development tool that is used to build applications for deployment into the SOA Suite.
Service-oriented architecture (SOA) has evolved to allow greater flexibility in adapting the IT infrastructure to satisfy the needs of business. Let's examine what SOA means by examining the components of its title.
A service is a term that is understood both by the business and IT. It has some key characteristics:
Encapsulation: A service creates delineation between the service provider and the service consumer. It identifies what will be provided.
Interface: It is defined in terms of inputs and outputs. How the service is provided is not of concern to the consumer, only to the provider. The service is defined by its interface.
Contract or service level agreements: There may be quality of service attributes associated with the service, such as performance characteristics, availability constraints, or cost.
The break-out box uses the example of a laundry service to make the characteristics of a service more concrete. Later we will map these characteristics onto specific technologies.
Tip
Consider a laundry service. The service provider is a laundry company, and the service consumer a corporation or individual with washing to be done.
The input to the company is a basket of dirty laundry. Additional input parameters may be a request to iron the laundry as well as wash it, or to starch the collars. The output is a basket of clean washing with whatever optional additional services such as starching or ironing were specified. This defines the interface.
Quality of service may specify that the washing must be returned within 24 or 48 hours. Additional quality of service attributes may specify that the service is unavailable from 5PM Friday until 8AM Monday. These service level agreements may be characterized as policies to be applied to the service.
An important thing about services is that they can be understood by both business analysts and IT implementers. This leads to the first key benefit of service-oriented architecture.
Services allow us to have a common vocabulary between IT and the business.
When we are building our systems we are looking at them from a service point of view or orientation. This implies that we are oriented or interested in the following:
Granularity: The level of service interface or number of interactions required with the service, typically characterized as course grained or fine grained.
Collaboration: Services may be combined together to create higher level or composite services.
Universality: All components can be approached from a service perspective. For example, a business process may also be considered a service that, despite its complexity, provides inputs and outputs.
Thinking of everything as a service leads us to another key benefit of service-oriented architecture—composability.
Note
Composing new services out of existing services allows easy reasoning about the availability and performance characteristics of the composite service.
By building composite services out of existing services, we can reduce the amount of effort required to provide new functionality as well as being able to build something with prior knowledge of its availability and scalability characteristics. The latter can be derived from the availability and performance characteristics of the component services.
Architecture implies a consistent and coherent design approach. This implies a need to understand the inter-relationships between components in the design and ensure consistency in approach. Architecture suggests that we adopt some of the following principles:
Consistency: The same challenges should be addressed in a uniform way. For example, the application of security constraints needs to be enforced in the same way across the design. Patterns or proven design approaches can assist with maintaining consistency of design.
Reliability: The structures created must be fit to purpose and meet the demands for which they are designed.
Extensibility: A design must provide a framework that can be expanded in ways both foreseen and unforeseen. See the break out box on extensions.
Tip
Extending Antony's house
My wife and I designed our current house. We built in the ability to convert the loft into extra rooms and also allowed for a conservatory to be added. This added to the cost of the build but these were foreseen extensions. The costs of actually adding the conservatory and two extra loft rooms were low because the architecture allowed for this. In a similar way it is relatively easy to architect for foreseen extensions, such as additional related services and processes that must be supported by the business. When we wanted to add a playroom and another bathroom, this was more complex and costly as we had not allowed for it in the original architecture. Fortunately our original design was sufficiently flexible to allow for these additions but the cost was higher. In a similar way the measure of the strength of a service-oriented architecture is the way in which it copes with unforeseen demands, such as new types of business process and service that were not foreseen when the architecture was laid down. A well architected solution will be able to accommodate unexpected extensions at a manageable cost.
A consistent architecture when coupled with implementation in SOA Standards gives us another key benefit—inter-operability.
Note
SOA allows us to build more inter-operable systems by being based on standards agreed by all the major technology vendors.
SOA is not about any specific technology. The principles of service-orientation can be applied equally well using assembler as they can in a high level language. However, as with all development it is easiest to use a model that is supported by tools and is both inter-operable and portable across vendors. SOA is widely associated with the web service or WS-* standards presided over by groups like OASIS. This use of common standards allows SOA to be inter-operable between vendor technology stacks.
A few years ago distributed object technology in the guise of CORBA and COM+ were going to provide benefits of reuse. Prior to that third and fourth generation languages such as C++ and Smalltalk based on object technology were to provide the same benefit. Even earlier the same claims were made for structured programming. So why is SOA different?
The use of terms such as "services" and "processes" allows business and IT to talk about items in the same way, improving communication and reducing impedance mismatch between the two. The importance of this is greater than what it appears initially, because it drives IT to build and structure its systems around the business rather than vice versa.
In the past there have been competing platforms for the latest software development fad. This manifested itself as CORBA and COM+, Smalltalk and C++, Pascal and C. This time around the standards are not based upon the physical implementation but upon the service interfaces and wire protocols. In addition these standards are generally text based to avoid issues around conversion between binary forms. This allows services implemented in C# under Windows to inter-operate with Java or PL/SQL services running on Oracle SOA Suite under Windows, Linux or UNIX. The major players like Oracle, Microsoft, IBM, SAP, and others are agreed on how to inter-operate together. This agreement has always been missing in the past.
Note
WS Basic Profile
There is an old IT joke that standards are great, there are so many to choose from! Fortunately this has been recognized by the SOA vendors and they have collaborated to create a basic profile, or collection of standards, that focus on inter-operability. This is known as WS Basic Profile and details the key web service standards that all vendors should implement to allow for inter-operability. SOA Suite supports this basic profile as well as additional standards.
SOA recognizes that there are existing assets in the IT landscape and does not force these to be replaced, preferring instead to encapsulate and later extend these resources. SOA may be viewed as a boundary technology that reverses many of the earlier development trends. Instead of specifying how systems are built at the lowest level it focuses on how services are described and how they inter-operate in a standards-based world.
A final major distinguishing feature for SOA is the concept of reuse in place. Most reuse technologies in the past have focused on reuse through libraries, at best sharing a common implementation on a single machine through the use of dynamic link libraries. SOA focuses not just on reuse of the code functionality but also upon the reuse of exiting machine resources to execute that code. When a service is reused the same physical servers with their associated memory and CPU are shared across a larger client base. This is good from the perspective of providing a consistent location to enforce code changes, security constraints, and logging policies but it does mean that performance of existing users may be impacted if care is not taken in how services are reused.
SOA Suite has a number of component parts, some of which may be licensed separately.
The most basic unit of a service-oriented architecture is the service. This may be provided directly as a web service enabled piece of code or it may be exposed by encapsulating an existing resource.
Services are defined by a specific interface, usually specified in a Web Service Description Language (WSDL) file. A WSDL file specifies the operations supported by the service. Each operation describes the expected format of the input message and if a message is returned it also describes the format of that message. The structure of WSDL files are described in Chapter 17.
Services are often surfaced through adapters that take an existing piece of functionality and "adapt" it to the SOA world so it can interact with other SOA Suite components. An example of an adapter is the file adapter that allows a file to be read or written to. The act of reading or writing the file is encapsulated into a service interface. This service interface can then be used to receive service requests by reading a file or to create service requests by writing a file.
Out of the box the SOA Suite includes licenses for the following adapters:
The database adapter and the file adapter are explored in more detail in Chapter 3 and Chapter 11. There is also support for other non-SOAP transports and styles such as plain HTTP, REST, plain TCP/IP, and Java.
Services are the most important part of service-oriented architecture and in this book we focus on how to define their interfaces and how to best assemble services together to create composite services with a value beyond the functionality on a single atomic service.
To avoid service location dependencies it is desirable to access services through an Enterprise Service Bus (ESB). This provides a layer of abstraction over the service and allows transformation of data between formats. The ESB is aware of the physical endpoint locations of services and acts to virtualize services.
Services may be viewed as being plugged into the service bus.
An Enterprise Service Bus is responsible for routing and transforming service requests between components. By abstracting the physical location of a service an ESB allows services to be moved to different locations without impacting the clients of those services. The ability of an ESB to transform data from one format to another also allows for changes in service contracts to be accommodated without recoding client services. The service bus may also be used to validate that messages conform to interface contracts and to enrich messages by adding additional information to them as part of the message transformation process.
Note that the SOA Suite contains both the Oracle Service Bus (formerly AquaLogic Service Bus) and the Oracle ESB. The stated direction by Oracle is for the Oracle Service Bus to be the preferred ESB for interactions outside the SOA Suite. Interactions within the SOA Suite may sometimes be better dealt with by the Oracle ESB, which will be known as the Mediator component in the 11g release of SOA Suite, but we believe that for most cases the Oracle Service Bus will provide a better solution and so that is what we have focused on within this book. However, the current release of the Oracle Service Bus, only executes on the Oracle WebLogic platform. So when running SOA Suite on non-Oracle platforms there are two choices:
Use only the Oracle ESB
Run Oracle Service Bus on a separate WebLogic Server while running the rest of SOA Suite on the non-Oracle platform
We will focus on the Oracle Service Bus in this book, as that is the preferred direction for ESB functionality within the SOA Suite. Later releases of the SOA Suite will support Oracle Service Bus on non-Oracle platforms such as WebSphere.
In order to build composite services, that is services constructed from other services, we need a layer that can orchestrate, or tie together, multiple services into a single larger service. Simple service orchestrations can be done within the Oracle Service Bus but more complex orchestrations require additional functionality. These service orchestrations may be thought of as processes, some of which are low-level processes and others are high-level business processes.
Business Process Execution Language is the standard way to describe processes in the SOA world, a task often referred to as service orchestration. The BPEL Process Manager in SOA Suite includes support for the BPEL 1.1 standard with some constructs from BPEL 2.0 also being supported. BPEL allows multiple services to be linked to each other as part of a single managed process. The processes may be short running, seconds and minutes, or long running, hours and days.
The BPEL standard says nothing about how people interact with it, but BPEL Process Manager includes a Human Workflow component that provides support for human interaction with processes.
The BPEL Process Manager may also be purchased as a standalone component, in which case it ships with the Human Workflow support and the same adapters as included in the SOA Suite.
We explore the BPEL Process Manager in more detail in Chapter 5 and Chapter 14. Human workflow is examined in Chapter 6 and Chapter 15.
Oracle also package the BPEL Process Manager with the Oracle Business Process Management (BPM) Suite. This package includes the former Aqualogic BPM product (acquired when BEA bought Fuego), now known as Oracle BPM. Oracle position BPEL as a system-centric process engine with support for human workflow while BPM is positioned as human-centric process engine with support for system interaction.
Business decision making may be viewed as a service within SOA. A rules engine is the physical implementation of this service.
SOA Suite includes a powerful rules engine that allows key business decision logic to be abstracted out of individual services and managed in a single repository. The rules engine is also included in the Oracle Application Server Enterprise Edition.
In Chapters 7 and 16 we investigate how to use the rules engine.
One of the interesting features of SOA is the way in which aspects of a service are themselves a service. Nowhere is this better exemplified than with security. Security is a characteristic of services, yet to implement it effectively requires a centralized policy store coupled with distributed policy enforcement at the service boundaries. The central policy store can be viewed as a service that the infrastructure uses to enforce service security policy.
The Oracle Web Services Manager has several roles to play within an SOA. Firstly it serves as a policy enforcement point for security, ensuring that only requests that comply with policy are accepted. Secondly it provides a monitoring service to ensure that services are compliant with their service level agreements.
Security policy may also be applied through the Service Bus although policy definition is currently different between the Service Bus and OWSM the direction is for Oracle to have a common policy management in a future release.
Applying security policies is covered in Chapter 20.
It is important in SOA to track what is happening in real time. Some business processes require such real-time monitoring. Users such as financial traders, risk assessors, and security services may need instant notification of business events that have occurred.
Business Activity Monitoring is part of the SOA Suite and provides a real time view of processes and services data to end users. BAM is covered in Chapter 8.
Although we can use adapters to talk to remote systems, we often need additional features to support external services, either as clients or providers. For example, we may need to verify that there is a contract in place before accepting or sending messages to a partner. Management of agreements or contracts is a key additional piece of functionality that is provided by Oracle B2B. B2B can be thought of as a special kind of adapter that, in addition to support for B2B protocols such as EDIFACT/ANSI X12 or RosettaNet, it also supports agreement management. Agreement management allows control over the partners and interfaces used at any given point in time. We will not cover B2B in this book as the B2B space is a little at the edge of most SOA deployments.
As our services execute we will often generate events. These events can be monitored and processed using the complex event processor. The difference between event and message processing is that messages generally require some action on their own with little or minimal additional context. Events on the other hand often require us to monitor several of them to spot and respond to trends. For example, we may treat a stock sale as a message when we need to record it and reconcile it with the accounting system. We may also want to treat the stock sale as an event, in which we wish to monitor the overall market movements in a single stock or in related stocks to decide whether we should buy or sell. The complex event processor allows us to do time based and series based analysis of data. We will not talk about CEP in this book as it is a complex part of the SOA suite that requires a complementary but different approach to the other SOA components.
We will now examine how Oracle SOA Suite provides the services identified above.
The SOA Suite is built on top of a Java Enterprise Edition (Java EE) infrastructure. Although SOA Suite is certified with several different Java EE servers, including IBM WebSphere, it will most commonly be used with the Oracle WebLogic Server. Currently the SOA Suite is provided with an integrated install for Oracles OC4J container but this is changing to make WebLogic the primary platform. The Oracle WebLogic Server (WLS) will probably always be the first available Java EE platform for SOA suite and is the only platform that will be provided bundled with SOA Suite to simplify installation. For the rest of this book we will assume that you are running SOA Suite on Oracle WebLogic Server. If there are any significant differences when running on non-Oracle application servers we will highlight them in the text.
In addition to a Java EE application server the SOA Suite also requires a database. The SOA Suite is designed to run against any SQL database, but certification for non-Oracle databases has been slow in coming. The database is used to maintain configuration information and also records of runtime interactions. Currently SOA Suite on Windows ships with an Oracle Lite database which is suitable for development use only. There is also the option to use a full Oracle Database on Windows, and this is required for non-Windows platforms. Oracle Database XE can be used with the SOA Suite.
In a previous section, we examined the individual components of the SOA Suite and here we show them in context with the Java EE container and the database.
All the services execute within the context of the JEE container (except for BAM which is a Windows application in 10.1.3), although they may use that container in different ways. BPEL listens for events and updates processes based upon those events. Adapters typically make use of the Java EE containers connector architecture (JCA) to provide connectivity and notifications. OWSM acts as a filter when used in embedded mode, and as a separate application when used as a gateway. Note that the Oracle Service Bus (OSB) is only available when the application server is a WebLogic server.
Oracle has put a lot of effort into making SOA Suite consistent in its use of underlying services. A number of lower level services are reused consistently across components.
At the lowest level connectivity services such as adapters, JMS, and Web Service Invocation Framework are shared by higher level components.
A service layer exposes higher level functions. BPEL Process Manager is implemented by a combination of a BPEL engine and access to the Human Workflow engine. Rules is another shared service that is available to BPEL or other components.
The SOA Suite architecture is a good example of service-oriented design principles being applied. Common services have been identified and extracted to be shared across many components. The high-level services such as BPEL and ESB share some common services such as transformation and adapter services running on a standard Java EE container.
Everything we have spoken of so far has been related to the executable or runtime environment. Specialist tools are required to take advantage of this environment. It is possible to hand craft the assemblies and descriptors required to build a SOA Suite application but it is not a practical proposition. Fortunately Oracle provide JDeveloper free of charge to allow developers to build SOA Suite applications.
JDeveloper is actually a separate tool but it has been developed in conjunction with SOA Suite so that virtually all facilities of SOA Suite are accessible through JDeveloper. The one exception to this is the Oracle Service Bus which in the current release does not have support in JDeveloper but instead has a different tool, WebLogic Workspace Studio. Although JDeveloper started life as a Java development tool, many users now never touch the Java side of JDeveloper, doing all their work in the SOA Suite components.
JDeveloper may be characterized as a model based, wizard driven development environment. Re-entrant wizards are used to guide the construction of many artifacts of the SOA Suite, including adapters and transformation.
JDeveloper has a consistent view that the code is also the model, so that graphical views are always in synch with the underlying code. It is possible to exercise some functionality of SOA Suite using the Eclipse platform, but to get full value out of SOA Suite it is really necessary to use JDeveloper. However, the Eclipse platform does provide the basis for the Service Bus designer, the Workspace Studio. There are some aspects of development which may be supported in both tools but easier in one than the other; for example, Workspace Studio provides a better WSDL editor than JDeveloper.
We have now touched on all the major components of the SOA Suite. However, there are a few items that are either of more limited interest or are outside the SOA Suite but closely related to it.
Oracle have a service repository and registry product that is integrated with the SOA Suite but separate from it. The repository acts as a central repository for all SOA artifacts and can be used to support both developers and deployers in tracking dependencies betweens components both deployed and in development. The repository can publish SOA artifacts such as service definitions and locations to the service registry. The Oracle Service registry may be used to categorize and index services created. Users may then browse the registry to locate services. The service registry may also be used as a runtime location service for service endpoints.
The Oracle BPA Suite is targeted at Business Process Analysts who want a powerful repository based tool to model their business processes. BPA Suite is not an easy product to learn, like all modeling tools there is a price to pay for the descriptive power available. Of interest to SOA Suite developers is the ability for the BPA Suite and SOA Suite to exchange process models. Processes created in BPA Suite may be exported to SOA Suite for concrete implementation. Simulation of processes in BPA Suite may be used as a useful guide for process improvement.
Links between BPA Suite and SOA Suite are growing stronger over time and it provides a valuable bridge between business analysts and IT architects.
Business Process Management Suite is focused on modeling and execution of business processes. As mentioned it includes BPEL Process Manager to provide strong system-centric support for business processes but the primary focus of the suite is on modeling and executing processes in the BPM Designer and BPM Server.
SOA Suite has no real end user interface outside the Human Workflow service. Front ends may be built using JDeveloper directly or they may be crafted as part of Oracle Portal, Oracle WebCenter or another Portal or front end builder. A number of portlets are provided to expose views of SOA Suite to end users through the portal. These are principally related to human workflow but also include some views onto BPEL process status. Portals can also take advantage of WSDL interfaces to provide a user interface onto services exposed by the SOA Suite.
Oracles preferred management framework is Oracle Enterprise Manager. This is provided as a base set of functionality with a large number of management packs which provide additional functionality. The SOA Management Pack extends Enterprise Manager to provide monitoring and management of artifacts within the SOA Suite.
As we have seen there are a lot of components to SOA Suite and although Oracle has done a lot to provide consistent usage patterns there is still a lot to learn about each component. The rest of this book takes a solution-oriented approach to SOA Suite rather than a component approach. We will examine the individual components in the context of the role they serve and how they are used to enable service-oriented architecture.