In the wake of the latest product announcement from IBM, InfoQ talked to Bertrand Portier, Architect in the IBM Software Group and co-author of the “Building Business Solutions using the Rational SDP” RedBook. The book presents a Model-Driven-Development approach to service construction. It is based on IBM”s SOA Foundation which includes Lifecycle, Reference Architecture and Scenarios, but the concepts are general enough to be applied to other product stacks.
The book explores a fictitious case study (JK Enterprises) to help illustrate the modeling concepts and development processes.
After a short introduction on Governance and IBM's SOA Reference Architecture, the book proceeds to the main topic by defining the development process based on RUP. The book is leveraging IBM Rational Method Composer which has an open source equivalent on the Eclipse Platform: EPF (Eclipse Process Framework). EPF comes with a simplified version of RUP called OpenUP.
The book then addresses the importance of Modeling before applying a model driven development approach to IBM’s SOMA (Service Oriented Modeling and Architecture). The subsequent chapters apply this MDD approach to the development process defined above (identification, specification, realization, implementation and testing): business modeling, requirements modeling and traceability, service model, service design model.
InfoQ: What is Rational Software Delivery Platform?
Bertrand: This is the latest evolution of our tool suite with a very high level of integration between the tools in four areas: Architecture Management, Change and Release Management, Process and Portfolio Management, and Quality management. It is based on RUP of course.
InfoQ: What is SOMA?
Bertrand: SOMA is a method that supports the identification, specification and realization of Services. It starts from an analysis of the business needs and existing assets. SOMA was developed by IBM Global Services for its own usage. RUP for SOMA is a plug-in available at DeveloperWorks. This is the third generation of the plug-in and combines the previous RUP for SOA content and the content from the IBM Global Business Services (GBS) Service-Oriented Modeling and Architecture (SOMA) method.
We wrote this RedBook to associate a Model Driven Development (MDD) approach to SOMA. Our goal is to increase productivity and automate tasks as we see fit. Beyond better automation points, MDD enables transformation, validation, traceability and change impact analysis.
It makes a lot of sense to follow an MDD approach to delivering SOA solutions. Imagine, for example, having models of your SOA solutions for each of the five functional SOA solution stack layers and being able to transform models from a higher to a lower level of abstraction for each layer.SOA profiles, models and transformations have been created and successfully used in projects. They include, for example, the Unified Modeling Language (UML) Profile for Software Services and the UML to Web Services Definition Language (WSDL) transformation. Benefits of using MDD in the context of SOA include improved consistency, having SOA perspectives for all the different stakeholders, quality and productivity gains, and traceability of decisions made all the way to business requirements.
This kind of approach is essential in a dynamic business environment. Requirements change often, understanding the impact on the project of these “in-flight” enhancements has become a critical task. Conversely, if the architect needs to change its plan, we also quickly gather a view of the requirements that are impacted.
InfoQ: How does this RedBook relate to one on Service Creation Scenario?
Bertrand: The link is at the SOA Reference Architecture level (a.k.a SOA Solution Stack). This other RebBook focuses on the building blocks to support different scenarios and how they need to be combined. Our RedBook is focused on an end-to-end method supported by tools and based on a metamodel. The methodology starts with the Component Business Model, Business Process Models, requirements and analysis to derive the service model, and finally the design and implementation models. The scenario explain how to start a Service Oriented Architecture, where are the entry points, what are the steps you take to increase your level of maturity.
We also have new products, which support our approach, RAM for instance, the Reusable Asset Manager. This is a development-time asset repository that helps manage the lifecycle of software development assets. By asset we mean documents, UML models,, components, java code… These assets are packaged and submitted to the repository, where they are later on accepted and ratified as part of a process as reusable assets. They become available to your development organization to leverage for the development of solutions in future projects .
InfoQ: How important is the concept of Assemblies and Service Components in Service Orientation?
Bertrand: Assembly is important, and reassembly is even more important! One of the key advantages of following a service-oriented approach is that software development artifacts can be reused. In the Redbook, we define assemblies as groups of service component implementations, which can be deployed. We follow a software development process that allows for the identification, specification, realization, and implementation of the appropriate services and service components. Assembly consists in putting together instances of service component implementations (developed in- house, outsourced, or bought from external provider) for a solution. The development process ensures that the deployed assemblies are traceable to business requirements, and reusable by others.
IBM has been actively involved in the definition and standardization of the SOA programming model, including Service Component Architecture (SCA), and Service Data Object (SDO). More specifically, SCA defines a model for the implementation of these service components in a language of your choice (e.g., Java, PHP), and then the assembly of the components into a solution. You may refer to the Open SOA collaboration site (www.osoa.org) for more details.
InfoQ: Could you give us your perspective on Contract-Last and Contract-First?
Bertrand: Services can be identified both from a Top-Down approach starting with a Component Business or Business Process Model for instance, or from a Bottom-Up approach based on a detail analysis of legacy assets. When it is time to design and implement services, we recommend adopting a “meet-in-the-middle” (MIM) approach. One of the key success factors in SOA is to be able to reuse existing assets and integrate them in your Service Oriented Architecture. But, this needs to be done in alignment with the business. This is what the MIM analysis gives you. The goal of this analysis is to match the business process level with the systems’ interfaces. The top-down view gives you the scope to help identifying the assets that you will investigate in the bottom-up view. We actually also have a RedBook dedicated to the topic of “Legacy to SOA”.
Organizations start adopting registries and repositories (R&R) in the traditional SOA sense, but this is not enough, this is where Rational Asset Manager plays a critical role: it is the link between the SOA R&R and the models, design and code.
This approach described in the redbook involves many steps, no question about it. Since we have identified all the steps in the methodology it gave us the foundation to automate a lot of them using patterns. For instance, we have written a transformation from the use case model to the service model. This is what we call “Pattern Based Engineering”. We have implemented this approach in our tools over the last 12 months and this is a great complement to our run-time engines.
InfoQ: The book describes 12 SOA patterns, the first one emphasizes that Process Logic should be factored away from Composition Logic. How prevalent is this pattern?
Bertrand: Business process transformations into executable assets are optimized for BPEL. If you apply a straight transformation, you don’t necessarily create reusable elements. If you think that some aspects of the process are reusable, you need to create a decomposition based on sub-processes. This is where the state machine representing the lifecycle of business entities appear. Typically, a business process is sequence based, but business entity lifecycles are mostly even-based. It is very important to be able to factor your solution with these two elements if you want to ensure a consistent lifecycle across any business process, which manipulates the state of business entities.
InfoQ: Can you share your experience writing a redbook? Is it open to non-IBMers?
Bertrand: The program is based on a residency concept. Residencies are open to IBM professionals, and also business partners, customers, or professionals from the marketplace. All the authors (residents) work together for 6 weeks. Sometimes 4 weeks on site and 2 weeks remote. This collaboration is very fruitful, this is the most interesting activity in my opinion. The authors exchange their experience and best practices. Everyone brings a different point of view. You also need to come to an agreement and create a synthesis between the points of view.
InfoQ: Thank you for your time!