Methods for Design of Semantic Message-Based B2B Interaction Standards Erwin Folmer1, Joris Bastiaans1 1

TNO Information and Communication Technology, Colosseum 27, 7521 PV Enschede, The Netherlands {erwin.folmer, joris.bastiaans}@tno.nl

Abstract. The business interest in interoperability is rapidly growing. However, interoperability is not an easy target and is in many cases not easily achieved. One of the means to reach interoperability, standardization of B2B interactions, is often lacking quality which unfortunately has impact on interoperability. It is well-known that methods can improve the quality of standards. This paper supports the search of adequate methods by comparing several methods than can be used for design of B2B standards. Keywords: design methodologies, interoperable systems, model-driven architecture, cross-enterprise business processes, collaborative business processes, tools, standards, messages, interaction.

1 Introduction In order to achieve interoperability, business partners standardize their collaborative business processes. The result of such standardization effort is the delivery of a specification that describes how the participating business partners will interoperate with each other. Besides specifying an interworking [19], the specification also serves as a contract [1]. Designing and specifying collaborative business processes is not a straight forward task. For instance, the resulting specification needs to be of acceptable quality in order to allow for successful implementation of the collaborative business processes. When the specification is incomplete or ambiguous, it may be impossible to realize such collaborative business processes. Thus, a specification’s quality directly affects the interoperability that is intended [1]. In order to be able to produce high quality specifications repeatedly, a design methodology is essential. In [1], we propose a quality framework for specifications. Specifications are considered to be of sufficient quality when they can be unambiguously implemented. From that perspective, we motivate that model-driven design approaches provide the means to realize this implementability constraint. A model-driven specification then comprises the models that can be transformed into

deployable artifacts. After all, when this specification can be transformed into the required deployable artifacts, the specification was implementable. It is clear that in this way, the MDA [2] directly contributes to realizing interoperability. It is no surprise that the MDA has gained much attention. However, interoperability can only be achieved when the design of the interoperations is correct. Design is obviously the most important factor in standardizing collaborative business processes. A model-driven approach can merely aid in delivery of deployable artifacts through transformations. Using a design methodology to guide the design process is the wise thing to do as this leads to constant quality of designs. This paper identifies and compares state-of-theart design methodologies for collaborative business processes.

2 Overview of UML-Based Design Methodologies Within this research, comparison and selection of modeling languages is out of scope. This research is limited to UML based modeling languages. The search for UMLbased methods for the design of message-based inter-organizational collaborative processes yielded the following methodologies, many of them discussed in [3] and [4]: • UN/CEFACT’s Modeling Methodology (UMM) [5]; • Villarreal’s MDA-based development process for collaborative business processes [6]; • Kim’s modeling and specification method for ebXML-based B2B business processes [7]; • Kramler’s UML 2 based approach for modeling Web Service collaboration protocols [8]; • Bauer’s model-driven approach to designing cross-enterprise business processes [9]; • Koehler’s model-driven transformation method [10]. Design Methodologies Elaborated In the following paragraphs, the state-of-the-art design methodologies are shortly elaborated. UN/CEFACT’s Modeling Methodology UN/CEFACT’s Modeling Methodology (UMM) is a UML modeling approach to design the business services that each business partner must provide in order to collaborate. It is a top-down and iterative approach that makes use of worksheets to capture the requirements and understand the domain [5].

The idea of standard business scenarios and the necessary services to support them was first created by the Open-EDI [12] reference model that became an ISO standard in 1997. Thereby Open-EDI separates the what in the Business Operational View (BOV) from the how in the Functional Service View (FSV). The BOV covers the business aspects such as business information, business conventions, agreements and rules among organizations. The FSV deals with information technology aspects supporting the execution of business transactions. UN/CEFACT’s Modeling Methodology is considered as a BOV-centric methodology [11]. It starts off with a clear understanding of the specific domain of business activities within which the entire model exists [5][11]. It de-emphasizes the use of business documents and transactions to model this view as that approach may have captured only one part of the required model. An emphasis is placed on the definition of business entities, their state management and state lifecycle identification to produce a model that encompasses all instances and can evolve as new business requirements emerge. The goal of UN/CEFACT’s Modeling Methodology is to understand and formalize the dependencies between partner processes for a problem domain. Historically, partner communication methodologies (such as EDI) have focused on modeling the business documents being exchanged while the UN/CEFACT’s Modeling Methodology instead focuses on modeling the business actions and objects that create and consume business information. Modeling with UN/CEFACT’s Modeling Methodology yields business collaboration models. These business collaboration models comprise four main views (all supported by worksheets and methodological guidance) [5]: • • • •

