Jian Yang Department of Computing, Macquarie University NSW, 2109 Sydney, Australia b.orriens@uvt.nl. jian@comp.mq.edu.

Transcription

1 Establishing and Maintaining Compatibility in Service Oriented Business Collaboration Bart Orriëns Dept of Information Management, Tilburg University PO BOX 90153, 5000 LE Tilburg, The Netherlands Jian Yang Department of Computing, Macquarie University NSW, 2109 Sydney, Australia jian@comp.mq.edu.au ABSTRACT Current composite web service development and management solutions, e.g. BPEL, do not cater for assessing and maintaining comparability of business partners during business collaboration development and management. It is our firm belief that to realize the vision of developing business collaborations on demand and on the fly while ensuring that collaboration between participants involved can take place, business collaboration design needs to apply software development principles and at the same time incorporate support for specification of relationships among requirements and capabilities of different participants. In this paper we introduce the business collaboration design framework, which uses a blend of design perspectives, facets and aspects to provide designers with the means to develop and deliver business collaborations in an effective and comprehensive manner. We then explore how compatibility in collaborations designs can be handled in a verifiable manner by establishing a traceability mechanism, which facilitates assessment of the impact of change on the diverse aspects of business collaborations. Categories and Subject Descriptors D.2.1 [Software Engineering]: Requirements/Specification languages, methodologies; D.2.4 [Software Engineering]: Software/Program verification model checking, programming by contract; D.2.11 [Software Engineering]: Software Architecture domain specific architectures, languages. General Terms Design, Standardization, Languages, Verification. Keywords Service Oriented Computing, Business Collaboration, Business- IT alignment. 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, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Conference 04, Month 1 2, 2004, City, State, Country. Copyright 2004 ACM /00/0004 $ INTRODUCTION Nowadays enterprizes need to be dynamic and adaptive in order to stay competitive. This has led to an increasing demand for providing business services on demand and on the fly, and automating business services that can adapt to changes in the area such as market conditions, organizational policies, usage scenarios, etc. Recently there has been increasing focus on service oriented computing, the new emerging paradigm for distributed computing and e-business processing, to deliver flexible and adaptable corporate business services by utilizing existing services cross organizational boundaries. business collaboration here refers to a cooperation between multiple enterprizes working together to achieve a business goal. In order to realize the vision of developing business collaborations in an adaptive fashion while ensuring that the different participants can interact with one another, the specifics of business collaborations must be properly captured and modeled. Business collaboration design needs to apply software development principles and at the same time incorporate the special requirements of modern business collaboration development, i.e, support for specification and management of compatibility among collaboration participants. Therefore methodologies, modeling languages, techniques and tools are required to support designers to develop and deliver business collaborations in an effective and manageable way. Furthermore, changes to existing collaborations e.g. because of shifting market conditions, internal policies and so on, must be verifiable to determine if they do not compromise the ability to collaborate. This requires the modeling languages to facilitate the specification of both individual and overall demands for a business collaboration, as well as dependencies among them. Unfortunately, current composite web service development and management solutions including the defacto standard BPEL4WS [5] are too narrowly focused and not rich enough to address the compatibility issues of relevance to business collaborations. As a result service composition based on existing technologies and standards is very much a manual process. In this paper we introduce a Business Collaboration Design Framework (BCDF) for designing business collaborations, which provides a systematic way for analyzing the requirements and modeling the activities involved in business collaboration development.

