Abstract:
A system and method that implements top-down and bottom-up model-driven transformations between platform-independent (business view) modeling approaches and platform-specific (IT architectural) models. On the business level, business view models may be expressed in, but not limited to ADF or UML2, whereas on the IT architecture side, service-oriented architectures with Web service interfaces and processes are specified in business process protocol languages including, but not limited to, BPEL4WS, or workflow definitions. An architecture and a transformation method based on typed information flows automatically transforms platform-independent business models into executable information technology (IT) architecture specifications constrained by a specific IT platform, and vice versa. The models generated span the entire life cycle of a software system and ease the software production, deployment and maintenance tasks. That is, the different models generated for the same system are “linked” in a way that relevant changes in one model may be propagated to the other models to keep the model set consistent.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to the creation of on-demand business systems, and more particularly, to a novel application that provides business to information technology (IT) transformation and vice-versa. 
     2. Description of the Prior Art 
     An “on demand business” is one that integrates its business processes end-to-end across its enterprise as well as with its trading partners such that it can respond with speed and agility to changing business conditions. This requires tight integration between the operational specification of a business and its execution mechanisms. 
     Model-driven architectures (MDA) have been proposed by the Object Management Group (OMG) which is a consortium that produces and maintains computer industry specifications for interoperable enterprise applications. Model-driven architectures are proposed to reinforce the use of an enterprise architecture strategy and to enhance the efficiency of software development. The key to MDA lies in three factors: 1) the adoption of precise and complete semantic models to specify a system and its behavior; 2) the usage of data representation interchange standards; and 3) the separation of business or application logic from the underlying platform technology. 
     Perhaps the most important is the model representations. Models can be specified from different views: the business analyst&#39;s or the IT architect&#39;s view, and they can be represented at different levels of abstraction. MDA distinguishes between platform-independent (PIM) and platform-specific (PSM) models, but other models may be used to describe the different aspects of a system. 
     For example, on the PIM side, business process models are used to reflect a business analyst&#39;s or consultant&#39;s view of a business process. Typical representatives of these models are the ARIS tool set by IDS Scheer (as described in A. W. Scheer, F. Abolhassan, W. Jost, and M. Kirchner  Business Process Excellence—ARIS in Practice . Springer, 2002), the ADF approach by Holosofx/IBM (as described in E. Deborin et al.  Continuous Business Process Management with HOLOSOFX BPM Suite and IBM MQSeries Workflow  IBM Redbooks, 2002.) or UML2 activity models (Unified modeling language superstructure, version 2.0. 2 nd  revised submission to OMG RFP ad/00-09-02, 2003). On the PSM side, several models are employable such including  IT architectural models and IT deployment models . An IT architectural model adopts a specific IT architectural approach. For example, a service-oriented architecture can be based on Web services (as described in E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, The web services description language WSDL http://www-4.ibm.com/software/solutions/webservices/resources.html, 2001) or an ERP architecture can be based on workflows (as described in F. Leymann and D. Roller.  Production Workflow . Prentice Hall, 2000). Thus, the IT architectural model will comprise certain types of architecture (or platform)-specific IT solution components such as Web services or workflows, but it will still be platform-independent in the sense that it abstracts from a (vendor-) specific runtime platform. Under this point of view, IT architectural models combine aspects of PSMs and PIMs. 
     Besides being representative of a system, a model must be further analyzable by algorithmic methods in order to be useful. For example, the fundamental properties of the behavior of a system should be verifiable in a model, and different models of the same system should be “linked” in a way that relevant changes in one model can be propagated to the other models to keep the model set consistent. 
     Thus, as model-driven architectures aim at spanning the life cycle of a system from modeling and design to component construction, assembly, integration, deployment, management, monitoring and evolution, it would be highly desirable to provide system tools and algorithmic techniques that support the evolution of models and the consistency of different modeling views of the same system. Although models can evolve independently of each other and one model might represent system aspects that are irrelevant for another model, fundamental features of a system will be present in all models. It is therefore necessary to identify these fundamental features, to detect feature changes in a model and to propagate those changes automatically to the other system models. 
     Thus, it would be highly desirable to provide a solution based on model-driven transformations between PIM and PSM applications. 
     SUMMARY OF THE INVENTION 
     The present invention thus is directed to a system and methodology based on model-driven transformations, and particularly to a Transformation Engine (TE) that addresses the “linkage problem”. 
     According to a first aspect of the invention, there is provided a top-down model-driven transformation approach that automatically transforms platform-independent business models into executable information technology (IT) architecture specifications constrained by a specific IT platform. The system and method comprises: 
     a computing device programmed for receiving a machine-readable representation of a business model, the computing device comprising: 
     a means for analyzing the specifications to automatically identify processes comprising discrete process steps that execute specific tasks in the process, and, information entities that are processed by the process steps; and, 
     a means for automatically developing representations in the form of one or more graphs having nodes representing the process steps and links depicting a flow of information entities between process step tasks; and, 
     a means for automatically synthesizing executable IT architecture components from the developed representations. 
     According to a second aspect of the invention, there is provided a bottom-up model-driven transformation approach that automatically transforms information technology (IT) architecture specifications constrained by a specific IT platform into a platform-independent business model view. The system and method comprises: 
     a computing device programmed for receiving executable IT platform components, the computing device comprising: 
     means for automatically developing representations in the form of one or more sub flow graphs according to one of more IT architecture specifications, a sub flow graph having nodes representing process steps and links depicting a flow of information entities between process step tasks; 
     means for automatically analyzing the one or more sub flow graphs and developing representations in the form of a process graph, the means automatically identifying processes comprising discrete process steps that execute specific tasks in the process, and, information entities that are processed by the process steps; and, 
     a means for automatically generating a platform-independent business model view from the process graph. 
     It is understood that both top-down and bottom-up transformations prolong the life cycle of the business view model. It is no longer only actively used in the design and analysis phase, but plays an active role in the entire system life cycle by constraining the IT architecture. 
     Advantageously, the invention is incorporated in different business process modeling approaches and extracts structured information flows as their underlying common modeling principle. It describes top-down and bottom-up transformations between process graphs and information flow graphs. The models generated span the entire life cycle of a software system and ease the software production, deployment and maintenance tasks. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
       The objects, features and advantages of the present invention will become apparent to one skilled in the art, in view of the following detailed description taken in combination with the attached drawings, in which: 
         FIG. 1  illustrates model-driven transformations between PIM (e.g., business view models) and PSM applications (e.g., IT architectural or Deployment models) according to the invention. 
         FIGS. 2(   a ) and  2 ( b ) are diagrams depicting the architecture of the transformation engine according to the invention; 
         FIG. 3  is an example UML2 representation of a travel agency example; 
         FIG. 4  is an example ADF representation of the travel agency example of  FIG. 3 ; 
         FIG. 5  is a process graph view of the example travel agency scenario depicted in  FIGS. 3 and 4 ; 
         FIG. 6  shows the Flight Service internal sub-process and its refinement in a separate ADF process model; 
         FIG. 7  illustrates the individual sub-flows  35   a – 35   c  for the respective three object types (trip request, hotel request, flight request) that are discovered in the travel agency (trip handling) example of  FIGS. 3 and 4 . 
         FIG. 8  illustrates the internal and external process boundaries of the process steps that constitute the trip request handling process. 
         FIG. 9  illustrates the message control flow of the example travel agency trip handling process. 
         FIGS. 10(   a )– 10 ( c ) illustrate the respective three state machines for the discovered business objects of the travel agency example. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       FIG. 1  illustrates a model-driven transformation solution according to the invention and depicting conceptually the bi-directional transformation between a PIM  12  (e.g., business view models) and PSM applications  14  (e.g., IT architectural  14   a  or Deployment models  14   b ). Central to this solution is a Transformation Engine that automatically performs top-down and bottom-up model-driven transformations between PIM and PSM, wherein the top-down transformation starts from the business view model of a system or process as the PIM and derives a platform-specific IT architecture model, the PSM. This ensures that the business model determines the relevant elements of the IT architecture. It transforms the blueprint of a system as it is envisioned during a business analysis and re-engineering process into an IT architecture that will implement that blueprint. The automatic derivation of the architecture allows developers to concentrate on the refinement of the architectural model into a deployment model and to optimize this deployment. The bottom-up transformation takes a platform-specific IT architecture model as input and abstracts it into a business view model. It allows the propagation of structural changes in the IT architectural model back to the business view model and thereby supports communication from IT people to business people. 
     More particularly, as shown in  FIG. 2(   a ), a transformation engine (TE)  20  transforms different business view models  12  automatically into Information Technology (IT) architectural models  14 , and vice versa. As will be explained in greater detail herein, at both sides, model-independent layers have been introduced into the TE architecture  20  so as to enable handling of a variety of PIMs and PSMs, as shown in  FIG. 2(   b ). For example, on the business view side, shown in  FIG. 2(   a ), the TE engine  20  handles modeling approaches that structure a business process into atomic process steps and subprocesses. Atomic process steps are not further refined, whereas subprocesses can be nested within each other and lead to a hierarchical process model. The process elements (subprocesses, process steps) are linked by typed information entities that present the flow of control and physical data objects or event messages between the process elements. As shown in  FIG. 2(   b ), representatives of these business modeling approaches include ARIS, ADF  12   a , UML2  12   b  activity models, and Business Operational Specifications  12   c  (hereinafter “BOpS”), a modeling approach available by assignee International Business Machines Corp. (IBM Research). These modeling approaches all support hierarchical process models that describe processes as structured information flows across distinguishable process elements. 
     The transformation engine  20  particularly includes specific readers and writers for each modeling approach. When performing a top-down transformation, as shown in  FIG. 2(   a ) indicated by downward arrow flow, a reader  22  reads in a specific business view model  12  and maps it to a so-called process graph  25 , which is developed as a generalization of the information-flow models. The process graph  25  is then further analyzed to extract  30  the information type-specific subflows and then decomposed into flow graphs  35  representing these subflows. The actual transformation therefore takes place between the process graph  25  on one side and the flow graphs  35  on the other side. From the flow graphs  35 , an IT architecture-specific synthesis method  40  generates solution components  14  that are required in the desired IT architectural model. In a preferred embodiment, as shown in  FIG. 2 , adaptive business objects (ABOs)  50 , which describe persistent abstract business documents (referred to interchangeably herein as ADocs) whose life cycle is controlled by an associated state machine, business protocols between Web services specified as BPEL4WS processes  60 , or workflows represented in Flow Definition Markup Language (FDML)  70  are generated. 
     When performing bottom-up transformations, as shown in  FIG. 2(   a ) indicated by upward arrow flow, the TE  20  is provided with an IT architectural model comprising a set of solution components  14  from which it synthesizes the flow graphs  35  that are merged into a single process graph  25 . This process graph can then be mapped to a specific business view model  12  using a model-specific writer  26 . 
     UML2 Activity and ADF Model Approaches 
     The generalization of business view models to process graphs is now provided by way of an example, namely a trip-handling process of a travel agency.  FIGS. 3 and 4  show respective UML2 activity model and an ADF model of this example process. As indicated in  FIGS. 3 and 4 , a travel agency  100  receives trip requests from customers  101 , e.g., over a telephone  102 . The requests are recorded in trip documents  105 , from which several flight requests  107  and hotel requests  108  are derived by an agent  104 . The flight and hotel requests are handled by specialized services  110 ,  112  respectively, that receive these requests from the travel agency. The services report their success or failure in booking the requests back to the travel agency. If all requests were successfully handled, the agency puts together the trip documents  115  for the customer  101  and confirms the travel itinerary  120 . If one of the services fails to make a requested reservation, the agency immediately informs the other service to put all reservation requests on hold and contacts the customer  101  to revise the trip itinerary  125 . In the models of  FIGS. 3 and 4 , various process steps (create itinerary, confirm itinerary, re-plan itinerary), information items (order event (OE), trip re-quest (TR), flight request (FR), hotel request (HR), booking failure (BF)) and decision/choice points are recorded. 
     The UML2 and ADF modeling approaches of respective  FIGS. 3 and 4  have several features in common. First, they structure a process into different process elements including: 1) subprocesses, which can optionally be further refined and which are either internal or external given the current view of the process; 2) atomic process steps that actively produce, or receive and modify one or more information entities; and 3) control steps that inspect and merge information entities and then modify the control logic of a process depending on the information content. Second, both models capture the flow of information entities, which can be object documents of a particular type, events, or any other messages. Arbitrary types of information entities may be defined by a modeler and then used to annotate links between the process elements. 
     Table 1 summarizes the specific elements from each modeling approach and how they fit into the categorization as subprocesses, process steps, control steps, and information entities. 
     
       
         
               
             
               
               
               
             
               
               
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Categorization of modeling elements in ADF and UML2 
               
             
          
           
               
                   
                 ADF (FIG. 4) 
                 UML2 (FIG. 3) 
               
               
                   
                   
               
             
          
           
               
                   
                 subprocess 
                 process 
                 activity 
               
               
                   
                   
                 external task 
               
               
                   
                   
                 external entity 
               
               
                   
                 process step 
                 task 
                 action 
               
               
                   
                 control step 
                 decision 
                 decision, merge 
               
               
                   
                   
                 choice 
                 fork, join 
               
               
                   
                 information entity 
                 Phi 
                 token 
               
               
                   
                 flow 
                 connector 
                 link 
               
               
                   
                   
                 stop 
                 initial marker 
               
               
                   
                   
                 goto 
                 final marker 
               
               
                   
                   
               
             
          
         
       
     
     While the graphical models of  FIGS. 3 and 4  are informative, the dynamic behavior of the process depicted may be subject to different interpretations as many details of the process behavior are either not visible in the model representation or, contained in natural language descriptions that are not accessible to an automatic analysis tool. The only unambiguous information that the models provide is the specification of the static flow of typed information entities between process elements. Any dynamic behavior might be sketched in the model, for example the interruptible region  130  identified in the UML2 model of  FIG. 3 , but no truly formal semantics underlies the model specifications, which would enable a tool or a user to derive an unambiguous interpretation. 
     According to the invention, the process graph representation possesses formal, state-based operational semantics that enables the representation of structured information flows in an unambiguous way. Particularly, the process graph  25  ( FIG. 2(   a )) is a formal model that represents structured information flows and only depicts the structure of the process and the principal information flow between process elements, i.e., it is an abstract process model that does not allow the study of the dynamic behavior of the process. 
       FIG. 5  illustrates the process graph view  25  that is generated from the UML2 and ADF models provided in the trip-handling examples of  FIGS. 3 and 4 . For each modeling approach, a specific reader, e.g., a Java or XML parser or like software tool, analyzes the model description and extracts model elements that may be mapped to the process graph elements following the basic mapping principles shown in Table 1. 
     In  FIG. 5 , repository symbols  28 ,  29  are used to depict control steps in order to emphasize that control steps inspect the state of objects, but do not change them (in contrast to the other process elements). In  FIG. 5 , the interruptible region  130  in the UML2 activity model and the lightning arrow  131  from the replan itinerary process step  125  into this region (shown in  FIG. 3 ) are mapped to a new subgraph including an event link from this process step to a new control step  29  (labeled EVAL2), from which event links  32  lead to all process steps or sub-processes in the region, e.g., Internal process steps  111 ,  113 . If a model establishes a link between two process steps without assigning to it any information item, which is usually known as a control link, then a new event constant is generated and the control link is mapped to an event link in the process graph. This guarantees that the ordering between two activities that are linked with the control link is preserved in the process graph via the event link. 
     Note that a process graph is flat if it has no hierarchical structure. If a business view model includes a hierarchical process model where a subprocess at a higher level is refined with a separate process model at a lower level, then the subprocess vertex in the process graph may be replaced by the process graph obtained from the lower-level process model if desired. It is up to a modeler to decide whether subprocesses should be kept as abstract process steps or refined into their subprocesses. The replacement only succeeds if the signature of the subprocess vertex is identical to the signature of the subprocess graph, which is the declaration of incoming and outgoing information entities for the subprocess. 
       FIG. 6  depicts the Flight Service internal sub-process  111  and its refinement in a separate ADF process model  111 ′. The Phi types of the ingoing and outgoing links  121 , 122  respectively of the ADF process node  110  and the ADF subprocess model  111 ′ must be the same. The model-specific readers follow very closely the informal semantics as it is described in the modeling guidelines of the various approaches. The example process graph  25  for the trip handling process  100  may be obtained in this way if the modelers provide precise information about the types of information entities that flow between the process elements in each model. In the UML2 model ( FIG. 3 ) this requires that token types be identified that flow along the links, whereas in the ADF model ( FIG. 4 ), different types of Phis have to be defined and related to either an event category, an object category, or other categories. 
     Some business process models may also annotate process steps with additional information who can execute the process step. In an ADF model, this can for example be done by adding so-called roles to a task. The information about roles may also specify whether a process step is done automatically (i.e. it is executed by a machine) or whether it requires a collaboration with a human user. It is assumed, for instance, that the business view models of the trip-handling example associate human roles with the process steps “Create Itinerary”, “Confirm Itinerary”, and “Replan Itinerary”. This information is not visible in the graphical depiction of the process graph as shown in  FIG. 5 , but is available in the machine-generated representation of this graph. 
     Discovery of Platform-Specific Elements in a Process Graph 
     After the process graph  25  ( FIG. 5 ) has been constructed, the transformation engine runs a discovery phase to extract various subgraphs from the process graph that provide information to synthesize components for the platform-specific model. It should be understood that even with very little information only sketching the static information flow, useful IT architectural components may still be derived. 
     As will be described in greater detail herein, the transformation engine  20  implements, but is not limited to six (6) discovery steps: 1) Business Objects; 2) stateful, adaptive business objects also called Adaptive Documents (ADocs); 3) Macroflows; 4) Collaborations; 5) Screenflows; and 6) Adapters; and, two (2) synthesis steps: 7) BPEL4WS specifications, and 8) ADoc State machines. Each discovery step works on the internal process graph representation and establishes an element in the IT model. 
     To discover Business Objects, the TE investigates the information flow in the process graph. Each information entity that has been declared as belonging to the object category is mapped to a Business Object in the PSM. 
     In the trip-handling process, the following Business Objects are discovered: 
     trip request 
     hotel request 
     flight request 
     To discover ADocs, the information flow of the discovered Business Objects is inspected further. Each Business Object that flows through at least two atomic process steps in the process graph is mapped to an ADoc in the PSM. 
     In the trip-handling process, this criterion applies to all three Business Objects, i.e. they all become ADocs in the PSM: 
     trip request 
     hotel request 
     flight request 
     For each ADoc, an ADoc state-machine will be synthesized as will be described in greater detail hereinbelow. 
     The discovery of Macroflows tracks the information flow of each of the ADocs and extracts the sub-graphs specifying the flow of one ADoc. The sub-graphs  35   a ,  35   b ,  35   c , for the respective three object types (trip request, hotel request, flight request) for the trip-handling example are shown in  FIG. 7 . The Macroflows will later be mapped to one or several BPEL4WS specifications. 
     Collaborations are discovered from the role information that was associated with the process steps in the business view model. If a process step is annotated with a role that can only be performed by a human, a collaboration is derived. In the trip-handling example, the process steps 
     “Create Itinerary”, 
     “Confirm Itinerary”, and 
     “Replan Itinerary” 
     have been marked with human roles. 
     The discovery of Screenflows is based on the discovery of collaborations and the information flow in the process graph. For each collaboration, a screen must be generated that allows a human to execute his/her role in the computerized business process. The information that has to be displayed on the screen, is derived from the information flow that is coming into a process step and leaving this process step in the process graph. The order of appearance of the screens is determined by the ordering of the process steps in the process graph that have been mapped to collaborations. In the trip-handling example, it is discovered that three screens have to be added to the PSM:
         a “Create Itinerary” screen that displays the order event, trip request, flight requests, and hotel requests.   A “Confirm Itinerary” screen that displays the updated trip request.   A “Replan Itinerary” screen that displays the updated trip request and the booking failure information.       

     The ordering of these screens follows the ordering of the process steps in the process graph. First the “Create Itinerary” screen must be displayed, then followed by either the “Confirm Itinerary” screen or the “Replan Itinerary” screen. 
     Adapters are generated between atomic process steps and external or internal subprocesses. They are used to map information items that cross the process boundaries as shown in  FIG. 8  for the trip-handling example.  FIG. 8  is a view  150  depicting the internal and external process boundaries of the process steps that constitute the trip-handling process, and particularly illustrates process boundaries and message interactions between the trip-handling process  100  and its internal  111 ,  113  and external  101  partners. In the trip-handling example, the following adapters are established as components in the IT architectural model: 
     Customer to Create Itinerary-Adapter 
     Confirm Itinerary to Customer-Adapter 
     Replan Itinerary to Customer-Adapter 
     Evaluate2 to Hotel or Flight Service-Adapter 
     Create Itinerary to Hotel and FlightService-Adapter 
     During the bottom-up transformation where the TE is provided with the subflow graphs, which were derived from the PSM components, these subflow graphs are composed into one process graph by merging identical vertices. However, it must be ensured that identical process elements in different subflow models have identical names or else a mapping between vertices must be provided. In many instances, the subgraphs shown in  FIGS. 7 and 8  will allow the process graph from  FIG. 5  to be completely restored. For instance, the example top-down subflow extraction process  30  ( FIG. 2(   a )) may not preserve event links between process steps in the subflows. In the trip handling example, this does not matter, because the original process does not contain event links between process steps. In other examples, it may cause a loss of information. Which subflows are of interest to the TE depends on the models used on both sides—the PSM side and the PIM side. 
     IT Architectural Models and the Automatic Synthesis of Solution Components 
     The following demonstrates how the Macroflow and ADoc solution components of an IT architecture are synthesized by the platform-specific synthesis methods. For exemplary purposes, one target IT architecture is based on Web services, i.e., self-contained, modular units of application logic which provide business functionality to other applications via an Internet connection. A Web service is specified by defining messages that provide an abstract definition of the data being transmitted and operations that a Web service provides to transmit the messages. Operations are grouped into port types, which describe abstract end points of a Web service such as a logical address under which an operation can be invoked. Concrete protocol bindings and physical address port specifications complete a Web service specification. 
     Web services support the interaction of business partners and their processes by providing a stateless model of “atomic” synchronous or asynchronous message exchanges. These “atomic” message exchanges may be composed into longer business interactions by providing message exchange protocols that show the mutually visible message exchange behavior of each of the partners involved. An example of such a protocol specification language is BPEL4WS such as described in the reference authored by F. Curbera et al. and entitled, “Business process execution language for web services” www-106ibm.com/developerworks/webservices/library/ws-bpel/, 2002, the contents and disclosure of which is incorporated by reference as if fully set forth herein. According to the invention, the basic elements of a BPEM4WS protocol specification are derived from the process graph and the subflows it comprises. 
     Synthesis of BPEL4ws Protocol Specifications 
     As shown in  FIGS. 3 and 4 , in the travel agency (trip handling) example, three object processing sub-flows have been identified that link four communicating partners: (1) the travel agent  104  who handles the trip request processing, (2) the customer  101  who is an external partner to the travel agent, (3) the flight service  111  which is an internal partner, i.e., a subprocess that has not been further specified, and (4) the hotel service  113  which is also an internal partner dealing with the hotel request processing. Each partner needs to specify how it wants to exchange messages, and these protocols need to match each other. 
       FIG. 8  summarizes the message interaction information of this process with its partners as may be automatically extracted from the process graph  25  ( FIG. 5 ). Besides the types of messages, (incomplete) information about the order in which the messages are sent may be derived as indicated with the circled numbers. 
     As will be described in greater detail herein, the synthesis of a BPEL4WS skeleton is generated in XML and the declaration of the partners that are derived from the external and internal process steps in the process graph are first performed. It is understood that other model types may be generated, e.g., UML. In this example, it is assumed that the interaction with the customer will also proceed via a Web service interface. 
     &lt;process name=“TripHandling”&gt; 
     &lt;partners&gt;
         &lt;partner name=“Customer”
           myRole=“TripHandlingAgent”   
               

     serviceLinkType=“CustomerServiceLink”
         partnerRole=“CustomerAgent”/&gt;   &lt;partner name=“FlightService”
           myRole=“TripHandlingAgent”   
               

     serviceLinkType=“FlightServiceLink”
         partnerRole=“FlightServiceAgent”/&gt;   &lt;Partner name=“HotelService”
           myRole=“tripHandlingAgent”   
               

     serviceLinkType=“HotelServiceLink”
         partnerRole=“HotelServiceAgent”/&gt;       

     &lt;/partners&gt; 
     &lt;containers&gt;
         . . .       

     &lt;containers&gt;
         . . .
 