The business domain view (BDV); The business requirements view (BRV); The business transaction view (BTV), and The business service view (BSV).

The business domain view is used to gather existing knowledge from stakeholders and business domain experts. In interviews, the business process analyst tries to get a basic understanding of the business processes in the domain. Use case descriptions of business processes are used to define the high-level collaborative processes. Furthermore, it is investigated which partner types participate in which processes and which stakeholders have interest in these processes. The business processes from the BDV that provide a chance for collaboration will be further detailed and refined by business process analysts in the business requirements view. This view consists of a number of different sub views, namely: • The business process view gives an overview about the business processes, their activities and resulting effects, and the business partners executing them. The activity graph of a business process may describe a single partner’s process, but

• • • •

may also detail a multi-party choreography. The business process analyst tries to discover interface tasks creating/changing business entities that are shared between business partners and thus, require communication with a business partner to realize state alignment. The business entity view describes the shared business entities. This is done by modeling the shared business entity’s lifecycle in a state chart The transaction requirements view describes business transaction use cases between roles. Assigning roles allows for flexibility; you do not need to assign the same use cases for each business partner. The collaboration requirements view includes a business collaboration use case which aggregates business transaction use cases and/or nested business collaboration use cases. The collaboration realization view defines which business partners play which role in which collaboration use case.

The business transaction view builds on the business requirements view and defines a global choreography of information exchanges and the document structure of these exchanges. The choreographies are realized by refining all business activities (activity nodes in the activity diagram) to activity diagrams specifying one transaction (the sending and receiving of business objects and an optional response). The information envelopes used to transfer these business objects is defined in class diagrams. In the business service view, the services for each participant’s interface are specified. Each transaction is refined in send-methods that instantiates the information envelope that is modeled in the BTV. With UN/CEFACT’s Modeling Methodology, it is possible to model the exchanged business information with the use of Core Components [13]. The core components provide easy to use building blocks for the construction of complex data structures. Quite some support is available for the UN/CEFACT’s Modeling Methodology. As it uses UML solely for its specifications, it is specified as a UML profile [14]. Furthermore, quite some mappings and transformations exist. UMM models can be transformed to BPSS [14] and BPEL stubs [15][16][17]. Furthermore, a mapping to the new WS-CDL standard was proposed [18]. A free add-in [15] is available for Sparx Systems’ Enterprise Architect which provides useful tool support for the UMM. The add-in provides a UMM UML profile, allows for validation and offers transformations to choreography languages (BPEL, BPSS). Furthermore, it features a built-in worksheet editor to facilitate the requirements and information gathering process. Villarrreal In [6], Villarreal identifies the MDA as the key enabler to assure consistency between partners’ interface specifications and collaborative processes. A model-driven approach for modeling collaborative processes is presented that is independent of the idiosyncrasies of particular B2B standards.

To support the design of collaborative processes, the use of the UML Profile for Collaborative Business Processes based on Interaction Protocols (UP-ColBPIP) is proposed. The development approach consists of three steps: • Analysis and design of collaborative processes; • Verification of collaborative processes, and • Implementation of collaborative processes. The analysis and design phase is about the modeling of collaborative processes from a business perspective of the B2B collaboration; it focuses on analysis and design of collaborative business processes. In order to design the way the involved parties collaborate with each other, UML models (Using the ColBPIP UML 2.0 Profile) models are created on four different views: • The B2B Collaboration View captures the participants and their communication relationships. These are modeled in extended collaboration diagrams. • The Collaborative Process View identifies collaborative processes. To define this, UP-ColBPIP extends the semantics of use cases to represent collaborative processes as informal specifications of a set of actions performed by participants. • The Interaction Protocol View defines the explicit behavior of the collaborative processes through the use of interaction protocols. UP-ColBPIP extends the semantics of UML 2 interactions to model this. • The Business Interface View offers a static view of the collaboration through the definition of the business interfaces of the participants. This is modeled in extended composite structure and interfaces In the verification phase, the collaborative processes are converted (based on a mapping) to a formal language. These formal models – such as Petri nets – can be validated for consistency and prevent common problems such as deadlocks and livelocks. In the implementation phase, specifications are generated for the business processes and the participating partners’ interfaces. It is argued that transformations exist from ColBPIP-models to ebXML, BPEL and WS-CDL specifications, yet, no proof of this could be found. Furthermore, it is also unclear to what extend message contents is modeled and to what kind of specifications these can be transformed. Kim Kim acknowledges in [7] that in order to support dynamic setup of business processes among independent organizations, a formal standard schema for describing the business processes is required. In other words, Kim standardizing interchangeable objects is not enough; the inter-organizational processes need to be standardized as well. The ebXML framework appears to provide such specification schemas (BPSS).

