Session II – SOA Best Practices

Umesh Bellur

IIT Bombay

umesh[at]it.iitb.ac.in

Are Web services for you?

•If you answer “Yes” to any of the following business questions, consider using Web services:

– Do you want to interact more tightly with your business partners?

– Is there a requirement to link internal stovepipe applications/packages?

– Do you want to make legacy assets available for reuse?

– Is your system environment heterogeneous?Note that there is a place for both Web services and more “traditional” EAI approaches.

Usage scenarios

Addressing potential inhibitors

•The following are the most typical inhibitors to adoption. Most can be overcome:

– Over-enthusiastic expectations– Goal conflicts– General scepticism regarding maturity of

new technology– Security and performance concerns– Logistical and organisational issues– Skill deficiencies

The technical litmus test

•If you answer “Yes” to any of the following technical questions, consider using Web services:

– In your use case model, are other systems the primary actors in your system?

– Do you have to support a heterogeneous or unknown client environment?

– Do you plan to extend the reach of J2EE applications to application clients?

Technical litmus test(2)

– Do you already transfer XML documents via HTTP-GET or -POST?

– Do your rich application clients use proprietary communication channels and are your firewall administrators unhappy about this?

– Does the number of service providers in your environment vary?

– Is your existing infrastructure capable of handling a rather verbose text-based, self-describing message exchange format?

Layered Approach with Legacy Assets

Layers

• Layer 1: Operational systems layer. This consists of existing custom built applications, otherwise called legacy systems, including existing CRM and ERP packaged applications, and older object-oriented system implementations, as well as business intelligence applications. The composite layered architecture of an SOA can leverage existing systems and integrate them using service-oriented integration techniques.

• Layer 2: Enterprise components layer. This is the layer of enterprise components that are responsible for realizing functionality and maintaining the QoS of the exposed services. These special components are a managed, governed set of enterprise assets that are funded at the enterprise or the business unit level. As enterprise-scale assets, they are responsible for ensuring conformance to SLAs through the application of architectural best practices. This layer typically uses container-based technologies such as application servers to implement the components, workload management, high-availability, and load balancing.

Layers (2)

• Layer 3: Services layer. The services the business chooses to fund and expose reside in this layer. They can be discovered or be statically bound and then invoked, or possibly, choreographed into a composite service. This service exposure layer also provides for the mechanism to take enterprise scale components, business unit specific components, and in some cases, project-specific components, and externalizes a subset of their interfaces in the form of service descriptions. Thus, the enterprise components provide service realization at runtime using the functionality provided by their interfaces. The interfaces get exported out as service descriptions in this layer, where they are exposed for use. They can exist in isolation or as a composite service.

• Level 4: Business process composition or choreography layer. Compositions and choreographies of services exposed in Layer 3 are defined in this layer. Services are bundled into a flow through orchestration or choreography, and thus act together as a single application. These applications support specific use cases and business processes.

Layers (3)

• Layer 5: Access or presentation layer. Although this layer is usually out of scope for discussions around a SOA, it is gradually becoming more relevant. I depict it here because there is an increasing convergence of standards, such as Web Services for Remote Portlets Version 2.0 and other technologies, that seek to leverage Web services at the application interface or presentation level. You can think of it as a future layer that you need to take into account for future solutions. It is also important to note that SOA decouples the user interface from the components, and that you ultimately need to provide an end-to-end solution from an access channel to a service or composition of services.

Layers (4)

• Level 6: Integration (ESB). This layer enables the integration of services through the introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, often described as the ESB

• Level 7: QoS. This layer provides the capabilities required to monitor, manage, and maintain QoS such as security, performance, and availability. This is a background process through sense-and-respond mechanisms and tools that monitor the health of SOA applications, including the all important standards implementations of WS-Management and other relevant protocols and standards that implement quality of service for a SOA.

Approach

• Combine:– A top down business driven approach with– A bottoms up approach to leverage legacy

investments

• Results in:– High level business process functionality

externalized as large grained services– Smaller grained services are realized by

using existing legacy functionality. These are used to realize the high level services.

Two View Methodology

Steps of the methodology

Identification

• Identification:– High level processes or use cases form good

cases for large grained services exposed at the edge of the business or across lines of business

– Componentization of existing legacy systems leading to identification of low level services that can be used to implement the higher level ones.

– Goal oriented decomposition can also be used to identify services arising out of a need to satisfy goals of a business.

Specification

• Service categorization or classification into a hierarchy allowing larger grained services to be composed of smaller grained ones.

• Component Specification: The details of the component that implement the services are specified: – Data – Rules – Services it implements– Configurable profile – Variations – Messaging and events specifications and management

definition occur at this step

Key architectural decisions which must be made

Architectural Decisions

ServiceModeling

WSDL Creation

Granularity

Naming

ServiceMessaging

SOAPRuntime

TransportProtocol

Comm.Style

Encoding

Compression

ServiceMatchmaking

SOAin general

Client API

XMLParser

ProviderType

RequestorType

Validation

CharacterEncoding

Deployment

SystemArchitecture

otther

AgencyType

Implemen-tation

Modelling

Population

Access

Gateway,other

SecurityArchitecture

ManagementOperations

AccountingBilling

SessionManagement

Handling non-functional requirements (NFRs)

•Performance– Ensure that requirements are realistic– Build a small prototype at start of project

to check if criteria can be met

•Scalability– Design your services to be as stateless as

possible– Normal J2EE scaling strategies can be

applied

•Availability– Normal J2EE availability strategies can be

applied

NFRs(2)

• Robustness– Create an effective error handling

mechanism with SOAP fault handling– The product building-blocks are now

mature enough for prime-time

• Portability– This is an API (rather than interface) issue.

Stick to agreed industry standards/specifications such as JAX-RPC

Best practices: WSDL and modelling

• Follow the design by contract principle• Separate concerns and isolate interface from

implementation• Provide interoperable versions of your WSDL

specifications• Follow the bottom-up design approach by default• Expose coarse-grained interfaces• Avoid complex operation signatures, stick with request-

response• Stick to standard XML schema data types• Keep service, method, parameter and type names small

and simple• Apply general XML and XML schema best practices

Best practices: SOAP and messaging

• Use HTTP as the default transport, but consider alternative bindings

• Carefully observe the messaging overhead• By aware of the trade-off between security and

performance• Design your Web services to be as stateless as possible• Include, but do not rely on the HTTP SOAP action header• Try to leverage existing transport layer or XML

compression features• Be aware of the differences between JAX-RPC and

Apache SOAP

Best practices: UDDI and matchmaking

•Carefully evaluation which type of UDDI registry (private vs. public) is suited for your scenario

•Consider lightweight alternatives to UDDI

•Obey the best practices already established by UDDI.org

Best practices : SOA

• Clearly identify business need and project scope

• Decide carefully whether Web services are the right technology for your problem at hand

• Apply standards pragmatically: follow the 80-20 rule

• Use stateless session EJBs are provider type if EJBs exist in your architecture

• Do not over-architect, do not under-architect and develop incrementally

• Design for performance• Apply performance measurement best

practices• Test early and often