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.

Case Study

RailCo is not in a position to invest heavily in creating the perfect SOA at this stage. Therefore, qualities such as intrinsic interoperability must take a back seat to more practical requirements. Further, none of the products that comprise RailCo's current technical environment provide any further support for WS-* specifications that RailCo was already using as part of their previous Web services solution (described in Chapters 6 and 7).

However, at the same time, architects do not want to build an environment that will need to be overhauled again in the near future. Upon reviewing the list of characteristics offered by contemporary SOA, RailCo identifies extensibility as being one that is of foremost importance to its future goals.

By focusing on the creation of extensible services, it is believed that a quality SOA can be delivered now to service immediate needs, while still capable of being extended to incorporate future requirements as they arise.

Extensibility is not one of the characteristics that is implemented automatically by a WS-* specification. Instead (as explained in Chapter 9), it is a quality that is realized through design. Therefore, as RailCo proceeds to build its service designs, it will keep extensibility in mind. (Examples in the following chapter explain design decisions made by RailCo in consideration of extensibility.)

TLS, on the other hand, already has an SOA in place, supported by a set of design standards with an emphasis on promoting a number of SOA characteristics, such as reuse, discoverability, and interoperability.

A new characteristic TLS is interested in fostering throughout its service-oriented solution environments is a service-oriented business modeling paradigm. Due to the unavailability of an adequate orchestration engine during the development of its original B2B system, this first service-oriented solution delivered by TLS did not incorporate an orchestration layer.

Since then, though, their underlying technology has significantly improved its support for key WS-* extensions. Most notably, orchestration support has been added in the form of a WS-BPEL orchestration engine. As a result, the TLS Timesheet Submission Process we introduced in Chapter 12 will be defined as a WS-BPEL process definition in Chapter 16.

Figure 14.9 displays the resulting set of specifications that comprise TLS's expanded SOA.

Figure 14.9. A composed view of the SOA TLS is planning for the Timesheet Submission solution.

SUMMARY OF KEY POINTS

• The extensions required for an SOA generally depend on which of the contemporary SOA characteristics need to be realized.
• The ability to implement WS-* extensions is dependent on the maturity of the specification providing the extension and available vendor support.