Modeling inter-organizational processes can be done through the UN/CEFACT’s Modeling Methodology. As noted earlier, this method uses worksheets to capture the domain knowledge. Kim argues that UML diagrams can also be used for this purpose and proposes guidelines on how such models are to be produced. Furthermore, a prototype modeling tool (“ebDesigner”) with BPSS generation features is presented. Kim’s modeling approach is therefore not a complete methodology on its own. Rather, it builds on the fundaments of UN/CEFACT’s Modeling Methodology. Kramler In [8], Kramler acknowledges that UN/CEFACT’s Modeling Methodology tackles the problems of: • Lack of graphical modeling; • Support for modeling collaborations (choreography) instead of individual interfaces, and • The lack of abstraction for modeling transactions. However, it is argued that UMM’s approach does not support the specifics of Web Service technology. In order to cope with this, Kramler proposes a UML 2.0 based modeling technique that supports platform independent modeling of Web Service collaboration protocols. Modeling is done in a top-down fashion across three layers At the collaboration level, an overview of the collaboration is provided. This is expressed in collaboration diagrams. The transaction level considers transactions and transactional processes. Each transaction is being performed by a set of participants from the collaboration. This level abstracts from the distribution of state and control in a collaboration to provide a convenient high-level model. Activity diagrams define transactional processes which refine the defined collaborations. Class diagrams are used to model objects and associated state charts define the behavioral aspects. At the interaction level, actual asynchronous exchange of messages is modeled. The allowed sequences are captures in sequence diagrams. Furthermore, class diagrams are used to model the content of messages that The strong side of this approach is the formal connection of the object models to the messages exchanged in the interaction level. Thereby, it creates an aggregated form of data flow control that is argued to be missing in most modeling approaches. It is assumed that this connection between objects and object exchange allow for a mapping to the implementation level. However, such a mapping is not yet provided by Kramler et al. Although this methodology does not provide a full model-driven approach for developing messaging standards, it is focused on delivery of models (CIMs and PIMs)

which – in the end – could be transformed to deployable artifacts. Therefore, this methodology could easily be fitted in a model-driven approach. Bauer Bauer et al propose a model-driven design approach [9] for modeling cross-enterprise business processes. The methodology is a top-down approach, in line with the MDA principles. The methodology proposes to model the existing business process at CIM level. Proposed modeling languages are BPDM for process modeling and UML activity diagrams for visual representation. At PIM level, the business processes are refined with data-flows and also modeled in activity diagrams. The PIMs are modeled from an IT implementation point of view. This means, that specific send and receive activities are modeled in the activity diagrams for each process. The distinction between business process at CIM level and implementation-oriented designs at PIM level make this approach clearly business-oriented. However, as the business processes are refined to more implementation-oriented models, information modeling is not mentioned in the methodology. No refinement of the data-flows is proposed. Furthermore, this method is merely a design method. No mappings are yet presented. In future work, mappings to BPEL4WS are promised. The methodology, however, does not restrict designers to model inter-organizational business process that can be implemented with BPEL4WS only. The methodology therefore is non-restrictive with regard to target realization platforms. Koehler Koehler presents a methodology [10] that implements model-driven transformations between particular platform-independent (business view) and platform-specific (IT architectural) models. It aims at deriving Web Services and executable business processes. On the PIM side, business process models (UML2 activity diagrams) are used to describe existing business processes. On the PSM side, the IT architectural models focus on WSDL’s and BPEL4WS models. Koehler acknowledges that the IT architecture should be aligned with the business processes and it should be the business process model that determines the IT architecture and not the other way around. The methodology is therefore clearly a topdown and absolutely business-oriented. The proposed methodology considers the PIMs to be specifications and the PSMs to be the solutions that satisfy the specification. Koehler proposes to a mapping of UML 2.0 activity diagrams to so-called process graphs. These process graphs reflect a value-network’s static information flows. Furthermore, it describes how BPEL4WS documents can be derived from these process graphs. Yet, a formal mapping is not presented.

The methodology only focuses on supporting the process side of inter-organizational collaborations. Information modeling (defining the messages) is not part of the methodology.

