Considerations for positioning core SOA standards

This second step within the SOA composition sub-process requires that we establish the foundation standards that will form the basis of our architecture. On the surface, this may seem like a pretty easy task, given that the core family of standards most SOA vendors support is provided by a very commonly accepted set of XML and first-generation Web services specifications (Figure 14.4).

Figure 14.4. SOA can structure the manner in which common XML and Web services standards are applied.

However, this step is not limited to simply picking and choosing what we want. We are required to properly position these standards so that they end up supporting the key characteristics we need our SOA to deliver. Therefore, this section consists of a series of discussions about how the utilization of core XML and Web services standards is commonly affected when utilized within the design parameters of a service-oriented architecture.

14.3.1. Industry standards and SOA

Even though we are creating abstract service designs, they still are realized in a physical implementation through the use of specific Web services markup languages. These languages originate from published specifications of which different versions in different stages of maturity exist. New versions of a specification can alter and extend the feature set provided by previous versions.

It therefore is important to ensure that your SOA is fully standardized with respect to the specification versions that establish a fundamental layer of your technology architecture. This not only ensures standardization within an organization, it also expresses consistent metadata to any services with which external partners may need to interface. This, of course, promotes interoperability.

Figure 14.5 recaps the core specifications that commonly are found in SOA. Let's discuss these further to explore how they can influence our service designs and how the standards themselves are shaped by and positioned within SOA.

Figure 14.5. The operational relationship between core SOA specifications.

 

14.3.2. XML and SOA

Fundamental to everything that comprises a contemporary SOA is data representation via XML. Practically all of the specifications within the Web services platform are expressed through XML and natively rely on the support and management of XML documents to enable all forms of communication. Further, for any SOA to be truly successful, it must build upon and remain in alignment with the underlying XML data representation architecture. This can raise various issues worth thinking about during the service-oriented design phase, including:

RPC-style versus document-style SOAP messages

To accommodate RPC communication, traditional data representation architectures tend to shape XML documents around a parameter data exchange model. This results in a fine-grained communications framework within distributed environments that inevitably leads to the use of RPC-style SOAP messages. This further conflicts with the document-style messaging model preferred by many WS-* specifications (as also explained in the SOAP and XML section).

Auto-generated XML

Many development tools offer the ability to provide auto-generated XML output. XML may be derived in numerous ways resulting in an instant XML data representation of a data model or data source. While useful to fulfill immediate conversion or data sharing requirements, the persistent use of auto-generated XML can lead to the proliferation of non-standardized data representation.

For example, when XML is auto-generated from different sources, the resulting XML documents tend to become inconsistent in structure and context and often vastly differ from those custom developed according to in-house standards. This causes problems with SOA, which relies on a unified data representation to promote a vision of enterprise-wide interoperability and federation.

Fitting SOA on top of an established XML data representation architecture

Steps can be taken to marry an established XML data representation environment with SOA. For example, it is highly advisable to ensure that the existing XML data representation architecture is fully standardized prior to moving to SOA. Even if the standards are not in complete alignment with how your services will need to express corporate data, it is important that the existing data representation be consistent and predictable. After standardization has been achieved, service abstraction can be used to bridge representation disparity.

The most effective way to coordinate this type of migration is to create a transition plan. Such a plan would include transition phases that specifically address XML compatibility issues.

14.3.3. The WS-I Basic Profile

The Basic Profile is the result of WS-I efforts to assemble a set of mature, core specifications that comprise a commonly supported and well aligned Web services platform.

Specifications are evaluated individually on a version by version basis. Many organizations turn to the Basic Profile because complying to its rules guarantees a level of industry-wide conformance.

For example, versions 1.0 and 1.1 of the Basic Profile propose that organizations standardize on the following specifications:

• WSDL 1.1
• SOAP 1.1
• UDDI 2.0
• XML 1.0
• XML Schema 1.0

Further, the Basic Profile dictates how features of each specification should and should not be implemented. This document therefore introduces a series of design standards of its own, targeted primarily at resolving potential interoperability issues.

Note that WS-I profiles are themselves versioned. A requirement, therefore, to using these profiles is that your current development tools support all of the specification versions referenced by a specific profile version.

Listed here are some examples of the design standards provided by the Basic Profile:

