Developing SOA solutions using IBM SOA Foundation Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.3 4.0.3
Unit objectives After completing this unit, you should be able to: Describe roles and activities involved in the SOA Lifecycle Describe the activities engaged in by the developer during SOA lifecycle phases Identify IBM s SOA entry points and the characteristics of BPM and service connectivity entry points Identify the RUP workflows, activities and work products pertaining to the development of SOA solutions Describe UML 2 profile for software services List the various service identification techniques offered by RUP Describe the technique for identifying services based on a process driven approach Describe how WebSphere Business Modeler and Rational Software Architect support process driven service identification Describe how to identify mediation services Describe service specification and design using Rational Software Architect Describe the integration of Rational Software Architect and WebSphere Integration Developer Describe the activities involved in implementation, assembly of mediation services and service choreographies and the support for these activities within Rational Software Architect and WebSphere Integration Developer Describe the activities involved in the support and management of mediation services and service choreographies
Roles and activities in the SOA life cycle Business Analyst This role involves identifying and analyzing business processes and expressing them at a high-level for consumption by the rest of development team. Integration Developer This role focuses on integrating functional components across the enterprise into a secure, composite SOA enterprise application. The ESB is an important tool in achieving this integration. Software Architect Designs the services and SOA architecture. Application Developer Implements the service components identified in the design. Identifies reuse scenarios, and develops components for use across the enterprise. System Administrator Deploys, configures, tunes and troubleshoots composite applications.
Developer activities in the SOA life cycle Integration and Application Developer activities in the SOA life cycle: Model Work with Business analysts to understand the semantics of the business processes to be integrated or business services that need to be offered. This includes understanding the key performance indicators and business measures of the business process. Work with software architects to perform service-oriented analysis and modeling. This includes identification, specification, and design of business services, service choreographies and mediations. Assemble Create and assemble services (service choreography) into composite applications. Develop mediations. Deploy Work with the System Administrators to deploy service artifacts to test and production environments. Manage Work with System Administrators and business users in monitoring performance, problem determination and troubleshooting of deployed services.
IBM s SOA entry points Represents common scenarios found within SOA engagements to be used as starting points for SOA design and development. This course focuses on BPM and Service Connectivity.
Rational Unified Process overview The Rational Unified Process (RUP) is a product that provides a process framework. Rational developed RUP based on years of experience and practice.
RUP for SOA overview A RUP for SOA plug-in was made available in 2005. RUP for SOA extends the RUP Analysis and Design discipline with workflows and artifacts required for serviceoriented analysis and design. The content of this plug-in has been incorporated into the latest version of RUP Included in Rational Method Composer 7.0.
Rational Unified Process for SOA workflows RUP for SOA introduces two key workflows for analysis and design discipline: Identify Services: Part of Refine the Architecture workflow Design Services RUP for SOA uses the UML 2 Profile for Software Services for modeling service artifacts.
UML 2 profile for software services elements overview
Rational Software Architect overview Rational Software Architect Used by software architects Modeling and design tool based on UML2 Turns business models developed in WebSphere Business Modeler into SOA service specifications in UML, ready for development Supports plug-in design patterns (including GoF) Extensible mechanism for custom pattern development and re-use Rational Software Architect
Identify services workflow Select service identification approach. A number of approaches are available (discussed next). Identify service partitions. Organize your services into logical groups. Analyze existing assets. Look into re-using existing service assets. Identify services. Develop initial service specification. Define the collaborations, relationships and composition of these services needed to address the requirements. Specify the service interface.
Service identification techniques overview The Rational Unified Process for SOA provides the following techniques for service identification (in this case, the act of populating the Service Model with Service Specifications): Top-down, business-process driven Top-down, use-case driven Bottom-up, exposing existing assets Data driven Rule driven Identification Collaboration Data/Message Rule/Policy Assets Use Cases Business Processes
Top-down business process driven Candidate Service Tasks within a business process (for example, modeled with WebSphere Business Modeler or Rational Software Architect) are candidates for services.
Top-down business process driven activity diagrams UML Activity Diagrams can be used to detail business processes The swimlanes correspond to Business Workers (human roles and IT systems) This is done in the context of a business use case
Importing process models into Rational Software Architect from WebSphere Business Modeler If you use WebSphere Business Modeler for process modeling and design, you can export a model to a UML 1.4 XMI 1.1 file using the Rational UML Profile for Business Modeling You can then proceed to use RUP for SOA process and Rational Software Architect for service-oriented analysis and design Task Decision Stop node Alternate paths Control flow Business Item Annotation
Top-down, use case driven RUP business modeling A Business Use Case describes a business process from an external, value-added point of view. Business Use Cases are business processes that cut across organizational boundaries, possibly including partners and suppliers, in order to provide value to a stakeholder of the business.
Top-down, use case driven example This technique includes the use of business process modelling (via UML activities), but also performs additional analysis to identify business workers, human and automated. Sequence diagrams, class diagrams, etc are used to perform further business-level analysis Potential software services are identified from this analysis
Data driven identification It is often appropriate to introduce data management services that are responsible for maintaining the integrity of a specific part of the data/domain model. The data responsibilities of all services should be clearly specified. One common pattern is to introduce specific data services that are responsible for non-overlapping parts of the data model. All other services must access the data through these designated services
Rule driven identification Certain classes of solutions tend to rely heavily on the use of Business Rules to extract the variability from the solution and externalize such that the rules can evolve outside of the main application logic. Business rule Service specification for evaluating the business rule In many cases complex rules are aggregated into Rule Sets. These are much more of a match for the granularity of a service.
Bottom-up, exposing existing assets This is not simply about exposing the existing interface to a system as a web service. You need to consider the design characteristics of the service. The interface to the existing system may not follow good service design principles, for example: Operations may not be grouped into cohesive interfaces. Fine-grained operations where an SOA approach would use a single operation with a composite message type. Technology-specific object references may be passed in and out. Assets to be exposed might include: Legacy (for example, CICS) transactions Application (for example, SAP, Siebel) API, messaging or service interfaces Bespoke applications, J2EE,.Net, client/server, and so on Services available from partners Services identified in this way: Are likely to be more fine-grained Will often be used in the implementation of higher-level services May be suboptimal in terms of conformance to SOA design principles If so, they should be encapsulated by higher level services that do have good design characteristics.
Identifying mediation services Identify transformations: Are there any data or message structure or content mappings needed? (For example, between legacy systems and other services.) Do multiple interfaces exist which implement the same functionality and need to mapped? Identify protocol switches: Which protocols are being used? Identify transformations (for example, JMS to HTTP). Identify the need for monitoring: Do the requirements call for message logging, monitoring, metering of services? Identify enrichment requirements: For example, do message payloads need to be augmented (for example, date-stamped)? Identify merging and routing and distribution needs: For example, message routing or broadcasting to different service providers.
Service specification Model candidate services Model composition and collaboration Structure of the collaboration (Composite Structure Diagram) Communication between services (Sequence Diagram) Sequence Diagram
Service design activity Designing services from the service specification involves: Adding design details: Model service elements. Apply patterns. Employ design mechanisms. Refine service interface. Determining reuse strategy: Find patterns and mechanisms. Exploit existing RAS assets. Eliminating duplicate or unnecessary information from the service specification. Specifying additional details of services: Messages. Realizations.
Apply design patterns Use wherever appropriate for the service being designed, following project design guidelines. Typically incorporated as the design evolves. Frequently applied across a set of model elements. Typically deployed as RAS assets: The RAS provides a standard format for assembling, organizing, storing, and documenting reusable assets, including extensibility artifacts. Available from: developerworks Custom, in-house Third party
Message design Design the messages exchanged between services. Areas of focus for message design include: Message exchange patterns Connection with domain modeling Message granularity Performance Common message exchange patterns: Synchronous Request and Response One Way Message Notification Asynchronous Request and Response Publish and Subscribe Synchronous Request and Response Asynchronous Request and Response
Service implementation and assembly WebSphere Business Modeler Create, Simulate & Analyze As-Is Business Model Create Financial Reports & ROI Estimates UML 1 Create, Simulate, Analyze and Optimize To-Be Business Model Import business process model from WebSphere Business Modeler UML into RSA, BPEL into WID. Create Observation Model with KPIs & export to Monitor BPEL Implement and assemble services and mediations and choreograph business processes. Java, SCA, BPEL, Rational Software Architect Create & Manage System Requirements and Use Cases Software Architect Trace Requirements & Architect System Use Case Realizations Model Services Application Developer Rational Application Developer Implement services, & expose as Web Services Integration Developer WSDL, EAR Implement/Re-use or Choreograph services using BPEL, WSDL, etc. 2 Import service designs into WID from RSA. WSDL.. Configure Human Task Manager & Client WebSphere Integration Developer Integration Developer Configure & Use Mediations, Business Rules, State Machines, Web Services, Adapters, ESB, etc. 3
Service deployment to WebSphere Process Server and WESB 1. Package and deploy the business process and mediations into an Enterprise project representing the module (EAR) 2. Configure resources and container settings on the WPS or WESB through the Administrative console or by using the command line tools: Resources: SIBus, JNDI, JDBC, JMS, Staff plug-in provider, and so forth Business process container, Human task container, and so on Choreograph services using BPEL, WSDL, etc. WebSphere Integration Developer WebSphere Process Server WebSphere ESB Configure Human Task Manager (including Ad-Hoc) & Client Integration Developer EAR Configure resources on WebSphere ESB Configure resources on WebSphere Process Server Use Business Rules, State Machines, Web Services, Adapters, ESB, etc. Deploy/Run System Administrator
Service support and management During the post-deployment phase developers work with System Administrators and business users on various tasks: Monitor performance of services. Perform problem determination and troubleshooting of deployed services. Monitor the run-time process and gather runtime performance data. Business Analyst Create, Simulate & Analyze As- Is Business Model WebSphere Business Modeler Create Financial Reports & ROI Estimates Create, Simulate, Analyze and Optimize To-Be Business Model Developers may monitor business events within WPS. However typically WebSphere Business Monitor (WBM) is used for this purpose. Key Performance Indicators and business metrics, defined by the Business Analyst during the Model phase, are imported into WBM. Runtime data is then exported back into WBM for comparison against the observational model and KPIs. The business process can be optimized based on the results of this analysis. Run-time Statistics Create Observation Model with KPIs & export to Monitor WebSphere Business Monitor WebSphere Process Server WebSphere ESB IBM Tivoli Offerings Monitor and Manage Observation Data Monitor System Adminstrator
Business process management on the SOA lifecycle summary WebSphere ESB - Mediations - Integrate services
Unit summary Having completed this unit, you should be able to: Describe roles and activities involved in the SOA Lifecycle Describe the activities engaged in by the developer during SOA lifecycle phases Identify IBM s SOA entry points and the characteristics of BPM and service connectivity entry points Identify the RUP workflows, activities and work products pertaining to the development of SOA solutions Describe UML 2 profile for software services List the various service identification techniques offered by RUP Describe the technique for identifying services based on a process driven approach Describe how WebSphere Business Modeler and Rational Software Architect support process driven service identification Describe how to identify mediation services Describe service specification and design using Rational Software Architect Describe the integration of Rational Software Architect and WebSphere Integration Developer Describe the activities involved in implementation, assembly of mediation services and service choreographies and the support for these activities within Rational Software Architect and WebSphere Integration Developer Describe the activities involved in the support and management of mediation services and service choreographies