Comparison In [1], a quality framework for design processes is proposed. Furthermore, it is argued that a specification should minimally specify: • The format for valid messages; • The vocabulary of valid messages that can be exchanged; • The intentions and semantics of these messages should be specified; • Which business interactions (services) to support; • The procedure rules for these interactions (the choreography); • The assumptions about the environment in which the interoperations take place. Selection Criteria The combination of the specification process’ quality aspects, the above stated ingredients for a specification and the concepts from the MDA yields us the following selection criteria for a suitable design methodology. A modeling methodology is adequate when it: • • • • • • • • •

Is top-down; Is model-driven approach; Is iterative; Is platform unbiased; Facilitates domain modeling; Facilitates choreography modeling; Facilitates information modeling; Has formal verification methods; Has tool support.

How these characteristics of design methodologies contribute to implementability of specifications is elaborated in the following paragraphs Top-down Messaging standards are used to facilitate an interworking. As the messaging mechanism must function in a value-network in the context of this interworking, the messaging mechanism must be designed for that purpose. This implies that a top down approach is followed where the interworking is refined with message-based

communication until this design is implementable. Modeling should be done from a business-operational viewpoint. Model-driven approach As motivated in this paper’s introduction, model-driven design contributes to implementability. Furthermore, it is believed that models are easier to maintain than implementations. Alterations to a collaborative process could be made to CIM or PIM models whilst deployable artifacts can be quickly generated (fully or partially automatically), hence improving maintainability. Iterative As it is better to have designs that are almost right than completely wrong, iterative design is suggested. Nowadays, iterative design is a common practice, particularly in software engineering. Platform non-restrictive Within the message-based abstract platform, a design methodology should not further restrict designers in their choice for potential target realization platforms. After all, the freedom of being able to select a target realization platform allows designers to select one platform that best fits the needs or situation. This obviously helps the quality of designs. Facilitates domain modeling As the exchanged messages in B2B interactions are about the business domain, this domain must be fully comprehended. Therefore, activities related to domain modeling and the involvement of domain experts contribute to the quality of the standard and should therefore be an integral part of the design methodology [roes]. Choreography modeling As this is one of the ingredients of a messaging standard’s specification, the design methodology should take this into account. This is closely related to domain modeling, since the choreography must be aligned with the existing business processes in the business domain. Information modeling In the end, as valid messages need to be specified, the methodology needs to facilitate the information modeling. Naturally, this is also closely related to domain modeling as the messages are about the business domain. Formal verification methods Formal verification methods offer the means to assess the design's correctness, completeness and consistency. Thereby, the standard's and specification's quality can be monitored and controlled

Tool support Tool support improves the quality of specifications as it reduces errors or inaccuracies caused by (human) manual activities. Tool support is also essential to support the model-driven approach. Comparison In our search for a design methodology, we do not want to be restricted to specific platforms within the abstract platform of message-based interaction. Therefore, Koehler’s methodology that focuses solely on the Web Service platform should not be selected. Kim, on the other hand, does not provide a methodology. His work merely explains how you could use UML diagrams to specify collaborative business processes. Kim’s approach should therefore not be used as the main design methodology for messaging standards. Furthermore, a design methodology should address all aspects of message-based interaction. As we seek top-down methodologies – methodologies that focus on existing business processes or collaborations – process modeling is often the first step in a design methodology. This, however, does not mean that information modeling should not deserve any attention. In order to realize successful interworking, the information aspects need to be modeled as well (be it as a refinement of processes or collaborations). Bauer’s methodology omits the information modeling aspects in the design. A more comprehensive design methodology is obviously preferred. Kramler’s, Villarreal’s and UN/CEFACT’s modeling methodologies appear to be comprehensive enough. Villarreal proposes a fully model-driven approach. With respect to quality assurance we must acknowledge that the formal verification phase is very appealing. However, (too) much is unclear about this methodology. For instance, uncertainty about the support for information modeling and lack of proof of the claimed transformations leads us to believe that the methodology is not mature enough. Kramler proposes a methodology that is very similar to UN/CEFACT’s. Yet, its strength – to directly connect messages to process models – cannot be fully enjoyed due to lack of (proven) transformations.

⌧

⌧

⌧

⌧

⌧

⌧

⌧ ⌧ ⌧

Kim

⌧

Tool support

⌧

Formal verification

Information modeling

⌧

Choreography modeling

⌧

Domain modeling

Villarreal

Platform non-restrictive

⌧

Iterative

UMM

Model driven

Methodology

Top-down

Table 1. Comparison of design methodologies.

Kramler

⌧

Bauer

⌧

Koehler

⌧

⌧ ⌧

⌧

⌧ ⌧ ⌧