2 To illustrate the ideas presented throughout this paper an example inspired by the case study in [4] is used. The example describes a complex multi-party scenario, which outlines the manner in which a car damage claim is handled by an insurance company (AGFIL). AGFIL cooperates with several contract parties to provide a service level that enables efficient claim settlement. The parties involved are Europ Assist, Lee Consulting Services, Garages and Assessors. Europ Assist offers a 24-hour emergency call answering service to policyholders. Lee C.S. coordinates and manages the operation of the emergency service on a day-to-day level on behalf of AGFIL. Garages are responsible for car repair. Assessors conduct the physical inspections of damaged vehicles and agree repair upon figures with the garages. The remainder of the paper is structured as followed: the framework BCDF is first introduced in section 2. Next in section 3 we analyze different types of compatibility that must be dealt with in the context of business collaboration design based on the BCDF framework. In section 4 different models for business collaboration design are presented. Subsequently, in section 5 we discuss how different aspects of collaboration designs and their compatibility is supported, and match this against the requirements identified in section 3. Related work is presented in section 6 followed by conclusions in section BCDF The Business Collaboration Design Framework (BCDF) employs a multi-layered approach based on three orthogonal concepts accommodate different design considerations from different viewpoints, i.e., collaboration, external and internal views of the participants. An overview of the Business Collaboration Design Framework is provided in Figure 1, which is briefly discussed in the following subsections. 2.1 Design Perspectives The design perspectives support 'separation of concern' which allow designers to focus on one aspect at the time without having to concern about the other aspects. Three design perspectives are identified in BCDF: 1) business perspective: from which the purpose and the requirements of the business collaboration is modeled and specified in terms of Goal, Schedule, Resource, Enterprize, Stakeholder, Step (see Figure 2). 2) conceptual perspective: from which a computational independent conceptual model is generated that depicts the business activities involved in the collaboration in terms of Rule, Event, Document, Unit, Actor, Task (see Figure 3). 3) logical perspective: from which a service-oriented business collaboration is modeled in terms of Constraint, Trigger, Message, Endpoint, Service, Operation (see Figure 4). Together these three perspectives encompass the business, operational and technical side of business collaborations. They can be used for design in a top-down or bottom-up manner, corresponding to forward and reverse engineering in system development respectively. In addition to the perspective specifications provided, mappings between them facilitate alignment of business, operational and technical requirements. Figure 1: Business Collaboration Design Framework (BCDF) perspectives, facets and aspects. The design perspectives represent different levels of abstraction in a business collaboration design, while design facets depict the elements in a business collaboration design, which have different contexts when observed from different design perspectives. Design aspects 2.2 Design Facets Business collaboration design can be seen from different perspective (abstraction level) as well as being observed from different, but equally valid points of view as described in

3 [6,11,13] that emphasis on the specification of different business description elements: what, how, where, who, when, why. Here we refer them as Design Facets in the context of business collaboration design. The what facet emphasizes the informational view of the business collaboration. The functional standpoint is taken in the how facet, which focuses on how things are done. The geographical facet of the collaboration is expressed in the where facet, whereas the who facet concerns about collaboration's participants. The temporal aspect is covered in the when facet that deals with schedules and events. Finally the why facet concentrates on describing the rational behind a collaboration. The facets and their interactions provide a complete coverage for each individual design perspective. 2.3 Design Aspects The design aspect views business collaboration design from different position: 1) collaboration aspect: describes the externally visible behavior between participants in a business collaboration, specifying how its participants are expected to behave in the collaboration, 2) participant behavior aspect: describes how an individual participant can behave in a business collaboration, i.e. its externally observable (public) behavior, and 3) local aspect: describes the internal (private) behavior which is only of the interest of a particular participant. All design aspects are expressed using the same modeling language for individual design perspectives, so that designers can define different roles of business collaborations in an uniform manner. As such they allow designers to express all standpoints of relevance for a collaboration at any given perspective. They also enable designers to focus on particular positions without losing sight of their relationship with other positions. 3. COMPATIBILITY In order to provide support for collaborations between enterprizes, it is important to get a clear picture of how the capabilities and requirements of the participants involved need to be comparable. Something is compatible if it "is able to work with something else" [3]. In the context of business collaboration compatibility is concerned with the key question of if and how participants can collaborate with one another, and it is of relevance in a wide range of areas (see e.g. [10]). In the BCDF compatibility comes in three flavors: 1) business compatibility dealing with whether participants have compatible views on the high level business requirements, e.g. whether goals are prioritized similarly; 2) operational compatibility focusing on the alignment of the internal activities of participants with their obligations in the collaboration, like the fulfillment of quality of service levels; and technical compatibility concerning the degree to which the participants' IT-infrastructures can interact with one another, such as usage of the same security mechanisms and protocols. Key to the facilitation of compatibility in the BCDF is the understanding that when a change happens in a particular aspect at a certain perspective, it must be propagated to the other aspects. For example, adoption of new communication protocols in the overall collaboration can result in loss of technical compatibility between participants. Similarly, more quality checks in internal processes may lead to longer processing time, comprising deadlines agreed upon with other participants. We refer to this self-managing capacity aspect compatibility. In addition to aspect compatibility changes must be propagated up and/or down to related aspects in other perspectives to assess their impact on compatibility there. For example, temporary service unavailability can not only lead to loss of technical compatibility, but also result in breaking quality of service levels thus compromising operational (and consequently business) compatibility. Again, the capability of self-managing such changes is called vertical compatibility. 4. MODELING IN THE BCDF There are two types of models in BCDF: meta models and models, both of which are defined from individual perspectives. The meta models are generic which provide design guidelines; while the models represent a particular design of an application, which have to conform to the meta-model in terms of the properties and associations. There are three meta-models, each describing the relevant elements of (six) design facets as classes and their Figure 2: Business Meta Model (BMM)

