By now, you should have a good initial understanding of all the key components that make up the Oracle SOA Suite. Typically we find that once someone has an initial grasp of the various components, one of the next questions we get is:

Answering this question is very much the focus of this section. To do this, we have built a complete, albeit, relatively small SOA solution designed for an online auction site for a fictional company called oBay(the o stands for Oracle).

Each chapter in this section tackles specific areas that need to be considered when developing an SOA-based solution, such as the design of the service contract, validation, error handling, message interaction patterns, and so on. To highlight and demonstrate key design considerations, each chapter uses examples based on key parts of the oBay application to illustrate...

Service contracts provide the glue that enables us to assemble disparate pieces of software or services into complete, composite applications. If we are to build a sustainable solution, that is, one that will achieve our goals of improved agility, reuse, and interoperability, then a careful design of the service contract is crucial.

The contract of a web service is made up of the following technical components:

Additionally, the service contract may be supported...

In Chapter 10, oBay Introduction, we went through the process of defining our high level SOA blueprint. One of the key layers within this blueprint is the business services layer, which we further categorized into Entity, Functional, and Task-based services.

When it comes to implementing Task-based or Functional services, the SOA Suite provides a number of ways of implementing these (many of which are covered within the pages of this book), depending on the nature of the requirements. In addition, with SOA we have the flexibility of implementing these services pretty much in a language of our choice, a key driver often being the existing skill sets within our organization.

However, when it comes to Entity services, which typically represent data entities held in a relational database, apart from the database adapter, the SOA Suite provides limited functionality for implementing these types of services. Certainly...

Once we have divided our solution into a number of composite components, one of the next questions we are typically faced with is:

At first glance, this may seem like an obvious question, but once you consider that a composite may be made up of other services, which in turn could be made up of other services and so on; it becomes clear that you could potentially end up implementing the same validation in every level.

Apart from the obvious performance implications, you also have the issue of having to implement and maintain the same validation at multiple points within the solution.

When you get down to an individual composite, you still have to consider, where in the service to place the validation and how best to implement it. Particularly, if you want the flexibility to be able to change the validation within a service without having to re-deploy it.

This chapter...

Handling errors or faults is an important consideration for service-oriented architecture (SOA) based applications, especially if you consider that a solution is likely to be a loose assembly of independent components, each with varying levels of resilience, throughput, and availability.

How faults are handled depends on a number of factors: whether it's a business or system fault, was the service where the fault originated called synchronously or asynchronously, and whether the interaction between the client and the component detecting the fault is synchronous or asynchronous.

A business fault is loosely defined as one we know about in advance. It is defined as part of the service contract, and thus represents a legitimate state within the business process. How we handle a fault of this type is largely driven by business requirements, and so it makes sense to handle these within the context of the process.

A system fault conversely is one that is...

In this chapter, we will examine some of the architectural features of the SOA Suite. We refer to them as advanced features because they are often ignored by developers, yet an understanding of how they work can give additional capabilities to our composite applications. We will begin by looking at how the BPEL component stores instance states during long running composite execution and then how it uses threads before moving on to examine where transaction boundaries occur. Finally, we will review how a cluster works, and how it may impact the way we design and build our composites. Clemens Utschig has been a great source of help in providing the information for this chapter.

In every composite, messages are exchanged between participants. So far, we have only looked at simple interactions, that is, a single request followed by a reply, whether synchronous or asynchronous.

Asynchronous messaging adds additional complexities around the routing and correlation of replies. In this chapter, we look at how the SOA Service Infrastructure uses WS-Addressing to manage this, and in situations where this can't be used, examine how we can use correlation sets in BPEL to achieve the same result.

As a part of this, we look at some common, but more complex, messaging patterns and requirements such as:

Finally, as we explore these patterns, we take the...

So far we've used workflow for simple task approval in conjunction with the worklist application. However, human workflows are often more complex, often involving multiple participants as well as requiring the task list to be integrated into the user's existing user interface rather than accessing it through a standalone worklist application.

In this chapter, we look at these common requirements. First, we examine how to manage workflows involving complex chains of approval, including parallel approvers and the different options that are available. Next, we look at the Workflow Service API, and how we can use that to completely transform the look and feel of the workflow service.

We have looked at how we can use the rules engine to define business rules that can then be invoked as a decision component within a composite. The examples we have used so far have been pretty trivial. However, the rules engine uses the Rete algorithm, which was developed by researchers into artificial intelligence in the 1970s.

Rete has some unique qualities, when compared to more procedural-based languages such as PL/SQL, C, C++, or Java, making it ideal for evaluating a large number of interdependent rules and facts. This not only makes it simpler to implement highly complex rules than would typically be the case with more procedural-based languages, but also makes it suitable for implementing particular categories of first-class business services.

In this chapter, we look in more detail at how the rule engine works, and armed with this knowledge, we write a set of rules to implement the auction algorithm responsible for...