&lt;/process&gt;
       

     The name of the process is derived from the name of the business view model. The names of the partners are mechanically derived from the external and internal subprocess names. The partner role names are composed of the partner names with the suffix Agent added, whereas the value of the attribute myRole is again the model name plus the Agent suffix. The default values for the service link types are also mechanically derived from the partner names. 
     For each information entity discovered in the business view model  12  and that occurs in the signature of at least one process step in the trip-handling process, message names OrderEvent, TripRequest, FlightRequest, HotelRequest and BookingFailure and corresponding container names are defined, as shown in  FIG. 8  and described herein below: 
     &lt;containers&gt; 
     &lt;container name=“OrderEvent”
         messageType=“OrderEventType”/&gt;       

     &lt;container name=“TripRequest”
         messageType=“TripRequestType”/&gt;       

     &lt;container name=“FlightRequest”
         messageType=“FlightRequestType”/&gt;       

     &lt;container name=“HotelRequest”
         messageType=“HotelRequestType”/&gt;       

     &lt;container name=“BookingFailure”
         messageType=“BookingFailureType”/&gt;
 
&lt;/containers&gt;
       

     According to the invention, the control flow of the message exchange between the process and its partners may be derived as the process graph  25  provides the basic information needed to specify the choreography of message exchanges between the partners. The edges define a partial ordering between the process steps that map to corresponding &lt;sequence&gt; and &lt;flow&gt; constructs. Ordered steps are arranged within a sequence, whereas unordered steps are arranged within a flow construct. Control steps are mapped to &lt;switch&gt; activities and introduce the required branching in the message exchange protocol. 
       FIG. 9  illustrates the message control flow  200  of the example travel agency trip handling process. Basically, the flow graph  200  of  FIG. 9  summarizes the message flow control structure from the business graph and shows how it maps to structured and atomic BPEL4WS activities. In  FIG. 9 , solid lines show message exchanges with partners, and dotted lines show message exchanges between internal process steps, which are not modeled in the BPEL4WS file. The control flow for the example trip handling message exchange process depicted in  FIG. 9  is provided as follows: 
     &lt;sequence&gt; 
     createItinerary 
     Evaluate 
     &lt;switch&gt;
         ConfirmItinerary   &lt;otherwise&gt;   &lt;sequence&gt;
           ReplanItinerary   Evaluate   &lt;switch&gt;
               Hotel Service   &lt;otherwise&gt;
                   FlightService   
                   &lt;/otherwise&gt;   
               &lt;/switch&gt;   
           &lt;/sequence&gt;       

     &lt;/otherwise&gt; 
     &lt;/switch&gt; 
     &lt;/sequence&gt; 
     The mnemonic step names have to be replaced with the message interactions a step has with a partner. Each directed link that links a step vertex with a partner vertex is mapped to a basic BPEL4WS activity. A directed edge from a partner vertex to a step vertex is interpreted as a message flow from a partner to the process. It is therefore mapped to a &lt;receive&gt; activity. A directed edge into the other direction, i.e. from a step vertex to a partner vertex is mapped to an &lt;invoke&gt; activity. 
     With respect to BPEL4WS synthesis, the process starts when it receives an order event message from the customer. By default, a new process instance is always instantiated. After the message has been received, a trip request object is created, and hotel and flight request messages are sent in any order to the two partner services. Port type names are simple default strings and operation names are derived from the (abbreviated) names of the interacting process elements. For example, “Customer to Create Itinerary” is abbreviated with CToCI, “Create Itinerary to Flight Service” is abbreviated with CIToFS, the control steps are abbreviated with EVAL. The container names correspond to the message names that are exchanged. 
     &lt;sequence&gt; 
     &lt;receive partner=“Customer”
         portType=“pt1”   operation=“CToCI”       

     createInstance=“yes”
         container=“OrderEvent”&gt;
 
