EFFICIENT: a Tool Set for Supporting the ... - Semantic Scholar

EFFICIENT: a Tool Set for Supporting the Modelling and Validation of ebXML Transactions Rik Eshuis [email protected] CRP Henri Tudor 29, Avenue John F. Kennedy L-1855 Luxembourg–Kirchberg Luxembourg

Pierre Brimont [email protected]

Eric Dubois [email protected]

Bertrand Grégoire Sophie Ramel [email protected] [email protected]

ABSTRACT

1.

ebXML is becoming the new international standard for the specification and deployment of complex B2B transactions over the internet. ebXML transactions are inherently distributed, involving many actors exchanging XML messages with each other according to complex flows and rules. This complexity hampers validation of the correctness of a modelled business transaction by business experts. To alleviate this problem, we have developed a tool set, consisting of a CASE tool for modelling ebXML transactions and an animator for validating the modelled transactions. At the specification level, the main UML models used are class diagrams to model messages and an activity diagram to model the global flow of the messages that are exchanged by the actors (companies). The animator is internet-based, thus supporting distributed animation of an ebXML transaction. The animator checks business rules on the messages exchanged during animation. Moreover, the animator annotates messages with possible responses. Heart of the animator is a workflow engine that can read workflow descriptions in XPDL. The animator is configured automatically from the UML specification models. We illustrate the whole approach on a real-life example.

The world of B2B commerce is changing today. For more than 25 years, EDI standards, like UN/EDIFACT or ANSI X12, have been the dominant ways of interchanging data between geographically dispersed business applications. These standards are message based: they define the syntax of each message and give some recommendations of use. However, the grammar describing the syntax is often complex and in some cases ambiguous. Hence, introducing new messages and modifying existing ones can be very costly, because parsers and validators that check a complex syntax must be updated. Moreover, rules that constrain the message content and usage are expressed in natural language with the possibility of misinterpretations, resulting in many exceptions that have to be manually handled. This impedes the STP (straight-through-processing) principle which requires a complete automatic management of messages. To overcome the problems described above, UN/CEFACT and OASIS, supported by several hundred participants, have launched the international ebXML initiative [13]. ebXML stands for ‘Electronic Business using eXtensible Markup Language’. As the name already suggests, a key aspect of ebXML is the adoption of XML as standard language for messages. Besides the message syntax, ebXML has also considered the semantic aspects by recommending usage of a specific UML profile for specifying the message content as well as its business usage. Finally, ebXML has shifted from a message-oriented paradigm into a transactionoriented paradigm through its associated UMM [4] methodology. This shift results in an end-to-end view of the business transaction where the purpose and the usage rules of each message can be make much more precise than with EDI. Business experts, even if they are able to read UML syntax, cannot easily validate UML models because these models are usually very complex when they are used to describe real business transactions in which multiple actors participate and in which several messages are exchanged according to complex flows and business rules. Nowadays, validation by business experts can only be done when the whole transaction is implemented and running. Then, business experts are able to discover some missing data elements in messages, some inadequate business rules or even deadlocks or some infinite loops (livelocks) in the transaction flows. Finding such errors will result in a revision of the UML specifications and in the propagation of the new changes in the software

Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques

General Terms Design, Languages, Verification

Keywords ebXML, animation

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ESEC/FSE’03, September 1–5, 2003, Helsinki, Finland. Copyright 2003 ACM 1-58113-743-5/03/0009 ...$5.00.

INTRODUCTION

implementation. This process is resource and time consuming, and impedes the rapid adoption and propagation of new B2B communication standards. This paper descibes a tool set, Efficient (E-business Framework For an effIcient Capture and Implementation of ENdto-end Transactions), we developed for supporting the modelling and validation of ebXML transactions. The tool set consists of a CASE tool and an animator. The CASE tool supporting development of the different UML models associated with the business and analysis representations of the ebXML transaction. The animator allows business experts to validate transactions models at the time they are built, before their implementation has started. The animator is automatically configured from the models produced with the CASE tool. Rather than simulation, we prefer to use the word ‘animation’ since the validation is done in an interactive way, each business expert playing the role of a business actor and participating in the execution of the transaction by receiving messages and sending answers. This way, business experts can validate the transaction by playing different possible scenarios that include different messages. The animator automatically checks the business rules defined on these messages and gives feedback in case of an error. Validating a specification by animating it has been proven a useful technique in different contexts [1, 2, 3, 5, 11]. Most animation approaches [1, 2, 5, 11] offer non-distributed, centralised animation facilities and are not internet based. Consequently, only a single actor is needed to animate the specification. A notable exception is the work by Heymans and Dubois [3], in which a distributed internet-based animator is presented that allows different actors to cooperatively animate a specification. However, that animator requires a human scheduler for coordinating the behaviour of the different actors, whereas our approach uses a workflow engine for this. Hence, we have automatic coordination whereas Heymans and Dubois require manual coordination. Another difference of our approach compared to the approaches mentioned above is that our implementation is based on open XML-based standards and related technologies, and does not use a proprietary language. The remainder of this paper is structured as follows. Section 2 explains how ebXML transactions are modelled. Section 3 discusses the architecture of the animator, which is based on a workflow engine. We end with conclusions.

