2.1 The PARIS Reference Model for Virtual Service Production Networks .... terms of network-level production control, brokers execute the orchestration ...
Technical Report
Service-Oriented Modelling and Design of Virtual Business Services∗ Christian Zirpins
Wolfgang Emmerich
Computer Science Department University College London United Kingdom
Economic theory defines business services as customisable, interactive processes that providers have the potential to carry out together with clients that benefit from the effects. It is understood that business service transactions are best organised by means of virtual networks, where information technology allows for configuring multiple providers and processes on a per-request basis. Existing conceptual models for virtual service enterprises propose business service virtualisation to allow for flexible and agile regulation and control of coordination between multiple providers and clients. In this paper, we present an approach for realising business service virtualisation based on software service technology. In particular, we propose a service-oriented software architecture for representing virtual business service processes as e-services. E-service models specify flexible business service interactions between multiple providers and clients of virtual service enterprises and allow for regulation and enforcement of their coordination. We demonstrate the utilisation of our e-service SOA in the context of an e-science scenario, where we show how to design e-service models for the use case of virtual polymorph prediction laboratories.
1 Introduction Business services are integral to any commodity and make up a growing industry of intangible goods. In terms of production, it has been argued that organisational requirements ∗
This work is supported by Marie Curie Intra-European Fellowship grant MEIF-CT-2005-025239 within the 6th European Community Framework Programme. See [Zir07b] for additional information.
1
to provide configurable, interactive and immaterial service processes are best met by virtual organisation principles [PN98]. Respective virtual service enterprises are temporal organisational networks that abandon institutionalised network management in favour of information technology. This allows for dynamic identification, initiation, negotiation operation and liquidation of service production networks on a per-request basis. As an important aspect of information technology support for virtual service enterprises, regulation and enforcement of coordination rules for cooperative activities of service client(s) and providers in temporal business service production networks need to be enabled in a flexible and agile manner. In earlier work we have shown, how this can be archived by virtualisation of business services themselves [Zir07a]. We presented a formal conceptual reference model that explains how to coordinate a virtual production network (VPN) for business services by means of planing and control production of virtual business services (VBS) [ZE07]. The latter procedures can be effectively supported by information technology. We showed that according technology includes electronic representations of virtual business service processes (e-services) as well as structured methods and procedures for their planing and control (e-service management). Moreover we presented evidence for the fitness of software service technologies – as promoted by the paradigm of Service-Oriented Computing (SOC) [PG03] – and especially Web Service technologies [ACK+ 04] in this respect. Software service abstractions showed potential to represent virtual business service processes in a way that service oriented development life cycle methodology can be adopted to regulate and enforce coordinative rules in virtual business service production networks. In the PARIS (Pattern-based ARchitecture for Service Interaction) research project, we have developed an approach to realise e-service technology by means of serviceoriented software architecture for e-services and service-oriented development life-cycle methodology for e-service management. In terms of e-services, we propose a general service-oriented software architecture model that defines how virtual business service processes according to our conceptual reference model are to be represented by software service abstractions. More explicit, we provide a formal e-service metamodel in UML that defines all details of workflow processes, software service composition and coordination processes and patterns as well as business service interaction underlying our e-service abstraction. The metamodel defines a domain specific graphical (i. e. UML-based) specification language for e-service models that can be used to design and execute e-services in the course of planing and control of virtual business service processes. In terms of e-service management, we propose a refinement of the GERAM enterprise architecture framework [II03] to integrate e-service-management into the wider context of business service enterprises. The framework defines all aspects that are to be considered for an engineering approach to run virtual business service production networks by means of e-service technology. In particular this includes an e-service development life-cycle that realises regulation and enforcement of coordination in virtual service enterprises. We propose a general software service development life-cycle model for e-services that modifies the generic life-cycle of service-oriented software development to support the
2
life-cycle of virtual service enterprises. Following our development process, e-service design and execution regulates and enforces the coordination of clients and providers throughout planing and control of business service production. More specifically, we have developed a concrete service-oriented development methodology and implemented a tool set demonstrator for our e-service SOA that includes a model-driven development tool chain as well as an execution platform based on OGSA and BPEL. In this paper we focus on the PARIS e-service metamodel and its service-oriented software architecture for representing virtual business service processes. To provide the conceptual background, Section 2 wraps up the underlying conceptual reference model of virtual business service production networks. It also summarises the technical realisation strategy of e-services and e-service management and outlines the utilisation of of SOCtechniques for this purpose. As the core of this paper, Section 3 introduces the software architecture model that has been designed in PARIS to realise e-services. This includes an informal service-oriented software model for e-service systems as well as a formal e-service metamodel that defines the structure and (informal) semantics of e-service design in UML. To underpin our proposal, Section 4 utilises the PARIS e-service metamodel in the context of an e-science scenario, where business service virtualisation is adopted for virtual organisation of laboratories for carrying out computational chemistry experiments. Here we show how to design virtual polymorph prediction service as service-oriented e-service models. The paper closes with a discussion of related work in section 5 and a summary and outlook in section 6.
2 VBSPN: Conceptual Model and Realisation Strategies Our technology approach to supporting coordination of virtual service enterprises is based on a conceptual reference model of virtual business service production networks (VBSPN) and a requirement analysis for information technology to realise VBSPN coordination. In this section, we give an overview of the conceptual model as well as the required class of e-service technology. An elaborated description and case study can be found in [ZE07].
2.1 The PARIS Reference Model for Virtual Service Production Networks Virtual organisation [Mow97] is a specific aspect of network organisation theory [Syd92]. It relies on information technology as its key enabling factor and is thereby inevitably inter-disciplinary. In the PARIS project, our goal is to provide novel information technology to enhance capabilities and properties of virtual organisation. This requires a profound organisational background. We provide this background by means of conceptual modelling. Generally, conceptual modelling is about representing (part of) a complex situation in an abstract manner and with precise notation. It allows for gathering and representation of information for the solution of complex problems from technical or organisational domains. Respectively, we use object-oriented UML notation to define economic, organisational and technical base concepts as well as their relationship and interplay. The result is an enterprise architecture reference model for virtual service
3
enterprises. In the following, we will summarise major aspects of the model and show high-level parts that directly underlie the technical framework we will propose. The complete model is described in [ZE07]. Additionally, the UML sources are available on the project website for inspection [Zir07b]. A fundamental part of the reference model defines common economic and organisational concepts. This mainly includes business services and virtual production networks. Business services (BS) are based on three fundamental service characteristics that together define a transaction between a client and a provider role [Cor01]: An initial pre-contact phase relates to the necessary potential of providers to serve clients. It involves providers planing services and clients observing service offers. A subsequent contact phase relates to interactive production processes. It involves clients and providers interacting in service provision. A final Post-contact phase relates to lasting beneficial effects of provision. It involves clients utilising and providers analysing provision effects. Central to the transactional business service model is the contact phase that includes the interactive provision process. We refine this contact phase as business service process (BSP) that is commonly structured into three categories of sub-processes [Har03]: Support processes (back office) involve providers that back provision with internal support activities. Control processes involve providers that coordinate provision with control activities. Core processes (front office) involve clients that participate in provision with core activities. Business service production is a provider-centric perspective on organising business service transactions. Following common suggestions, we focus on virtual organisation of business service production. Fundamental to this is the concept of virtual production network. As an underlying concept, we need to introduce production networks as decentralised form of production systems with multiple production units cooperating to share resources [EST00]. Formally, we define production networks (PN) as organisational networks consisting of producer, broker and coordinator roles. Their responsibilities revolve around the central task of production management that includes production planing and control both on the level of the network as a whole and on the level of network nodes (i.e. production units). We define node-level production planing and control as autonomous responsibility of producers. Network-level production planing and control are considered responsibilities of the network broker and coordinator respectively. While production networks are potentially long lasting, their virtualised form is temporary with respect to a single request. As a consequence, production management needs to allow for ad hoc planing and control. We address this requirement on network-level. Our concept of virtual production networks (VPN) refines network-level production planing as regulating coordination of producer interactions [SK00]. This includes coordinative programs that can be readily enforced and plans on how to archive rapid change of such programs. Accordingly, network-level production control is refined as enforcing coordination of producer interactions by means of executing coordinative programs. Production management on node-level remains unchanged. In a nutshell, the idea is to have a pool of long-term production plans on node-level that are composed by ad hoc selection and rapid adaptation of interaction programs between them. The result is a global plan that is customised to a single production request and can be readily enforced.
4
> > Core Activity Extension Points
> > BSP Front Office Extension Points
> PSM Consumption Extension Points Demand:Interaction
>
> PSM VBS-Demand
coordinates
>
> PSM VBS-local capabilities
Contact Phase (BSP) Extension Points VBSP:Operation PARIS VBSP:Control
> BSP Control Extension Points > >
coordinates
>
> PSM Provision Extension Points Capability:Interaction
> Control Activity Extension Points
> PSM VBS-Capabilities Extension Points
PARIS Virt. Contakt (PARIS VBSP)
>
PSM VBS-global capabilities > > BSP Back Office Extension Points
coordinates > PSM Content Extension Points Asset:Interaction
> >
> PSM VBS-Assets
> > Support Activity Extension Points
Figure 1: Virtual Business Service Process
The main part of the reference model defines an original organisational approach to refine virtual production networks for business service production. Such virtual business service production networks (VBSPN) are based on business service virtualisation. We seek to exploit side-effects of business service virtualisation in order to virtualise business service production networks in turn. Our virtualisation strategy for business services is based on the fundamental distinction of service content and provision. Service content is based on assets of providers that are potentially beneficial to clients (e.g. knowledge, money, machinery etc.). Service provision relates to capabilities of administrative procedure to make content accessible to clients. As a counterpart to service content, we define service consumption as demands of clients to receive benefits during service provision. A business service is based on a set of assets (service core), each of which gets provided by means of a local capability. A second type of global capabilities combines the set of local capabilities into an integrated business service process (service shell). Service content, provision and consumption are all represented in the common business service process. Fig. 1 defines this relationship by means of an UML use case diagram. It shows the case of business service process on the left which consists of the aforementioned sub-processes and activities. Next to the right are the cases of content, consumption and provision generally corresponding to support, core, and control parts of the service process. Note, that we consider all parts of the process structure as well as control
5
activities as service provision. Finally, the right part of the diagram defines the actual service virtualisation as regards substitution by information technology counterparts. We substitute the interactive aspects of provision processes by electronic representations of interaction processes referred to as capabilities that can be formally specified and automatically executed. Interaction aspects of activities representing service content and consumption are substituted by electronic representations of communication endpoints referred to as assets and demands. Again this enables formal specification and automated interaction. As the intended side effects of virtualisation, we apply the newly acquired abilities to production management of virtual business service production networks. In virtual business service production networks, producers become joint providers of virtual business services. Brokers and producers of virtual production networks take over responsibilities of coordinators with respect to local and global parts of the virtual business service processes. Furthermore, clients of virtual business services become involved as producers because they actively participate in provision. The production management tasks of the various roles are being enabled by two basic types of virtualisation: substitution of interaction processes and communication endpoints with electronic representations. Both types of virtualisation allow for formal specification methods and automated execution of the respective service process part. We consider formal specification as a way of planing and automated execution as a way of controlling a part of the service process. Subsequently, we define a virtual business service (VBS) as a business service that is based on a virtual business service process and that utilises automated planing and control methods during pre-contact, contact and post-contact phases for management of a virtual production network. In the following we explain the mechanics of virtual business service production management in the course of virtual business service transactions and show respective parts of the conceptual reference model in UML notation that refer to virtual business service production planning (fig. 2) and control (fig. 3). Virtual business service production planing starts in pre-contact phase. On nodelevel, providers and clients perform long-term production planing and expose results as formal specifications of assets and demands. Additionally, providers formally specify local capabilities that enable access to their assets. On network-level, brokers plan a variety of business service offers based on assets and local capabilities of producers in the production network. They expose plans as virtual business service shells including formal specifications of all global capabilities and requirements on local capabilities of producers. Providers may in turn inspect global plans and adjust their local counterparts. We anticipate that brokers will need to plan for flexibility of service offers with respect to changing non-functional requirements of clients. We therefore introduce a patternbased approach to virtual business service planning. In essence, we refine the case of specifying capabilities as capability regulation. Capability regulation includes the case of interaction regulation that specifies a general pattern of coordinative rules for the capability. Interaction regulation goes along with a set of orchestration regulation cases. Each case of orchestration regulation specifies an idiom that enforces the coordinative rules of the capability in a different way and thereby results in different non-functional
6
Development of Assets
Development of Local Capabilities Extension Points Regulation Pattern:variation
> PSM Interaction Regulation
PARIS Provider
>
> >
>
Extension Points Regulation Pattern:variation
PSM VBS-Capability Regulation
>
PARIS Broker
> Development of Global Capabilities
> PSM Orchestration Regulation
1..*
Sighting and Adjustment of Capabilities
Extension Points Regulation Pattern:variation PARIS Client > > 1..*
PSM VBS-Capability Enforcement
Capability Instance Evaluation
Figure 2: Production Planing Functions of VBSPN Actors
properties. Differences are mainly archived by shifting control between participants of virtual production networks (e.g. centralised control may lead to higher security and lower robustness then decentralised control). Based on service offers of brokers, clients check virtual business service shells (i.e. the interaction regulations of capabilities) against their demands and may issue a request including non-functional requirements. Brokers will then select appropriate providers and orchestration regulations to control business service provision within the virtual production network in an optimised way. Virtual business service production control is realised within contact phase of virtual business services. Control is chiefly based on automation of virtual business process parts. This includes automated communication with assets and demands as well as execution of capability orchestration regulations (referred to as capability enforcement). In terms of node-level production control, providers and clients run their internal processes related to assets and demands individually and autonomously. They are integrated by means of electronic communication interfaces to assets and demands that allow for automated interaction with other parts of the virtual business service process. Providers also execute the orchestration regulations of local capabilities to control access to their assets. In terms of network-level production control, brokers execute the orchestration regulations of global capabilities to control the flow of virtual service processes. After finishing the virtual business service process, virtual business service production planing is continued in post-contact phase. In this phase, providers and brokers analyse the preceding contact phase in terms of efficiency and effectiveness. This might leads to needs of changing virtual business service production planning. Also in post-contact phase, clients will analyse and utilise the effects of preceding business service processes.
7
> PSM VBS-Capability Enforcement
>
> PSM VBS-Capabilities
> PSM VBS-Assets
content specific interaction
provision of contact points for production specific interaction
usagespecific interaction
control of global interaction flow
Control of local interaction flow
PARIS Broker
PARIS Coordinator
PSM VBS-Demand
provision of contact points for consumption specific interaction
control of interaction flow
PARIS Provider production specific interaction requests
>
Extension Points Enforcement Instance:variation
PARIS Client production specific interaction requests
Figure 3: Actors of Operational Virtual Business Service Production Networks Again, they might want to change formal specifications of their demands at this point in order to maximise benefit of future business service provision.
2.2 E-Service Technologies for Business Service Virtualisation The PARIS conceptual reference model for virtual business service production networks suggests realising coordination of virtual networks by means of virtualising business services. Business service virtualisation is required to substitute a) business service processes and b) business service transaction phases by means of information and communication technology. These technologies are meant to enable regulation and enforcement of coordination in virtual production networks by means of planing and control of virtual business service production. In particular, this capability implies that planing and control need to be flexible and agile enough to allow for ad hoc changes with respect to the individual missions of virtual production networks. Requirements for respective information and communication technologies can be summarised in the definition of two types of business service representation technologies: • E-services provide electronic representations of a virtual business service processes including virtualised interaction process patterns and communication endpoints. Both aspects need coverage as model, design, architecture, executable and audit trail for information systems of participants within virtual production networks. E-service technologies must provide design models to formally specify flexible coordinative regulations of virtual business service production networks as e-service models. E-service technologies must also provide execution models and middleware frameworks to rapidly adapt and implement e-service models as coordinated flows of communication activities between operative information systems belonging to network participants. Thereby e-services build the integrative core of an interenterprise cooperative information system for control of business service production.
8
• E-service-management relates to virtual business service phases of preparing, operating and analysing virtual business service processes. Theses phases build on methods for design, adjustment, verification, construction, testing, deployment, execution, monitoring, analysis and evolution of e-services (and the respective inter-enterprise cooperative information systems). Generally, e-service-management technologies subsume development processes and methods for e-services that conform to flexibility and agility requirements for instant planning and control of virtual business service production networks. It can be argued that e-service technologies extend common models of technology infrastructure for virtual enterprises [CM05]. From this perspective, e-services extend communication and cooperation techniques of horizontal base infrastructure for interaction and coordination within virtual enterprises. E-service-management extends vertical support functions of virtual enterprise life-cycle with respect to distributed business process management. As the general concepts of e-services are technology agnostic, various technologies like software objects, components, agents and services, which have all been discussed as virtual enterprise technology infrastructure [CMA03], may be used for e-service realisation. Following, we focus on software service technology. Common roots of business services and software services encourage this choice, as was also noted by CamarinhaMatos [CMA03]. In particular, we outline the realisation of e-services and e-servicemanagement by means of Web Service technologies [ACK+ 04]. E-services can be based on Web Service technologies for interoperable communication as well as coordinative regulation and enforcement of interactions. Web Services naturally provide an implementation of communication endpoints. They offer ways of description (e.g. WSDL) and interoperable access (e. g. SOAP) as well as support for publishing and discovery (e. g. UDDI) in organisational networks. Moreover, formal semantics are increasingly becoming available (e.g. WSMO). In general, technologies for Web Service interaction provide basic mechanisms to implement business service interaction patterns. This includes service coordination regulation via interaction protocols (e. g. WSCI) and implementation of regulations via Web Service composition techniques (e. g. BPEL). Pattern concepts for virtual business service interaction and orchestration regulation are generally corresponding to software service interaction patterns (e. g. Barros et al. [BDH05]) and pattern primitives for service-oriented architecture description (e. g. Zdun et al. [ZHD07]). Regarding base-technologies for e-service-management, results on software service development methodology are already available. Papazoglou proposed a “service-oriented development life-cycle methodology” [PvdH06] that shows similarities to virtual enterprise life-cycle models like that of Mertens et al. [MF97]. He also lists service-oriented software development methods that include several aspects of e-service-management technology requirements. The PARIS project refined these basic relationships by means of an elaborated software service technology framework. In the remaining parts of this paper we will focus on the PARIS approach to e-services and demonstrate its application in a use case experiment.
9
3 Service-Oriented Software Architecture for E-Services Business service virtualisation technology fundamentally builds on realisation of virtual business service processes. These are essentially to act as interaction programs to flexibly regulate and rapidly enforce coordination of cooperative activities between members of virtual business service production networks. In order to archive this, virtual business service processes substitute interactive aspects of conventional business service processes by information and communication technology. The goal is for electronic representations of communication endpoints and interaction process patterns to allow for formal specification and automated enforcement of interaction and coordination between operative information systems of clients, providers and brokers. This ability shall then be used to integrate systems of virtual organisation members into temporal cooperative information systems for control of business service production that we refer to as e-service systems. With other words, e-service systems are ad hoc compositions of loosely coupled information system components. Generally, we refer to the integrative core of such a composite system as e-service. Furthermore, we distinguish regulation of composition logic by means of e-service schemas from enforcement of composition logic by means of e-service instances. Respectively, we refer to software technology infrastructure that facilitates the software development life-cycle of e-service systems as e-service management system. With respect to the discussion at the end of the last section, our general concept is to leverage service-oriented software technology to realise e-service systems in general and e-services – their integrative core – in particular. More precisely, we adopt serviceoriented software architecture for e-services and service-oriented development life-cycle methodology for e-service management. In this paper, we focus on service-oriented software architecture of e-service instances and design of e-service schemas as serviceoriented architecture models. In the following, we will first outline a specific serviceoriented software model that explains the roles, functions and software service abstractions involved in the development life-cycle of e-service-systems. We will then present an UMLbased e-service metamodel that gives a detailed description of service-oriented software architecture for e-service instances and builds the foundation of a graphical language for e-service schemas. Finally, we discuss how to adopt the metamodel for virtual bisiness service planning and present the PARIS UML profile for e-service modelling. Serviceoriented software development life-cycle methodology for this kind of e-service systems is subject of a complementary paper [ZE08].
3.1 A Basic Model for Service-Oriented E-Service Systems Service-oriented computing is a paradigm for building and operating software application systems by means of software service abstractions and architecture, utilising software service development life-cycle methods and methodology. The paradigm is fundamentally described by “service-oriented models” like that of Papazoglou et al. [PG03] that specify common roles (e. g. client, provider, broker, aggregator, operator) and their functions (e. g. description, publishing, discovery, selection, access, coordination, composition, marketing,
10
support etc.) with respect to the development of software services on various abstractionlevels (basic, composed, managed). In our approach to realise virtual business services by means of software service technologies, we propose a refinement of the service-oriented model for the case of managing e-service-systems. Our service-oriented model corresponds to the PARIS conceptual reference model for virtual business service production networks and we refer to it as PARIS SOM . The PARIS SOM refines general SOM service abstractions, roles and role functions in order to match the requirements for business service virtualisation in the PARIS conceptual reference model. The fundamental aspect of the model is the refinement of software service abstractions for business service process virtualisation. The PARIS model defines demands, assets and capabilities as the main concepts of virtual business service processes (see fig. 1). In the PARIS SOM, we map these concepts to refined software service abstractions. Demands and assets represent communication endpoints of PARIS clients and providers. They handle interactions necessary for consumption of self-contained service content. We map both concepts to refinements of the atomic software service abstraction referred to as demand and asset service. Demand and asset services are formally specified by software service description languages and automatically controlled by means of software service access mechanisms. We require specification and automation of business service interaction steps by means of operational interfaces. Further specifications might include supported conversations as well as semantic classification. Capabilities represent interaction process patterns of PARIS providers and brokers. They regulate and control an administrative procedure to access service content. We map this concept to a refinement of composite software services referred to as capability services. Capability services are formally specified by means of software service coordination protocols and automatically controlled by means of software service composition schemata. Fundamentally, we require specification and automation of business interaction processes by means of functional business process structure, roles and implementation. Further specifications might include non-functional process aspects. To realise PARIS concepts of flexible planing, we require specification of protocol patterns and their automated resolution into executable orchestration schemas. Such technologies are beyond current SOC state-of-the-art, but we will show a possible solution in our e-service SOA metamodel. With respect to the structure of PARIS virtual business service processes, asset services are associated with local capability services that regulate and enforce interactions with demand services to access service contents. Furthermore, global capability services regulate and enforce interactions between local capability services to combine service content of various providers. Fig. 4 shows the refined software service abstractions of the PARIS SOM and their relationships. Furthermore, the figure indicates the refinement of SOM roles and functions to match the roles of the PARIS conceptual model and their responsibilities of virtual business service production planning and control. Here, client- and provider roles of the PARIS SOM are both refinements of SOM software service providers, as they provide atomic demand- and asset services. The PARIS coordinator role is a refinement of the SOM software service aggregator, as it provides composite capability services. The
11
Consumption Resource
PARIS Client
Capability Capability Glob. Capability Srv.
PARIS Broker /Coordinator
Loc. Capability Srv
Demand Srv.
Provision/Shell
Asset Srv.
Content/Core Resource
PARIS Provider /Coordinator
Figure 4: Service-oriented Model of Business Service Virtualisation in PARIS
abstract coordinator role is assigned to the concrete PARIS roles of broker and provider with respect to global and local capability services. In the pre-contact phase of VBS, the various roles of the PARIS SOM are responsible for specification and mutually adjusting their software services. Fundamentally, PARIS providers describe their asset services as well as their local capability services and publish them in repositories of PARIS brokers that are accessible within and outside of the organisational business service network. Outside of the network, PARIS clients query the repository to discover asset services and capability services. In turn, they specify their demand services and likewise publish them in a repository. Inside of the network, PARIS brokers discover demand services as well as asset services and related local capability services. They specify global capability services that combine asset services with respect to demand services by composing respective local capability services. In the contact phase of virtual business services, the roles of the PARIS SOM execute their software services to automate control of business service processes. PARIS brokers rapidly optimise and implement global capability services with respect to given client requests that contain actual non-functional requirements. All other services can be implemented and deployed in the pre-contact phase. In turn, execution of global and local composite capability services automatically enforces the planned regulation of interactions in the business service process. Finally, in the post-contact phase of the virtual business service, PARIS SOM roles analyse the interaction logs of their software services that were monitored in the contact phase. With respect to the results, they might evolve specific aspects of the software service specifications to optimise effectiveness or efficiency of the virtual business service process. They re-publish these changes for future business service transactions.
12
3.2 Service-Oriented software Architecture for E-Services The PARIS SOM gives a general overview of the principle of business service process virtualisation by means of software service abstractions. However, a much more precise specification is needed in order to realise the indicated role functions of a virtual business service transaction. The planing functions require a specification language that enables the formal design, analysis and adjustment of all parts of an e-services. The control functions require a software architecture framework as well as executable languages to construct and run all e-service components. We provide both by means of a serviceoriented metamodel for e-services that we refer to as PARIS E-Service Metamodel or PSM for short. On the one hand, the PSM defines components and relationships of a service-oriented architecture for e-services. On the other side, the PSM defines the syntactical elements and semantics of a language for e-service design. Our definition focuses on the structural aspects of the e-service architecture and respectively the formal syntax of e-service specification language by means of UML class diagrams. As key characteristic, the PSM is as agnostic as possible with respect to specific standards and technologies of service-oriented computing in general and the Web Service architecture in particular. PSM conception aims at abstraction layers of platform independent e-service models and platform specific software service models that are precisely mapped to conform to business service process virtualisation requirements. PSM architecture does not define the concrete technology platform to implement platform specific software service models. The rationale of this conception is to define a generic framework architecture that is applicable to multiple existing SOC standards and technologies and to decouple the architectural concepts from their fast evolution cycles. Concrete mappings need to be defined from platform specific software service models onto concrete ones. In order to represent process organisation of business service provision, the PSM defines a process-driven service-oriented software architecture. Abstracting from specific process-oriented software service interaction technologies, the PSM is based on a generic notion of working process [Kos62]. In organisation theory, working processes involve performers that carry out associated activities of structured methods for the sake of transforming inputs into outputs. In the PSM, we adopt the generic concepts of working processes for both business service processes and software service interaction processes and we base their mapping upon these common roots. Technically, we use a workflow metamodel to formalise working processes and define metamodels of software service interaction and e-services as stepwise refinements. Fig. 5 shows an overview of the PSM in terms of its UML packages and some key classes. The foundation of the PSM is a graph metamodel that introduces directed graphs (Digraph) as a formal basis for higher-level process descriptions. Consequently, the PSM defines a graph-based workflow metamodel. Its main ingredients are workflow process and package elements defined in respective sub-models. Workflow processes refine and extend digraphs as regards concepts of general working processes including participants, applications, data and structured activities. Workflow packages offer a further structuring principle that allows to define multiple workflow processes with a shared scope of common elements.
13
eServices
pattern
context
coordination
composition
workflow
capability
eService Interaction Context
eService Capa bility Conversa tion Regulation
SW Service Conversation Pattern
Converation Pattern
Conversation Regulation
shell
eService Shell
graph
process
SW Service Interaction Pattern
eService Capa bility Interac tion Regulation
Orchestrated Multi-Party Conversation
SW Service Orchestration Process
Conversation Protocol
SW Service Composition Protocol
Conversation Implement
SW Service Composition Schema
Workflow Process
Digraph
* package
Workflow Package
*
1..* Orches tration Variant
Sub-Pattern 1..*
SW Service Orches tration Idiom
ws composition bpel BPEL Process
Figure 5: Overview of the PARIS E-Service Metamodel (PSM)
On the next level of abstraction, the PSM refines and extends general workflow elements as software service interaction processes. These either serve as coordination protocols to regulate software service interactions or as composition schemas for automated enforcement of these regulations. Composition schemas are defined in the composition metamodel for software services. It refines and extends workflow processes as software (SW) service orchestration processes. They are structured within software service composition schema containers that refine workflow packages. Coordination protocols are defined in the coordination metamodel as generalised perspective on service interaction processes (like e. g. in BPEL). Here, software service orchestration processes are refined as orchestrated multi-party conversations that focus on fewer elements of service interaction processes with respect to coordinative regulation. Conversations are aggregated into software service composition protocols, which represent observable choreography in the course of software service compositions. Beyond composition schemas and coordination protocols, the PSM defines an additional abstraction of interaction process patterns to capture multiple variants of software service interaction that are equivalent in terms of their functional effect but different in terms of their non-functional properties. Interaction patterns are defined in the pattern metamodel for software service interaction. It refines and extends orchestrated multiparty conversations as software service conversation patterns. Such a conversation pattern allows a flexible non-deterministic description of an orchestrated conversation that is part of an interaction pattern. Software service interaction patterns refine composition protocols as non-deterministic choreography protocols. They aggregate a set of interaction sub-patterns whose conversation patterns together comprise a typical interaction situation with multiple implementations. Each sub-pattern can be root of an individual interaction pattern as well. Interaction patterns also contain a set of software service orchestration idioms that each represent one possible transformation of non-deterministic software service conversation patterns into deterministic orchestrated multi-party conversations and software service orchestration processes.
14
On the topmost abstraction level, the PSM eService metamodel defines concepts of virtual business service processes and relates them to software service interaction processes. It defines a SOA that realises assets, demands and capabilities. In particular, the metamodel refines software service conversation patterns as eService capability conversation regulations that capture provision logic of local or global virtual business service capabilities in a flexible non-deterministic way. eService capability conversation patterns are part of eService capability interaction regulations that are refined software service interaction patterns. eService capability interaction regulations specify interaction patterns that involve multiple capability conversations of sub-patterns and define alternative coordination protocols and orchestration schemas with varying non-functional properties. PARIS brokers/providers in charge of a capability are responsible for its interaction regulation and all related conversation regulations of sub-patterns. Multiple capability interaction regulations are composed into an eService shell that represents a holistic virtual business service process. It also contains the eService roles (brokers, providers, clients) and the endpoints of involved assets and demands including message data formats that are defined within a common eService interaction context. From a top-down perspective, PSM concepts define how the design of a virtual business service process is to be structured, how its structural parts are to be specified by means of software service interactions and protocols and how these specifications are to be implemented by software service interfaces and composition schemas. The successive layers correspond to platform independent and specific parts of a modelling hierarchy that can be extended and mapped to various concrete software service technology platforms. One such refinement that we have been experimenting with was defined from general software service composition to Web Service composition. Here, the ws composition metamodel defines extended concepts of Web Service architecture like WSDL-based interface descriptions and correlated orchestrations. From this model, we defined a mapping onto BPEL software service composition descriptions that can be deployed and executed within BPEL-compliant software service composition middleware platforms. However, these parts are beyond the general PSM and will not be detailed further. The PSM modelling hierarchy encourages a stepwise development of e-services by means of structured semi-formal design, verification and transformation methods. Such methods are at the heart of our e-service management approach as they open up potentials for meeting the requirements of agility and flexibility in virtual business service transactions. As a basis for such methods, the sub-models and classes of the PSM define elements of a graph-based process specification language for virtual business service processes and software service interaction processes. In the following we describe the main concepts1 of these PSM metamodels as regards workflow, software service interaction and e-services. 3.2.1 Working Processes The purpose of the workflow metamodel is to formally capture concepts of working processes with respect to coordination. Among others, the metamodel defines working 1
The full UML model is available online: http://www.cs.ucl.ac.uk/staff/c.zirpins/paris/.
15
Workflow Activity
Node *
* Workflow Process
Digraph Tail
From To
Head Transition Information
Arc
*
*
Figure 6: Process Graph Metamodel
processes as regards their participants, activities they are performing and relationships between activities in terms of data and control flow [vdAvH02]. Workflow models complying to this definition represent coordinative regulations for participants in a working process as regards execution of activities and exchange of data. These models facilitate formal analysis of coordinative regulations as well as their automated enforcement by means of controlling activity execution and data exchange. Regulation and enforcement of coordination in working processes is a fundamental concept of the PSM. It serves as a basis to refine similar concepts for software service interaction processes and business service administration processes. For the sake of intuitiveness, we are adopting a graph based workflow metamodel. Therefore, we initially define a fundamental level of graph concepts. The PSM graph metamodel defines some well known concepts of graph theory [Die06] including digraphs as aggregations of nodes and directed arcs. The graph concepts are then refined into a fundamental process model as shown in fig. 6. In particular, we are defining workflow processes as digraphs with activity nodes and transition arcs.
> Workflow Process Data (from workflow :: context )
> Workflow Data
>
>
*
>
* >
*
*
*
> Allocation Decission Data Participant (from workflow :: context )
>
>
>
> Activity Set
> *
>
> Block Activity
> Workflow Participant
>
>
>
Application (from workflow :: context )
* > Workflow Application
* * > Workflow Activity
> Sub Process Definition
> > Transition Information
Figure 7: Workflow Process Metamodel
>
> Atomic Activity
>
Constraint Evaluation Data
16
*
* *
>
Based on process graphs, the workflow metamodel defines a variety of concepts that conform to the reference model of the Workflow Management Coalition [Hol95]. The WfMC reference model represents a basic set of commonly understood and accepted concepts, whose adoption fosters comprehensibility and applicability of the PSM. Accordingly, the PSM workflow metamodel is structured into context, process and package sub-models. The workflow context metamodel includes general concepts of participants and the applications they may use to accomplish tasks. It also defines the notion of data that is used to allocate participants and as input and output of applications. The workflow process metamodel that is shown in fig. 7, uses concepts of the workflow context and process graph metamodels and extends them towards formalised working processes. Beyond activities and transitions workflow processes are extended by workflow participants, applications and data representing performers, methods and information of working processes. Furthermore, the model defines various refined activity concepts to structure workflow activities into blocks, sets and sub-processes. Finally, the workflow package metamodel defines scoping and structuring concepts for multiple workflow processes. Herein, The concept of workflow package defines a scope, in which common participants, applications and data elements can be specified and reused by multiple workflow processes. Multiple such packages may be structured as hierarchical scopes. 3.2.2 Software Service Interaction The purpose of the PSM software service interaction metamodels is to formally define those service oriented concepts that the PARIS SOM informally stipulates for virtualisation of business service processes. Here, communication endpoints of assets and demands are mapped to interactions defined by operations of atomic software service components. Interaction processes of capabilities are mapped to software service interaction processes of composite software services by means of interaction patterns, coordination protocols and composition schemas. In the PSM, we define a process-centric service-oriented software architecture that refines general concepts of working processes to model interaction processes between software services. Generally, such software service interaction processes define causal and data dependencies between interaction activities that software service clients and providers perform by means of software service components. As with workflow, these processes are utilised for the purpose of regulation and enforcement of coordination between software service clients and providers within the architecture. The PSM adopts the orchestration model [FP06] of coordinating software service interactions. Thus, it defines a multi-lateral software service interaction process between a central orchestrator and a set of participants in different roles. Interactions are generally taking place between the aggregator and one of the other participants in either direction. Coordination of the multi-lateral software service interaction process is regulated by a software service coordination protocol. The aggregator enforces coordination of multiple interactions between participants by execution of a software service composition schema that implements the service coordination protocol.
17
Beyond rigid specification of individual orchestrations, the PSM introduces a software service interaction pattern model that defines non-deterministic process patterns for flexible orchestration protocols and puts them into the context of a global choreography that consists of multiple interrelated orchestrations. Software service interaction pattern, coordination protocol and composition schema are defined as different perspectives on the same kind of software service interaction process derived from general working processes. The PSM first derives the software service composition metamodel from the workflow metamodel, including enough detail for execution. It subsequently derives the more general perspective of the software service coordination metamodel. Finally it defines the broader view and non-deterministic elements of the software service interaction pattern metamodel. In the following, we describe the models in this sequence. Software Service Composition The PSM software service composition metamodel defines various concepts that allow enforcing coordination of software service interaction processes by means of following software service orchestration schemas. The model refines general concepts of workflow with respect to specific concepts of software service orchestration. Fig. 8 shows the PSM software service composition metamodel as UML diagram. It displays workflow concepts on the right and derived concepts of software service composition on the left. In terms of general structure, the model defines two principal classes of refined workflow packages. The software service interaction context package defines a repository of software service component operations and message types as well as provider- and organisation roles that might be used within multiple software service interaction processes. Associated with an interaction context, the software service composition package defines a container for specific composition schemas. Whereas the interaction context contains no process definitions, the service composition contains exactly one software service orchestration process that is a refinement of the general workflow process concept. Based on this general structure, the composition model addresses the conceptual aspects of software service entities, their schematic coordination within composition as well as the aggregation of instances. Software service entities might be software service components that provide building blocks for compositions or composite software services that result from compositions. In general, the PSM derives its software service concepts from service interactions that a software service provider receives in the course of a service interaction process. The set of service interactions determines the operations and message types of a software service system associated with the service provider. A software service system may be realised by different means (e.g. WSDL-based or REST-style), as long as all its parts are associated with a single provider. Generally, software service operations, message types and providers are refinements of workflow applications, data and participants. Software service message type declarations are defined as global concepts in the software service interaction context. Software service operations and providers are defined for atomic and composite software service systems individually.
18
> Component SW Service Binding
SW Service Organisation > Organisation Correlation Map
-ParticipantType:String=ORGANIZATIONAL_UNIT
1..*
1..* >
-Name:String=paris.orgCMap -Value:String SW Service Provider > Provider Correlation Map
-ParticipantType:String=SYSTEM
1..*
1..*
> Workflow Participant (from workflow :: package )
SW Service Component Operation
0..1
1..*
> Workflow Application (from workflow :: package )
>
> Correlation Set
1..*
1..* >
*
>
SW Service Message Type Declaration
-Name:String=paris.cSet -Value:String
*
>
>
-Name:String=paris.proCMap -Value:String
> Workflow Data Types (from workflow :: package )
1..*
> *
0..1
SW Service Interaction Context
>
>
> Workflow Package (from workflow :: package )
>
SW Service Composition Schema
*
>
Conversation Implement
* >
SW Service Orchestration Process
1..*
SW Service Component Interaction
SW Service Composition Interaction
> Workflow Process (from workflow :: process )
>
SW Service Interaction
> Atomic Activity (from workflow :: process )
-Implementation-Type:String=Tool -Type:String=Implementation >
*
> Service Parameter
Orchestration Data
> Workflow Data (from workflow :: process )
* >
>
* >
> Composite SW Service Binding
SW Service Composition Operation > Aggregator Correlation Map -Name:String=paris.aggCMap -Value:String
*
> Workflow Participant (from workflow :: process )
* >
>
1..*
SW Service Aggregator -ParticipantType:String=SYSTEM
Figure 8: Software Service Composition Metamodel
19
The software service interaction context defines several systems of component software services. Each such system comprises a set of component operations, references to global message type declarations as well as a provider and an organisation role. Software service operations associated with a provider role constitute exactly one component software service system (or component software service for short) to be provided as a coherent whole. Organisation roles define aggregations of providers and their component software services within organisational units that are responsible for their realisation. Each software service orchestration process defines exactly one composite software service system. Such a system comprises a set of composition operations, references to global message type declarations and an aggregator role. Software service operations bound to an aggregator role constitute exactly one composite software service system (or composite software service for short) that is realised by the software service orchestration process. Generally, composite software services represent an internal perspective of defining orchestration processes. Their utilisation (e.g. as part of another software service composition) requires a complementary representation as component software service. We divide the coordination aspect of the software service composition metamodel into aspects of orchestration and data modelling. Both aspects are closely associated with the underlying workflow concepts. In the case of workflow, a central coordinator evaluates a graph-based process model of associated activities on the basis of data variables and controls participants to perform these activities by means of applications (or tools) and on the basis of actual data parameters. In the software service composition model, all process activities are refined as software service interactions that represent the reception of messages by participants of the orchestration process and define bindings to respective operations and messages of their software services. Like in workflow processes, software service orchestration processes model the activities of participating software service providers as software service component interactions and thereby represent the interaction of messages from a central software service aggregator to software service operations of these providers that are determined by component software service bindings. Unlike in workflow processes, software service orchestration processes also include the central aggregator role as a first class entity and model activities of this aggregator role as software service composition interactions that represent the interaction of messages from participating software service providers to software service operations of the aggregator determined by composite software service bindings. Together, the two types of interactions allow modelling an orchestration-type software service interaction process as a multi-lateral and bidirectional conversation between the software service aggregator and a set of software service providers. The software service orchestration process specifies how the aggregator controls the software service interaction process by carrying out interactions that either include sending or receiving messages from participating providers. The control flow of orchestration processes might be based on the same data variables as in workflow processes. However, actual parameters of interactions need to be based on specific orchestration data variables that conform to global software service message type declarations defined in the interaction context.
20
The final aspect of the software service composition metamodel is about aggregation of software service instances. On the one hand side, aggregation concerns the assignment of software service provider, aggregator and organisation roles to software service implementations of organisational units that are to allocate instances of component and composite software services. On the other side, aggregation concerns the management of these instances within and between software service compositions. As regards role assignment, software service roles are assigned to software service implementations that realise all associated software service operations by means of any technology and allocate single unique software service instances. Implementation might build on internal software service composition in which case the software service implementations play aggregator roles in theses contexts. Software service organisation roles are assigned to organisational units that are to host all associated software service implementations. The management of software service instances is based on correlation. Roles might be associated with sets of message type declarations (correlation sets) that indicate individual role assignments. Interactions with software services (either component or composite) that are associated with a correlated role, need to map actual message parameters to correlation sets as defined in correlation maps. For service component interactions, each combination of correlated provider roles and sets of data values mapping their correlation sets is assigned to a software service implementation that is to allocate an individual software service instance. Organisation roles that might be correlated as well, indicate, if provider roles might be associated to the same software service implementation hosted by a single organisational unit. For service composition interactions, combinations of aggregator roles and sets of data values mapping their correlation sets indicate individual instances of software service orchestration processes. Beyond these concepts, we found aggregation aspects to be rather specific with respect to a) application functionality and b) technology platform of software service composition. Thus, we decided not to make any further assumptions and keep the composition metamodel general. Instead we offer enough flexibility to extend the model in an application- and technology-specific way. To proof feasibility, we created an extended software service composition metamodel for Web Services that includes meta data for dynamic binding of component Web Service instances as well as correlation of composite Web Service instances but found this to be to specific for the general software service composition metamodel.2 Software Service Coordination The PSM software service coordination metamodel defines concepts for regulating coordination of software service interaction processes by means of declaring software service orchestration protocols. Such protocols are meant to regulate coordination as regards orchestrated software service interaction processes. Therefore, the coordination metamodel is based on concepts of orchestration schemas that are defined in the PSM software service composition metamodel and refines them with respect to the general perspective of orchestration protocols. 2
The extended Web Service Composition Metamodel is part of the PSM UML model that is available at the PARIS website http://www.cs.ucl.ac.uk/staff/c.zirpins/paris.
21
SW Service Orchestration Process (from composition )
SW Service Composition Schema (from composition )
Conversation Implement > Aggregator Correlation Map
> Composite SW Service Binding (from composition )
> Provider Correlation Map
SW Service Composition Interaction (from composition )
>
> Component SW Service Binding (from composition )
SW Service Component Interaction (from composition )
> Organisation Correlation Map
SW Service Organisation (from composition )
*
Orchestrated Multi-Party Conversation
SW Service Aggregator (from composition )
SW Service Composition Operation (from composition )
SW Service Provider (from composition )
SW Service Component Operation (from composition )
Conversation Orchestrator
Conversation Orchestrator Receptor
Conversation Party
Conversation Party Listener
> Partner Correlation Map
Party Statement
> Conversation Protocol
Conversation Organisation
-Name:String=paris.parCMap -Value:String
Conversation Orchestrator Connection
SW Service Composition Protocol
Orchestrator Directive
Conversation Party Connection
Figure 9: Software Service Coordination Metamodel
The PSM software service coordination metamodel is shown as a diagram in fig. 9. It shows concepts of software service orchestration schemas on the top and derived concepts of software service orchestration protocols on the bottom. In the context of the coordination metamodel, software service composition is refined as a software service composition protocol. In this protocol perspective, software service orchestration processes are represented by orchestrated multi-party conversations. Here, the focus is not on provision of software services but on software service interactions between providers. Thus, software service aggregators and providers are refined as conversation orchestrators and conversation parties providing receptors and listeners for interactions from partners. Interactions can either be directives from the orchestrator to parties or statements form parties to the orchestrator. Conversation connections define receptor/listener and orchestrator/party of each interaction, leading to self contained interaction vocabularies for each role. Multiple conversation parties might belong to conversation organisations defined by conversation party connections of their interaction vocabulary. For regulation, it is important not only to model the receivers of message interactions – as is sufficient for orchestration schemas in order to execute them – but also the partners who send them. Because a conversation includes just one orchestrator, both partners of orchestrator directives are known. As this is not the case for party statements, we extend those with a Partner Correlation Map for the party that initiates the conversation step. As a result, a composition protocol not only regulates the multi-lateral conversation of its aggregator but also implicitly regulates the bilateral conversations of its parties.
22
Software Service Interaction Patterns While software service interaction processes as they are defined by the software service composition and coordination models conform to the common characteristics of respective SOC technologies, they have limitations in terms of scope and flexibility. While some degree of flexibility is possible by means of control flow structures inherited from workflow, there are no means to distinguish between and optimise for complex process variations in terms of their properties. Furthermore, conversation protocols and orchestration schemas limit the scope of coordination to the multi-lateral interaction process between one aggregator and a set of providers but can not easily express relationships between multiple such processes. The purpose of the PSM software service interaction pattern metamodel that is shown as a diagram in fig. 10, is to introduce abstractions that allow to compensate the above mentioned limitations to some extend by means of pattern concepts. Patterns are commonly used to represent knowledge as to solve general recurring problems in software design and implementation. We define patterns for the case of knowledge about how to design and (automatically) implement software service interaction processes for specific software service client requests. In particular, the PSM pattern metamodel defines software service conversation patterns and software service interaction patterns as two kinds of design patterns for software service interaction processes. Conversation patterns represent functional characteristics of a specific class of software service orchestration as well as possible solutions to achieve them with varying non-functional properties. They extend orchestrated multi-party conversations by means to specify multiple process variations. For each individual client request, exactly one such variation is selected and used to generate a specific conversation protocol and orchestration schema. The implementation of a conversation pattern with respect to a specific process variation is referred to as an idiom and denominated by an idiom identifier. To specify process variations, certain elements of the conversation process are extended with idiom identifiers that associate them with idioms. In particular we consider variants with respect to orchestrated multi-party conversation process coordination and aggregation. For coordination variants, workflow transitions are refined as transition variants. Transition variants indicate branches of process flow that are specific to individual process variations. Furthermore, party statements and orchestrator directives are refined as pattern statements and directives. These may contain multiple variants of connections with alternative aggregator-, provider- and organisation roles. Such alternatives are defined by means of connection variants that extend conversation connections by adding an idiom identifier. This allows for process variants with individual role assignments and instance management. Interaction patterns extend software service composition protocols with structural means to specify a context of interrelated conversation patterns. Conversation pattern contexts represent recurring interaction situations with multiple solutions for implementation. In particular, they define pattern knowledge of which solution to select for specific client requests. Fig. 11 indicates the structure of software service interaction patterns. Each interaction pattern contains a top-level conversation pattern and aggregates a set of sub-patterns. The aggregated conversation patterns define a non-deterministic choreography of interrelated conversation protocol variants, whose logic spans multiple
23
Party Connection Variant
Conversation Party Connection (from coordination )
Orchestrator Connection Variant
Conversation Orchestrator Connection (from coordination )
Transition Variant
> Transition Information (from process )
Pattern Statement
Party Statement (from coordination )
Pattern Directive
Orchestrator Directive (from coordination )
SW Service Conversation Pattern
Orchestrated Multi-Party Conversation (from coordination )
1..* > Idiom Identifier -Name:String=paris.idiomId -Value:QName 1..*
generated from Converation Pattern
transforms
> QoS Parameter Set
Conversation Protocol
generated by
> Transformation Ruleset
-Name:String=paris.qosPSet -Value:anyURI
> Idiom Identifier
-Name:String=paris.tRuleset -Value:anyURI
-Name:String=paris.idiomId -Value:QName
match > Orchestration Policy Ruleset
> SW Service Orches tration Idiom
select
-Name:String=paris.pRuleset -Value:anyURI
-ParticipantType:String=SYSTEM
1..*
> SW Service Inter action Sub-Pattern
> Orches tration Variant
SW Service Interaction Pattern
SW Service Composition Protocol (from coordination )
-Name:String=paris.subIP -Value:QName 1..* SW Service Interaction Context (from composition )
Figure 10: Software Service Interaction Pattern Metamodel orchestrations. Global process variants are indicated by interrelated variants of conversation process coordination and aggregation, namely transition and connection variants, that refer to the same idiom identifiers. Additionally, aggregated conversation patterns share a single software service interaction context to define common conversation parties and listeners. A more versatile specification of variations can be reached by combining multiple interaction patterns. Each sub-pattern can be root of an individual interaction pattern that possibly overlaps with others (e.g. interaction pattern 2 in fig. 11). In order to ensure sound regulation of software service interaction processes, we define a hierarchical
24
Paris-E-Service-Meta-Model Mini-Max-A-V2.0
Interaction Pattern1
Conversation Pattern 1a
Interaction Pattern 5
Conversation Pattern 2b
Interaction Pattern 2
Conversation Pattern 1b+2a
Interaction Pattern 6
Conversation Pattern 2c
Interaction Pattern 3
Conversation Pattern 1c
Interaction Pattern 7
Conversation Pattern 2d
Interaction Pattern 4
Conversation Pattern 1d
Figure 11: Software Service Interaction Pattern Structure
responsibility between aggregators of overlapping interaction patterns that puts the topmost aggregator in charge over any aggregators of sub-patterns. In terms of representing pattern knowledge, interaction patterns define sets of software service orchestration idioms and an orchestration policy rule set. Orchestration idioms refine system type workflow participants that implement related process variants of the aggregated conversation patterns. Specific implementations are specified by transformation rules for software service interaction processes, referenced by a transformation rule set attribute. Transformation is generally based on the identification of process parts that are specific to individual process variants. In its simplest form, transformation-based implementation concerns deletion of transition and connection variants. After identifying the optimum idiom for a given client request, all transitions and connections that are associated with other idioms are deleted. Only those parts of a conversation pattern that are generic or specific to the identified idiom remain in the process implementation. Transformation could however comprise much more complex means of implementing deterministic conversation protocols and orchestration schemas. Specific transformation models are therefore not part of the PSM but need to be defined for individual technology platforms and applications. In earlier work, we have developed a rule-based workflow transformation technique [ZP04] that well fits the purpose. Other possibilities include graph transformation techniques [BH02]. The knowledge of which orchestration idiom to chose in order to satisfy non-functional requirements of specific client requests is represented by orchestration policy rule sets that are referenced from extended attributes of software service interaction patterns. Orchestration policy rules relate process variants and the orchestration idioms implementing them with specific non-functional properties. When a client request arrives, orchestration policies of interaction patterns are evaluated with respect to the required non-functional properties. The result is an indication of which orchestration idioms and process variants may be selected for the individual case. As with the transformation model, the policy model is likewise specific to application area and technology platform that the metamodel is used with. Therefore, the PSM does not restrict it any further.
25
3.2.3 Virtual Business Services Based on abstractions of the software service interaction metamodels, the topmost level of the PSM defines concepts of a process-driven service-oriented architecture for VBSPs in the e-service metamodel. The metamodel that is shown in fig. 12 as an overview diagram, is generally structured similar to the PARIS conceptual business service process model (see fig. 1). It defines eServices as representations of virtualised business service processes that are structured with respect to general aspects of business service content, -consumption and -provision and contain respective representations of eService Core Assets, eService Client Demands and eService Capabilities. These parts are further defined by means of software service abstractions following PARIS SOM strategy. In the provision-centric perspective of the PSM, assets and demands are modelled as abstract representations of internal business processes that are carried out by providers and clients autonomously. Their coordination is based on communication endpoints that connect internal business processes with external business service interaction processes. In the PSM, endpoints are modelled by the eService context metamodel based on the interactions they carry out. Interactions of endpoints are defined by refinements of party connection variants. They consist of refined conversation organisations, parties,
eService
content
> eService Core Asset
eService Asset Provider Connection (from eServices :: context )
*
eService Role (from eServices :: context )
common roles in scope
1..* >
*
> eService Client Demand
eService Client Demand Connection (from eServices :: context )
consump tion
eService Inter action Contact (from eServices :: context )
common endpoints in scope
* >
eService Capability (from eServices :: shell )
eService Capa bility Provider Connection (from eServices :: context )
1..* provision
eService Data Format (from eServices :: context ) * >
eService Shell (from eServices :: shell )
eService Interaction Context (from eServices :: context )
1..*
eService Capa bility Interac tion Regulation (from eServices :: capability )
SW Service Interaction Pattern (from pattern )
Conversation Regulation
Converation Pattern
Figure 12: E-Service Metamodel
26
eService Capa bility Conversa tion Regulation (from eServices :: capability )
SW Service Conversation Pattern (from pattern )
common messages in scope
listeners and orchestration data complying to software service message type definitions. Respectively, eService Asset Provider Connections and eService Client Demand Connections consist of an eService Role (further refined as eService Client or Provider) as well as an eService Interaction Contact (further refined as eService Asset Contact or Demand Contact) and orchestration data complying to eService Data Formats. eService Asset/Demand Contacts and eService Data Formats associated to the same eService Client/Provider define communication endpoints of assets/demands and their realisations as asset/demand component software services. Participants of a virtual business service production network are represented as eService organisations that refine conversation organisations and might be assigned a number of roles in the virtual business service process. All these parts are specified in an eService Interaction Context that refines the software service interaction context. It provides a repository of virtual communication endpoints that is in the scope of all eService specifications. Capabilities are contained within an eService as parts of its eService Shell. The shell is defined in the eService shell metamodel as specifying the interaction context and capabilities of an eService. Capabilities represent virtualised interaction process structure of an administrative procedure to provide assets of service content for consumption by client demands. The PARIS SOM suggests to realise capabilities as software service interaction processes. In particular, the model requires means to specify and execute functional interaction process structure as patterns that allow to anticipate and quickly adopt multiple variants of coordination. Respectively, the PSM defines eService Capability Conversation Regulations that are refined from software service conversation patterns, as major ingredient of an eService capability. In terms of structure, conversation regulations are packaged in eService Capability Interaction Regulations that are part of the shell. The shell keeps a registry of capabilities and their associated interaction regulations. Capability conversation regulations are defined in the eService capability metamodel. Extending software service interaction processes, the model defines various specific concepts to specify the interaction process structure of a capability as orchestrated conversation of one eService Interaction Coordinator and the different types of eService roles that are defined in the eService interaction context. Conversations may consist of 6 types of interactions. The first 3 types of interaction are refined pattern directives that involve communication from a capability towards an asset, demand or another capability. The interaction (in terms of reception) is carried out by a provider, client or provider of another capability and its conversation partner is always the eService interaction coordinator. An eService Client Feedback defines one or more variants of demand connections with clients that receive eService data via their demand contacts. An eService Resource Directive defines one or more variants of asset connections with providers that receive eService data via their asset contacts. Interaction between capabilities (e.g. between global capabilities or from a global to a local capability) makes it necessary that capabilities are complementarily represented as endpoints in the eService interaction context. We model capability endpoints based on eService Capability Provider Connections that involve eService Capability Providers who accept specific eService data via sets of eService Capability Contacts. The aggregated
27
contacts and data of a capability provider define an endpoint and its realisation as capability component software service. Based on these representations, an eService InterCapability Handover defines one or more variants of capability provider connections with capability providers that receive eService data via their capability contacts. The remaining 3 types of interaction are refined pattern statements that involve reverse communication towards a capability from an asset, demand or another capability. In these cases, interactions are always carried out by eService interaction coordinators and their conversation partners are either asset providers, clients or capability providers. Coordinators receive messages via eService Interaction Receptors that refine conversation orchestrator receptors. We model the endpoints of capability conversation regulations based on eService Interaction Coordinator Connections that involve correlation maps of coordinators who accept specific eService data via sets of receptors. The aggregated receptors and data of a coordinator define an endpoint and its realisation as capability composite software service. Based on these representations, eService Client Statements, eService Provider Statements and eService Inter-Capability Takeovers define one or more variants of coordinator connections with eService clients, eService providers and eServices capability providers that send eService data to receptors of the coordinator. The holistic virtual business service process is based on interaction patterns that specify multiple variants of coupling individual capabilities into a whole. Beyond serving as containers for capability conversation regulations, capability interaction regulations define entry points and sub-patterns of a set of flexibly coupled capabilities. Generally, coupling of capabilities is based on inter-capability interactions that are specified within capability conversation patterns. We distinguish two types of capability couplings that are derived from eService inter-capability handovers and takeovers. The first type is a synchronous form of control passing referred to as sub-capability call. In this case, a first capability interacts with a second one via an eService SubCapability Outgoing Request (derived from inter-capability handover) that is received by the second capability as eService Sub-Capability Incoming Request (derived from inter-capability takeover). The first capability then blocks its control flow while the second one is active. Eventually, the second capability interacts with the first one via an eService Sub-Capability Outgoing Response (derived from inter-capability handover) that is received by the first capability as eService Sub-Capability Incoming Response (derived from inter-capability takeover). At this point, the second capability stops its activities and the first one resumes its control flow. The second type of coupling is an asynchronous form of control split referred to as capability flow passing. Here, a first capability interacts with a second one via an eService Capability Flow Handover (derived from inter-capability handover) that is received by the second capability as eService Capability Flow Takeover (derived from inter-capability takeover). After the interaction both capabilities carry on with their control flows and might or might not interact again at a later point. Both types of coupling have their individual advantages and disadvantages and might be selected for designing virtual business service processes in different situations. Subcapability calls lead to a global control flow that is easy to understand but limited
28
sub-cap. call
Global Capability Conversation Regulation ccr1 (cir1)
Capability Interaction Regulation (cir)
cap. flow passing orchestration idiom (oi) transition
oi1.2 oi1.1 oi1.2 oi1.1
oi1.2
Global Capability Conversation Regulation ccr4 (cir2)
oi2.1
Local Capability Conversation Regulation ccr3
Asset/ Demand SW Service a/dcs1
Local Capability Conversation Regulation ccr5
oi1.1 : org1
Asset/ Demand SW Service a/dcs2
2 org
oi1 .2 :
Global Capability Conversation Regulation ccr2
: .2 oi1
org 1
orchestration idiom coordinator role
Asset/ Demand SW Service a/dcs3
Asset/ Demand SW Service a/dcs4
Figure 13: E-Service Capability Interaction Pattern Structure in its expressiveness. Capability flow passing allows for flows of global control that are much more sophisticated including parallelisation, loops etc. but might lead to unwanted behaviour that is difficult to predict. In terms of interaction pattern design, there is an additional characteristic of coupling types that might be exploited. Whereas sub-capability calls lead to centralised forms of coordination, capability flow passing allows for decentralised coordination which both go along with different non-functional characteristics. Consequently, different forms of capability coupling can be used to specify variants in capability interaction regulations. Fig. 13 shows a typical structure of eService interaction regulations as pseudo model. Interaction regulation cir1 contains the conversation regulation of a global capability ccr1 and aggregates other global and local capabilities with conversation regulations ccr2...ccr5 that are designed to support two variants of centralised and decentralised coordination. Implementation of variants is specified by 2 orchestration idioms oi1.1 and oi1.2. The first idiom relates to subsequent sub-capability calls from ccr1 to ccr2 and from ccr1 to ccr4 that put capability 1 in the centre of coordination. The second idiom relates to subsequent capability flow passing from ccr1 to ccr2, then from ccr2 to ccr4 and finally from ccr4 back to ccr1 that shift coordination control between capabilities. Together with flow variants, the idioms specify two variants of aggregating capabilities into organisational units. The first idiom oi1.1 defines connections with a single organisation role org1 that is to provide capabilities ccr2 to ccr5. The second idiom oi1.2 defines alternative connections with two organisation roles org1 and org2 that are to provide capabilities ccr2, ccr3 and ccr4, ccr5 respectively. Thus, this exemplary design makes sure that in the decentralised case there are really distinct service providers without whom decentralisation would be useless. Likewise in the centralised case, the
29
fact that there are effectively at most two service providers involved compensates for the disadvantages of synchronous sub-capability calls. Also indicated in the illustration is the possibility to nest multiple capability interaction regulations. Here, another interaction regulation cir2 with an orchestration idiom oi2 is adumbrated. As such regulations might or might not overlap in terms of interaction logic, it is crucial to obey a strict hierarchy of responsibilities between brokers and providers that maintain them. This hierarchy of responsibilities generally corresponds to the hierarchy of capabilities.
3.3 PSM-based Modelling of E-Services In the VBSPN conceptual model, formal specification of VBSPs provides the central tool for coordinative regulation of virtual business service production. VBSP specification supports brokers, providers and clients to develop, sight and adjust assets and capabilities. For such activities of capturing complex characteristics within the context of an organisational network, graphical modelling has several advantages over textual specification, as it fosters communication, abstraction and analysis of these characteristics [BLTvdW01]. Consequently, we adopt graphical modelling as a means for VBSP specification. Graphical specification of virtual business service processes requires a modelling language. Such a language needs to provide syntax and semantics that can express particularities of business service processes from the perspective of the e-service metamodel. Desirable properties of such a language include appropriateness of its expressive power and ease of use. In particular, the language should be intuitive, graphical, compositional and sufficiently formalised as well as allow for multiple level of abstraction and different viewpoints. Furthermore, it should allow for generality, economy, orthogonality, consistency and coherence as regards its application. In PARIS, we use an extended version of UML as specification language and propose a respective PARIS UML profile. We extend the generic language constructs of UML by means of specific concepts defined by the PSM. The result is a set of UML elements with PSM-specific semantics for designing models of e-services, SW service interaction patterns, coordination protocols, orchestration processes and workflows. It has been argued that UML is a sub-optimal choice for the general task of modelling networked enterprises [SLvdW02]. While we do not object in the general case, we argue that customised UML is however a good compromise for the specific case of e-service specification. The UML standard offers widely accepted means to model software intensive systems like the class of cooperative information systems defined by e-services. UML is appropriate in this case, because it provides generic language elements that generally address the main structural and behavioural aspects of virtual business services and allows customisation to express the concepts of our e-service metamodel. Ease of using a modelling language is particularly important for VBSPN, where multiple organisational partners need to agree on and adopt it. As to this, widespread familiarity, existing tool support and often already accomplished adoption add to the feasibility of UML. In the folowing, we will briefly outline the conceptual and technical background of UML-based model specification in PARIS.
30
3.3.1 PARIS UML Profile UML is a standardised graphical language for object-oriented modelling of software intensive systems [OMG03].3 As such, it offers a rich set of generic language constructs to represent structural and behavioural system aspects from various perspectives and on various levels of abstraction. UML adoption for domain specific modelling is supported by various means of extending and refining the language. The most common way of extension is by declaration of UML profiles [OMG03, S. 2-73] that are defined as part of the language itself. Profiles build on the three concepts of stereotypes, tagged values and constraints. Stereotypes allow for decorating UML elements in order to represent specific semantics. Tagged values provide means for annotating decorated elements with name value pairs. Constraints are expressions in object constraint language (OCL) that might be used to define requirements for using stereotypes in a model. UML profiles aggregate various stereotypes, tagged values and constraints that together define specific semantics of models within a particular domain. In PARIS, we use an UML profile to extend UML for the graphical specification of e-services. The PARIS UML profile mainly introduces the comcepts of the e-service metamodel by means of UML stereotypes. Corresponding to the PSM abstraction levels, the profile is structured into 5 hierarchical sub-profiles with stereotypes for models that describe e-services, software service interaction patterns, protocols and orchestrations as well as workflow processes. The fundamental level is given by a sub-profile for modelling WfMC compliant workflow processes. This workflow-profile is generally based on the PSM workflow metamodel. Beyond that, it includes stereotypes to represent further workflow concepts on a more detailed level that allow to specify executable workflow schemas. These concepts are derived from the WfMC-standardised schema of the XML-based process definition language XPDL [WfM02]. Tables 1 and 2 show an overview of the profile. Here, we list all stereotypes and their hierarchical relationships starting left from e-service stereotypes on the highest level of abstraction and going right towards workflow stereotypes on the lowest level of abstraction. On the right hand side, the tables show the UML base elements and additional tagged values. An initial goal of the PARIS UML profile is to make the complexity of XPDL-based workflow models manageable for interactive specification. Therefore, it maps numerous model structuring concepts to UML packages and captures their attributes by means of tagged values. Major concepts of the PSM are often represented by pairs of UML packages and corresponding classes to capture more complex contents. Furthermore, the profile defines constraints to restrict value domains and cardinality. The resulting hierarchy of packages structures the numerous elements of complex models into homogeneous partitions. This structure is less suitable for virtualisation by means of diagrams. It is however well suited for representation in tables or trees that are often used in UML modelling tools. Thereby, the profile fades out secondary aspects of model organisation and focuses on key aspects of specification. Predominantly, this is the case for process structure. In particular, the profile includes UML activity diagrams for process-based concepts that visualise activities and transitions of their process graphs. 3
PARIS adopts UML version 1.5.
31
eService Capability Sub Process eService Interaction Context eService Capability Interaction Regulation eService Initial Capability Interaction
Æ Conversation Party
Service Coordination Model Stereotypes Conversation Orchestrator SW Service Provider
Service Composition Model Stereotypes SW Service Aggregator
Service Pattern Model Stereotypes
Æ
—
Tagged Values
Notes
—
UML Elements
Actor + Class, Attributes (Description, Name, ParticipantType)
—
WfMC-Modell Stereotypes
Participant
Class, Attributes (Name, Value)
—
Description, Type, Id Type = PROCEDURE, Id = reference to endpoint
Type = Route, Implementation-Type = none
May contain to endpoint specification
ParticipantType = ORGANIZATIONAL_UNIT Name = paris.cSet, Value = type declaration list
ParticipantType = SYSTEM
ExtendedAttribute
Package + Class, Attributes (Name, Description)
ExtendedAttribute
Package
Class, Attributes (Name, Value)
Package
Package + Transition, Class (Transition-Information), Attributes (Description, Name), Dependencies (From, To, Transition) Actor + Class, Attributes (Description, Name, Transition Participant
— — —
always points to element Points to element
Name, AccessLevel only Identifier = Capabilities, only elements
—
—
GraphConformace = LOOP_BLOCKED Name, GraphConformace = LOOP_BLOCKED GraphConformance Identifier = e-service name, GraphConformace = LOOP_BLOCKED Name = paris.idiomId, Value = Qname Name = paris.pRuleset, Value = anyURI — Name = paris.subIP, Value = Qname Name = paris.qosPSet, Value = anyURI Name = paris.tRuleset, Value = anyURI Contains From = , To = , Transition = UML transition element in process diagram ParticipantType = SYSTEM
Name = paris.parCMap, Value = parameter index Name = paris.aggCMap, Value = parameter index Class, Attributes (Name, Value) — Name = paris.proCMap, Value = parameter index Name = paris.orgCMap, Value = parameter index Package + Class (Activity-Information), Attributes (Name, Type = Implementation, Implementation-Type = SubFlow, Description, Limit, Performer, StartMode, FinishMode, Implementation-Type Activity: UML activity element in process diagram Priority, Icon, Documentation, Type), Activity, Dependency
Package
Application
SW Service Component Interaction
SW Service Component Operation
Æ
Conversation Organisation SW Service Organisation Æ Correlation Set Conversation Orchestrator Receptor SW Service Composition
Component SW Service Binding
ExtendedAttribute
Conversation Party Listener
Orchestration Directive
Organisation Correlation Map Provider Correlation Map Aggregator Correlation Map —
Activity
Æ Æ Æ
Pattern Directive
Æ
—
Æ
Æ Conversation Party Connection
SW Service Interaction Context
SW Service Composition Interaction
Party Connection Variant
SW Service Composition
Party Statement
Orchestrator Connection Variant
Conversation Orchestrator Connection Æ Æ Æ Partner Correlation Map
—
Pattern Statement
Æ Æ Æ Æ —
—
Type = Implementation, Implementation-Type = Tool, Implementation-Type Activity: UML activity element in process diagram
— Æ
Æ
Package + Class, Attributes (Name, Description, Limit, Performer, StartMode, FinishMode, Priority, Icon, Documentation, Type), Activity, Dependency (Activity)
eService Interaction Coordinator Connection
Æ
—
SW Service Composition Protocol
—
Activity
— — — —
SW Service Interaction Pattern
Æ
Idiom Identifier Orchestration Policy Ruleset SW Service Interaction Sub-Pattern — QoS Property Set Transformation Ruleset Transition Variant —
—
—
Tool
eService Shell
Æ
Orchestrated Multi-Party Conversation SW Service Orchestration Process
Composite SW Service Binding
Æ Æ Æ Æ Æ Æ SW Service Orchestration Idiom
E-Service-Model Stereotypes eService Interaction Coordinator eService Client eService Provider eService Capability Provider eService Organisation — eService Interaction Receptor eService Demand Contact eService Asset Contact eService Capability Contact eService Client Feedback eService Resource Directive eService Sub-Capability Outgoing Response eService Sub-Capability Outgoing Request eService Flow Handover eService Client Statement eService Provider Statement eService Sub-Capability Incoming Response eService Sub-Capability Incoming Request eService Flow Takeover Æ eService Asset Provider Connection eService Client Demand Connection eService Capability Provider Connection
Æ
SW Service Conversation Pattern
eService Capability Interaction Sub Process
Æ
Package + Class (Process-Diagram), Activity Diagram
TypeDeclaration
Package + Class (TypeDeclaration-Information, Attributes (Description, Name) Package + Class (DataField-Information), Attributes (Description, InitialValue, IsArray, Length, Name) Dependency
WorkflowProcess
SW Service Message Type Declaration
DataType
DataField
— Æ
Æ
Orchestration Data
—
Æ
Æ
Æ
—
eService Capability Conversation Regulation eService Capability
eService Data Format
Æ
Æ
eService Capabilities
Æ
32
Æ
Table 1: PARIS UML Profile Part 1
Roles Endpoints Interactions Service Structure Data
Process Definition Metadata Specification Structure
E-Service-Model Stereotypes
Service Pattern Model Stereotypes
Service Coordination Model Stereotypes — —
— — Æ Æ Æ Æ Æ Æ Æ Æ opt opt
— —
opt
— — Æ Æ Æ Æ Æ Æ Æ Æ opt opt
Service Composition Model Stereotypes
WfMC-Modell Stereotypes SubFlow
UML Elements Package + Class (SubFlow-Information), Attributes (Execution, Id)
Dependency (Responsible)
opt
Responsible
Æ Æ Æ Æ Æ Æ Æ Æ opt opt
opt
Script
Class, Attributes (Grammar, Type, Version) Class (Package_Header), Attributes (CostUnit, Created, Description, Documentation, PriorityUnit, Vendor, XPDLVersion)
opt opt
opt
PackageHeader
Æ Æ Æ Æ Æ Æ Æ Æ opt opt
opt opt
opt
opt opt opt opt
Package + Class (FormalParameter-Information), Attributes Formal Parameter (Description, Index, Mode) ActivitySet Package + Class (Process-Diagram), Activity Diagram ActualParameter Package + Class, Attribute (Content) Package Condition Xpression Class, Attribute (XmlSource) Join Class, Attribute (Type) Package Split TransitionRestriction Package TransitionRef Class + Dependency (Transition) ExternalReference Class, Attributes (location, namespace, xref) ExtendedAttribute Class, Attributes (Name, Value) Class, Attributes (Author, Version, Codepage, Countrykey, RedefinableHeader PublicationStatus)
— opt
WorkflowProcesses ExtendedAttributes ExternalPackages ExternalPackage TypeDeclarations DataFields Participants Applications Formal Parameters ActivitySets Activities ActualParameters Transitions TransitionRestrictions TransitionRefs
Class, Attributes (DeadlineCondition, ExceptionName, Deadline Execution) Class, Attributes(Cost, Instantiation, SimulationInformation TimeEstimation:Duration, TimeEstimation:WaitingTime, TimeEstimation:WorkingTIme) Package Package Package Package Package Package Package Package Package Package Package Package Package Package Package
— —
Tagged Values
Notes
Only for or elements
Optional for or
Contains Contains or element Transition: For external specifications For extensions
One for each
Optional for , Responsible:
Content = element No Exceptions XPath 1.0 Expression
—
— — Type — — Type — — — —
— — —
—
Optional for
Optional for
One for each
—
Contains elements Contains elements Contains elements Contains elements Contains elements Contains elements Contains elements Contains elements Contains elements Contains elements Contains elements
Contains elements Contains elements Contains elements
— — — href — — — — — — — — — — —
Class, Attributes (Created, Description, DurationUnit, Limit, Priority, TimeEstimation: Duration, TimeEstimation: Waiting — Time, TimeEstimation: Working Time, ValidFrom, ValidTo)
opt
opt
ProcessHeader
opt
opt
opt
opt
opt
Æ Æ Æ Æ Æ Æ Æ Æ — Æ Æ Æ Æ Æ Æ
opt
opt opt
Æ Æ Æ Æ Æ Æ Æ Æ — Æ Æ Æ Æ Æ Æ
opt
opt Æ Æ Æ Æ Æ Æ Æ Æ — Æ Æ Æ Æ Æ Æ
opt
Æ Æ Æ Æ Æ Æ Æ Æ — Æ Æ Æ Æ Æ Æ
Table 2: PARIS UML Profile Part 2
33
Refined high-level stereotypes for e-service models and software service interaction models build on fundamental stereotypes for WfMC workflow models. Explicit hierarchical relationships between stereotypes are depicted in successive table columns of each row from left to right (printed tables are rotated by 90 degree). The model structures of individual levels are specified in the PSM, where stereotypes map to interrelated concepts of different metamodels. Note that all UML associations on the different levels of the PSM build on concepts of the workflow metamodel. In ambiguous cases, associations are decorated by respective stereotypes. E.g. in the e-service metamodel (figure 12) composition of eService Data Formats as parts of an eService Interaction Context is mapped to the workflow concept of Type Declarations within a Workflow Package . Further notes on using individual stereotypes are given in the rightmost columns of the tables.
4 A Case Study of Virtual E-Science Service Models To demonstrate and evaluate the PARIS approach, we have conducted a case study experiment in the area of computational chemistry e-science. It is based on the application scenario of polymorph prediction (PP) research, where benefits were expected from carrying it out by means of virtual e-science labs. Next, we will introduce the scenario and summarise earlier findings on its potential for virtualisation by means of PARIS VBSPN concepts (sec. 4.1). In particular, we analyse virtual PP VBSP for virtualisation of PP lab organisation. Then, we show the design and formal specification of PP VBSP as service-oriented software architecture based on the PSM (sec. 4.2).
4.1 Virtualisation of Polymorph Prediction Research For our case study we chose a scenario of e-science research that was originally conducted by a single organisation lab but likely to allow for and benefit from virtual organisation. The scenario builds on the research method of PP and its implementation in computational grids. To introduce PP research, we will firstly outline the method and its grid-based implementation at University College London (UCL). We will also motivate an extension as virtual lab in the UK e-Science network and discuss requirements for experimental variation. Secondly, we will introduce the PARIS approach to virtual PP labs and particularly summarise a conceptual analysis of virtual PP services. 4.1.1 Towards Virtual Polymorph Prediction Labs The research method of PP builds on the fact that organic molecules tend to appear in different forms of crystal structures (polymorphs) with distinct physical properties. For many molecules, the range of polymorphs is initially unknown. Utility of molecules however depends on their physical properties.and prediction of polymorphs is highly desirable. Computational approaches to PP tackle this problem systematically [Pri04]. The idea is to first compute (parts of) the theoretical packing of a molecule into crystal structures with algorithms like MOLPAK [HDA93] and then to compute the physical properties of each crystal structure (to a certain degree of accuracy) with algorithms like
34
Setup Search
MOLPAK
MOLPAK
DMAREL
DMAREL
DMAREL
DMAREL
Convert Data
Convert Data
Convert Data
Convert Data
Visualise Results
Visualise Results
Visualise Results
Visualise Results
Store Data Sets and Publish on Data Portal
Figure 14: Polymorphic Search Workflow [EBCW05] DMAREL [WPLC95]. Finally, scientists assess lattice energy and molecular volume of crystal structures to predict thermodynamic plausibility. Fig. 14 shows the working process of computational PP experiments. It starts with specification of the molecule as well as search parameters like packing range and accuracy. The following independent computations split into parallel runs of MOLPAK and DMAREL algorithms. Result data needs to be converted into formats acceptable by algorithms to compute and human scientists to access. The later case takes on the form of visualisation as scatter plot diagrams. Finally, result data is persisted in a database and published for access by collaborating scientists. PP is a research method with high computational demand and natural parallelism. It can therefore benefit from grid-based implementation and high throughput computing [NBC+ 04]. A respective implementation of polymorph search processes has been realised at UCL [EBCW05]. It applies BPEL-based software service orchestration to capture the experiment process and control execution of its activities in different organisational units. Those units are thereby integrated into an e-Science lab for PP. The original lab consisted of an interactive workplace and result database at the UCL chemistry department, experimental control and auxiliary functions at the UCL computer science department and the UCL Condor high-throughput commodity computing pool for experiment computations.
35
The fact that the UCL Condor pool (980+ nodes) gets fully utilised by a PP experiment and not all job requests can be served in parallel, leads to demand for more grid resources [WBE04]. An apparent solution is to transform the e-Science lab into a virtual organisation that combines the grid resources of scientific organisations in the UK eScience network. Federated condor clusters and pools exist in other UK Universities like Aston, Cambridge, Cardiff, Imperial, Southampton and Westminster. Additionally, various scientific and auxiliary services from members of the UK e-Science network are available for utilisation in a virtual PP lab. Examples include plotting functionality from the Southampton e-Science Centre or publication of result data via scientific mediator facilities such as the CCLRC data portal [DKS+ 03]. A framework of mutual agreements in context of mostly national e-Science initiatives provides the strategic network from which to initiate virtual organisations to run specific experiments. In the strategic UK e-Science network, virtual PP labs are temporal organisational networks of individual members that are individually selected and coordinated to carry out exactly one experiment in the best possible way. In order to set up such virtual labs, it is crucial to consider the requirements of carrying out PP experiments. Generally, experiments may vary in terms of completeness and precision. Broad experiments serve to identify candidates for further examination. They consider fewer packing-alternatives and compute physical properties with less precision. Deep experiments are meant for accurately predicting single polymorphs. They need to consider all possible packing-variants and compute properties as exact as possible. Different types of experiments make similar functional requirements on virtual labs, but non-functional requirements vary. Deep experiments require the highest possible level of computational throughput performance. A virtual lab can achieve this by involving as many grid pool providers as possible and delegating as much as possible workload to them. Broad experiments demand less computational performance but a higher level of agility to set-up and run experiments of a series with minimum delays. A virtual lab can obtain this quality by simplifying coordinative regulations and minimising participating grid pools, thus lowering administrative overhead. We also mention varying requirements of confidentiality, trust and security depending on research subjects and contexts. Virtual labs must adjust there administrative procedures to prevent unauthorised access to experimental data. 4.1.2 Virtual Polymorph Prediction Services In PARIS, we have examined virtualisation of PP labs as virtual scientific service production networks (VSSPN). As shown earlier, this involves two major aspects: 1) virtualisation of PP experiments as virtual scientific service processes (VSSP) and 2) planning and control of VSSPs over the lifecycle of VSSPNs. In this paper we focus on the first aspect, because we want to demonstrate the application of the PARIS PSM for this purpose. Beforehand, we summarise an earlier conceptional analysis of requirements for VSSP structure and pattern variation [ZE07].
36
coordinates
> PSM VBS-Demand (from PARIS VBSPN )
> PSM VBS-Capabilities (from PARIS VBSPN )
coordinates
> PSM VBS-Assets (from PARIS VBSPN )
coordinates
Extension Points
> Result Visualisation
coordinates
>
Scientific Services
regulates
> Result Visualisation
> Result Handling
coordinates
> coordinates
Data Assessment
regulates coordinates coord.
coordinates
Polymorph Prediction
> Result Transformation
> Packing Management
regulates
>>
Search Specification
regulates
coord.
> Packing Management coordinates
>
Auxiliary Services
>>
Results Download
Result Handling
>>
Data Publishing
regulates
coordinates
>>
Dissemination Management
> Poly Pred coordinates
Search Monitoring
regulates > Confidential
> Analysis Management > Deep > PSM Orchestration Regulation (from PARIS VBSPN )
>
DMAREL
coordinates
> coord.
> Job Submission
regulates > PP Pattern
1..*
> Dissemination Mngmt.
> Analysis Management
coordinates
Job Submission
>>
Grid Job
>>
MOLPAK
> Broad
> Open
> PSM Interaction Regulation (from PARIS VBSPN )
Figure 15: Polymorphic Prediction Experiments as VSSP Virtualisation of PP experiments starts with analysing coordination aspects of experiment processes. In PARIS, this is done by structuring the experiment process as components of a VBSP. Here, the PARIS model proposes the concepts of assets, capabilities and demands. In terms of assets, which represent core competencies of providers to produce content, PP labs predominantly consist of computations in the form of grid jobs in general and MOLPAK and DMAREL jobs in particular. Additional assets include scientific services like graph plotting, (meta-)data publishing and auxiliary services like result data transformation. Regarding demands of PP experiments, which represent client side activities to consume service content, we identify the specification of experiment subject (i.e. definition of molecule) and parameters (e.g. types of packing and accuracy of properties), monitoring of the experiment, assessment of result visualisation and download of result data. The remaining parts of the virtual service process fall into the category of capabilities, which represent administrative procedures to coordinate cooperation of assets and demands for service provision. The first type of local capability relates to coordination
37
aspects of individual assets. In PP experiments, this translates to coordination of cooperation with grid pools and services. In particular, we identify the need for local capabilities to coordinate grid job submission, result transformation, result visualisation and dissemination management. The second type of global capabilities relates to coordination aspects between assets and interconnects local capabilities. In the scenario, we identify respective capabilities to coordinate series of MOLPAK and DMAREL computations with respect to management of molecule packing and packing analysis in an experiment. We also identify the need for a capability to coordinate scientific and auxiliary services as regards handling of results. Finally, a top-level polymorph prediction capability needs to coordinate service provision aspects and demands. The identified components make up the VSSP that captures coordination aspects of PP experiments. In fig. 15, we model the process by means of use cases that extend respective concepts of the PARIS model (see fig. 1). In the diagram, assets/demands are shown in black, capabilities in dark grey and patterns/idioms (introduced next) in light grey. The result is a systems requirements model for polymorph prediction VSSPs. After discovering high-level functional structure of a VSSP, we need to analyse its refinement by means of flexible regulations that capture required variations of PP experiments. Anticipation of experiment variations provides flexibility and agility of organisational structure required for VBSPN planning. Therefor, the PARIS VBSPN model provides concepts of pattern-based regulation. In particular, this includes regulating coordination of cooperation by means of interaction patterns and regulating enforcement of coordination by means of orchestration idioms (see fig. 2). Cases of virtual lab interaction patterns (indirectly) refine the abstract concept of PARIS Interaction Regulation with respect to the PP scenario and generally arise from VSSP capabilities (see fig. 15). Each pattern represents a specific piece of coordinative regulation as regards its functional scope and marks a variation point for enforcement in terms of orchestration activities and assignment of executive responsibility. In particular, the Polymorph Prediction pattern serves search specification demands from clients, initiates experiments and delegates main experiment phases to respective coordinators. The Packing and Analysis Management patterns select packing/analysis strategies and delegate MOLPAK/DMAREL tasks to respective coordinators. They also forward results and serve client monitoring demands. The Result Handling pattern collects results, delegates data utilisation tasks to coordinators and serves client demands of result download as well as data assessment. The Result Visualisation, Result Transformation, Dissemination Management and Job Submission patterns request scientific and auxiliary service assets as well as data publishing, DMAREL and MOLPAK assets from providers. Orchestration idioms correspond to non-functional requirements of experiment variations for PP. Each idiom captures a distinct strategy to implement the enforcement of general interaction patterns by translating them into specific orchestration procedures and assigning executive responsibilities to specific roles. In the diagram, cases of Deep, Broad, Open and Confidential idioms refine the general case of PARIS Orchestration Regulation and are (indirectly) associated with all patterns of the VSSP. They all provide an optimised implementation strategy for interaction patterns as regards respective PP
38
Idiom
Requirements
Implementation Strategy
Broad
Series of approximating experiments requiring agility
Implementation strategy translates interaction patterns to orchestration activities of single consolidated capability enforcement instances for centralised execution by PP service providers. The goal is to minimise deployment and interaction between global capabilities.
Deep
Single detailed experiment requiring throughput performance
Implementation strategy translates interaction patterns to orchestration activities of many interrelated capability enforcement instances for decentralised execution by a maximum of providers. Load balancing of global capabilities results in optimised performance and scalability.
Confidential
Experiment on classified subject requiring confidentiality
Implementation strategy translates interaction patterns into orchestration activities of few interrelated capability enforcement instances for execution by a set of trusted providers. Limiting data visibility and reducing interaction of global capabilities minimises risk of disclosure.
Open
Cooperative experiment requiring transparency
Implementation strategy translates interaction patterns into orchestration activities and combines them into a general capability enforcement instance for replication and execution by all providers. Sharing of procedure and state between global capabilities maximises individual insight.
Table 3: Orchestration Idioms for VSSP Capability Patterns experiment variants. The design of implementation strategies mirrors requirements of experiment variations and translates into non-functional properties of resulting organisational coordination structures. We summarise their different implementation strategies for experiment variations in table 3.
4.2 A SOA Model for Polymorph Prediction E-Services After conceptual analysis of our case study scenario, we will now show how to apply the PARIS e-service metamodel to design and specify a process-driven service-oriented software architecture model for regulating coordination of virtual lab participants carrying out polymorph prediction experiments. As a first step, we will discuss the design of VSSP structure and variations by means of PSM eService abstractions. Then we will demonstrate how to apply the PARIS PSM in order to formally specify the VSSP model by means of UML. 4.2.1 Designing Patterns for Experimental Processes Prior to formal specification, we will discuss how to translate the conceptual systems requirements model into a PSM-based architectural model. Generally, such design procedure is a part of the pre-contact phase of a virtual business service, which is mainly about planning of virtual business service processes. VBSP planning comprises activities of VBSPN members to specify, mutually adjust and analyse regulations of their cooperation within the virtual business service contact phase. In the PARIS approach, cooperative regulations are represented as e-service schemas and their planning is part of an e-service management methodology that is not subject of this paper. We will instead describe general steps of designing e-service schemas as well as resulting structures.
39
As PARIS adopts a model driven development (MDD) approach, E-service design generally follows a top-down approach. We distinguish e-service models on three levels of abstraction. Platform independent e-service models (PIM) represent specific domain concepts of virtual business service processes and the organisational network they rely upon. Platform specific e-service models (PSM) refine specifications as regards realisation of domain concepts by means of software service technology in general (as defined by the PSM) as well as software service standards and platforms (e. g. Web Services) in particular. Executable e-service models implement PSMs for running them within service oriented middleware. E-service design activities occur on all of these levels. In this paper we are mostly interested in the design of PIMs, which is an interactive exercise specifically tailored to the requirements of individual business services. In the spirit of MDD, designing subsequent levels is a more schematic (i. e. model transformation) and especially for executable models automated (i. e. code generation) activity. For PIM design, the PARIS metamodel offers a variety of abstractions that are specified in its eService sub-models. On topmost level, these comprise structural abstractions including eService Core Assets/Client Demands (ca, cd) and eService Shell/Capabilities (sh, ec). These provide a context for functional abstractions of eService Roles/Organisations (er, eo) and , Asset/Demand Component Software Services (acs, dcs) with respective eService Interaction Contacts (ic) and Data Formats (df ) as well as eSerice Capability Conversation/Interaction Regulations (ccr, cir). For variants, the pattern metamodel offers Software Service Orchestration Idioms (soi) and QoS Parameter Sets (qps). Designing PIMs for individual business services is mainly about translating their system requirements models into the above mentioned abstractions. As a first step, cases of PSM VBS-Assets and -Demands might be directly related to respective functional abstractions (ca + acs, cd + dcs). Also PSM VBS-Capabilities and PSM Interaction Regulations might be related to corresponding model elements (ec + ccr). In a second step, PIM design needs to address functional requirements of cases. Most elemental, this includes refining component software services (acs, dcs) in terms of roles, contacts and data formats (eo + er + ic + df ). Beyond that, the most challenging part is the translation of PSM Orchestration Regulations (idioms). On the one hand, represented variations relate to respective functional abstractions (soi + qps). On the other hand, required implementation strategies need to be captured in the design of capability regulations (ccr, cir). Design of capability interaction regulations defines adequate scopes of variation. Within these scopes, design of capability conversation regulations captures variants of flow and aggregation. Generally, design activities in the second step need to consider generic principles of good design [FWar] (low coupling, high cohesion etc.). In our case study, designing an architectural model of virtual scientific service processes for polymorph prediction experiments starts with a look at its requirements model. The VSSP use case diagram in fig. 15 lists asset-, demand- and capability cases and indicates their functional characteristics. It also lists the cases of capability-related interaction patterns and four global orchestration patterns. Pattern cases are further described as regards the coordination logic of interaction patterns and the implementation strategies for orchestration patterns.
40
In the first design step, we map asset and demand cases as well as capability cases and related interaction pattern cases to an initial set of model elements: ca1...5 + acs1...5 , cd1...4 + dcs1...4 , ec1...8 + ccr1...8 + cir1...8 Furthermore, the metamodel requires e-service roles to define asset, demand and capability endpoints and related component software services, which result in elements er1...17 . Finally, we map cases of orchestration patterns to elements that represent orchestration idioms and their properties soi1...4 + spq1...4 . In the second design step, we refine the initial set of model elements as regards functional requirements of interaction- and orchestration pattern cases. In the polymorph prediction scenario, Web Service descriptions are already provided for most of the assets. We can directly translate their WSDL operations and message types into more generic contact- and data format elements of the model and largely reuse them for the refined design of remaining assets and demands. Main contacts include setup- (ic1 ), packing(ic2 ), analysis- (ic3 ), result handling- (ic4 ), transformation- (ic5 ), visualisation- (ic6 ) and dissemination requests (ic7 ) as well as notification (ic8 ). Main data formats include experiment specification (df1 ) as well as packed- (df2 ), analysed- (df3 ), monitored- (df4 ), transformed- (df5 ) and visualised data (df6 ). To complete the design of the eService interaction context, we define a number of eService organisations eo1...10 that have been identified in the conceptual analysis of virtual lab planning and control.4 The first 8 organisational roles of PP Service Provider (eo1 ), Data Portal Owner (eo2 ), Scientific Service Provider (eo3 ) and PP-Grid User (eo4 ) as well as PP- (eo5 ), Packing- (eo6 ), Analysis- (eo7 ) and Evaluation Coordinator (eo8 ) are fixed for each VSSP instance. The rest of the organisational roles comprises a variable number of Grid Job managers. These are further refined into n PP Packers (eo1...n ) plus m PP Analysers (eo1...m 9 10 ). Related to the variable number of grid job managers we also define a variable number of associated MOLPAK- (ca1...n + acs1...n ) and DMAREL Assets (ca1...m + acs1...m ) as well as a variable 1 1 2 2 1...n+m 1...n+m number of local capabilities for Job Submission (ec5 + ccr5 + cir51...n+m ). This design accounts for scalability of virtual labs as it allows for an arbitrary number of grid resource providers and their resources to be included depending on requirements of individual experiments. After preparing an interaction context, design turns to behavioural requirements identified in the conceptual analysis of interaction- and orchestration patterns. As a design decision, we first refine some of the capability cases. In order to allow for the required range of variation, we split some of the capabilities in order to a) further divide or b) add a global perspective to their coordinative functions. Namely do we divide functionality to coordinate client interactions with demands into 4 additional local capabilities (ec2,6,16,18 ). We also introduce a global perspective to all local capabilities that coordinate asset interactions. This includes 3 global capabilities that coordinate inter-capability interactions for Result Transformation (ec10 ), Result Visualisation (ec12 ) and Dissemination Management (ec14 ). Regarding local capabilities of Job Submission, we add two global sets of capabilities that coordinate inter-capability interactions for 4
Please see [ZE07] for details on conceptual analysis of virtual lab planning and control.
41
id ic1 ic2 ic3 eService ic4 Interaction ic5 Contacts ic6 ic7 ic8 df1 df2 eService Data df3 Formats df4 df5 df6 eo1 eo2 eo3 eo4 eService Organi- eo5 sations eo6 eo7 eo8 eo9.1…n eo10.1…m er1, ca/acs1.1…n eService Core er2, ca/acs2.1…m Assets, Asset er3, ca/acs3 Providers and er4, ca/acs4 endpoints er5, ca/acs5 eService Client er6, cd/dcs1 Demands, er7, cd/dcs2 Clients and er8, cd/dcs3 er9, cd/dcs4 endpoints type
name setup request packing request analysis request result handling request transformation request visualisation request dissemination request notification experiment specification packed data analysed data monitored data transformed data visualised data PP service provider data portal owner scientific service provider PP-grid user PP coordinator packing coordinator analysis coordinator evaluation coordinator PP packer PP analyser MOLPAK DMAREL auxiliary service scientific service data publishing search specification monitoring results download data assessment
type
id er10, ec/cir/ccr1 er11, ec/cir/ccr2 er12, ec/cir/ccr3 er13, ec/cir/ccr4.1…n er14, ec/cir/ccr5.1…n+m eService er15, ec/cir/ccr6 Capabilities, er16, ec/cir/ccr7 Capability er17, ec/cir/ccr8.1…m Providers, er18, ec/cir/ccr9 Capability er19, ec/cir/ccr10 Conversation er20, ec/cir/ccr11 Regulations and er21, ec/cir/ccr12 Capability er22, ec/cir/ccr13 Interaction er23, ec/cir/ccr14 Regulations er24, ec/cir/ccr15 er25, ec/cir/ccr16 er26, ec/cir/ccr17 er27, ec/cir/ccr18 er28, ec/cir/ccr19 SW Service oi1, qps1 Orchestration oi2, qps2 Idioms and QoS oi3, qps3 Parameter Sets oi4, qps4 cir1 cir9 eService Capability Interaction Regulations defining global interaction pattern contexts
name polymorph prediction (global) specification management (local) strategic packing management (global) tactic packing management (global) grid job submission (local) monitoring management (local) strategic analysis management (global) tactic analysis management (global) result handling (global) result transformation (global) download management (global) result visualisation (global) assessment management (global) dissemination management (global) result transformation (local) download management (local) result visualisation (local) assessment management (local) dissemination management (local) broad deep confidential open computation pattern utilisation pattern
Table 4: Main VSSP Model Elements job submissions with respect to packing jobs (ec1...n ) and analysis jobs (ec1...m ). The 8 4 reason is that we additionally divide the coordinative functionality of Packing/Analysis Management (ec3,7 ) into strategic and tactic aspects and add the later to the sets ec4,8 . Together, these additional capabilities will allow us to realise the required implementation strategies of orchestration pattern cases. At this point, the main model elements have been completely defined. Table 4 gives a summary. Based on the extended set of capabilities, the last part of design concerns associated patterns and idioms. Patterns of the VSSP model comprise eService capability conversation- and -interaction regulations. Firstly, we define 2 interaction regulations that aggregate self-contained sets of conversation regulations and define their integrated behavioural variations by means of orchestration idioms. VSSP interaction regulations include a computation pattern (cir1 ) and a utilisation pattern (cir9 ). Both patterns allow for broad, deep, confidential and open software service orchestration idioms oi1...4 1,9 . Conversation regulations contained in each of the interaction patterns define respective variations of behavioural specification by means of interaction flow and role aggregation. Each variation is associated with one or more idioms. Variations in different conversation regulations that are associated with the same idiom define a single integrated variation of the interaction pattern. We distinguish variations of interaction flow from variations of role aggregation and refer to the former as flow variants and the later as aggregation variants. Different variants might be combined in one idiom to reach a desired characteristic of the implementation. We will now define 2 flow- and 2 aggregation variants and thereafter describe their combination to realise orchestration idioms.
42
Computation Pattern cir1
5: ic2(df1) 14:rcv(df2)
1:ic1() 4:rcv(df1)
6.1:ic2(df1) 11.1:rcv(df2)
Search Specification Demand dcs1
15: ic3(df2,df1) 24:rcv(df3)
Strategic Packing Management ccr3 (global)
Specification Management ccr2 (local)
2:ic1() 3:rcv(df1)
Polymorph Prediction ccr1 (global)
25:ic4(df2,df3,df1) 47:rcv(cnf)
Strategic Analysis Management ccr7 (global)
12.1-12.n:ic8(df4)
6.n:ic2(df1) 11.n:rcv(df2)
16.m:ic3(df2,df1) 21.m:rcv(df3)
16.1:ic3(df2,df1) 21.1:rcv(df3)
22.1-22.m:ic8(df4)
Utilisation Pattern cir9
Resullt Handling ccr9 (global)
26:ic5(df2,df3,df1) 31:rcv(df5)
32:ic8(df5)
35:ic6(df5) 40:rcv(df6)
41:ic8(df6)
44:ic7(df5)
Tactic Packing Management ccr4.1 (global)
Tactic Packing Management ccr4.n (global)
Tactic Analysis Management ccr8.1 (global)
Tactic Analysis Management ccr8.m (global)
Result Transformation ccr10 (global)
Download Management ccr11 (global)
Result Visualisation ccr12 (global)
Assessment Management ccr13 (global)
Dissemination Management ccr14 (global)
7.1:ic2(df1) 10.1:rcv(df2)
7.n:ic2(df1) 10a.n:rcv(df2)
17.1:ic3(df2,df1) 20.1:rcv(df3)
17.m:ic3(df2,df1) 20.m:rcv(df3)
27:ic5(df2,df3,df1) 30:rcv(df5)
33:ic8(df5)
36:ic6(df5) 39:rcv(df6)
42:ic8(df6)
45:ic7(df5)
Job Submission ccr5.1 (local)
Job Submission ccr5.n (local)
Job Submission ccr5.n+1 (local)
Job Submission ccr5.n+m (local)
Result Transformation ccr15 (local)
Download Management ccr16 (local)
Result Visualisation ccr17 (local)
Assessment Management ccr18 (local)
Dissemination Management ccr19 (local)
8.1:ic2(df1) 9.1:rcv(df2)
8.n:ic2(df1) 9.n:rcv(df2)
18.1:ic3(df2,df1) 19.1:rcv(df3)
18.m:ic3(df2,df1) 19.m:rcv(df3)
28:ic5(df2,df3,df1) 29:rcv(df5)
34:ic8(df5)
37:ic6(df5) 38:rcv(df6)
43:ic8(df6)
46:ic7(df5)
MOLPAK Asset acs1.1
MOLPAK Asset acs1.n
DMAREL Asset acs2.1
DMAREL Asset acs2.m
Auxillary Services Asset acs3
Results Download Demand dcs3
Scientific Services Asset acs4
Data Assessment Demand dcs4
Data Publishing Asset acs5
Monitoring Management ccr6 (local)
13.1-13.n,23.1-23.m:ic8(df4)
Search df4itoring Demand dcs2
Figure 16: Polymorph Prediction Flow Variant 1
Computation Pattern cir1
Polymorph Prediction ccr1 (global)
5::ic2(df1) 1:ic1() 4:rcv(df1)
Strategic Packing Management ccr3 (global)
Specification Management ccr2 (local)
Strategic Analysis Management ccr7 (global)
Utilisation Pattern cir9
Resullt Handling ccr9 (global)
21.1:ic4(df2,df3,df1)
21.m:ic4(df2,df3,df1)
13.1:ic3(df2,df1)
22:ic5(df2,df3,df1) 14.m:ic3(df2,df1)
6.n:ic2(df1) 6.1::ic2(df1)
14.1:ic3(df2,df1) 13.n:ic3(df2,df1)
Tactic Packing Management ccr4.1 (global) 11:ic8(df4)
7.1:ic2(df1) 10.1:rcv(df2)
2:ic1() 3:rcv(df1)
Search Specification Demand dcs1
Tactic Analysis Management ccr8.1 (global) 11:ic8(df4)
19:ic8(df4)
7.n:ic2(df1) 10.n:rcv(df2)
Tactic Analysis Management ccr8.m (global)
Job Submission ccr5.n (local)
8.1:ic2(df1) 9.1:rcv(df2)
8.n:ic2(df1) 9.n:rcv(df2)
MOLPAK Asset acs1.1
MOLPAK Asset acs1.n
Monitoring Management ccr6 (local)
12.1-12.n,20.1-20.m ic8(df4)
Search df4itoring Demand dcs2
Result Transformation ccr10 (global)
19:ic8(df4)
Download Management ccr11 (global)
Result Visualisation ccr12 (global)
26:ic8(df5)
15.1:ic3(df2,df1) 18.1:rcv(df3)
Job Submission ccr5.1 (local)
38:ic7(df5)
30:ic6(df5)
Tactic Packing Management ccr4.n (global)
15.m:ic3(df2,df1) 18.m:rcv(df3)
Assessment Management ccr13 (global)
Dissemination Management ccr14 (global)
35:ic8(df6)
23:ic5(df2,df3,df1) 26:rcv(df5)
28:ic8(df5)
31:ic6(df5) 34:rcv(df6)
36:ic8(df6)
39:ic7(df5)
Job Submission ccr5.n+1 (local)
Job Submission ccr5.n+m (local)
Result Transformation ccr15 (local)
Download Management ccr16 (local)
Result Visualisation ccr17 (local)
Assessment Management ccr18 (local)
Dissemination Management ccr19 (local)
16.1:ic3(df2,df1) 17.1:rcv(df3)
16.m:ic3(df2,df1) 17.m:rcv(df3)
24:ic5(df2,df3,df1) 25:rcv(df5)
29:ic8(df5)
32:ic6(df5) 33:rcv(df6)
37:ic8(df6)
40:ic7(df5)
DMAREL Asset acs2.1
DMAREL Asset acs2.m
Auxillary Services Asset acs3
Results Download Demand dcs3
Scientific Services Asset acs4
Data Assessment Demand dcs4
Data Publishing Asset acs5
Figure 17: Polymorph Prediction Flow Variant 2
43
Computation Pattern cir1
Polymorph Prediction ccr1 (global)
av1 : eo5
Strategic Packing Management ccr3 (global)
Strategic Analysis Management ccr7 (global)
Utilisation Pattern cir9
Resullt Handling ccr9 (global)
av2: eo6,7,8 av1 : eo5 av2: eo9.1...m Tactic Packing Management ccr4.1 (global)
av2: eo10.1...m
Tactic Packing Management ccr4.n (global)
Tactic Analysis Management ccr8.1 (global)
Tactic Analysis Management ccr8.m (global)
Result Transformation ccr10 (global)
Download Management ccr11 (global)
Result Visualisation ccr12 (global)
Assessment Management ccr13 (global)
Dissemination Management ccr14 (global)
av2: eo1,4,3,4,2
Figure 18: Polymorph Prediction Aggregation Variants 1 and 2
We first introduce the flow variants. For this purpose, we use schematic diagrams as they where introduced in section 3.2.3. Fig. 16 shows the first flow variant f v1 , which implements a centralised control flow. In this case, major parts of control functionality is implemented in a limited set of conversation regulations, namely ccr1,3,7,9 . Control functions utilise synchronous sub-capability calls as means of inter-capability coupling. The resulting control procedure is mostly sequential and highly predictable. Fig. 17 shows the second flow variant f v2 , which implements a decentralised control flow. In this case, implementation of control functionality is more widely spread over conversation regulations. In particular, parts are implemented by a variable number of tactical packing and analysis management capabilities (ccr41...n , ccr81...m ) as well as global capabilities associated with assets (ccr10,12 ). Control functions utilise asynchronous capability flow passing for inter-capability coupling. The resulting control procedure introduces some parallelism and is more effective. In terms of aggregation variation, VSSP design comprises of 2 variants. Fig. 18 shows both of them in a single schematic diagram. The first variant av1 implements concentrated aggregation. In this case, a single broker organisation eo5 aggregates many of the capabilities. This organisation gains and shields central parts of control as well as insight into its state and data. The second variant av2 implements distributed aggregation. The goal is not to cluster capabilities but assign them to as many different organisations as possible – in particular those capabilities that implement vital parts of control functionality (e. g. ccr3,7,9 ). This prevents single organisations to gain too much influence on control functions and opens insight into state and data of the service process to a wider set of organisations. The required VSSP orchestration idioms are realised by combining the different flow and aggregation variants as shown in fig. 19. In the following we describe how the combinations of variations lead to the required non-functional properties of different experiment implementations.
44
fv2: decentralised control flow
av1: concentrated aggregation
oi1: broad centralised and concentrated control functions
oi3: confidential decentralised but concentrated control
av2: distributed aggregation
ow ts Fl n n ria io Va at s eg nt gr ria Ag Va
fv1: centralised control flow
oi4: open centralised but distributed control
oi2: deep decentralised and distributed control
Figure 19: Variant Combinations for VSSP Orchestration Idioms • Idiom oi1 , representing broad experiments, combines centralised control flow with concentrated aggregation. Complex control functionality is centralised and assigned to a single role. As a consequence, there is no overhead for deploying complex functions or coordination-related inter-capability interactions. Therefore, experiments can be relatively quickly set up. The coordination procedure however lacks effectiveness. • Idiom oi2 , representing confidential experiments, combines decentralised control flow with concentrated aggregation. The complete set of experiment data is only visible to one coordinator and those providers that inevitably require it. The coordination procedure is reasonably effective as control functions are split between capabilities and assigned to a limited set of roles. Experiment set up might take time. Idiom oi1 might be an alternative. • Idiom oi3 , representing deep experiments, combines decentralised control flow with distributed aggregation. The coordination procedure is most effective as it takes full advantage of parallelism. Control functions are split between capabilities and assigned to a maximum of distinct roles. Experiments take time to set up and experiment data is disclosed to many organisations. • Idiom oi4 , representing open experiments, combines centralised control flow with distributed aggregation. Control functions are centralised to a limited set of capabilities, which are assigned to different roles. These roles share the state of experiments between them. Coordination procedure lacks effectiveness and experiments are naturally not confidential. Idiom oi2 might be used here as an alternative.
45
4.2.2 VSSP Modelling and Specification We will now demonstrate the utilisation of PARIS UML profile for modelling and specification of the virtual service process design for polymorph prediction experiments. We will first discuss general implementation issues. Thereafter we explain modelling methodology for VSSP regulation and introduce major parts of the PP e-service model. Finally, we briefly discuss specification methods for VSSP regulation and enforcement. In order to utilise the PARIS UML profile, it has to be implemented within an UML modelling tool. Generally, any such tool might be used as long as it provides means for supporting UML profiles. Implementation can be as simple as defining the required stereotypes and tagged values. It is however advisable to implement support functions to govern the modelling process by generating associated elements and monitor constraints. Consequently, we have developed a plug-in for e-service modelling as an extension of the Poseidon for UML5 tool. The PARIS modelling plug-in provides an interactive tool for generating associated UML elements and diagrams for all concepts of the workflow sub-profile and allows for their extension as regards higher-level constructs. Modelling of the PP e-service has been done by means of this implementation. We will however omit implementation- specific aspects and focus our discussion on general issues of UML-based e-service modelling. VSSP modelling starts with structural aspects. Initially, each e-service model follows a mandatory model structure that is defined by the e-service metamodel. The PP e-service 5
http://www.gentleware.com/
>
>
PolyPred_context
PolyPred_shell
>
>
eService Data Formats
Processes
>
>
df1_ExperimentSpecificationType
Package_Header
... > eService Interaction Contacts >
-XPDLVersion:string=1.0 -Vendor:string=UCL -Created:string=2008-01-10 22:25:50 -Description:string[0..1]=PP E-Service -Documentation:string[0..1]=none -PriorityUnit:string[0..1] -CostUnit:string[0..1]
>
>
>
ec1
ec10
ec11
>
>
ec2
ec12
>
>
ec3
ec13
>
>
ec4
ec14
ccr2-ic1 >
...
Redefinable_Header
>
-Author:string[0..1] -Version:string[0..1]=rev02 -Codepage:string[0..1] -Countrykey:string[0..1] -PublicationStatus:string[0..1]=UNDER_TEST
acs1-ic2
... > dcs1-ic1
...
>
>
>
ec5
Capabilities
ec15
> eService Roles >
>
>
ec6
ec16
>
>
ec7
ec17
>
>
ec8
ec18
>
>
ec9
ec19
... er5_DataPublishing-ACSP >
... er10_PolymorphPrediction-CCSP >
... er6_SearchSpecification-DCSP >
... eo1_PP-ServiceProvider
Figure 20: UML E-Service Model Base Structure
46
base structure consists of a pp_shell eService shell and a pp_context eService Interaction Context . Furthermore, the model contains a number of eService Capability Interaction Regulations each including a eService Capability Conversation Regulation . All base concepts go along with a number of mandatory sub-concepts. E. g. the eService Shell always includes an eService Capabilities registry that contains several eService Capability entries pointing to eService Capability Conversation Regulation elements. Each of the resulting hierarchically structured concepts is modelled as a set of corresponding UML elements as specified by the profile. As a consequence, an e-service base model consists of several complementary package hierarchies containing a considerable number of interrelated elements (fig. 20 shows an overview in an UML class diagram). As this base structure is similar for all e-service models, the use of templates helps to avoid labour intensive and error prone manual initiation of models. Based on an e-service model template, the first interactive modelling step relates to the individual organisational context of a specific virtual service production network. This includes modelling network participants, their cooperative activities as well as global data elements. As indicated in fig. 20, these aspects are modelled within the eService Interaction Context as eService Roles , eService Organisations , eService Interaction Contacts and eService Data Formats . Organisational participants are specified by means of eService Organisations and might include references to an external organisational model. eService Roles specify self-contained functional aggregates containing associated activities of assets, demands or capabilities. These activities are specified as specific eService Interaction Contacts . Each such contact represents an endpoint to interact with a participant in the course of his activity. In subsequent refinement steps, endpoints might be specified in more detail by specifying them as one or more Conversation Party Listener / SW Service Component Operation elements that may contain references to external specifications (e.g. an operation of a WSDL port type). Likewise, eService Data Formats might be initially specified as abstract entities of an e-service model. Subsequently, they can be refined as detailed message type declarations of an associated software service composition model with references to external specifications (e. g. XML schema definitions). For the PP e-service model, all elements of the e-service design are specified as described above. Although some of these specifications are indicated in fig. 20, this modelling step does not generally benefit from visualisation in diagrams but is more suitable for representation in an UML model tree. The next major modelling phase pertains to VSSP behaviour. Predominantly, it includes modelling conversation variants of individual VSSP capabilities as well as modelling patterns of global capability interaction that these conversation variants support. Patterns of global capability interaction are specified by eService Capability Interaction Regulation elements. While any capability builds on one of these, some may actually represent patterns and consequently include SW Service Interaction Sub-Pattern elements to define the pattern context. In case of the PP e-service model, two such patterns are defined for computation and utilisation aspects by cir1 and cir9 . We visualise the pattern structure of an e-service by means of a pattern structure diagram. This is a refinement of an UML class diagram that contains all relevant eService
47
>
> >
cir9 >
sub-pattern
> sub-pattern
cir10 >
ccr9
ccr10
>
>
cir3
cir11
>
> >
sub-pattern
> sub-pattern
ccr3
>
ccr11
>
cir1
>
cir4
cir12 >
>
>
ccr1
>
> sub-pattern
ccr4
ccr12
sub-pattern
>
>
cir7
cir13
>
> >
sub-pattern
> sub-pattern
ccr7
ccr13
>
>
cir8
cir14
>
> >
sub-pattern
> sub-pattern
ccr8
oi1, oi4
ccr14
oi1, oi4
>
oi2, oi3
>
cir9
cir10 oi1, oi4
>
oi1, oi4
>
ccr9
ccr10
oi1, oi4
>
>
cir3 oi2, oi3
ccr3
>
>
cir1
cir4
>
>
oi1, oi4
ccr11
oi2, oi3
oi1, oi4
> cir12
>
ccr1
oi1, oi4
>
ccr4
oi1, oi4
oi2, oi3
cir11
>
ccr12 oi1, oi4
oi1, oi4
>
oi2, oi3
>
cir7 oi1, oi4
oi2, oi3
cir13
> ccr7
oi1, oi4
> ccr13
oi1, oi4
oi1, oi4
oi2, oi3 >
oi1, oi4
>
cir8
cir14
>
oi1, oi4
ccr8
> ccr14
oi2, oi3
>
> cir9
>
oi1, oi3 >
> oi1, oi2, oi3, oi4
>
ccr9
eo8_EvaluationCoordinator
> oi1, oi3
>
ccr10
eo5_PP-Coordinator
> >
oi2, oi4 >
eo1_PP-ServiceProvider
>
cir3
>
cir11
oi2, oi4
>
oi1, oi3
oi1, oi3
>
> >
>
cir10
>
oi2, oi4 >
ccr3
oi2, oi4 > ccr11
>
eo6_PackingCoordinator
>
>
cir1
eo4_PP-GridUser
>
>
cir4
cir12
oi2, oi4 > ccr1
oi1, oi3 >
>
> >
ccr4
ccr12
eo10_PP-Analyser
>
oi2, oi4 >
eo3_ScientificServiceProvider
>
>
>
cir7
cir13
oi2, oi4
>
oi1, oi3
oi1, oi3
>
> >
ccr7
oi2, oi4 > >
ccr13
eo7_AnalysisCoordinator
>
>
>
cir8 oi1, oi3 >
eo9_PP-Packer
>
cir14
oi2, oi4 >
ccr8
oi2, oi4 >
>
ccr14
>
eo2_DataPortalOwner
Figure 21: Pattern Structure (top), Flow Variation (middle) and Aggregation Variation Diagram (bottom) for the Polymorph Prediction E-Service
48
start
ccr1-ic0 >
t1
ccr2-ic1_eo1 >
t2 > ccr1-ic1.1 >
t3_oi2-oi3
ccr3-ic2_oi2-oi3 > end
t4_oi1-oi4 >
ccr3-ic2_oi1-oi4 >
t5.1
ccr1-ic2.1 >
t6
ccr7-ic3_oi1-oi4 >
t7
ccr1-ic3.1 >
t8
ccr9-ic4_oi1-oi4 >
t9
ccr1-ic4.1 >
end
Figure 22: Polymorph Prediction Conversation Regulation Pattern ccr1 Capability Interaction Regulation elements of an e-service and shows their sub-pattern dependencies. Such a diagram of the PP e-service is shown in fig. 21 (top). Furthermore, those eService Capability Interaction Regulation elements that represent patterns need to specify the possible variants of implementing the pattern by means of SW Service Orchestration Idiom elements. Related to these, associated Transformation Ruleset , QoS Property Set and Orchestration Policy Ruleset elements may be used to specify implementation instructions, qualitative effects and selection logic of idioms. In the case of the PP e-service, 8 such idioms oi1...4 1,9 are added. In the PIM, they specify Idiom Identifiers to mark variants within conversations. Modelling capability conversation variants addresses VSSP behaviour in terms of flow and aggregation variants for conversation processes. This activity includes integrated specification of all eService Capability Conversation Regulation elements of a pattern. For each of these, a non-deterministic process specification defines all elements related to directives, statements, data, roles, connections and transitions as well as their different
49
variants for individual idioms. Resulting processes are visualised by means of refined UML activity diagrams. Such a capability interaction diagram is shown in fig. 22 for the case of ccr1 , which is the topmost conversation regulation of the PP e-service. It contains both, Transition Variant elements as well as Pattern Directive elements with multiple Connection Variant elements thus specifying flow as well as aggregation variants of the global pattern. In ccr1 , there are two Transition Variants that either lead to a branch of decentralised control flow (t3_oi2-oi3) or centralised control flow (t4_oi1-oi4). For the decentralised flow variant, the conversation regulation defines a capability flow handover to the provider of ccr3 and terminates. Otherwise, it defines sequential sub-capability calls to the providers of ccr3,7,9 . All these interactions are Pattern Directives that define Connection Variants for either concentrated or distributed aggregation. The combinations of flow and aggregation variants realise the four idioms and each variant is marked with two idiom identifiers accordingly. E. g. Transition Variant t3_oi2-oi3 realises idioms oi2,3 that both rely on decentralised control flow. Pattern Directive ccr3-ic2_oi2-oi3 also realises idioms oi2,3 by means of two Connection Variants . These either aggregate ic2 to the PP service provider organisation eo1 for concentrated aggregation as to realise idiom oi3 or to the packing coordinator organisation eo6 for distributed aggregation as to realise idiom oi2 . As idioms of an interaction pattern include variants in multiple conversation regulations, their interrelation and coherence can be dificult to observe. It is therefore crucial to get a global picture of the interrelated variations for all conversation regulations and idioms. For this reason, we introduce two types of refined UML class diagrams. Flow Variation Diagrams show all eService Capability Conversation Regulation elements with their dependencies as regards the flows of control that result from their Transition Variant elements for different idioms within each pattern context. Correspondingly, Aggregation Variation Diagrams show all eService Capability Interaction Regulation elements with their dependencies as regards organisational roles that result from Pattern Directive and Connection Variant elements for different idioms within each pattern context. These diagrams are shown in fig. 21 (middle and bottom) for the case of the PP e-service model. Note that the three types of diagrams in fig. 21 are formal counterparts of the informal diagrams used in the design phase (fig. 16, 17, 18). Modelling PP e-services as PIM results in a high-level VSSP regulation for respective virtual labs. In subsequent steps, the platform independent model needs to be transformed into a platform specific model with respect to software service interaction concepts that are specified in the PARIS metamodel. This transition mainly consists of extending the model with additional details and elements that are required for software service interaction patterns, coordination protocols and orchestration processes. The resulting VSSP PSM, or e-service schema, represents a coordinative regulation for virtual labs. In the pre-contact phase of virtual PP experiments, this regulation is used for the planning process of virtual laboratories, which includes publication, sighting and adaptation of model parts by participants of the strategic e-science network. In the contact-phase, the schema is rapidly adapted with respect to one of the idioms and an e-service instance is constructed and aggregated.
50
While UML-based models are well suited for interactive design, they are less suitable for tasks like verification or adaptation of e-service schemas or construction of e-service instances that need to be automated. Automated support of these tasks can be realised more effectively based on textual specifications of e-service schemas. As the PSM is based on the WfMC workflow reference model and the PARIS UML profile additionally builds on concepts of the XPDL schema, the natural form of textual specification is by means of the WfMC XML process language XPDL. In our implementation of the PARIS UML profile, we have integrated a code generator for XPDL-based e-service schema specifications. Listing 4.1 shows a little fragment of the generated VSSP specification that shows the Pattern Directive element ccr3-ic2_oi2-oi3. The fragment shows the specification of the two connection variants as XPDL tools with extended attributes to specify alternative idiom identifiers and correlation maps. out:ServiceId out:ExperimentSpecification out:ServiceId out:ExperimentSpecification
Listing 4.1: XPDL-Specification of Aggregation Variants in a Pattern Directive XPDL-based e-service schemas might be used for verification and adaptation of the VBSP. We have implemented tool support for both tasks. So far, verification is done with respect to the syntactical structure of XPDL-based e-service schemas. Adaptation builds on a rule based approach for XPDL transformation [ZP04]. While XPDL is generally an executable workflow language, its use for implementing capability composite software service systems as part of an e-service instance is compromised by its limited adoption in real world organisational information system infrastructure. XPDL was however specifically designed as a transfer format for workflow specifications. It is therefore
51
often possible to transform it into alternative execution languages of individual choice. For instance, we have refined the software service composition metamodel with respect to the Web Service technology platform and particularly to the BPEL Web Service orchestration language. Resulting XPDL-based e-service schema specifications can be used as input for a code generator that creates equivalent BPEL specifications. These can be used as configurations of BPEL-based Web Service composition middleware in order to realise e-service instances. The tool chain of XPDL generator, XPDL analyser, XPDL transformation rule engine and XPDL-based BPEL generator allows for flexible and rapid implementation of e-service instances from UML-based e-service schemas. In order for this mechanism to work seamlessly, at least transformation rules need to be defined in a separate specification (referenced by Transformation Ruleset elements) and we suggest our XPDL-specific transformation rule language for this purpose. Furthermore, complete automation of e-service adaptation requires additional separate specifications of non-functional idiom properties (referenced by QoS Property Set elements) and policies for idiom selection (referenced by Orchestration Policy Ruleset elements). Our architecture does not restrict the use of common policy languages for this purpose and practically, the choice might dependent on existing management technologies within organisational information system infrastructure.
5 Discussion and Related Work After introducing our proposal and demonstrating its utilisation in a case study experiment, we will now discuss the actual results of this work and put them in relation with similar research work of the scientific community.
5.1 Discussion of Results Based on earlier work on conceptual modelling of virtual business service production networks and their foundation of virtual business services and service processes, we have worked on service-oriented computing technologies for realisation of e-services and e-service management as technology classes for business services and service processes virtualisation. In this paper we have reported on our work to develop service-oriented e-service technologies that electronically represent business service interaction processes. As to this, it was our goal to develop technical solutions for modelling and design of architectural and executable descriptions of virtualised interaction process patterns and communication endpoints. In particular, these technologies had to allow for flexible description and ad hoc adaptation of architectural models as well as rapid construction of executable specifications. The results of our work constitute a service-oriented software architecture for e-services that can be used for modelling and design of flexible e-service schemas. In particular, this includes a fundamental model for service-oriented e-service systems, a holistic e-service metamodel and an UML profile for e-services. As we have demonstrated in our case study experiment, the service-oriented software architecture specified in the PARIS e-service metamodel can be adopted for virtual scientific service process that were required for virtualisation of e-science laboratories
52
in polymorph prediction research. In particular, PSM abstractions allowed designing a flexible and scalable e-service schema for coordinative regulation of virtual laboratories and the PARIS UML profile enabled its interactive graphical modelling. Furthermore, we have introduced XPDL-based e-service specifications that allow for automated analysis, adaptation and implementation of e-service schemas. Altogether, we have provided evidence that indicates the fitness of our technical solution for its intended purpose of supporting virtual business service production planning by means of modelling and designing service-oriented e-services.
5.2 Related Work The focus of this document is on utilising pattern-based, process-driven service-oriented software architecture for virtualising business services in order to support planning and control of virtual service enterprises. In particular, we have presented a solution for flexible modelling and design of service-oriented collaborative information systems that represent coordinative regulations of business service processes and allow for their rapid adaptation and enforcement. With respect to this focus, we will discuss related work in two areas. On the one hand side, we discuss modelling approaches for VO communication and coordination aspects that either address virtual service enterprises or build on service federation concepts. On the other hand, we discuss approaches to flexible modelling and design of interaction-based software architecture for collabotive information systems. 5.2.1 Modelling Communication and Coordination in Virtual Service Enterprises Generally, modelling aspects of VO communication and coordination is one aspect of a multitude of perspectives and levels in a holistic VO model [CMA06]. Respective enterprise engineering/system requirements or enactment models [LZK05] usually build on common classes of technical solutions. In particular, for hub-and-spoke, supply chain and peer-to-peer type VOs [KZL05], such approaches frequently consider service federation, workflow and agent interaction paradigms [CM05]. With respect to our own work, we are especially interested in those approaches that are related to general service networks because they either address service industries or utilise service federation technology. The first project to mention here is Fetish-ETF [CMAKC01] from the virtual enterprise area. It follows a peer-to-peer type VO approach for service providers of a tourism industry cluster. A promoter node utilises service market mechanisms for virtual enterprise initiation. He promotes services either in atomic form or as value added services. The latter build on general distributed business processes. An ICT infrastructure supports the organisational approach by mechanisms including service interaction, catalogues and workflow-based composition. An example of an infrastructure approach from the database area, that employs a system requirements model of business services, is the CrossFlow project [GAHL00]. Its background is the dynamic outsourcing of a part of the business process of a company to another company that provides this part as a service. The resulting bilateral supply chain organisation builds on service contracts. A crossorganisational workflow platform layer supports contract establishment, infrastructure
53
configuration, contract enforcement and infrastructure disposal. In an approach from the area of service engineering, the FRESCO project investigated system requirements models of business service collaboration and their implementation based on software service infrastructure [ZLP04]. The focus is on supply chain type organisation of b2b eCommerce scenarios that builds on a process-based model of business service collaboration. A service-engineering platform offers lifecycle support for definition, enactment and evolution of collaborative services. The platform implementation adopts Grid and Web Service interaction process technologies. The VO coordination approach in PRODNET II [CMPL01] builds on a complex process model and shows similarities to our virtual service processes. The process structure includes services as abstractions for coordination functionality on different hierarchical levels. The coordination approach materialises as an infrastructure layer that provides mechanisms to define and enforce coordination processes. The WebBIS [BMB+ 00] project employs a system requirements type service model with rule-based coordination concept. It introduces virtual enterprise services that specify and enforce their individual coordination logic by means of ECA rules. They group in communities that resemble a peer-to-peer type VO. A higher level service model is proposed in CMI [GSCB02]. Here, e-Services build on a model of service-oriented processes (SOP) for behavioural description. SOPs also model supply chain type VOs as multi-enterprise processes (MEP) that integrate and coordinate e-services and are executable by means of the collaboration management infrastructure (CMI). Overall, CMI introduces sophisticated models of system behaviour. Finally we mention the WISE project [LASS00] that proposed a service federation approach that not only considers system requirements but also management type models. It introduces virtual business processes to integrate services of members in trading communities that resemble supply chain type VOs. Integration follows a higher-level context of regulations named virtual enterprise. A workflow-based ICT infrastructure layer supports definition, enactment, monitoring and analysis of virtual business processes as well as some unstructured forms of communication and coordination. Overall, WISE offers a process-based structural and lifecycle model of virtual enterprises. Our own approach utilises service federation concepts to model communication and coordination in virtual service enterprises that classify as complex type of supply-chains overlaying hierarchical hub-and-spoke structures. As far as we know, none of the other modelling approaches for IT-based VO communication and coordination explicitly considers the specific characteristics of business services at this level. Furthermore, our approach introduces a flexible way to model service-oriented implementation variants for VO communication and coordination. Moreover, it offers high-level abstractions for their business-related design and enterprise engineering. Most of the other approaches do not explicitly model flexible variation of VO communication and coordination and none of the approaches represents the determinants of flexibility as abstractions on business level. 5.2.2 Flexible Modelling of Interaction-Oriented Software Architecture Several approaches from areas like workflow and business process modelling, serviceoriented computing and multi-agent systems are tackling issues of flexible software
54
architecture for distributed (information) systems that allows for agile or ad hoc adaptation of processes and interactions. We are especially interested in the aspects of flexible systems modelling and design as well as the use of pattern concepts to achieve this. Fundamentally, Baros et al. present a collection of informal service interaction patterns that describe the implementation of organisational collaboration scenarios by means of software service interaction processes [BDH05]. The patterns demonstrate the diversity of software service interaction processes in the context of organisational collaboration and provide requirements for respective modelling techniques. Zdun and Dustdar propose a technique for actual pattern-based modelling of process-driven service-oriented architecture [ZHD07]. They introduce informal software patterns to capture best practises of process-driven service integration. Furthermore, they identify the building blocks of these patterns and define respective pattern primitives as abstractions for individual serviceoriented architecture models. Such models explicitly refer to their patterns and might be subject to validation or generative development methods. Hofreiter et al. propose an approach for flexible modelling of generic business processes [HHW04]. The approach builds on the UN/CEFACT modelling methodology (UMM) that provides an UML profile for high-level business collaboration protocols and transactions. The authors extend this profile by OCL constraints and describe a technique to specify generic business process templates that can be parametrised and translated to enactment models for a variety of business cases. The StPowla approach of Gorton et al. aims at flexible high-level modelling of service interaction processes by means of combining concepts of workflow, policies and software services [GMRMSar]. It includes a basic workflow notation and utilises the policy language Appel for activity specification. The latter contain ECA rules that dynamically affect various system attributes and particularly facilitate software service selection, binding and invocation. Baresi et al. propose an approach that tackles workflow adaptation for the specific case of mobile environments [BMM05]. In particular, complex workflows implementing collaborative processes with mobile participants are partitioned as to optimise independence of the latter with respect to unstable communication links. Technically, workflow partitioning builds on rule-based transformation of BPEL graphs by means of attributed graph grammar. Modafferi et al. propose an approach for context-aware workflow applications that can adapt to conditions of the external environment [MBCP06]. The approach builds on a methodology for development of context-sensitive business processes. It includes language primitives to model contextsensitive regions of a process by means of context change patterns and transformation rules to construct BPEL processes from context-sensitive business processes. Udupi and Singh introduce a systems requirements type modelling approach for service interaction that includes pattern concepts [US08]. They focus on agreement and enactment of service engagements based on commitments of autonomous parties. Commitments of service engagements are combined as (virtual) organisations that include the policies of involved participants and determine their interactions. Specification of such engagements is guided by design-patterns. The approach materialises by means of a governance architecture [US07]. In our own approach of flexible business service interaction process modelling, we propose high-level interaction pattern abstractions, respective idioms of qualitative
55
differing orchestration variants and their policy-driven expploitation to adapt to requests of service clients. Like Baros, Zdun, Modafferi and Udupi, we build on the basic concept of capturing recuring problems of organisational collaboration by means of design patterns and like Zdun and Modafferi represent these as abstractions for individual models. Our approach to exploit non-functional characteristics of equivalent orchestrations is supported by the findings of Baresi. The main distinguishing factors of our work are the federated characteristic of our software service interaction patterns and in particular the structuring of interworking software sevice orchestrations as well as the explicit representation of variations as idiom abstractions on business level. Together, these factors mirror requirements of the virtual organisation domain that our work is exlusively targeting.
6 Summary and Outlook In this paper we have introduced a SOA model for virtual service enterprises. In particular, we have proposed an UML-based SOA metamodel for realisation of e-services that represent virtual service processes. Planning of virtual service processes by means of e-service modelling provides means to regulate coordination of cooperative activities in a service network. Concepts of service interaction patterns allow for flexibility of coordinative regulations as well as their rapid enforcement. We have also demonstrated the utilisation of our concepts and metamodels in the context of computational chemistry e-science. In particular, we have shown how to apply the PARIS e-service metamodel for design and specification of virtual e-science services processes that represent polymorph prediction experiments. Our current work concentrates on e-service management technology. We are refining GERAM [II03] to integrate e-service-management into the wider context service enterprises. The resulting framework defines an engineering approach to run virtual service enterprises by means of e-service technology. We are developing a service-oriented development methodology and implementing a tool set demonstrator for our e-service SOA that includes a model-driven development tool chain as well as an execution platform based on OGSA and BPEL.
References [ACK+ 04]
G. Alonso, F. Casati, H. Kuno, et al. Web Services - Concepts, Architectures and Applications. Springer, 2004.
[BDH05]
A. Barros, M. Dumas, and A.H.M. ter Hofstede. Service Interaction Patterns. In W. M. P. Van der Aalst, B. Benatallah, F. Casati, et al., editors, Business Process Management: Second International Conference, BPM 2004, Potsdam, Germany, June 17-18, 2004. Proceedings., volume 3649 of Lecture Notes in Computer Science, pages 302–318. Springer, 2005.
56
[BH02]
L. Baresi and R. Heckel. Tutorial Introduction to Graph Transformation: A Software Engineering Perspective. In A. Corradini, H. Ehrig, H.-J. Kreowski, et al., editors, Graph Transformation, First International Conference, ICGT 2002, Barcelona, Spain, October 7-12, 2002, Proceedings, volume 2502 of Lecture Notes in Computer Science, pages 402–429. Springer, 2002.
[BLTvdW01] F.P.M. Biemans, M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. Dealing with the Complexity of Business Systems Architecting. Systems Engineering, 4(2), 2001. [BMB+ 00]
B. Benatallah, B. Medjahed, A. Bouguettaya, A. Elmagarmid, et al. Composing and Maintaining Web-based Virtual Enterprises. In First VLDB Workshop on Technologies for E-Services, Cairo, Egypt, September 2000, pages 155–174. Informal Proceedings, 2000.
[BMM05]
L. Baresi, A. Maurino, and S. Modafferi. Workflow partitioning in mobile information systems. In E. Lawrence, B. Pernici, and J. Krogstie, editors, Mobile Information Systems, IFIP TC 8 Working Conference on Mobile Information Systems (MOBIS), 15-17 September 2004, Oslo, Norway, volume 158 of IFIP International Federation for Information Processing, pages 93–106, 2005.
[CM05]
L. M. Camarinha-Matos. ICT Infrastructures vor VO. In L. M. CamarinhaMatos, H. Afsarmanesh, and M. Ollus, editors, Virtual Organisations: Systems and Practices, pages 83–104. Springer, New York, 2005.
[CMA03]
L. M. Camarinha-Matos and H. Afsarmanesh. Designing the Information Technology Subsystem. In P. Bernus, L. Nemes, and G. Schmidt, editors, Handbook on Enterprise Architecture, International Handbooks on Information Systems. Springer, Berlin u.a., 2003.
[CMA06]
L. M. Camarinha-Matos and H. Afsarmanesh. Towards a Reference Model for Collaborative Networked Organizations. In W. Shen, editor, Information Technology For Balanced Manufacturing Systems, volume 220/2006 of IFIP Series, pages 193–202. Springer Boston, 2006.
[CMAKC01] L. M. Camarinha-Matos, H. Afsarmanesh, E. C. Kaletas, and T. Cardoso. Service Federation in Virtual Organizations. In George L. Kovács, Peter Bertók, and Géza Haidegger, editors, Digital Enterprise Challenges: LifeCycle Approach to Management and Production, IFIP TC5 / WG5.2 & WG5.3 Eleventh International PROLAMAT Conference on Digital Enterprise - New Challenges, November 7-10, 2001, Budapest, Hungary., IFIP Conference Proceedings 205, pages 305–324. Kluwer, 2001. [CMPL01]
L. M. Camarinha-Matos and C. Pantoja-Lima. Cooperation coordination in virtual enterprises. Journal of Intelligent Manufacturing, 12(2):133–150, 2001.
57
[Cor01]
H. Corsten, editor. Dienstleistungsmanagement. Oldenbourg, 2001.
[Die06]
R. Diestel. Graph Theory. Graduate Texts in Mathematics, Volume 173. Springer, third edition edition, 2006.
[DKS+ 03]
G. Drinkwater, K. Kleese, S. Sufi, L. Blanshard, et al. The CCLRC Data Portal. In S. Cox, editor, Proc UK e-Science All Hands Meeting 2003, pages 540–547. UK Engineering and Physical Science Research Council, 2003.
[EBCW05]
W. Emmerich, B. Butchart, L. Chen, and B. Wassermann. Grid Service Orchestration Using the Business Process Execution Language (BPEL). J Grid Comp, 3(3-4):283–304, 2005.
[EST00]
W. Eversheim, O. Schellberg, and O. Terhaag. Gestaltung und Betrieb von Produktionsnetzwerken. In B. Kaluza and T. Blecker, editors, Produktionsund Logistikmanagement in Virtuellen Unternehmen und Unternehmensnetzwerken, pages 35–59. Springer, Berlin, 2000.
[FP06]
D. Florian and B. Pernici. Insights into Web Service Orchestration and Choreography. Journal of E-business Research, 2(1):58–77, 2006.
[FWar]
G. Feuerlicht and A. Wijayaweera. Determinants of Service Resuability. In Proceedings of the 6th International Conference on Software Methodologies, Tools and Techniques, SoMet 07, November 7-9, 2007, Rome, Italy, Volume 161. IOS Press, 2008 (to appear).
[GAHL00]
P. Grefen, K. Aberer, Y. Hoffner, and H. Ludwig. CrossFlow: crossorganizational workflow management in dynamic virtual enterprises. Computer Systems Science and Engineering, 15(5):277–290, 2000.
[GMRMSar] S. Gorton, C. Montangero, S. Reiff-Marganiec, and L. Semini. StPowla: SOA, Policies and Workflows. In 3rd International Workshop on Engineering Service-Oirented Applications: Analysis, Design and Composition (WESOA’07), Vienna, Austria, September 17th, 2007. Springer, to appear. [GSCB02]
D. Georgakopoulos, H. Schuster, A. Cichocki, and D. Baker. Process-Based e-Service Composition for Modeling and Automating Zero Latency Supply Chains. Information Systems Frontiers, 4(1):33–54, 2002.
[Har03]
V. Harms. Prozessgestaltung bei Dienstleistungen. In W. Pepels, editor, Betriebswirtschaft der Dienstleistungen. nwb - Verlag Neue Wirtschaftsbriefe, Herne Berlin, 2003.
[HDA93]
J. R. Holden, Z. Du, and H. L. Ammon. Prediction of possible crystal structures for C-, H-, N-, O-, and F-containing organic compounds. Journal of Computational Chemistry, 14(4):422–437, 1993.
58
[HHW04]
B. Hofreiter, C. Huemer, and W. Winiwarter. OCL-Constraints for UMM Business Collaborations. In K. Bauknecht, M. Bichler, and B. Pröll, editors, OCL-Constraints for UMM Business Collaborations, volume 3182 of Lecture Notes in Computer Science, pages 174–185. Springer, 2004.
[Hol95]
D. Hollingsworth. The Workflow Reference Model. Technical Report TC00-1003, Workflow Management Coalition, 1995.
[II03]
IFIP-IFAC. GERAM: The Generalised Enterprise Reference Architecture and Methodology Version 1.6.3 (Final). In P. Bernus, L. Nemes, and G. Schmidt, editors, Handbook on Enterprise Architecture, International Handbooks on Information Systems, pages 21–63. Springer, Berlin u.a., 2003.
[Kos62]
E. Kosiol. Organisation der Unternehmung. , Wiesbaden, 1962.
[KZL05]
B. R. Katzy, C. Zhang, and H. Loeh. Reference Models for Virtual Organizations. In L. M. Camarinha-Matos, H. Afsarmanesh, and M. Ollus, editors, Virtual Organisations: Systems and Practices, pages 45–58. Springer, New York, 2005.
[LASS00]
A. Lazcano, G. Alonso, H. Schuldt, and C. Schuler. The WISE Approach to Electronic Commerce. International Journal of Computer Systems Science and Engineering, 15(5):343–355, 2000.
[LZK05]
H. Loeh, C. Zhang, and B. R. Katzy. Modeling for Virtual Organizations. In L. M. Camarinha-Matos, H. Afsarmanesh, and M. Ollus, editors, Virtual Organisations: Systems and Practices, pages 29–44. Springer, New York, 2005.
[MBCP06]
S. Modafferi, B. Benatallah, F. Casati, and B. Pernici. A methodology for designing and managing context-aware workflows. In Mobile Information Systems II; IFIP International Working Conference on Mobile Information Systems, (MOBIS) Leeds, UK, December 6–7, 2005, volume 191/2005 of IFIP, pages 91–106. Springer Boston, 2006.
[MF97]
P. Mertens and W. Faisst. Virtuelle Unternehmen: Idee, Informationsverarbeitung, Illusion. In A.-W. Scheer, editor, 18. Saarbrücker Arbeitstagung für Industrie, Dienstleistung und Verwaltung, pages 101–135. Physica-Verlag, Heidelberg, 1997.
[Mow97]
A. Mowshowitz. Virtual organization. Communications of the ACM, 40(9):30–37, 1997.
[NBC+ 04]
H. Nowell, B. Butchart, D. S. Coombes, S. L. Price, et al. Increasing the scope for polymorph prediction using e-Science. In S. Cox, editor, Proceedings of the UK E-Science All Hands Meeting 2004, Nottingham,
59
pages 968–971. UK Engineering and Physical Science Research Council, 2004. [OMG03]
OMG. Unified Modeling Language, v1.5. Technical Report formal/200303-01, Object Management Group (OMG), 2003.
[PG03]
M. P. Papazoglou and D. Georgakopoulos. Service-Oriented Computing: Introduction. Communications of the ACM, 46(10):24–28, 2003.
[PN98]
A. Picot and R. Neuburger. Virtuelle Organisationsformen im Dienstleistungssektor. In M. Bruhn and H. Meffert, editors, Handbuch Dienstleistungsmanagement, pages 513–534. Gabler, Wiesbaden, 1998.
[Pri04]
S. L. Price. The computational prediction of pharmaceutical crystal structures and polymorphism. Advanced Drug Delivery Reviews, 56(3):301–319, 2004.
[PvdH06]
M. P. Papazoglou and W.-J. van den Heuvel. Service-Oriented Design and Development Methodology. Int. J. on Web Engineering and technology, 2(4):412–442, 2006.
[SK00]
D. Specht and J. Kahmann. Regelung kooperativer Tätigkeiten im virtuellen Unternehmen. In H. Albach, D. Specht, and H. Wildemann, editors, Virtuelle Unternehmen, ZfB Ergänzungsheft 2/2000, pages 55–74. Gabler, Wiesbaden, 2000.
[SLvdW02]
M.W.A. Steen, M.M. Lankhorst, and R. G. van de Wetering. Modelling Networked Enterprises. In A. D. Williams, editor, Proc. Sixth International Enterprise Distributed Object Computing Conference EDOC2002, September 17-20 2002, Lausanne, Switzerland, pages 109–119. IEEE Computer Society, Los Alamitos, California, 2002.
[Syd92]
J. Sydow. Strategische Netzwerke: Evolution und Organisation. Gabler, Wiesbaden, 1992.
[US07]
Y. B. Udupi and M. P. Singh. Governance of Cross-Organizational Service Agreements: A Policy-Based Approach. In Proceedings of the 4th IEEE International Conference on Services Computing (SCC’07), Salt Lake City, Utah, pages 36–43, 2007.
[US08]
Y. B. Udupi and M. P. Singh. Design Patterns for Policy-Based Service Engagements. Technical Report TR-2008-3, Department of Computer Science, North Carolina State University, 2008.
[vdAvH02]
W. M. P. van der Aalst and K. van Hee. Workflow Management: Models, Methods, and Systems. Cooperative Information Systems. MIT Press, Cambridge u.a., 2002.
60
[WBE04]
P. Wilson, J. Brodholt, and W. Emmerich. Leveraging High Throughput Computing for UK eScience with Very Large Condor pools: Demand for transforming untapped power into results. In S. Cox, editor, Proceedings of the UK E-Science All Hands Meeting 2004, Nottingham, pages 308–315. UK Engineering and Physical Science Research Council, 2004.
[WfM02]
WfMC. Workflow Process Definition Interface – XML Process Definition Language 1.0 Final Draft. WfMC Specification WFMC-TC-1025, Workflow Management Coalition (WfMC), 2002.
[WPLC95]
D. J. Willock, S. L. Price, M. Leslie, and C. R. A. Catlow. The relaxation of molecular crystal structures using a distributed multipole electrostatic model. Journal of Computational Chemistry, 16(5):628–647, 1995.
[ZE07]
C. Zirpins and W. Emmerich. Virtual Organisation by Service Virtualisation: Conceptual Model and e-Science Application. Research Notes RN/07/07, University College London, Dept. of Computer Science, 2007.
[ZE08]
C. Zirpins and W. Emmerich. Service-Oriented Development of Virtual Business Services. Research notes, University College London, Dept. of Computer Science, to appear 2008.
[ZHD07]
U. Zdun, C. Hentrich, and S. Dustdar. Modelling Process-Driven and Service-Oriented Architectures Using Patterns and Pattern Primitives. ACM Transaction on the Web, 1(3):14:1–14:44, 2007.
[Zir07a]
C. Zirpins. A Conceptual Model for Virtual Service Enterprises. In P. Kommers, editor, Proceedings of the Iadis International Conference E-Society 2007, Lisbon, Portugal July 3-6, 2007, pages 129–136. IADIS Press, 2007.
[Zir07b]
C. Zirpins. PARIS Project. zirpins/paris/, 2007.
[ZLP04]
C. Zirpins, W. Lamersdorf, and G. Piccinelli. A Service Oriented Approach to Interorganisational Cooperation. In M. Mendes, R. Suomi, and C. Passos, editors, Proceedings IFIP International Conference on Digital Communities in a Networked Society: eCommerce, eBusiness, and eGovernment (I3E) 2003, pages 307–318. Kluwer, Boston, 2004.
[ZP04]
C. Zirpins and G. Piccinelli. Evolution of Service Processes by Rule Based Transformation. In W. Lamersdorf, V. Tschammer, and S. Amarger, editors, Proceedings IFIP International Conference on Digital Communities in a Networked Society: eCommerce, eBusiness, and eGovernment (I3E) 2004, pages 287–305. Kluwer Academic Publishers, Boston Dordrecht London, 2004.
http://www.cs.ucl.ac.uk/staff/c.
61