4 relationships for a particular design perspective. The relationships connect the classes to indicate the interactions between design facets. Meta-models for the business, conceptual and logical perspective and conforming models are introduced in subsections 4.1 through 4.3 respectively. All models are represented based on UML conventions. 4.1 Business Perspective The design activities in the business perspective are of a scoping and discovering nature. Scoping is reminiscent to early requirements analysis in software development, where the objective is to get an idea of the goals of a collaboration in order to establish its boundaries. Discovery is comparable to requirements analysis in software development, in which a description of the collaboration-to-be within its operating environment is established, and its major functions are linked to the goals. The purpose of these activities is to define one of all possible models conceivable in the Business Meta Model (BMM), where the resulting model is called a Business Model (BM). The classes and associations in the BMM are portrayed in Figure 2. In order to distinguish different design facets, we represent them in different shapes in their UML models. Resource instances such as customer plus car provide an abstraction mechanism for means such as financial, human and informational capital. Resources can be scarce, which affects the feasibility of usage scenarios. Compromises may need to be made in which strategic considerations come into play. Goals are achieved through steps, which represent high-level functions such as process claim. Steps can be dependent on one another or contain other steps to form complex ones. consume claim must have been completed before process claim can take place. Steps are of type 'internal' or 'exchanged'. Internal steps like process claim are specific to an enterprize and are not observable by others (presented inside the stakeholder boundary in Figure 3). Exchange steps provide a mechanism for defining the supply or consumption of resources between stake holders, for example consume claim information. Steps can have schedules linked to them, reflecting temporal constraints, like the 1 day deadline for process claim. Schedules have a begin and end date to define the period in which a step is to be completed. Schedules for different steps must be consistent, so that, e.g., the schedule of process claim does not interfere with that of supply claim information. Figure 3: AGFIL Business Model (AGFIL-BM) Classes need to be instantiated during design. A snippet of a BM for the AGFIL case study, the AGFIL-BM, is provided in Figure 3. One of the main classes to be instantiated first in the business meta model is the Goal class, whose instances are concrete goals in an application. Goals represent desirable aims such as 24hr receipt, manage claims. Goals are pursued by stake holders (e.g. insurance director) who serve for the participating enterprizes. A stakeholder can be interested in achieving multiple goals. The information about the participating enterprize is captured in the Enterprize class. 4.2 Conceptual Perspective At the conceptual perspective analysis is performed to study the collaboration and investigate its properties. As the result one possible instance model, called Conceptual Model (CM), is produced which is encompassed by the Conceptual Meta Model (CMM). The CMM is portrayed in Figure 4, whereas an example AGFIL-CM can be found in Figure 5.