2. MODELLING EBXML TRANSACTIONS Together with ebXML, a methodological approach, called UMM (UN/CEFACT Modeling Methodology), for the design of business transactions has been introduced. UMM has been developed by UN/CEFACT’s Techniques and Methodologies Working Group (TMWG) since 1998. However, a UMM version [4, 12] was merged with the RosettaNet methodology [10] during the ebXML initiative. Like other UMLbased methodologies, UMM relies upon a number of UML models to be developed at different stages of the B2B project. Those models have some specific characteristics, therefore we can consider UMM models as a specific UML profile. We have adopted a three layered approach (see Figure 1): • The business layer gives a general overview of the business transactions. The global structure of each business transaction is depicted with a UML use case diagram and a UML class diagram. The use case diagram

TradeCondition

InstructingParty

ExecutingParty

-TradeDate: Date -PriceConditio n: Rea l

-SWIFTIde nt: B IC

-SWIFTIde nt: B IC

order

Business layer

exec ute 0..*

allocate 0..* 0..*

Trade -Security: IS IN -Exec utedQuantity: Real -Action: {Buy/Se ll} -AveragePrice: Rea l

AllocationInstruction -Client: String -AllocatedQua ntity: Rea l

OrderToBuyOrSell

Specification layer TradeCo nditio n

InstructingParty

Exec uti ngParty

-TradeDate: Date -PriceConditio n: Rea l -OrderedQty: Rea l

-SWIF TIdent: BIC

-SWIF TIdent: B IC

Trade -Security: IS IN -Action: {Buy/Sell}

Code generation Xpdl XMLSchema

Technical layer

Figure 1: Different levels within B2B project specifies the global structure of the business processes underlying the business transaction. The global class diagram specifies the information manipulated in the business processes. At this layer, there is no concept of message. • The specification layer details a message-based structure of a business transaction. This detailed specification is needed to support the B2B automation of business transactions. The business process activities of the business transaction are specified using a UML activity diagram. Each message is specified using a UML class diagram. The activity diagram refines the use case diagram at the business layer. Each class diagram is a particular view of the global class diagram at the business layer. • At the technical layer, the business transaction is executed using the animator. The infrastructure used at the technical layer is automatically configured from the models developed at the specification layer. In ebXML, business process models have three levels of detail. Swimlanes and object flow states only occur in the lowest level activity diagram, in which the behaviour of two parties that exchange business documents is modelled. To make the specification more easy to comprehend, we decided to merge all these levels into one activity diagram. We can easily transform our activity diagrams into a layered ebXML model and vice versa, because we require that each object flow state has one input and one output activity, which belong to two different swimlanes. To support the validation of ebXML transactions, we have extended an existing commercial UML-based CASE tool, MagicDraw [9], with plugins that execute the code generation depicted in Fig. 1. Since MagicDraw is a state of the art CASE tool, we expect that the developed plugins can be easily transferred to other UML-based CASE tools. Because of space limitations, we only give an example of models at the specification layer. The example is about Mercata, an online broker of standard products (taken from the MIT process handbook [7]). We focus here on one particular business transaction: a business client creates an order by submitting his demand for certain products to Mercata. After Mercata provided some technical information on the delivery (e.g. delay, cost), the client can pay. Depending upon the payment means, the payment is checked by either the Credit Company or by Mercata’s accountant. Figure 2 shows an activity diagram of the business transaction. Each









Business

Mercata

Credit Company

Accountant

write order

order

check summary

[incorrect]

send summary

