CBDI Forum CBDI Web Services Roadmap. Guiding the transition to Web Services and SOA
 
CBDI Knowledgebase

Real World Migration of Development Projects to SOA cont'd...

Introduction

By driving all development from a model, accelerated delivery, reduction of complexity and governance follow. Governance ensures consistency between model and implementation and is a key characteristic of MDA. From it flow many improvements in the quality and cost of development, for the entire project scope including legacy and other non-service oriented functionality.

In this report we will look closely at how MDA contributes to the task of building and integrating SOA in the heterogeneous enterprise. One of the classic difficulties faced by IT Directors is that ROI (Return On Investment) cases are hard to make for projects that clean up and unify architecture. Companies like to see obvious functional improvements before committing resources to software projects. A tool like OptimalJ has a distinct advantage in its ability to accelerate business-driven projects while ensuring that the code follows best practices and conforms to SOA.

OptimalJ starts with a business model where the important objects and their relationships to each other are modelled. These objects relate to the business domain and describe items such as: people, account, product, payment, etc. Services are included in the model, typically business operations such as "Open_Account", "Buy_Product" and so on. Once the model has been refined, OptimalJ generates an application model and from that working Java code. Developers add Java business logic to complete the solution and the tool builds and deploys the finished components to the server.

Using MDA to Move to SOA

Managing Complexity with Model-Driven Pattern-Based Development

In our introduction we said that MDA manages complexity. This is achieved by promoting application development to a higher level of abstraction, which focuses on business requirements rather than technological details. Developers can focus their creativity on the business functionality and leave OptimalJ to build architecture.

OptimalJ builds applications for the J2EE platform. Flexibility and power have shaped J2EE into a platform that requires many lines of source code and deployment descriptors. While Compuware's wholehearted adoption of OMG's MDA specification cannot remove complexity from J2EE it can provide a mechanism for managing it through application of established patterns. Patterns are a way of capturing a tried and tested solution to a problem in a generalized format that allows others to apply it to a particular problem. Patterns have become a standard approach in the Java world and OptimalJ's MDA implementation is a logical progression from manual identification and application of patterns to a more automated method.

"MDA bridges what has been a significant gap between business modeling and software development by ensuring that business models drive application development, not the other way around. Patterns, however, are key. While models help designers to reduce the complexity of the business process, patterns reduce the technology complexity. The combination of models and patterns, therefore, closes the gap between business and IT", Franco Flore, Senior Product Manager, Compuware

The benefits of using tried and tested patterns are apparent in the quality of the resulting applications and their timely delivery

Service Oriented Architecture (SOA)

SOA is important for enterprise IT because it provides the framework that unites the business model with the applications that provide the functionality required for efficient business. Without SOA IT systems become a disjointed collection of packages, functions and screens that consume ever-increasing resources to maintain and evolve. SOA imposes a direct correlation between business operations and software services, making it a simple task to maintain and re-factor new systems from existing services

The SOA concept includes some structural features that go deeper into the corporate IT system than Web Services. Where Web Services address the interoperability mechanisms to allow functions to be made public, SOA addresses the layering and structure of software. Enlightened organisations have been moving towards SOA by exposing core services in a loosely coupled way that reduces complexity, promotes re-use and improves agility. Some key features of SOA are:

  • Platform-independent interfaces
  • Loosely coupled
  • Business level granularity
  • Discoverable

Earlier attempts at SOA using technologies such as CORBA fell short because they could not provide full platform independence or easy communication. Web Services, using SOAP over HTTP to provide easier communication and WSDL to provide interface description, completes the technology stack needed for SOA. By bringing together the techniques perfected for web commerce, modeling methods and component-based development corporations have at their disposal all the tools needed to create an agile software infrastructure capable of integrating internal and external business transactions. The success of Web Services will be due to its industry-wide support, platform independence and modest demands on server infrastructure. Any corporation with an operational e-commerce web site has the necessary platform for Web Services.

The Business Services Bus


Figure 1 - The Business Service Bus

The Business Services Bus concept, first coined by CBDI Forum, is a way to tie together services into logical sets that reflect the structure of the business and are designed for wide-spread use across the enterprise. The Human Resources Bus would for example contain the set of services that underpin HR applications for the enterprise. The logical grouping and design of each bus ensures that there is minimal duplication plus uniformity in naming, ordering, and types of parameters. Each service forms a façade for the components, or other technologies, that implement the business logic. A top-down modeling approach is encouraged when designing the enterprise Business Services Bus; this helps to unify the business model and the technical implementation of business services.

Governance

The word 'governance' has the ring of politics about it and to understand why we throw this controversial term into the debate we must explore one common scenario facing the UML-driven team. A UML model is driven by the business problem as perceived by the analysts and business users. Once the application starts to take shape the business problem shifts in the light of experience of the prototype and a new process is needed to re-synchronize the model with the prototype code. In a large project with many developers, the model and the application drift apart and a point arrives where a reverse engineering exercise is tried. This often results in a model that is unintelligible, badly commented and laid out. So we now have a pretty model that doesn't reflect the code and a messy one that is true but unusable. Typically the analysts continue to work with their tidy model and the developers stick with the 'code view'.