Fully satisfied Partially satisfied or not entirely clear

Conclusions UN/CEFACT’s Modeling Methodology has been around for quite some time. It has proven its value and a lot of support (tool support, mapping and transformations) are available. Furthermore, the worksheets and design guidelines offer valuable methodological support for the entire process of developing standards. UN/CEFACT’s Modeling Methodology is therefore the only design methodology that deals with all modeling aspects and is able to model all the required aspects of collaborative business processes. Although the UMM is not a fully model-driven design methodology, the availability of transformations and tool support provides opportunities. As the UMM is a modeling methodology for CIM and PIM models, the UMM and existing transformation tools could easily be incorporated in a model-driven design process. From that perspective, organizations involved in standards development and setting (such as TNO) will have a good starting point by using UMM.

References [1] Bastiaans, G.J.A., “Standardizing electronic transaction based on state-of-the-art concepts”, MSc-Thesis, forthcoming. [2] Miller, J. & Mukerji, J., “MDA Guide Version 1.0.1”, OMG omg/2003-06-01, http://www.omg.org/docs/omg/03-06-01.pdf [3] Roser, S. & Bauer, B., "A Categorization of Collaborative Business Process Modeling Techniques," cecw , pp. 43-54, 2005. [4] Dorn, Grun, Werthner & Zapletal, "A Survey of B2B Methodologies and Technologies: From Business Models towards Deployment Artifacts," hicss , p. 143a, 2007. [5] UN/CEFACT’s Modeling Methodology User guide, 2003-09-22, http://www.unece.org/cefact/umm/UMM_userguide_220606.pdf [6]Villarreal, P.D., Salomone, E. & Chiotti, O., “A MDA-based development process for collaborative business processes”, in proceedings of European Workshop on Milestones, Models and Mappings for Model-Driven Architecture (3M4MDA), Bilbao, Spain, July 11, 2006 [7] Kim, H.D.,. "Conceptual Modeling and Specification Generation for B2B Business Process based on ebXML." ACM SIGMOD Record 31.1 (2002): 37-42. [8] Kramler, G., Kapsammer, E., Kappel, G., and Retschitzegger, W., “Towards Using UML 2 for Modelling Web Service Collaboration Protocols,” in Proceedings of the First International Conference on Interoperability of Enterprise Software and Applications (INTEROP-ESA’05), Feb. 2005. [9] Bauer, B., Müller, J.P. & Roser, S.: A Model-Driven Approach to Designing CrossEnterprise Business Processes, University of Augsburg, 2004. [10] Koehler, J., Hauser, R., Kapoor, S., Wu, F.Y. & Kumaran, S., "A Model-Driven Transformation Method," edoc , p. 186, 2003. [11] Huemer, C., “UN/CEFACT’s Modeling Methodology (UMM) in a nutshell”, http://unece.org/cefact/umm/UMM_userguide-nutshell.pdf [12] ISO. Open-EDI Reference Model, 1995. ISO/IEC JTC 1/SC30 ISO Standard 14662. [13] Huemer, C. & Liegl, P., A UML Profile for Core Components and their Transformation to XSD. accepted at the Second International Workshop on Services Engineering, Istanbul, Turkey, 2007. [14] Hofreiter, B., Huemer, C., Liegl, P., Schuster, R. & Zapletal, M., “UN/CEFACT’S Modeling Methodology (UMM): A UML Profile for B2B e-Commerce”, in Advances in Conceptual Modeling - Theory and Practice (ER 2006), 2006. Tucson, Arizona, VS: Springer, 19-31. [15] Hofreiter, B. & Huemer, C.. UMM Add-In: A UML Extension for UN/CEFACT’s Modeling Methodology. In European Conference on Model Driven Architecture (ECMDA’06), July 2006. [16] Hofreiter, B., Huemer, C., Liegl, P., Schuster, R.& Zapletal, M., "Deriving executable BPEL from UMM Business Transactions," scc, pp. 178-186, IEEE International Conference on Services Computing (SCC 2007), 2007 [17] Hofreiter, B. & Huemer, C.. Transforming UMM Business Collaboration Models to BPEL. In Proceedings of the International Workshop on Modeling Inter-Organizational Systems (MIOS), 2004. [18] Frick, A. & Helger, P., “UMM BTV nach WS-CDL Transformator”, online resource, http://philip.helger.com/gt/get.php?where=gt&file=wscdl.pdf, downloaded at 10-18-2007. [19] Krämer, B., Papazoglou, M. & Schmidt, H.W., “Information Systems Interoperability”, Research Studio Press, 1998.