summary send credit_ask

[correct]

credit_ask

[means is credit] payment_means

evaluate credit allowance [yes]

check means

[no]

[means is not credit] no_credit

summary_reject

send payment_required

send payment_wait

credit_allowance

payment_wait pay order

payment_required

send payment_status

receive message

payment_received

Figure 2: Activity diagram of “create order” credit_ask

Credit_Contract -credit_contract 0..1

Order

-code : int -debtor_id : string -key : string

Credit_Card

-ask_answer : boolean -payment_means : Payment_Means_Def 0..1

-card_number : string -expiration_date : date

...

Delivery_Mode -mode : Delivery_Mode_Def

Delivery_Mode_Def -express -get_it_yourself -normal -quick

effective_delivery

-effective Delivery_Cost -cost : int

Payment_Means_Def

Client1

object flow state in this activity diagram models a message, whose structure is modelled with a class diagram. Figure 3 shows the class diagram for object flow state credit ask. This class diagram is a view of the global class diagram at the business layer. Message class diagrams can be annotated with business rules. These rules are expressed in structured English. We have defined a translation from structured English expression into xlinkit constraints, and we are currently implementing it in a tool. xlinkit [8] is a tool which checks the consistency of xlinkit constraints (XPath-like boolean expressions) against a set of XML documents.

3. ANIMATING EBXML TRANSACTIONS Once the models have been designed at the specification layer, business experts can interactively ‘play’ with them through the animator. The animator is internet based, allowing business experts dispersed over several places to cooperatively animate the specification through a simple web browser. Each of the experts is responsible for animating one or more of the actors involved in the transaction. Heart of the animator is a workflow (WF) engine that has been developed before at our research center. In general, a WF engine coordinates the execution of automated business processes. In this case, it coordinates the execution of the business transaction modelled at the specification layer. The business activities of the business process are executed by actors outside the workflow system (i.e. the business experts), not by the WF engine itself. To coordinate the business process, the WF engine needs to have a description of the

XML Message + possible responses

SOAPServer XMLMessageHandler

XMLMessageSender Call Workflow

-bank_transfert -credit_card -credit_partner -post_mail

Figure 3: Class diagram of message credit ask

Client2 SOAPServer

XML XMLMessage

XML Message XML Schema XMLSchemaChecker XMLDataChecker

Workflow Engine XML Schemas

XPDL.xml

XMLSchema + building rules Dynamic XML message + rulesconstraints xlinkit XML XLinkitConstraintChecker

Figure 4: Architecture of the animator process. Our WF engine reads process descriptions in XPDL format. XPDL [14] (‘XML Process Definition Language’) is a standard language developed by the Workflow Management Coalition (WFMC). The XPDL process description used during animation is derived automatically from the activity diagram at the specification layer. Figure 4 shows the overall architecture of the animator. The architecture heavily relies on XML technology. The animator exchanges XML messages with clients using the SOAP protocol. To allow for reuse, the animator architecture consists of many small independent modules. We now discuss the architecture in more detail. First, the XMLMessageHandler module receives XML messages from a client through a SOAP server. The module first stores the XML message in an XML database, eXist [6], and also stores some relevant information, i.e. the name of the recipient, initial sender and the reception time. This information is used in the subsequent checks. Next, XMLMessageHandler calls the WF engine using an API definition defined by the WFMC. Each message signals the end of some running activity: the XMLMessageHandler calls the WF engine to terminate this activity. Next, the WF engine calls the XMLSchemaChecker module, which checks whether the message conforms to its defin-

ing W3C XML Schema. This XML Schema has been derived automatically from the class diagram of the message at the specification layer. In case of an error, an error message is generated and sent back to the initial sender, and the WF engine enables the sending activity again. Otherwise, the WF engine proceeds with the next activity. If the message is error free, the WF engine calls module XlinkitConstraintChecker, which checks the constraints annotated on the message. These constraints are defined at the message class diagrams at the specification layer. The module calls xlinkit [8], a tool that verifies the consistency of the rules against a set of XML documents, in this case XML messages. The current message is always part of the set. If a rule refers to other (previous) messages, xlinkit retrieves these relevant messages from the XML database. Again, if the verification fails, an error message with feedback is sent to the message sender and the WF engine enables the sending activity again. Finally, the workflow engine calls module XMLMessageSender. This module computes the message that the recipient of the validated input message could send, in the next activity of the business transaction. The module prefills as many fields of the response message as possible with information already known from previous messages. This feature is helpful if the next message should include a lot of information items already included in the current message. However, the recipient can overwrite a prefilled field. The prefilling is governed by building rules, which identify which parts of the current message equal parts of previously sent messages. The next message is attached to the current message, and forwarded to the SOAP server at the recipient site. For example, if message order arrives, XMLMessageHandler finds out that the next activity will output message summary, and it will therefore annotate order with a summary message that is prefilled as much as possible. If the activity started next is a activity, more than one response message is possible. Note that the recipient, in the next activity, in most of the cases merely has to select the right answer. Hence, prefilling can reduce the workload of the message’s recipient considerably.

