Considerations for choosing service layers

The service-oriented analysis process likely will have resulted in a preliminary identification of a suitable service layer configuration. The first step to designing SOA is deciding how you intend to configure service layers within your environment, if at all (Figure 14.3).

Figure 14.3. Designated service layers organize and standardize Web services within SOA.

Depending on the scope of your planned architecture, this step may require an analysis process that is highly organization-specific. Immediate and long-term goals need to be taken into account because when you choose a configuration, you essentially are establishing a standard means of logic and data representation.

The biggest question you will be faced with is: "Should we invest in building business services?" This one decision point deserves a great deal of attention. The answer to this question will set your SOA on one of two very different paths. To assist you with making this and other decisions relating to service layers, here are some high-level guidelines:

• Existing configurations If service layers already have been standardized within your enterprise, you should make every attempt to conform new service designs to these layers. The exception to this is if a need to alter the current service layer configuration has been identified. Then the scope of your project will include a change to the overall complexion of your enterprise's standard SOA.
• Required standards If you are building new types of services or service layers, ensure that these are delivered along with accompanying design standards. These standards must be written so that they apply to the services as part of this and future projects.
• Service composition performance Service compositions can impose a significant amount of processing overhead, especially when intermediary services are required to process the contents of SOAP messages. In this case, each hop between requestor and provider can result in validation, deserialization, and serialization steps. This can really add up, especially in environments not equipped with enterprise processors or accelerators. It is highly advisable to conduct performance tests prior to deciding on a multi-level service layer configuration.
• Service deployment When designing service layers that will produce solution-agnostic services, deployment can become a concern. In a highly distributed environment, reusable services that are centrally located can impose remote messaging latency on solutions that need to connect to them. Redundant deployment of services can solve this problem, but this approach also results in an administration burden. These and other deployment issues need to be assessed prior to proceeding with solution-agnostic service layers.
• Service versioning If you are planning to deliver reusable services as part of your service-oriented solution, ensure that you fully understand the extent to which future service requestors could possibly come to rely on them. After the service is deployed, extensions may be required to further complete the service's expected feature set. If these extensions result in changes to the initial interface, a versioning system will need to be in place to accommodate your solution and any other requestors that are using the service.
• Business services and XSD schema designs If your enterprise already has established a comprehensive XML data representation architecture, it is worth taking a look at your existing set of XSD schemas. These should be analyzed for potential compatibility issues with planned business services. This is especially important when considering the use of entity-centric business services, as these rely on the processing of document entities that would ideally be accompanied by entity-centric schemas.
• Business service maintenance If proceeding with the agile delivery strategy (as explained in Chapter 10), the on-going maintenance of business services needs to be planned for. As the top-down analysis proceeds, revisiting services to keep their business logic representation in alignment introduces a separate administration process that may need to tie into the versioning system mentioned earlier.