&lt;/receive&gt;
 
&lt;flow&gt;
       

     &lt;invoke partner=“HotelService”
         portType=“pt2”   operation=“CIToHS”       

     inputContainer=“HotelRequest”&gt; 
     &lt;/invoke&gt; 
     &lt;invoke partner=“FlightService”
         portType=“pt3”   operation=“CIToFS”       

     inputContainer=“FlightRequest”&gt; 
     &lt;/invoke&gt; 
     &lt;/flow&gt; 
     After the partner services have been invoked, the process waits for the services to send the results of their booking operations, which again may arrive in any order. 
     &lt;flow&gt; 
     &lt;receive partner=“HotelService”
         portType=“pt4”   operation=“HSToEVAL1”   container=“HotelRequest.”&gt;       

     &lt;/receive&gt; 
     &lt;receive partner=“FlightService” 
     
         
         
           
             portType=“pt5” 
             operation=“FSToEVAL1” 
             container=“FlightRequest”&gt; 
           
         
       
    
     &lt;/receive&gt; 
     &lt;/flow&gt; 
     After the answers have been received, the process has to branch depending on whether the services were able to book the requests or not. This introduces a first &lt;switch&gt; construct in the process. No condition for the switching can be derived from the process model and therefore a default placeholder is inserted. In the first branch (Confirm Itinerary to Customer), the process needs to inform the customer about the successful completion of his reservation and send the completed trip request documents. In the second branch (Replan Itinerary to Customer, Evaluate to Hotel Service or Flight Service), it needs to inform the customer about the booking failure and decide which of the services has to be informed about the failure of the other partner. The partners can be informed in any order, which again introduces a &lt;flow&gt; construct into the process. Within the flow, another &lt;switch&gt; construct is nested that decides which partner is informed. 
     
       
         
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;switch&gt; 
               
             
          
           
               
                   
                 &lt;case condition = “condition1”&gt; 
               
             
          
           
               
                   
                 &lt;invoke partner = “Customer” 
               
             
          
           
               
                   
                 portType = “pt6” 
               
               
                   
                 operation = “ConIToC” 
               
             
          
           
               
                   
                 inputContainer = “TripRequest”&gt; 
               
             
          
           
               
                   
                 &lt;/invoke&gt; 
               
             
          
           
               
                   
                 &lt;/case&gt; 
               
               
                   
                 &lt;otherwise&gt; 
               
             
          
           
               
                   
                 &lt;sequence&gt; 
               
             
          
           
               
                   
                 &lt;invoke partner = “Customer” 
               
             
          
           
               
                   
                 portType = “pt7” 
               
               
                   
                 operation = “RIToC” 
               
             
          
           
               
                   
                 inputContainer = “BookingFailure”&gt; 
               
             
          
           
               
                   
                 &lt;/invoke&gt; 
               
               
                   
                 &lt;switch&gt; 
               
             
          
           
               
                   
                 &lt;case condition = “condition2”&gt; 
               
             
          
           
               
                   
                 &lt;invoke partner = “HotelService” 
               
             
          
           
               
                   
                 portType = “pt8” 
               
               
                   
                 operation = “EVAL2ToHS” 
               
             
          
           
               
                   
                 inputContainer = “BookingFailure”&gt; 
               
               
                   
                 &lt;/invoke&gt; 
               
             
          
           
               
                   
                 &lt;/case&gt; 
               
               
                   
                 &lt;otherwise&gt; 
               
             
          
           
               
                   
                 &lt;invoke partner = “FlightService” 
               
             
          
           
               
                   
                 portType = “pt9” 
               
               
                   
                 operation = “EVAL2ToFS” 
               
             
          
           
               
                   
                 inputContainer = “BookingFailure”&gt; 
               
               
                   
                 &lt;/invoke&gt; 
               
             
          
           
               
                   
                 &lt;/otherwise&gt; 
               
             
          
           
               
                   
                 &lt;/switch&gt; 
               
             
          
           
               
                   
                 &lt;/sequence&gt; 
               
             
          
           
               
                   
                 &lt;/otherwise&gt; 
               
             
          
           
               
                   
                 &lt;/switch&gt; 
               
               
                   
                 &lt;/sequence&gt; 
               
             
          
           
               
                 &lt;/process&gt; 
               
               
                   
               
             
          
         
       
     
     By default, it is assumed that all message exchanges are asynchronous. The BPEL4WS specification becomes rather complicated due to the two control steps included within the process. Obviously, these could be merged into a single &lt;switch&gt; construct with three different cases by applying BPEL4WS optimization techniques similar to the ones presented in the reference authored by N. Sato, S. Saito, and K. Mitsui entitled “Optimizing composite webservices through parallelization of service invocations” In EDOC-03 [5], pages 305–316, incorporated by reference as if fully set forth herein. The transformation engine of the invention may then propagate this simplification back to the business view model where it could be discussed with the process designers. 
     The Business Objects, Collaborations, Adapters, and Screen Flows discovered as part of the transformation and discussed hereinabove are further refined and integrated with the BPEL4WS as part of the manual refinement from IT Architecture Model to IT Deployment model shown in  FIG. 1 . The integration of these components with BPEL4WS is described in greater detail herein. Business Objects map to the message types discussed in the containers section of the BPEL4WS definition. Collaborations, also known as microflows, map to the Web service operations that are invoked from BPEL4WS and invoke activities that are performed internal to the business process. Adapters map to BPEL4WS and invoke activities that are performed external to the business process. Screen flows map to BPEL4WS and receive activities in which the activity is pending for human input to the business process. Further details on business objects, collaborations, adapters, and screenflows may be found in the reference authored by Simon Cheng, Mathews Thomas, Santhosh Kumaran, Amaresh Rajasekharan, Frederick Wu, Yiming and Ye, Ying Huang, entitled “A Model-Driven Approach for Item Synchronization and UCCnet Integration in Large E-commerce Enterprise Systems”, in Proceedings of the Fifth International Conference on Enterprise Information Systems, published by ESEO, Angers, France in April 2003, the whole contents and disclosure of which is incorporated by reference as if fully set forth herein. 
     Synthesis of State Machines 
     Another programming model that is supported with the synthesis method are stateful business objects. So called adaptive documents (ADocs) as described in the reference authored by P. Nandi, S. Kumaran, T. Heath, K. Bhaskaran, and R. Dias entitled “ADoc-oriented programming” In  Proceedings of the International Symposium on Applications and the Internet  ( SAINT -2003) IEEE Press, 2003, incorporated by reference as if fully set forth herein, and also referred to as adaptive business objects (ABO), which are persistent data objects that carry their own processing instructions in the form of an associated (possibly non-deterministic) finite-state machine. When in a particular state, an ABO can invoke an activity and, depending on the result of the activity execution, it will transit to one of the possible successor states. The task of the synthesis process is to generate state machine specifications for each of the discovered business objects. 
     In the travel agency example described, three different adaptive business objects are discovered, namely: the trip request, the flight request, and the hotel request. Each of them is processed by different activities reflected in the subprocesses and process steps of the process graph. This information is used to determine the state machine of the objects. 
     Considering the flow graph of each object as a means of defining the words of a formal language L o , the names of the vertices are the symbols of the language, and the edges define the allowed concatenation of the symbols to obtain a word in the language L o . To simplify the notation, the activity names are abbreviated with single letters: create itinerary (c), evaluate (e), hotel service (h), flight service (f), replan itinerary (r), and confirm itinerary (o). The flow graph for the trip request object defines the words ce(o|r). For the hotel request object “c h e” is obtained and for the flight request object “c f e” is obtained. Three finite state machines may now be constructed that accept these words. 
     The construction process defines a transition for each graph vertex and annotates it with the name of the vertex to indicate the activity that has to be invoked. For each transition, a start and an end state are defined. When a process step “A” is directly followed by a process step “B” in the graph, the end state of “A” becomes the start state of “B”. This way, the state machines are built until the end state of the last process step is marked as a final state of the machine or until a process step is revisited if the process graph is cyclic. In the latter case, a cyclic state machine is obtained and it can happen that a state machine without end states is constructed. In such a case, a warning is issued as this would mean that the adaptive business object is processed in an infinite loop that never terminates. Process steps, which are unordered with respect to each other, introduce multiple successor states and lead to non-deterministic state machines. There must at least be one edge whose start state is not the end state of another edge, i.e., there must be one clearly identifiable first activity in the process graph. This state is marked as the initial state of the state machine, otherwise the construction fails. 
       FIGS. 10(   a )– 10 ( c ) illustrate the result of the construction for the discovered business objects of the travel agency example, and particularly illustrate the respective three state machines  210 ,  220 ,  230  for these business objects. As shown, the state machines have the common symbols “e” and “c”, but each machine also has private symbols that the others do not read. 
     In the ADoc-oriented programming model, the IT deployment model is created by manual refinement of Business Objects, Collaborations, Adapters, and Screen Flows and integration of these with the ADocs as discussed herein. Business Objects map to the data in the events received and processed by the ADocs. They could also appear as arguments in the activity invocations executed by the ADoc as part of state transitions. Collaborations and adapters are triggered via the activity invocations executed by the ADoc as part of state transitions. Screen flows generate a subset of the events processed by the ADocs. More details on this can be found in the above-mentioned “ADoc-oriented programming” reference incorporated as wholly set forth herein. 
     It should be understood that the business view models and platform-specific IT solution components may be accessed by humans for further inspection or have been created by them as input to the transformation engine. The process graph and flow graphs may not be externally visible, but are merely thought as internal representations of the fully automatic transformation engine. This means, when transforming from one external representation into the other (business view models into solution components or vice versa) no human interaction is required, but only the result is shown. A human input may only be needed to determine, which output is described from the set of available synthesis methods and writers. 
     Further, the transformation engine is additionally able to support dynamic model reconciliation. For example, after a given business view model has been transformed into an IT solution component, the generated component can be further refined and/or modified by a human. By transforming the modified component back into a new business view model and comparing the original business view model with the result of the back-transformation, the transformation engine can automatically detect deviations between both models and report them to a user. 
     While the invention has been particularly shown and described with respect to illustrative and preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention that should be limited only by the scope of the appended claims.