4. CONCLUSION AND FURTHER WORK We have introduced a tool set that supports the development and validation of B2B transactions. The tool set consists of an extension of a CASE tool and an animator. The animator is automatically configured from the models specified in the CASE tool, thus enabling a fast animation. Moreover, the animator architecture is internet based, allowing business experts dispersed over different places to cooperatively animate distributed business transactions using a simple web browser. Business rules defined in the UML models are checked automatically by the animator. The animator is tightly integrated with state of the art XML technology, showing the feasibility of our approach for ebXML. Future work includes lifting the business rules from xlinkit to a higher level language. We are currently investigating the use of structured english as a business rule language. Another extension of our work concerns activity diagrams. We plan to add the specification of real-time constraints, e.g. timeouts. At the tool level, we plan to interface the CASE tool with a model checker, to allow an exhaustive verification of the dynamic behaviour of the business transaction. Error traces returned by the model checker can serve as input for

the animator.

Acknowledgements The research reported upon in this paper has been supported by the FNR under grant FNR/01/01/07 (Efficient). The work of Rik Eshuis has been supported by a grant from FNR and has been performed within the scope of the LIASIT (Luxembourg International Advanced Studies in Information Technologies) Institute.

5.

REFERENCES

[1] A. Grau and M. Kowsari. A validation system for object oriented specifications of information systems. In Proc. of the First East-European Symposium on Advances in Databases and Information Systems (ADBIS’97), pages 249–256, 1997. [2] D. Harel, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtull-Trauring, and M. Trakhtenbrot. STATEMATE: A working environment for the development of complex reactive systems. IEEE Transactions on Software Engineering, 16(4):403–414, Apr. 1990. [3] P. Heymans and E. Dubois. Scenario-based techniques for supporting the elaboration and the validation of formal requirements. Requirements Engineering Journal, 3(4):202–208, 1998. [4] C. Huemer. Defining electronic data interchange transactions with UML. In R. H. Sprague, Jr., editor, Proc. 34th Annual Hawaii International Conference on System Sciences (HICSS-34). IEEE Computer Society, 2001. [5] J. Magee, N. Pryce, D. Giannakopoulou, and J. Kramer. Graphical animation of behavior models. In Proc. of the 22nd Intern. Conference on Software Engineering (ICSE), pages 499–508. ACM Press, 2000. [6] W. Meier. eXist: An open source native XML database. In A. B. Chaudhri, M. Jeckle, E. Rahm, and R. Unland, editors, Web, Web-Services, and Database Systems, Lecture Notes in Computer Science 2593. Springer, 2003. [7] MIT process handbook. http://ccs.mit.edu/ph. [8] C. Nentwich, L. Capra, W. Emmerich, and A. Finkelstein. xlinkit: a Consistency Checking and Smart Link Generation Service. ACM Transactions on Internet Technology, 2(2):151–185, 2002. URL: http://www.xlinkit.com. [9] No Magic, Inc. MagicDraw. URL: http://www.magicdraw.com. [10] RosettaNet. Guide to RosettaNet Specifications, 1999. URL: http://www.rosettanet.org. [11] J. Siddiqi, I. Morrey, C. Roast, and M. Ozcan. Towards quality requirements via animated formal specifications. Annals of Softw. Engineering, 3, 1997. [12] The UN/CEFACT Modeling Methodology (UMM). URL: http://www.diffuse.org/ebXML.html. [13] UN/CEFACT and OASIS. ebXML. URL: http://www.ebxml.org. [14] Workflow Management Coalition. Workflow process definition interface– XML process definition language, 2002. WFMC document WFMC-TC-1025. URL: http://www.wfmc.org.