Exploring SOA Best Practices and Web Services

1. Session II – SOA Best Practices Umesh Bellur IIT Bombay umesh[at]it.iitb.ac.in

2. 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.

3. Usage scenarios

4. 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

5. 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?

6. 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?

7. Layered Approach with Legacy Assets

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. Two View Methodology

14. Steps of the methodology

15. 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.

16. 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

17. Key architectural decisions which must be made

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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