• SOAP envelopes cannot contain Document Type Declarations or processing instructions.
• The use of the SOAP encodingStyle attribute within SOAP envelopes is highly discouraged.
• Required SOAP header blocks must be checked prior to proceeding with the processing of other header blocks and the message contents.
• When a WSDL part construct (within the message construct) uses the element attribute, it must reference a global element declaration.
• The sequence of elements within the SOAP Body construct must be identical to the sequence established in the corresponding WSDL parts construct.
• The WSDL binding element can only use the WSDL SOAP binding.

Use of the WS-I Basic Profile is not only recommended if you are required to deliver WS-I compliant solutions, as explained in the Use WS-I Profiles even if WS-I compliance isn't required design guideline in Chapter 15.

14.3.4. WSDL and SOA

The creation of WSDL definitions is an important part of the SOA delivery lifecycle. The service interface is the focal point of the service-oriented design phase and the primary deliverable of each of the service design processes. WSDL definitions are the end result of business and technology analysis efforts and establish themselves as the public endpoints that form a new layer of infrastructure within a service-oriented enterprise. Some of the key design issues that relate to WSDL design within SOA are highlighted here:

Standardized use of namespaces

WSDL documents are comprised of elements associated with different specifications, including SOAP, XML Schema, and the WSDL specification itself. These are further supplemented by user-defined elements. Namespace standardization therefore becomes a primary concern. (The Use namespaces carefully design guideline provided in Chapter 15 emphasizes this issue further.)

Modular service definitions

As with many XML and WS-* specifications, WSDL supports the capability for service definitions to be composed. This means that you can modularize your WSDL documents to facilitate reuse and centralized maintenance. (See the Consider using modular WSDL documents design guideline provided in Chapter 15.)

Compatibility of granularity

Service interface granularity ideally corresponds to XML document granularity. However, the "WSDL first" design approach often conflicts with existing XML document structures. If anticipated, these challenges can be dealt with by incorporating design-time measures, such as the use of an additional service abstraction layer.

14.3.5. XML Schema and SOA

XML Schema definitions (or XSD schemas) establish data integrity throughout service-oriented architectures. They are used intrinsically by many WS-* specifications but are most prominent in their role as defining a service's public data model. Following are some considerations as to how XSD schemas can be positioned and utilized in support of SOA.

Modular XSD schemas

XSD schemas can be broken down into individual modules that are assembled at runtime using the include statement (for schemas with the same target namespace) or the import statement (for schemas with different target namespaces). Because WSDL documents also can be modularized, the XSD schema contents of the WSDL types construct can reside in a separate document.

Schema modularization establishes a flexible data representation architecture that fits nicely into the composable world of SOA. XSD schema modules can provide various definitions that can be reused by different WSDL definitions that process messages with identical or similar payloads. Further, entity-centric XSD schemas can be designed to represent specific information sets that correspond to corporate entity models. This directly supports the business-centric aspects of contemporary SOA as implemented by the entity-centric business service layer.

Document-style messages and XSD schemas

The document-style SOAP messages required by SOA are increasingly intelligence-heavy and therefore place a greater emphasis on advanced validation requirements. For example, there can be a tendency to bundle groups of XML data into a single SOAP message.

The use of extensible or redefined schemas may, therefore, be required when building documents that represent multiple data contexts. However, even the advanced features of the XML Schema Definition Language may be insufficient. Supplementary technologies (XSLT, for example) may be required to implement extensions, such as conditional validation.

14.3.6. SOAP and SOA

SOAP messages are what fuel all action within contemporary SOA. They are therefore considered just as fundamental to service-oriented environments as WSDL definitions. Following are two primary areas in which SOAP messaging can be affected.

SOAP message style and data types

Probably the biggest impact SOA can have on an existing SOAP framework is in how it imposes a preferred payload structure and data type system. This relates specifically to the style attribute used by the soap:binding element and the use attribute assigned to the soap:body element, as explained in the WSDL language basics section in Chapter 13 and discussed in the Use the SOAP document and literal attribute values guideline at the end of Chapter 15.

Because introducing SOA into RPC-style distributed environments can inhibit the potential of many WS-* specifications that expect document-style payloads, changes need to be made to accommodate SOA requirements. For example, RPC-style approaches support the transmission of granular XML documents with targeted data. This leads to the creation of many granular, parameter-type XML documents. Therefore, these documents may need to be bundled to support the coarser grained, document messaging model.

