Considerations for choosing SOA extensions

Although by completing Steps 1 and 2, we may have assembled a basic service-oriented environment consisting of core standards and planned service layers, Step 3 is where we get to compose unique variations of SOA (Figure 14.7).

Figure 14.7. WS-* extensions allow for individual SOAs to be uniquely composed.

14.4.1. Choosing SOA characteristics

As we've already established numerous times, primitive SOA is based on the principles of service-orientation that drive at the root of the service-oriented environment we are building. However, when you begin to explore how service-oriented business processes and application environments can be extended, composed, and even reconfigured, the true power of SOA really comes to light.

In Chapter 3 we established a list of contemporary SOA characteristics. We later revisited this list in Chapter 9 to determine which of these characteristics are provided by the primary influences that shape SOA, which we identified as:

• principles of service-orientation
• first-generation Web services concepts
• WS-* concepts

In the previous section of this chapter we covered the core standards that implement some service-orientation principles through first-generation Web services (and XML) specifications. Although there is some leeway as to what standards can be chosen (UDDI, for example, is not yet that common), for the most part, the first-generation Web services standards establish a commonly accepted core architecture and therefore are considered required components of contemporary SOA.

Most of the contemporary SOA characteristics we studied in Chapter 9 are optional, which means that we only need to pursue features of the characteristics we actually require. This is in line with the composite nature of SOA. As a result, the decisions we make regarding how we define our target SOA will be influenced heavily by how our requirements can be addressed or fulfilled by specific qualities of the architecture we are building.

Therefore, it is recommended that you identify the primary SOA characteristics you want your services to inherently support and promote. If you are building an application-level SOA that is destined to reside within an existing enterprise-wide SOA, then many of the required characteristics will have already been defined for you. However, if you are delivering your first service-oriented architecture, this becomes a critical decision point and one worth mulling over before proceeding with the design of service interfaces.

14.4.2. Choosing WS-* specifications

It is through the use of the many available WS-* specifications that we can build upon our foundation architecture extensions that implement features specific to our automation requirements. When you understand what characteristics or features you need your service-oriented architecture to support, you can begin exploring the possibility of those characteristics being realized through the use of the extensions provided by WS-* specifications.

Unfortunately, choosing which WS-* features we want as part of our service-oriented environment is not a matter of selecting a series of checkboxes on a form and clicking the "Apply" button. While the WS-* landscape continues to evolve, vendor support for some specifications will continue to remain inconsistent. Further, until a specification is fully implemented via a vendor platform, it is not uncommon for revisions to surface. Though parts of the WS-* arena remain volatile, other parts have become more settled.

Therefore, the key considerations for adding the features of a WS-* specification to your SOA is the maturity of the specification itself, and the available support it is receiving by product vendorsspecifically, vendors whose products you already are using.

14.4.3. WS-BPEL and SOA

Worth singling out at this point is the WS-BPEL specification. It is a good example of a WS-* extension for which relatively strong vendor support already exists. We first introduced concepts derived from WS-BPEL in Chapter 6 during our discussion of orchestration.

An operational business process language, such as WS-BPEL, is of immediate importance to our service design process because it enables us to create process services that establish the orchestration service layer (Figure 14.8).

Figure 14.8. WS-BPEL realizing the orchestration service sub-layer within our service layer.

A key advantage to working with WS-BPEL is that we are able to use its markup to create a process description with no ties to a particular implementation technology. Another reason we highlight WS-BPEL is because we use its syntax as part of the examples provided in Chapter 16, to demonstrate the creation of an orchestration layer for one of our case studies.