5 As illustrated in the AGFIL-CM in Figure 5 actors such as claim office employee and consultant interact with each other to perform tasks. Tasks are of type 'internal' or 'communication' (represented inside or on the boundary of the actors respectively). Internal tasks constitute private activities, e.g. collect claim info done by claim office employee. Communication tasks involve receipt or sending of information like report invoice. Actors belong to units such as claim handling unit, which provide Figure 4: Conceptual Meta Model (CMM) organizational grouping constructs like project team. Events are used to assess progress, keep logs to ensure nonrepudiation, etc. Events describe business occurrences, which have properties such as 'date', 'time', 'severity'. Events can trigger, modify, pause, resume or end both internal and communication tasks. claim received is an example of an internal event, whereas estimate send illustrates the usage of external events. Figure 5: AGFIL Conceptual Model (AGFIL-CM)

6 Events are signaled by the receipt or sending of documents, like estimate send being signaled by estimate. Documents are communicated between actors to further their own state as well as that of the overall collaboration, e.g. communication of invoice between claim office employee and consultant. All classes, properties and associations in the CMM can be constrained by rules. Rules comprise statements that define or constrain some aspect of the business, which are intended to assert business structure or to control or influence the behavior of the business [2]. A rule has a condition and conclusion part, where the former describes what must be true in order for the latter to be true (e.g. if estimate > 500, then select assessor followed by consultant). Other rules may constrain event occurrences, actor selection, etc. 4.3 Logical Perspective A conceptual model is realized in the logical model where the collaboration is put into a computational context, which is referred as service oriented computing (SOC) in this paper. The Logical Meta Model (LMM) is illustrated in Figure 6. A snippet for the AGFIL example is depicted in Figure 7 as one possible logical model (LM) of LMM. allow clients for example to request claim management. Services provide containers for collections of logically related operations. Operations such as place invoice are specific business functions, and are described in terms of their access details as well as relevant non-functional properties. Inputs and outputs of operations are represented as messages, which represents containers of information (e.g., claim management request), consisting of meta-data and actual data. Meta-data comprises the information required to deliver the message and enable processing (like parameters concerning reliable messaging, encryption styles, characters used, etc). The second type of information in messages constitutes payloads, which contain any content of the message not conveyed in its meta-data (like text documents, images, video files, etc). The receipt and sending of messages result in triggers, which express a relevant system occurrence e.g. claim request acknowledged. They are similar to events in the CMM, however here emphasis is on monitoring the computational progress. Triggers can be controlled by constraints, which have properties such as 'condition', 'action' and 'status'. They can constrain any LM element e.g. an operation's performance parameters. Figure 6: Logical Meta Model (LMM) Actors involved in the AGFIL-CM are represented as 'endpoints' in the context of service oriented computing. Endpoints such as claim handling endpoint have properties 'network location' and 'type'. Endpoints can be specified abstractly or concretely, and are the access points through which services are requested and/or provided. claim handling endpoint e.g. provides claim handling service, while requiring claim management service. Services expose their functionality through interfaces, prescribing the conditions under which other endpoints can access them. claim management service provided by consultant endpoint 5. COMPATIBILITY Compatibility management (automatic or manual) requires traceability, while traceability requires a mechanism to identify all the dependencies between different design areas. In this section, we shall explain how compatibility management is supported in the BCDF framework.