The use of schema modules may be required to accommodate the assembly of unique SOAP message payloads from differently structured XML data sources. In the end, though, standardization is key. Consistent XML document structures will accommodate the runtime assembly of document-style SOAP payloads.

SOAP headers

Because a WSDL definition describes a service, it is the primary deliverable of each of our service design processes. However, it only provides a partial description of the SOAP messages required for services to communicate within contemporary SOA. While the XSD types used by WSDL definitions define and validate the contents of a SOAP message's Body construct, they do not typically supply information regarding SOAP header blocks implemented via WS-* extensions.

Metadata embedded into SOAP message headers alleviates the need for a service to contain logic specific to message exchange scenarios. The SOAP headers used by messages processed by a service depend primarily on the WS-* specifications supported by the service-oriented architecture in which the service resides. Therefore, the identification and definition of SOAP headers is tied to the establishment of our SOA and its supported WS-* specifications.

These extensions shape the overall messaging framework and determine the extent to which SOAP messages self-govern their message path and the processing they ask of services that receive them. Understanding the extent of metadata abstraction allows us to adjust service operations accordingly.

14.3.7. Namespaces and SOA

An easily overlooked part of establishing a standardized SOA is the information domain organization system provided to us through the use of namespaces. Namespaces in SOA cannot be created arbitrarily. They must be viewed as identifiers of business or technology domains and accordingly applied as qualifiers for corresponding WSDL elements.

The WS-I Basic Profile provides a set of best practices for implementing namespaces within WSDL definitions. However, additional design standards are required to ensure that namespaces are used properly in XML documents outside of WSDL definition boundaries. See the Use namespaces carefully guideline in Chapter 15 for some more information.

14.3.8. UDDI and SOA

UDDI provides an industry standard means of organizing service description pointers to accommodate the process of discovery through service registries. When implemented, UDDI typically represents an enterprise-wide architectural component positioned to provide a central discovery mechanism within and across SOAs.

Therefore, depending on the scope (application-level, enterprise-wide, etc.) of the service-oriented architecture being designed, UDDI may become one of the technologies established as part of the overall service-oriented environment.

While UDDI enables the discovery of service descriptions and is also one of the core specifications identified by the WS-I Basic Profile, some organizations are resorting to traditional directory-based approaches (such as LDAP) to keep track of their service descriptions. Regardless, our service design processes take potential discovery into account by promoting the creation of intuitive service interface designs and the documentation of supplementary metadata (as explained in the Document services with metadata guideline in Chapter 15).

Case Study

In an attempt to design an environment that fosters service-orientation from the ground up, RailCo discards the architecture that hosts its existing Web services.

It then completes the following steps:

1.	Existing forms of XML data representation are studied, and it is discovered that, to date, little actual XML formatted data is being utilized by RailCo solutions. This is seen as a positive development, as the XML usage that is identified has been implemented in a highly non-standardized manner. In support of this new project, XML data representation standards are established to position XSD schemas that represent key RailCo information sets using a document-style format.
2.	The document + literal SOAP message type is chosen as the preferred messaging model. Existing development tools and application servers are reviewed to ensure that support for this style of SOAP message is consistent. This, surprisingly, reveals that one of RailCo's products only provides support for RPC-style SOAP messaging. Fortunately, replacing this product is not too expensive, nor is the change disruptive, as no other Web services-based solutions exist.
3.	Namespaces are standardized to reflect the creation of planned WSDL definitions and XSD schemas.
4.	Finally, it is decided that there is no need for a discovery component within their planned SOA. Therefore, UDDI is excluded as part of the core standards within the RailCo SOA (Figure 14.6).   Figure 14.6. A composed view of the core standards that comprise part of RailCo's planned SOA.

TLS already underwent this process during the delivery of their first service-oriented solution. Because their existing SOA was the result of an extensive top-down delivery process, TLS architects are confident that they will be able to build upon this environment without further re-evaluation.

SUMMARY OF KEY POINTS

• The WS-I Basic Profile provides a convenient guideline by which to choose specific versions of core SOA specifications. Relevant specifications identified by the Basic Profile include XML, XML Schema, WSDL, SOAP, and UDDI.
• SOA imposes design requirements and preferences that further affect how features within these primary specifications are utilized and positioned