Governance is our word for the ability of the tool to unite model and code so that it can't drift apart. This can be achieved best by unifying the tools used by the business modelers and the code developers. Using the extensible and open frameworks offered by IDEs such as NetBeans, Eclipse and JBuilder there is no reason why this shouldn't be achieved to the satisfaction of all concerned. Comparing the serious players in this field, only Compuware with its OptimalJ focuses on managing architecture implementation. That is to say, OptimalJ prevents the model from being changed through the Java code. This is achieved by a system of guarded and free blocks in the code. Code that implements a business requirement is added into the free blocks and this is preserved when the application is re-generated. Guarded blocks are blocked out by the code editor so that the model is never compromised by a change of the Java code.

Benefits in terms of quality, re-use and lower maintenance all follow from having a consistent model and application. Investment in the business model is protected for the future because new applications can be factored from parts or the entire model without any risk of losing bug fixes or enhancements made to the deployed application.

Changing Roles

We were interested in how Compuware see the roles of architect, analyst and developer changing where its MDA tool is in use. Clearly the system architect and analyst roles must be made easier by OptimalJ's approach but developers could be seen as being de-skilled. We asked:

Does MDA change the developer skills needed to build enterprise class applications? Is there reluctance from developers to adopt the MDA approach?

When using OptimalJ developers have less coding to do, as OptimalJ generates between 60% and 75% of the application. It is possible, however, to influence what type of code is generated because OptimalJ includes pattern-editing functionality enabling the customization and extension of OptimalJ's default patterns, which in turn, will influence the code that is being generated. The generated code is derived from the models by OptimalJ's Transformation Patterns resulting in pre-tested and thus high-quality code. Therefore, it isn't possible to change the generated code (protected in guarded blocks). Developers, however, have the opportunity to further define the application in the 'free blocks'. MDA compliant tools should provide a mechanism where developers can add their code to the generated code. This allows them to focus on the real added value of the application, which is adding business logic and they don't have to bother about specific low-level coding details. This allows developers to continue being creative and to focus on adding value by enhancing business logic, rather than building infrastructure. In this scenario developers should not be reluctant to adopt MDA but should see the benefits of embracing it.

Building the Business Case

Enterprise IT is emerging from a period in which central controls were relaxed in order to allow the business benefits and not system architecture to drive purchasing decisions. With these constraints it was difficult to impose any architecture on the collection of point solutions and packages that inevitably built up. Is it likely that a realistic return on investment case could be made for cleaning up the architecture?

We recommend that the only way to combine development productivity with a timely transition to SOA is to use tools that give you the architecture at no additional cost; i.e. with no extra development resource. MDA is a good candidate here because it can deliver functionality quickly, guarantee SOA in its new solutions but most importantly OptimalJ can integrate exiting resources into the new architecture, again with minimal cost.

OptimalJ: Management Overview

OptimalJ is a full implementation of OMG's MDA specification; unlike the previous generation of code generators it is standards based and generates J2EE code.

Domain Model, Application Model and Code Model

OMG's approach describes separate models; the Platform Independent Model (PIM) and the Platform Specific Model (PSM), which maps to code to create a viable application. OptimalJ implements these two models as the Domain Model and the Application Model, and maps the code to a Code Model. OptimalJ uses a set of rules known as Transformation Patterns to carry out transformation from one model to the next.

MDA's models force a separation of concerns as follows:

Platform Independent Models (PIMs) provide formal specification of the structure and function of the system and is independent of the computing platform. In OptimalJ this model contains the business objects and services. OptimalJ provides a subset of the full UML capability allowing analysts to specify business objects and services. Models can be imported from other UML tools.

Platform Specific Models (PSMs) are generated automatically from the PIM using OptimalJ and contain components that apply to the target platform and architecture. In this model the technical architecture is now visible at the level of components, web pages and services.

Code is generated from the PSM and includes all the source code, Java, deployment descriptors, web pages, SQL scripts and so on to run the application.

MDA describes the mappings needed to transform one model to the next and also describes the refinement and reuse of components in both the PIM and PSM. MDA builds on existing XML standards, for example UML uses the XMI (XML Metadata Interchange) standard to communicate structure of objects and interfaces and MOF (Meta Object Facility) is used to describe objects.

OptimalJ sits very solidly in the analysis, design, build and re-factor stages of the application development lifecycle. It leaves the infrastructure provided by the J2EE application server to sort issues of management, security routing etc. This should be seen as a clear benefit, especially in a time when the full standards stack is still emerging and no one wants to build any dependencies on non-standard server capabilities. Most would see that the lack of any 'black boxes' in the runtime implementation of an OptimalJ application as a 'must have' feature. After all why pick an open platform such as J2EE if you then become dependent on a 'closed' module from a tools vendor. Once you have a well modeled and 'blue print' Java application the down-stream benefits flow from the flexibility, re-use and modularity.


Previous Page Next Page
CBDI Knowledgebase

  © Everware-CBDI Inc 1999-2008