7 5.1 Compatibility along perspective Dependencies exist among design aspects as they encompass different parts at the same perspective for a business collaboration. As observed in subsection 2.3 all aspects are expressed using the same modeling language for a particular design perspective. Looking for example at the business perspective, Collaboration-BMs can be defined from the generic BMM by excluding internal goals, etc, constituting all description elements on or outside the boundary of participants in Figure 3 (like 24hr receipt and damaged car). The individual views of participants on the collaboration constitute the elements positioned at their border, such as supply claim info and repair evaluation information of insurance director, and are captured in so-called ParticipantBehavior-BMs prohibiting use of internal description elements or more than one external stakeholder and enterprize. All description elements contained within a participant's borders together form the model of its local aspect, i.e. Local-BMs expressed through internal elements only, e.g. inspect car and assess for assessor manager. 5.2 Compatibility along aspect The design perspectives in the BCDF are different in terms of level of abstract and content. However, for the same business collaboration they are related to one another. These relationships need to be made explicit to determine the impact of changes in an aspect at one perspective on the other. This is realized by providing links between the classes in different meta-models and instance models at different perspectives. Implicit links already exist between classes that describe the same design facet at different design perspectives. For example, stakeholder in the BMM is related to actor in the CMM (they are all octagon shape in the figures). The semantic meaning is that the work that a stake holder promises to fulfill, is delegated to actors such as employees, information systems, etc. insurance director in the AGFIL-BM is mapped to claim office employee in the AGFIL- CM. Continuing the traceability within the who facet, an actor in a CM is represented as one or more endpoints in the corresponding LM. For example, assessor in Figure 5 offers its services via assessment endpoint in Figure 7 Figure 7: AGFIL Logical Model (AGFIL-LM) To illustrate how aspect compatibility is supported let us assume that AGFIL decides to adjust its business strategy and will now pursue the goal accurate assessment rather than quick assessment, thus changing the AGFIL Collaboration-BM. As a consequence the expected behavior from assessor manager changes, requiring it to assess how the ParticipantBehavior-BM describing its potential behavior needs to be modified. This can lead to the installment of an extra quality check of step assess, as such resulting in changes to its Local-BM. Of course changes to internal behavior can also be traced to potential behavior of participants, and consequently to the overall public behavior. To exemplify vertical compatibility suppose that the internal implementation of claim management service has changed with regard to its message encryption technique. As a result these now differ from the ones adopted by claim handling service in the AGFIL-LM. Tracing the change to the AGFIL-CM we find that communication of estimate must be done confidentially. Moving further up the AGFIL-BM states that exchange of customer plus car information must be done securely. Thus we find a conflicting situation in which a lack of technical compatibility between the services claim handling service and claim management service leads to a lack of business compatibility between AGFIL and Lee C.S as the security requirement can no longer be met.

8 6. RELATED WORK Most of the work in service composition and business collaboration has been focusing on the development of compositions without taking modeling and compatibility management into too much consideration. BPEL [5], the de facto standard in this area, provides "a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners". BPEL provides no basis though for capturing different aspects of processes. Representative work from the scientific community on service composition specification is provided in [8] that provides an "appropriate conceptual model for developing and describing web services and their composition". The framework offers no support though for a traceability mechanism to establish or maintain compatibility among business collabration participants. Some specific work has been done in the service composition arena concerning aspects and their compatibility. For example, [12] presents a development process to incrementally align socalled global and local requirements within business collaboration through negotiation. However, there is no clear-cut separation between technical and business requirements, compromising the capability to establish and manage compatibility. [7] identifies similar design aspects as in our framework, however, their application is limited to a service oriented computing context. Prominent work in the area of business process modeling is the ebxml framework. Its specification, ebbpss [9], defines a metamodel for describing business collaborations. The implementation of conforming models is facilitated through other components of the ebxml suite. ebbpss in conjunction with the components ebcpp and ebcpa offers a conceptual approach for merging business profiles into agreements, but this mechanism is not grounded on an explicit traceability mechanism with which compatibility can be easily determined. The system development community has focused much of its efforts in developing comprehensive methodologies for developing enterprize information systems. An exemplary proponent is Tropos [1], an agent-oriented software engineering methodology focusing on "activities that help to gain understanding of how and why the intended system would meet the set out goals". The main difference with our work lies in the fact that the notion of aspects is not present, and its potential is thus not harnessed. The contributions of our work in comparison to the abovementioned work on business collaboration design can be summarized as followed: The BCDF provides the modeling methodologies and languages required for business collaboration design ranging from high-level requirements to actual implementation in a consistent and comprehensive manner. Moreover, designers can view and model collaborations from different positions via the design aspects. Due to its support for tracing the BCDF enables the assessment of the impact of changes in the existing collaboration design, and solutions can be provided accordingly. The support for traceability enables automated detection of conflicts arising due to the incorporation of a change in a design aspect or perspective. Especially when combined support for the two forms of compatibility can provide a powerful set of tools for ensuring compatibility throughout business collaboration designs. Its ability to develop business collaborations in a modeldriven fashion, makes it possible for the rapid development and delivery of business collaborations based on proven and tested models, which is a critical benefit in a highly dynamic business environment. 7. ACKNOWLEDGEMENTS This work was partially funded with an UNSW Australian ARC Discovery Research Grant. 8. CONCLUSIONS Current standards in business collaboration design, such as BPEL and ebxml, are not suitable for dealing with the complex and dynamic nature of developing and managing business collaborations while maintaining compatibility between participants. Without the support for high level modeling facilities and traceability such standards cannot facilitate the verification of compatibility required in cross-organizational business processes. The challenge is thus to provide a solution in which business collaboration design can be done in an effective and traceable manner to establish and maintain compatibility of business, operational and technical requirements among participants. In this paper we have presented the Business Collaboration Design Framework (BCDF), a framework that utilizes a multiperspective and multi-facet approach to collaboration design. Business collaborations are modeled in three different perspectives where designers can view the collaboration in three aspects. The work presented herein emphasizes the relevance of the BCDF for modeling different aspects of business collaboration and establishing a traceability mechanism to support verification of their compatibility. Work for future research will be foremost focused on the formalization of the BCDF to allow formal verifiability of compatibility rather than just conceptually. Another issue that needs to be addressed is the development of a change management sub-system to control the evolution of business collaboration designs. 9. REFERENCES [1] Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., and Mylopoulos, J. Tropos: An Agent-Oriented Software Development Methodology. Autonomous Agents and Multi- Agent Sytems, Vol. 8, pp , 2004 [2] Business Rules Group. Defining business rules - What are they really. July [3] Cambridge Learner's Dictionary. [4] Grefen, P., Aberer, K., Hoffner, Y., and Ludwig, H. CrossFlow: Cross-Organizational Workflow Management in Dynamic Virtual Enterprises. International Journal of Computer Systems Science & Engineering, Vol. 15, No. 5, pp , 2000.

9 [5] Curbera, F., Goland, Y., Klein, J., Leymann, F., Roller, D., Thatte, S., Weerawarana, S. Business Process Execution Language for Web Services ibm.com/developerworks/webservices/library/ws-bpel/, July 31, [6] Curtis, B., Kellner, M., and Over, J. Process Modeling. Communications of the ACM, Vol. 35, No. 9, pp , [7] Dijkman, R., Dumas, M. Service-oriented Design: A Multiviewpoint Approach. International Journal of Cooperative Information Systems, Vol. 13, No. 4, pp , [8] Fensel, D., Bussler, C. The Web Service Modeling Framework WSMF. Electronic Commerce Research and Applications, Vol. 1, No. 2, [9] EbXML. Business Process Specification Schema. [10] Nagy, A., Orriens, B., and Fairchild, A. The Promise and Reality of Internet-Based Interorganizational Systems. In Proceedings of the E-Society IADIS International Conference, Avila, Spain, [11] Scheer, A. Architecture for Integrated Information Systems - Foundations of Enterprise Modeling. Springer-Verlag New York, Secaucus, NJ, USA, [12] Traverso, P., Pistore, M., Roveri, M., Marconi, A., Kazhamiakin, R., Lucchese, P., Busetta, P., and Bertoli, P. Supporting the Negotiation between Global and Local Business Requirements in Service Oriented Development. In Proceedings of the 2th Int. Conference on Service Oriented Computing, New York, USA, [13] Vernadat, F. CIMOSA - A European Development for Enterprise Integration Part 2, Enterprise Modeling. Pergamon Press Inc. Tarrytown, NY, USA, 1992.