Currently I am working as a [[post-doctoral researcher|]] at the computer science department of the Helsinki University where I work in the [[SOAMeS-project|]].\n\nEarlier, I was working as a PhD researcher at the [[Information Systems Department|]] of the [[TU-Eindhoven|]]. The concept of eSourcing is the result of my ongoing research and an integral part of the EU research project called [[CrossWork|]]. Contact details are contained on my [[web site|]].
The figure contained in the [[Interaction dimensions]] shows the //assignment// dimension, which focuses on the way a service provider is determined for an eSourcing configuration. The values on the //assignment// dimension state to which degree the collaborating parties know at the beginning of an interaction, that they collaborate with each other during enactment time of an inter-organizational business process configuration.\n*//Static// assignment means the collaborating parties already know before setup time they surely collaborate with each other. \n*On the other hand, //dynamic// assignment means the collaborating parties bid in an anonymous and completely open market for service provision and/or consumption and only towards the end it is clear who collaborates during enactment. \n*In the //semi-dynamic// case, the number of collaborating parties that engage in a setup phase is limited at the beginning and therefore known. However, only at the end of the setup phase it is clear who collaborates.
The refined auction service of the trusted third party is depicted in below. In the auction service component the contained bidding library stores bids that are committed and retrieved by a bid manager. This component is communicating with the contracting-client component that places and retrieves bids from the bidding library. As described earlier, the bid manager is exchanging bid- and service data with the template-search-engine component of the service broker. \n\n[img[eSRA_third_level|arch_3rd_auction.jpg]]\n\n
''Problem:'' The service consumer is interested in using service provision. However, the consumer does not mind how the provision is carried out as long as the specified exchanges are performed correctly. \n[img[black-box pattern|buildVisibilityBlackBox.jpg]]\n''Description:'' In the case of black-box visibility, only the interfaces of the consumer sphere are focused on. These interface places must be equally contained with identical labels in the consumer sphere and the provider sphere. It is not permitted for any sphere of the external level or the respective conceptual levels to have a deviating set of interface places or differing labels. The opposing eSourcing parties are not aware of other details in the consumer sphere and the provider sphere since the contractual spheres only contain interface places with their labels. Thus, the provider sphere may otherwise completely deviate from the consumer sphere provided the similar interface places are serviced correctly according to their labels.\n''Forces:'' When only the interfaces of a contractual sphere are given, the service provider might struggle to fill the provider sphere with process content. During the enactment of an eSourcing configuration the consumer might experience service provision that is counter productive.\n''Examples:''\n*A travel agency organizes journeys abroad for arbitrary customers. Such a travel package consists of booking a trip, finding a hotel, renting a car, and so on. The travel agency does not specialize on negotiating and ordering affordable hotel bookings. As a result such a service is sourced in from service brokers where providers are registered who know the market and have special agreements with hotels in proximity. Since the concrete procedures of finding and booking most suitable hotels differs from country to country, the travel agency merely discloses the interfaces for starting and ending the hotel-booking service.\n*In the figure above, an abstract example of a black-box pattern is presented. The //in// and //out//-labeled interface places are fully disclosed in the contractual sphere. Consequently these interface places are also part of the provider sphere. However, it is depicted that all transitions contained in the consumer sphere and the provider sphere have a //tau// label, which means the eSourcing counterparts are not aware of the other's process content. Additionally, the figure above depicts that control-flow constructs in both conceptual-level spheres are different. These differences do not result in soundness problems as long as the interface places are adhered to. The reason is that the consumer sphere and the provider sphere are [[WF-nets|]] when the //in// and //out//-labeled interface places are removed.
The refinement of the CE translator depicts a CE projector component that is performing projections between the conceptual and external levels. To perform that function, the CE projector uses a rules database. The figure below shows several bidirectional arcs to the CE-projector of which some are related to each other. The rules- and process-modeler components exchange contractual rules and workflow sniplets and composed processes via the CE projector with the contracting client on the external level. The global rules engine receives contractual rules from the CE projector through which rules- and events data is exchanged via the rules- and events data exchanger down to the local rules engine on the internal level. \n\n[img[eSRA_third_level|arch_3rd_CEtranslator.jpg]]\n\nThe figure above depicts a detailed exchange between the CE projector and components of the global WFMS. The enactment engine receives contractual spheres from the service consumer or provider respectively. During enactment, an exchange occurs for enabling local the enactment [[Monitorability]] and the [[Conjoinment]] monitor. The latter two components exchange events- and production data via the CE projector and the workflow/events data exchanger down to the local enactment monitor and conjoinment monitor that are located on the internal level of the reference architecture.
The refinement of the CI translator in the figure below depicts a similar setup as for the [[CE translator]]. However, the information exchange to neighboring components differs. The CI translator contains a CI projector component that projects information between the conceptual and internal level. To do so, a projection-rules database is exchanging rules with the CI projector. With respect to information exchange between the CI translator and its environment, different subsets of arcs depicted in the figure below are related to each other. \n\n[img[eSRA_third_level|arch_3rd_CItranslator.jpg]]\n\nThe CI projector receives contractual rules from the rules modeler, and in-house processes and refined spheres from the process modeler. The contractual rules are projected to the local rules engine of the internal level. Furthermore, the in-house processes and refined spheres are also projected to the internal level where a process database stores them until the local WFMS loads the processes for enactment. To coordinate the local WFMS and rules engine\sindex{Rules engine} with corresponding components on the external level, the CI projector transfers production, rules, and events data between the internal and external levels of the reference architecture.\n
between the in-house process and the consumer sphere (see [[eSourcing example]]) is projected to the external level. Consequently the provider's contractual sphere contains equal conjoinment constructs that result in transitive exchanges during enactment between the in-house process and the provider sphere of the service provider. This way the basis for exchange is established across the domains from the service provider to the consumer and vice versa. \n*//One-directional// conjoining implies that there is one //out-// or //in//-labelled interface place present that is either complemented by an active send node or an active receive node respectively. Those active send and receive nodes are contained in the spheres of a Sourcing configuration and handle the exchange between the domains of a service consumer and provider. \n*//Bi-directional// conjoining is initiated by a sending active node to the domain of the Sourcing counterpart that returns the communication exchange immediately to the initiating Sourcing party. \nSee also ConstructionPatterns.
it needs to be stated that all four conjoinment patterns are exposed to the same forces. When a conjoinment construct is chosen, the performance characteristics of an exchange during enactment is influenced by incorporated monitorability patterns. Depending on the conjoinment direction, the //out// and //in//-labelled interface places need to be linked with monitorability arcs. If messaging is applied, token propagation (see TokenPropagationPattern) is suitable and if polling is applied, token takeover (see TokenTakeoverPattern) is appropriate. However, such a monitorability choice influences the speed of conjoinment enactment. If token takeover is used, the defined polling period potentially postpones the conjoinment until the next polling interval starts. If token propagation is chosen, the conjoinment across eSourcing domains is started immediately. However, it is possible that the //R//, //RT//, or //B//-labelled conjoinment node is not yet enabled for responding to the conjoinment exchange.\n\nLet us assume equally labelled conjoinment nodes are part of the consumer sphere, the respective contractual spheres, and the provider sphere. If these active nodes are linked for life-cycle monitorability (see LifeCycleMessagingPattern and LifeCyclePollingPattern) then conjoinment construction fails during build time if the lower level life-cycles can't be semantically matched. Furthermore, just as in the case of linking //out// and //in//-labelled interface places, the speed of enacting conjoinment nodes varies depending on the type of employed monitorability links.
An extra notation for active nodes is used for further discussing the conjoinment dimension of eSourcing. By using this notation, particular features of conjoinment patterns become apparent. The active nodes of the figure below either receive a message, send a message, or receive and send a message consecutively. Such nodes can either be transitions that fire immediately when enabled or they contain more elaborate life cycles (see LifeCycleMonitoring). \n[img[conjoinment notation|conjoinmentNodes.jpg]]\nIn order to make those distinctions visible, additional labels are depicted in the figure above that are carried by the shown nodes. The labels //S//, //R//, //B// are for active nodes with lower level life cycles where the first is sending or initiating an exchange, the second receives or accepts an exchange, and the latter is bidirectional, i.e., the node needs to accept an exchange before it is enabled to initiate a counter exchange after firing. The labels //ST//, //RT//, //BT// are for active nodes that are transitions without any contained life cycle where the first is for an exchange-initiating transition, the second an exchange-accepting transition, and the latter node is a bi-directional transition that needs to accept an exchange before an exchange is initiated in response.
The approach of investigating [[DIBPM]] by looking at features within different, related perspectives is represented in the figure below. A cube is depicted, created by three axis representing different eSourcing dimensions on which further detailing values are positioned. Each of those values creates a taxonomy and is guiding for later pattern discovery. The created multi-dimensional space permits the positioning of eSourcing configurations. In the figure below the black circles on the walls of the cube stand for dimension-value instances,i.e., [[patterns|]], that are employed to create a eSourcing configurations.\n[img[Multi-dimensionalspace of construction patterns|sourcingDimensions.jpg]]\nThe depicted construction dimensions\n*[[Contractual visibility]]\n*[[Monitorability]]\n*[[Conjoinment]] \ncreate a perspective cube for positioning eSourcing configurations. Simultaniously the dimensions group ConstructionPatterns.
Below, the [[patterns|]] are listed in groups that correspond to the [[Construction dimensions]] of eSourcing:\n\n__[[Contractual visibility]]__\nThe figures of patterns in this category, only contain two levels, namely the service provider and consumer conceptual level, and the external level (see [[eSourcing example]]). The reason is that the consumer and provider contractual spheres always need to be isomorph for representing a consensus. Thus, depicting both contractual spheres does not add to the specification of contractual-visibility patterns. \n\nFurthermore, if the consumer contractual level only the sphere is depicted and the rest of the in-house process omitted as the content of the in-house process has no influence on the type of contractual-visibility pattern. Finally, when an active node is depicted with a Greek //tau//-label in a consumer sphere or a provider sphere, it means the eSourcing counterpart is not aware of this active node during the build time and the enactment of an eSourcing configuration. During build time the eSourcing counterpart is not aware because a //tau//-labeled active node is not projected to the external level and during enactment the counterpart is not aware since the effects of enacting a //tau//-labeled active node are hidden from the counterpart.\n1. [[BlackBoxPattern]]\n2. [[WhiteBoxPattern]]\n3. [[GreyBoxPattern]]\n\n__[[Monitorability]]__\nTo understand patterns of this category, the nature of LifeCycleMonitoring needs to be introduced.\n4. [[TokenPropagationPattern]]\n5. [[TokenMessagingPattern]]\n6. [[TransitionMessagingPattern]]\n7. [[LifeCycleMessagingPattern]]\nThe following patterns focus on different ways of //polling// changes during the enactment of an eSourcing configuration. Those polled changes help one eSourcing party to monitor and mirror the enactment progress of the opposing eSourcing party.\n8. [[TokenTakeoverPattern]]\n9. [[TokenPollingPattern]]\n10. [[TransitionPollingPattern]]\n11. [[LifeCyclePollingPattern]]\n\n__[[Conjoinment]]__ \nFor this dimension a ConjoinmentNotation must be explained. These nodes are used in the depictions contained in the patterns below. Every pattern specification includes a visualization that consists of two parts. The top shows the conceptual-level in the consumer domain consisting of an in-house process with a contained consumer sphere (see [[eSourcing example]]). Due to the requirement of well-directedness (see [[eSourcing control-flow specifics]]) the conjoinment pattern of the top figures is replicated in the contractual spheres and the refined sphere. Thus, for sake of brevity a depiction of the external level and the provider's conceptual level are omitted. If the labels of conjoinment nodes in the top depictions are in brackets, then the service provider is not aware of them as they are part of the in-house process. The same is true for active nodes that carry a //tau//-label. The bottom of the pattern figures show pattern variations that employ different types of conjoinment nodes (see ConjoinmentNotation). The specified conjoinment patterns do not contain a description of related forces as they are similar. Instead the forces are given towards the end of this section.\n12. [[ProviderInitiatedOneDirectionalPattern]]\n13. [[ConsumerInitiatedOneDirectionalPattern]]\n14. [[ProviderInitiatedBiDirectionalPattern]]\n15. [[ConsumerInitiatedBiDirectionalPattern]]\n Finally, all conjoinment patterns are exposed to comparable ConjoinmentForces.\n
''Problem:'' The consumer needs to initiate an exchange with the service provider. However, the provider is immediately responding to the opposing eSourcing domain. Such bi-directional information exchange must not endanger the correct termination of an eSourcing configuration.\n''Description:'' A sending conjoinment node that is part of the in-house process outside of the consumer sphere, is connected to a port through which information is injected into eSourcing spheres. This port is connected to a bi-directional conjoinment node that is replicated in all spheres of to the same eSourcing configuration. The latter conjoinment node responds with information that is sent through another port back to the domain of the service consumer. Finally, a receiving conjoinment node located in the in-house process outside of the consumer sphere serves as a recipient for the information that is delivered through the second port.\n[img[bi-directional consumer initiated pattern|biDirectionalConsumerProviderConsumer.jpg]]\n''Example:''\n*A broker deals with a customer who wants to buy a house. While the process of finding a suitable house is on the way, in parallel a service provider deals with the financial matters related to providing a mortgage. For example, the service provider first needs to evaluate whether the customer of the broker is free of debts. At some point a house is found and the broker exchanges details about the price to the service provider. Based on the evaluated credit-worthiness, the provider needs to respond immediately whether a mortgage can be granted for purchasing the house. Based on the response, the broker goes ahead to offer the house or recommends that the customer needs to look for a less expensive house. \n*The top of the figure above depicts an in-house process that contains a sending and receiving conjoinment node. The first node carries a //S// label and the latter node a //R// label. The sending node has a passive output node that is an //in//-labeled interface place, which denotes an information exchange into a consumer sphere takes place. This interface place serves as a passive input node for the bi-directional conjoinment node in the depicted consumer sphere. A contained //B//-labeled node produces an immediate response by placing a token in an //out//-labeled interface place. The latter interface place is a passive input node for the //R//-labeled receive node contained in the in-house process. Since the //R// and //S//-labeled conjoinment nodes are positioned outside of the sphere, the provider's provider sphere does not contain equally labeled conjoinment nodes. Instead the //in// and //out//-labeled interface places are part of all spheres involved in the eSourcing configuration. Consequently, a //B// or //BT//-labeled conjoinment node is part of the provider sphere.
''Problem:'' The eSourcing parties need to reach consensus on an information exchange directed from the consumer domain to the provider domain. Such an exchange should not endanger the correct termination of the overall eSourcing configuration.\n''Description:'' In the domain of the service consumer a sending conjoinment node that initiates information exchange to the domain of the service provider, is part of an in-house process outside of the consumer sphere. Such a transition is connected to a port through which information is injected into the spheres of the eSourcing configuration. The input port is followed by a node that receives this information and which is located in the consumer sphere, the respective contractual spheres, and the provider sphere.\n[img[one-directional consumerinitiated pattern|oneDirectionalConsumerInitiated.jpg]]\n''Examples:''\n*In alignment with the first business example given in ProviderInitiatedOneDirectionalPattern, the exchange is now directed from the OEM to the service provider who delivers engines for truck production. The produced trucks may individually vary depending on customer demand. Thus, for every engine that is produced by the provider, the adjusted engine specifications must be communicated as input to the provider. That way the overall eSourcing configuration is stable from a process point-of view. However, it is possible to adjust the engine production in a flexible way to requested engine variations. \n*The consumer's in-house process is depicted in the fgure above where it has a sending conjoinment node equipped with an //S// label in brackets and a passive output node that is an //in//-labeled interface place. This interface place in the domain of the service consumer serves as a passive input node for a receiving conjoinment node contained in the consumer sphere. In the figure above that latter node carries an //R// label. Due to well-directedness, the //in//-labeled interface place is replicated and contained in the provider sphere of the service provider. During enactment of the overall eSourcing configuration an exchange is carried out that is initiated by the consumer and accepted by the provider. If data flows along such control flow that is verified for soundness, it is likely that the exchange from the domain of the service consumer to the provider does not create problems.
This dimension is focusing on how much process detail is disclosed at build time of an eSourcing configuration. In the figure of the [[eSourcing example]] a consensus exists since the consumer contractual sphere and the provider contractual sphere are isomorph. Three values are located on the contractual-visibility dimension of the [[Construction dimensions]]. \nThe values are regarding the amount of nodes from the conceptual level that are projected to the contractual sphere of the external level.\n*First, a //white-box// value means that all nodes of a consumer sphere are contained in the contractual sphere of the external level. \n*In case of a //black-box// classifier only the interfaces of a consumer sphere are projected to the contractual level. \n*Finally, the //grey-box// classifier means the interface places and a subset of the nodes and arcs of the consumer sphere are projected to the external level's contractual sphere. \nSee also ConstructionPatterns.\n\n
Achieving sustainable growth and improving competitiveness in increasingly complex and dynamic market environments requires businesses to build agile partnerships and alliances. Market demands can only be satisfied within dynamic networks of collaborating organisations. True collaboration inside such networks requires tight but flexible integration of business processes.\n\nIn [[|]] we focus on distributed, cross-organisational development processes in the automotive industry, forming Networks of Automotive Excellence (NoAE). The main project objective is the development of mechanisms for automated workflow formation and enactment, enabling NoAE. Our technological approach is based on Multiagent Systems (MAS), introducing the paradigm of distributed & decentralised decision making in Workflow Management Systems (WfMS).\n\nIn contrast to state-of-the-art WfMS we avoid statically linked workflows, but let workflows form dynamically. The flexible mechanisms of CrossWork also handle exceptions during the enactment phase, resulting in dynamic workflow adaptations. To facilitate automated share and exchange of information across organisational boundaries we will develop a machine-readable representation of domain and workflow knowledge (an ontology). A novel enterprise modelling framework, supporting the automated formation of cross-organisational workflow models, will result in less effort for development, maintenance and adaptation of enterprise models, which is of specific interest for SMEs. Automatically generated user interfaces will allow users to acquire hands-on-experience which leads to improved local workflow models.\n\nOur business objectives are improved overall process quality (through enabling selection and integration of best-of-class network partners), reduced transaction costs and information flow-time (due to fast and effective integration of network partners), and improved flexibility with an open platform architecture and exception handling mechanisms.
Since eSourcing is embedded in DIBPM, a model is required to manage the complexity resulting from matching and subsequently enacting inter-organizational processes. A definition of DIBPM is given as follows:\n\n//A dynamic inter-organizational business process is formed dynamically by the (automatic) integration of the subprocesses of the involved organizations. Here dynamically means that during process enactment collaborator organizations are found by searching business process market places and the subprocesses are integrated with the running process.// \n\nNote that at least one organization involved in DIBPM must expose explicit control-flow structure of its business process. Related issues to DIBPM are the definition and identification of processes, the way compatible business partners find each other efficiently, the dynamic establishment of inter-organizational processes, and the setup and coupling for process enactment. In order to manage such complex issues, a [[three-level framework]] is a suitable model.
The data-flow definitions of eSML are modeled after [[specified patterns|]] that were extracted from evaluating intra-organizational workflow systems. The first line below shows the eSML schema definition that refers to the main parts of the data-flow definition.\n{{{\n<xs:element name="data_definition_section" type="list_of_data_packages" minOccurs="0"/>\n\n<data_definition_section>\n <!-- Data:IntierOrderPreparation -->\n <data_package>\n <package_id>IntierOrderPreparationRequest</package_id>\n <document_section>\n <document>\n <document_id>MANwaterTankSpecification</document_id>\n <name>MHwaterTankSpecification</name>\n <uri></uri>\n </document>\n </document_section>\n </data_package>\n</data_definition_section>\n}}}\nThe example code below the eSML schema line shows a data-package definition. Such data packages contain variable and document definitions that flow through a process (see task definitions of SpecifyingValueExchanges), however, in the water-tank case only documents are defined. The packages are input and output of tasks and can be passed between the organizational domains of collaborating parties.
On the external level of a Sourcing configuration, the eSML file contains a definition of parties that intend to collaborate. Below the first line shows the eSML schema definition for party specification shows there is no limitation of parties in an eSML file. In a party definition company information is specified using regular variable elements and attributes if the schema.\n{{{\n <xs:element name="party" type="company_info" maxOccurs="unbounded"/>\n <party>\n <company_data>\n <var_section>\n <string_var tag_name="CompanyName" var_id="Intier" changeable="false" enabled="enabled">Intier Automotive</string_var>\n <string_var tag_name="RegisterNr" var_id="registerIntier" changeable="false" enabled="enabled">119876h11</string_var>\n <string_var tag_name="BankName" var_id="bankNameIntier" changeable="false" enabled="enabled">HypoBank</string_var>\n <integer_var tag_name="BankNr" var_id="bankNrIntier" changeable="false" enabled="enabled">2687295</integer_var>\n <string_var tag_name="ContactPerson" var_id="ContactPersonIntier" changeable="true" enabled="enabled">Alfons Weinreich</string_var>\n </var_section>\n </company_data>\n <company_contact_data>\n <var_section>\n <string_var tag_name="MailAddress" var_id="mailIntier" changeable="true" enabled="enabled">Taunusstraße 27, 80807 München</string_var>\n <string_var tag_name="Tel" var_id="tel1Intier" changeable="true" enabled="enabled">+49 (0) 89 444449-900</string_var>\n </var_section>\n </company_contact_data>\n <resource_section>\n <role>\n <name>IntierOrderPreparer</name>\n </role>\n <role>\n <name>IntierWaterTankAssembler</name>\n </role>\n </resource_section>\n </party>\n}}}\n\nBelow the first schema line, an example of a party definition is given. In the contained variable section various data can be specified in a flexible way. Furthermore, roles are defined that can be filled by employees during enactment. These roles are used in the value-exchange part (see SpecifyingValueExchanges) of an eSML file for the executor attributes of task nodes.
The second dimension depicted in the figure contained in [[Interaction dimensions]] is named //direction// and focusses on the degree of external-level harmonization of inter-organizational business process collaboration. Thus, the interaction between collaborating parties may either start with a harmonization at the beginning of a setup phase or perform harmonization at the end. \n*//Internal-to-external// assignment direction means the collaborating parties have internal processes that are only harmonized externally at the end of their setup interaction.\n*Likewise, the assignment direction //in-sourcing// means a service provider has a service that is subsequently integrated into the process of a service consumer. Thus, external harmonization is only performed at a later stage.\n*//Out-sourcing// is similar to in-sourcing with respect to harmonization. However, now the consumer starts the interaction with externalizing a service demand first.\n*Finally, //the external-to-internal// dimension means that external harmonization is the starting point of interaction and the collaborating parties set up internal processes at a later stage just before enactment starts.
A. Norta\n[[Exploring Dynamic Inter-Organizational Business Process Collaboration|]]\nPhD thesis, Beta Research School for Operations Management and Logistics, 2007. Eindhoven, The Netherlands.\n\nNorta and P. Grefen\n[[Discovering Patterns for Inter-Organizational Business Collaboration|]]\nAccepted for publication in the International Journal of Cooperative Information Systems(IJCIS)\n(PREPRINT VERSION)\n\nA. Norta and P. Grefen\n[[A Framework for Specifying Sourcing Collaborations|]]\nAccepted paper for: 14th European Conference on Information Systems\nGothenburg, Sweden, June 12-14, 2006\n\nA. Norta and P. Grefen\n[[Discovering Patterns for Inter-Organizational Business Collaboration in a Top-Down Way|]]\nBETA Working Paper Series, WP 163, 2006\nEindhoven University of Technology, Eindhoven\n\nA. Norta and P. Grefen\n[[Developing a Reference Architecture for Inter-Organizational Business Collaboration Setup Systems|]]\nBETA Working Paper Series, WP 170, 2006\nEindhoven University of Technology, Eindhoven\n\nA. Norta, M. Hendrix, and P. Grefen\n[[A Pattern-Knowledge Base Supported Establishment of Inter-Organizational Business Processes|]]\nIn R. Meersman, Z. Tari, and P. Herrero, editors,\nProceedings of On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops, Volume 4277 of Lecture Notes in Computer Science, pages 834-843.\nSpringer-Verlag, Berlin, 2006.\n\nA. Norta\n''Web Supported Enactment of Petri-Net Based Workflows with XRL/flower''\nAccepted paper for: 25th International Conference on Application and Theory of Petri Nets\nBologna, Italy, June 21-25, 2004
''Problem:'' For a part of the overall in-house process, an organization intends to externalize this process part to find a Sourcing counterpart. However, it is not clear who the best counterpart is. Thus, the service-externalizing organization wants to see the prospective candidates engage in a competition for service collaboration.\n''Description:'' An organization externalizes its service to a public broker that functions as an anonymous process-market place for the purpose of engaging in a business collaboration. Other organizations may evaluate the published process and decide to engage in a bidding for service. The service-externalizing organization chooses the offer and rejects all other.\n[img[dynamic-assignment pattern|dynamicAssignmentExample.jpg]]\n''Forces:'' The publicly available process broker needs to be equipped with a directory that allows service consumers to correctly file their process according to attributes like, e.g., the type of industry, geographic location, language, and so on. With the help of a search engine, potential service providers must be able to find those filed processes. Furthermore, it must be ensured that bids and eventually bid acceptance and bid rejections can be communicated between the potential service providers and the consumer. If the consumer happens to be confronted with a big number of provision bids, tool support must permit the evaluation of those bids in an efficient and effective way.\n''Examples:''\n*A travel agency carries out the booking of a trip for a customer who needs to travel to a capital city. The overall booking comprises a flight ticket, a hotel, and renting a car. However, the hotel booking is carried out by a different company that is actually located in the capital city and therefore has the appropriate expertise. Thus, the travel agency submits the part of the in-house process to a public broker as a request for service provision. Many potential service providers start bidding and the travel agency chooses the best deal and rejects all other offers.\n*In the figure above a possible setup phase is depicted that uses a dynamic-assignment pattern for creating an eSourcing configuration. First, the service consumer creates an in-house process and defines a consumer sphere in it. Next, the consumer sphere is projected to a publicly available service broker that can be searched by potential service providers. Thus, interested parties place bids for service provisions that are evaluated by the service consumer. The latter party chooses a service provider that represents the best deal and rejects all other offers. After that interaction blocks termed contracting, verifying, monitorability negotiation, and enactment follow that contain interaction sequences similar to the figure contained in StaticAssignmentPattern.
In the figure below, the eSourcing middleware of one collaborating party is depicted. The eSourcing counterpart contains the same second level components, however, for sake of brevity only the relationship between the coordination-interface components is depicted. Furthermore, the figure below shows the trusted-third-party component as a white box and its relationship with the Sourcing-middleware component. A dashed arc between the trusted-third-party component and the Sourcing-middleware is an abstraction of more detailed information exchange that is described in SecondLevel. \n\n[img[eSRA_second_level|arch_2nd_parties.jpg]]\n\nIn the trusted-third-party component several refining components are contained. The contracting client component provides support for the management of an e-contracting process. Concretely, the contracting client semi-automatically assembles services by using workflow sniplets that are stored in a corresponding database of the trusted third party. That way the workflow sniplets may be communicated between collaborating organizations. Depending on whether a collaborating party slips into the role of a service consumer or service provider, the contracting client submits or retrieves contractual spheres from a service broker. If a submitted service contains the definition of a concerned party, a submission notification is sent out from the service broker. If several parties are interested in the same service, a bid can be placed with the auction service. The latter component relates the bid data with services stored in the service broker. Finally, when an eSourcing configuration is established, the collaborating parties send their in-house processes and refined spheres to a verifier component for testing the correct termination, i.e., the soundness (correct termination), of the overall eSourcing configuration. The verification results are returned to the collaborating parties. By having a trusted third party perform the verification, the collaborating parties do not have to disclose their internal business details to each other. \n\nWhen an eSourcing configuration is established, the contracting client distributes the business rules and the processes contained in the contract to the global rules engine and the workflow management system (WFMS) respectively. In order to synchronize the global WFMSs and global rules engines in the Sourcing-middleware components of other collaborating parties, events-, production-, and rules data is communicated via a coordination interface. Production data is for example the specification of a product or data needed for condition statements. Furthermore, the global WFMS and rules engine also exchange production-, and event data with each other. \n\nFinally, the contracting client sends workflow sniplets and composed processes and contractual rules to the translator. That way the workflow sniplets and composed processes and contractual rules are prepared for the heterogenous system environment that exists on lover internal levels of a collaborating party. Also the global WFMS and rules engine send data to the translator component that is depicted as a white box in TranslationExternalInternalRefinement. \n\n
''Problem:'' Two parties want to establish a [[B2B|]] supply chain without existing constraints resulting from historically grown business processes in their own domains.\n''Description:'' The service consuming and providing organizations start with negotiating process properties on an external level. When they have reached consensus, both parties take over the publicly agreed upon process for their internal domains. In the domain of the service consumer the adopted process becomes a subnet of a bigger in-house process, while in the service provider's domain further refining process steps are inserted. \n[img[iexternal-to-internal pattern|externalToInternalAssignmentExample.jpg]]\n''Forces:'' A service broker can not be employed if there is no published service offer available in the beginning. Thus, it might be a problem to find a collaborating party. Furthermore, integrating the externally agreed process might fail because of an inadequacy of internal resources, e.g., the organizational structure turns out to mismatch, no employees have the appropriate skills for carrying out certain tasks, required production resources might be lacking, and so on.\n''Examples:''\n*An IT company intends to develop an innovative software package for a leading telecom enterprize. For this purpose personnel with state-of-the-art skills is hired. Still, a part of this new software package for the telecom enterprize can't be developed internally. Instead, a subcontractor that has been founded very recently is used for this externalized part of the overall software.\n*In the figure above an example of external-to-internal sourcing is depicted. Since there is no initial contractual process available to publish in a public service broker, collaborating parties need to find each other in a different way. The example in the figure above suggests that a service consumer directly contacts a suitable provider to engage in contractual negotiation on an external level. Thus, the collaborating parties propose to each other their respective contractual spheres until a consensus is reached. Next, the contractual spheres are backed by processes in the domains of the service consumer and provide. The first party integrates the sphere in the in-house process, and the latter party extends the contractual sphere to a refined process. The following phases are depicted by interaction blocks that have been detailed in previous pattern examples. Thus, the service consumer initiates a verification phase that is followed by a negotiation phase for determining which process steps need to be monitored. Finally, the resulting eSourcing configuration is enacted.
In the figure below, the highest abstraction level of the eSRA is depicted. In the figure two collaborating parties show the same set of components distributed across an external, conceptual, and internal level. The gray shaded boxes represent components and arcs between the components depict exchanges between the components.\n\n[img[eSRA_top_level|arch_1st_overall.jpg]]\n\nOn the external level the //Sourcing middleware// is replicated on the respective external levels of collaborating parties. This component is the main enabler of interoperability and direct information exchange exists between the eSourcing middleware of each collaborating party to synchronize the respective components. Between the collaborating parties a component is located termed //trusted third party// that exchanges information with the eSourcing middleware. A trusted third party is necessary for several reasons. Firstly, collaborating parties expose service demands or service offerings to the trusted third party for public evaluation. Secondly, the trusted third party performs verification of services and checks quality features of eSourcing configurations before enactment. If collaborating parties perform verifications and checks of eSourcing configurations themselves, they would need to reveal competitive secrets to each other, which is undesirable.\n\nThe conceptual level of the figure above, depicts two components, namely the translators and the eSourcing setup support. The //translator// component exchanges information between the components located on the external and internal level. The //Sourcing setup support// contains among other functionality tools for modeling business rules and processes. Finally, the internal level depicts a //legacy management// component that interfaces on the one hand with the translator component of the conceptual level and on the other hand with the legacy system of a collaborating party. \n
In the figure below, the global WFMS component of the Sourcing middleware that is situated at the external layer, is depicted as a refinement. It shows an enactment engine for the consumer's or provider's consumer spheres that are delivered from the [[CE translator]]. Event and production data is created during enactment and also needed for enactment and therefore stored and retrieved from dedicated databases. In order to support the concept of eSourcing, the figure below shows an enactment-monitor component and [[Conjoinment]]-monitor component (also see ConstructionPatterns). \n\n[img[eSRA_third_level|arch_3rd_globalWFMS.jpg]]\n\nThese components are important to support the [[eSourcing patterns]]. Concretely, the enactment monitor is responsible for aligning the enactment progress of internal level processes of the collaborating parties. In [[Monitorability]] the patterns are specified that are supported by the enactment-monitor component. Likewise, the conjoinment-manager component supports the [[Conjoinment]] patterns. Both the enactment monitor and the conjoinment manager exchange production and event data with components in the domain of the collaborating party via the coordination interface. Furthermore, production and event data is communicated to the internal level via the [[CE translator]] to coordinate local components.
''Problem:'' The service consumer does not mind in large parts how service provision is realized. However, the consumer wants to ensure that particular steps contained in the provided service are mandatory and carried out in certain control-flows.\n[img[grey-box pattern|buildVisibilityWhiteBox.jpg]]\n''Description:'' The pattern does not permit deviating interface places in the consumer sphere, the contractual sphere, and the provider sphere. Furthermore, a subset of nodes different from interface places contained in the consumer sphere and provider sphere is projected to the contractual sphere. The resulting consumer sphere is a connected graph. \n''Examples:'' \n*An OEM in the automobile industry demands from a provider the delivery of leather coated car seats. However, the OEM insists the provider must purchase the leather from a special certified seller following an agreed upon flow of tasks.\n*An example of grey-box contractual visibility is depicted in the figure above. The provider sphere of the service consumer depicts interface places with labels that are identical compared to the consumer sphere and the contractual sphere. The contractual sphere shows a connected graph that contains a subset of nodes of the consumer sphere. The provider sphere is a refinement of the contractual sphere, as the inserted //tau//-labeled transition shows.
''Problem:'' A company has serendipitously discovered a process innovation that poses a competitive advantage. However, it is initially not clear which companies the potential purchasers of the process innovation are. \n''Description:'' The service provider sets up a process in its own domain and subsequently exposes a subset of the process details publicly. Compared to the exposed version, the internal process contains additional refinement steps that remain opaque. Next, an interested service consumer adopts the exposed process and integrates it in the in-house process.\n[img[in-sourcing pattern|inSourcingAssignmentExample.jpg]]\n''Forces:'' The service consumer may find it impossible to integrate the exposed process of the provider. In that case extra negotiation about the exposed process content needs to unfold between the collaborating parties. The situation can occur that potential consumers are not aware of the offered service and as a result no collaboration comes into existence.\n''Examples:''\n*A firm has set up a service where databases of many airline companies are queried for last minute offers that are available for a reduced price. The search is embedded in a bigger service where the booking and payment of the flight are automatically handled. Travel agencies that sell tailored holiday trips to end customers may integrate the flight-booking service into their booking process that also incorporates insurance purchases, bookings of hotels, cars, and so on.\n*In the Figure above an in-sourcing example is depicted. First, a service provider models a refined sphere internally. A subset of this refined sphere is turned into a provider's contractual sphere and committed to a publicly available service broker. Next, interested service consumers check the committed contractual process and respond with placing offers. The service provider evaluates the offers, accepts the best, and rejects all other offers from the remaining consumers. Once two collaborating parties are allocated, the remainder of the figure above is described by interaction blocks that are detailed in the patterns belonging to the AssignmentDimension. Thus, the collaborating parties engage in concrete contracting, followed by a verification phase. After negotiating which process steps need to be monitored, the resulting eSourcing configuration is enacted.
To discover interaction patterns for eSourcing in a structured way, the following method is chosen. As depicted in the figure below, two feature dimensions exist in the form of axis that create a two-dimensional, logical space. The dimensions result of carefully studying CrossWork case studies and literature. On every axis further refining dimension values are located. Consequently, the axis and their contained values serve as a taxonomy for discovering, ordering, and relating a set of interaction patterns for eSourcing to each other. Furthermore, by evaluating the types of patterns used, it is possible to position an eSourcing configuration in the depicted logical space.\n[img[interaction dimensions|dimensions2InteractionPatternsNoPlus.jpg]]\nThe two interaction-dimensions are called as follows:\n*AssignmentDimension\n*DirectionDimension \nThese dimensions are depicted together with further refining values and are instrumental for deducting and categorizing top-down discovered InteractionPatterns.\n
For the examples of interaction patterns, sequence diagrams are used that propose a possible interaction during the setup phase of an eSourcing configuration. However, for sake of brevity, completeness of the interactions is not claimed. Furthermore, chunks of the overall interaction sequences are grouped into phases that are reused as ''interaction blocks'' in following sequence diagrams. In order to keep the figures brief, those reused interaction blocks abstract from the message exchanges and merely contain activation bars to depict, which parties and applications are active in that particular interaction block.\n\nBelow, the [[patterns|]] are listed in groups that correspond to the [[Interaction dimensions]] for setting up an eSourcing configuration:\n\n__[[AssignmentDimension]]__\n1. StaticAssignmentPattern \n2. DynamicAssignmentPattern\n3. SemiDynamicAssignmentPattern\n\n__[[DirectionDimension]]__\n4. OutSourcingPattern\n5. InSourcingPattern\n6. ExternalToInternalPattern\n7. InternalToExternalPattern\n
The figure below visualizes a second-level refinement of the legacy-management component. In it, a local WMFS and rules engine constitute the core components. These components are exchanging data between each other and are instrumental for coordinating legacy systems. The business rules and processes that are enacted by the WFMS and rules engine are translated down to the internal level by the CI translator. For enactment, the local WFMS and rules engine use a production database. Furthermore, to coordinate the enactment on an internal level and external level, the local WFMS and rules engine communicate events, rules, and production data bi-directionally. \n\n[img[eSRA_top_level|arch_2nd_legacy.jpg]]
''Problem:'' Collaborating parties have historically grown, stabile business processes in their respective domains. These processes need to be harmonized on an external level across organizational boundaries. \n''Description:'' Both the service consumer and provider have established business processes in their domains. The consuming organization considers a part of its in-house process to not be core business. On an external level, the consumer and provider engage in negotiating a consensus process that accommodates their already existent respective internal processes.\n[img[internal-to-external pattern|internalToExternalAssignmentExample.jpg]]\n''Forces:'' The internal processes of the service consumer and provider may proof to differ so extensively from each other that it is not possible to find a consensus on an external level.\n''Examples:''\n*A market-share dominating original equipment manufacturer (OEM) is a producer of high-precision track maintenance machines. The OEM feels no necessity to change the production and business processes. The suppliers of the OEM are equally not prepared to change their historically grown production and business processes. After investing in information technology and techniques the OEM and its suppliers begin to establish business collaborations electronically.\n*An abstract example is depicted in the figure above as a sequence diagram. First the collaborating parties model their internal processes before they engage with each other proposing to commence with contractual negotiations on an external level. The external negotiations are depicted as an interaction block that is detailed in the figure above. Once a consensus is reached, the contractual processes are integrated in the processes of the respective domains. The remaining interaction shows several interaction blocks for verification, monitorability negotiations, and the eventual enactment of the ready eSourcing configuration.
''Problem:'' During the enactment of transitions carrying labels that are equally located in the domains of the respective eSourcing parties, the life-cycle changes need to be communicated from the domain of the service provider to the consumer's domain. \n''Description:'' This pattern assumes the life-cycle of transitions that are linked for monitoring consist of lower-level nets. Consequently, life-cycle states and life-cycle transitions that are semantically matched for the respective transitions, are linked with token messaging and transition messaging arcs. \n[img[transition-messaging pattern|lifeCycleMessaging.jpg]]\n''Forces:'' Prior semantic life-cycle mapping is required in the heterogeneous system environments of the service consumer and provider. As discussed in LifeCycleMonitoring, linked transitions might have different life cycles with steps not present in the opposing eSourcing domain or with differently positioned life-cycle steps. Some life-cycle steps may be mutually present but differently termed. Thus, a decision needs to be taken about the semantic equivalence of particular life-cycle steps.\n''Examples:''\n*In the example depicted in the figure above, the life-cycle states in the consumer's and provider's transition carry the equal //executing// label. Thus, the respective life-cycle states are linked with a token-messaging arc (see TokenMessagingPattern). During the enactment of an eSourcing configuration the life-cycle transitions in the provider sphere propel the life cycle of transitions. Tokens that appear in the source life-cycle state are messaged to the equally labeled target life-cycle state in the consumer domain.\n*Equally labelled life-cycle transitions are linked with a transition-messaging arc (see Pattern TransitionMessagingPattern) from the direction of a service provider to a consumer. An example is given in the previous pattern.
For applying patterns of life-cycle monitorability, it is necessary to explore whether it is possible to achieve a mapping of life-cycle stages that equally labeled, active nodes use in opposing eSourcing domains. For presenting an analysis of the problem in this subsection, a life cycle of an active node is refined to a labeled [[WF-net|]] when an isolated active node has only one passive-input node and one passive-output node. As the figure below shows, there is only one life-cycle transition serving as an output node of that active node's passive-input node and only one life-cycle transition serving as an input node of the active node's passive output node. Those life-cycle transitions propel an active node's life-cycle states, which are represented by labeled passive nodes. \n\nIf an active node in a process has multiple passive-input nodes, they are at the same time multiple passive-input nodes of the first labeled life-cycle transition that is starting to propel the life cycle. Equally, when the active node with a life cycle has multiple passive-output nodes, they are at the same time the passive-output nodes of the last unique, labeled life-cycle transition. \n[img[black-box pattern|lifeCycleMapping.jpg]]\nIn the figure above the respective active nodes' life cycles are [[WF-nets|]] as both have one passive input and one passive output node. The active nodes are depicted by gray shaded boxes. All other nodes are connected, i.e., they have at least one input and one output arc. In both cases the life-cycle nets terminate after enactment so that only one token is left in their passive-output nodes. Furthermore, the figure contains a loop for pausing and resuming an active node that is in the life-cycle stage //executing//. The active node contains an additional life-cycle transition and state for event setting, which is not present in the consumer's life cycle. When an active node is accepted by a provider, this may serve as an event that other active nodes might need to wait for before they can be enabled. \n\nRevisiting the notion of projection inheritance (see [[eSourcing control-flow specifics]]), the life-cycle of the provider's isolated active node in the figure above is a subclass of the consumer's active-node life cycle. Thus, in this case, when all active nodes in a refined sphere and an in-house process are replaced with life-cycle transitions and life-cycle states then an in-house process containing a refined sphere instead of the consumer sphere is still a sound [[WF-net|]].
''Problem:'' During enactment of an eSourcing configuration the life cycles of transitions in the consumer sphere need to be synchronized with the life-cycles of equally labelled transitions in the provider's domain. However, the initiative for triggering alignments during service enactment should occur in the consumer domain.\n''Description:'' This pattern assumes the life-cycles of transitions consists of a lower-level net (see LifeCycleMonitoring). It is a prerequisite that life-cycle states and life-cycle transitions need to be semantically matched across eSourcing domains. Consequently they are linked in the direction from the service consumer to the provider domain with token-polling and transition-polling arcs. \n[img[life-cycle polling pattern|lifeCyclePolling.jpg]]\n''Forces:'' For this pattern the forces are comparable to those mentioned in LifeCycleMessagingPattern. Additionally, the polling intervals must be set appropriately. The consumer sphere runs the danger of falling behind during enactment when polling is not performed promptly. However, too frequent polling is a burden for the efficiency of applications that are used during the enactment of an eSourcing configuration. \n''Examples:''\n*In the example depicted in the figure above the life-cycle states labeled //executing// in the consumer's and provider's transition are linked with a token-polling arc (see TokenPollingPattern). During enactment of an eSourcing configuration the provider's transition is polled for having reached the life-cycle stage //executing//. If the response results in having a lower number of tokens contained in the respective life-cycle state, the number of tokens is aligned in the domain of the service consumer. Consequently, the tokens in the provider's life-cycle state remain unchanged.\n*Equally labelled life-cycle transitions are linked with a transition-polling arc from the direction of a service consumer to a provider domain. An example is given in TransitionPollingPattern.
The internal level refinement of the figure below shows a setup that is comparable to the GlobalWFMS. The local WFMS contains an enactment engine that receives in-house processes and refined spheres from the process database. Production data that is produced and consumed during process enactment, is exchanged with the production-data database. \n\n[img[eSRA_third_level|arch_3rd_localWFMS.jpg]]\n\nEvent data is exchanged with the local rules engine that carries out contractual rules. Furthermore, the enactment engine exchanges data with ports for the coordination of legacy systems. To coordinate the local enactment progress with the external level, production data and event data are exchanged with the [[Conjoinment]] manager and the enactment monitor respectively. The latter two components exchange events- and production data via the [[CI translator]] with the equally named components located on the external level.
----\n[[Welcome]]\n[[eSourcing definition]]\n[[SuitabilityFeatures]]\n[[eSourcing example]]\n----\n----\n[[Patterns]]\nPatternMetaModel\nPatternKnowledgeBase\n@@[[eSourcing patterns]]@@\n----\n[[Interaction dimensions]]\n@@[[InteractionPatterns]]@@\n----\n[[Construction dimensions]]\n@@[[ConstructionPatterns]]@@\n----\n----\n[[eSML]]\n[[eSML example]]\n[[eSML schema]]\n----\n----\n[[eSRA]]\n[[FirstLevel]]\n[[SecondLevel]]\n[[ThirdLevel]]\n----\n----\n[[Documentation]]\nCrossWork\n----\n\n^^[img[favicon.ico]] [[TiddlyWiki|]] <<version>>^^\n\n\n\n
This dimension covers the way how nodes in a consumer and provider contractual spheres (see [[eSourcing example]]) of the external level are linked with each other. Available linking values are //messaging// and //polling//. The nodes of the contractual spheres are connected to nodes in the corresponding spheres in the respective conceptual levels. Various degrees of monitorability of service provision are achieved for a service consumer during the enactment of a Sourcing configuration. At a minimum all interface places of both contractual spheres need to be linked with each other to transitively relate the consumer sphere and provider sphere with each other. Additional passive and active nodes of the contractual spheres may be linked. \n*//Messaging// can be applied to linked passive and active nodes contained in both contractual spheres. If two passive nodes are linked in a messaging way, the node experiencing a change in number of tokens signals that information to the linked destination node. When active nodes are linked in a messaging way, the executing node messages this event to the linked active node. \n*The classifier termed //polling// links nodes of the service consumer's and provider's contractual sphere in a way where one node periodically checks whether the linked node has changed. When passive nodes are linked in a polling way, one node checks if the number of contained tokens has altered. Consequently, the change is mirrored by the polling node. If two active nodes are linked in a polling way, one node periodically checks if the linked node has experienced an execution event. Thus, the polling node reflects the execution event (also see ConstructionPatterns).
''Problem:'' A company has a part of its in-house [[business process|]] that is detrimental to its overall competitive advantage. Thus, the company knows that a subcontractor could carry out the process in a better way. \n''Description:'' A part of an organization's in-house process that should be carried out by a third party, is demarcated into a subprocess. Next, the subprocess is taken over by an organization that agrees with offering the service. In the domain of the service provider further refinement of the service may take place that remains opaque to the service consumer. The subprocess in the domain of the service consumer and the refined process in the domain of the provider are linked with each other and the service consumer starts with enactment of the created inter-organizational configuration. \n''Forces:'' Since the assignment patterns of SemiDynamicAssignmentPattern, DynamicAssignmentPattern, and StaticAssignmentPattern are variants of the out-sourcing pattern, all forces mentioned in the assignment patterns also apply for this direction pattern.\n''Example:'' All examples mentioned for the assignment patterns of SemiDynamicAssignmentPattern, DynamicAssignmentPattern, and StaticAssignmentPattern are variants of the out-sourcing direction pattern.
The Pattern package focuses on properties around class //Pattern//. As the figure below shows, a pattern can have one or several //Alias// instances associated, e.g., the control-flow pattern called sequence is also known as sequential routing or serial routing. Patterns can relate to each other in different ways. The package depicted in the figure below includes relationships where patterns are either //Similar// to each other or one pattern is a //Generalization// of another one. For example, it can be argued that the control-flow patterns called parallel split and synchronization are similar as they complement each other where the first pattern creates parallel branches of execution and the latter pattern is required to join them. On the other hand, the discriminator pattern is a generalization of the n-out-of-m-join [[pattern|]]. Both patterns perform a merge of many executing paths and execute the subsequent activity only once. However, while the first pattern performs no synchronization, the latter pattern is more flexible as it is possible to set the number of parallel branches that need to be synchronized.\n\n[img[pattern packages|patternPackage.jpg]]\n\nThere are two different ways how a //Solution// may relate to a pattern. Firstly, a pattern tackles a particular problem for which one or many //Solution// instances are applicable. On the other hand a solution is only assigned to one pattern problem. Secondly, it may require the application of several patterns to achieve one greater solution. Therefore a second relationship arc is depicted in the figure above where a solution may use several patterns. In this context a solution contains static relationships and dynamic rules describing how to realize a desired outcome. For example, for the eSourcing category [[Contractual visibility]] the //problem// attribute states the service consumer is interested in using service provision. However, the consumer does not mind how the provision is carried out as long as the specified exchanges are performed correctly. The applied pattern is called BlackBoxPattern from the category and is characterized by a disclosure of business-process interfaces only without revealing the rest of internal process content. A solution that tackles the pattern problem is the application of a three-level framework (see [[eSourcing example]]) where it is possible to disclose on an external layer less than the full content of an internally given process on an internal layer.\n\nThe pattern and solutions are additionally linked by the //Requirement// class. Thus, a pattern must fulfill some requirements so that a solution becomes applicable. It represents a statement about the demanded pattern function and performance with respect to quantitative and qualitative features. For example, a requirement term can be system-interoperability support. A complementary description may mention that a solution must pay attention that collaborating parties do not want to disclose all their system details to each other. \n\nThe association class //RequirementCoverage// allows textual statements expressing to which extent a solution covers a requirement or not. For example, system-interoperability support is fully covered by a solution that represents a three-layer framework with internal process levels and conceptual process levels for the respective collaborating parties, and one external level for process merging (see [[eSourcing example]]). That way collaborating parties have the chance to hide internal details from each other while only needing to disclose what is necessary to perform process merging on an external level.\n\nTwo more classes are depicted in the figure above, namely the classes //Example// and //Model//. While one example only belongs to one particular pattern, a pattern may inspire several examples. An example is a textual description of a concrete instance in a real-world setting where a pattern is used. Alternatively, it is also possible to give an abstract example that is based on a formal model,e.g., Petri nets.
The [[Patterns]] lifecycle shows which actions of application users an application architecture must support. An //author// is a user who submits a pattern to the knowledge base. A //review leader// forms a review committee for the evaluation of newly submitted patterns. Registered users of the knowledge base who indicate to be volunteers as //reviewers// are invited by the review leader to form a committee. An inter- and intra-organizational knowledge worker (IKW) with the role termed //analyst// is interested in browsing a knowledge base that contains patterns of different perspectives and corresponding information about their artifact support. As indicated in the figure below, that pattern information helps an analyst to estimate which patterns collaborating business parties support despite their heterogeneous system environments. That way the setup time of inter-organizational business processes is accelerated. Finally, an //administrator// of the pattern knowledge base is required to grant roles to registered users, troubleshoot during pattern reviews, and so on.\n\n[img[pattern packages|onlineRepositoryArchitecture.jpg]]\n\nThe mentioned roles for knowledge-base users are input for an architecture that uses the pattern meta-model as a foundation. The described knowledge-base user types are depicted in the figure above where bi-directional arrows indicate an exchange with certain modules of the application's web interface. In the interface layer, modules are contained, for user management related interfaces, pattern related interfaces, and review related interfaces. \n*The //user management interfaces// offer a knowledge-base user to register, claim various qualifications, and request particular roles. As different roles give a knowledge-base user different rights, the administrator may need to authorize the roles. Once a knowledge-base user is approved, the user management interfaces allow user to login and logout, and modify roles and qualifications. \n*The //pattern interfaces// allow users to browse the knowledge base for patterns with a search engine that uses facts from the classes belonging to the taxonomy package (see TaxonomyClasses) and the support package (see SupportClasses). The generated lists of patterns can be individually selected for exploring their details.\n*//Review interfaces// allow a review leader to set up a review committee consisting of reviewers who either volunteer or are appointed based on their qualifications. In the latter case an appointed reviewer may decline through an interface. After the reviewers explore the properties of a pattern, they submit an accept or reject and their feedback for the pattern author. The latter knowledge-base user checks the feedback from the reviewers through another interface.\nThe functionality layer of the figure above shows modules that support the presentation-logic layer, namely the //user manager//, //pattern manager//, and the //review manager//. They process input of the knowledge-base users and control the interfaces that are presented for the signing up and signing in of users, submitting and browsing patterns, performing reviews, and various administration activities. The figure above depicts the modules of the functionality layer that are referencing each other. For example, to perform a review, the review-manager module uses functionality contained in the user-manager module. As a result, competent review teams are organized with the right qualifications. During a review, functionality from the pattern manager allows a reviewer to explore the context a pattern proposal is embedded in, i.e., the taxonomy location, technology support, relationship with other patterns, and so on. Furthermore, a reference between the pattern-manager module and the user-manager module exists for the same reason of employing functionality from each other. For example, if a knowledge-base user wants to browse for pattern information, she needs to have the role of an analyst, which must be checked by using functionality from the user manager. \n\nThe bottom of the figure above depicts the data layer showing databases for //user data//, //pattern data//, and //review data//. These databases are referenced by the corresponding modules of the functionality layer. The figures of PatternMetaModel contain data elements that are in the pattern data. The review and user data is depicted in UserManagementClasses without claiming completeness.
A pattern meta-model must be able to accommodate for new patterns belonging to newly introduced perspectives that are relevant for DIBPM. It is predictable that the meta model needs to capture many patterns and an inter-organizational knowledge workers (IKW) should be able to quickly find them based on characterizing search options. As inter-organizational business processes are supported by a heterogenous system environment, a meta model needs to capture technology support.\n\nSuch information is useful for IKWs to determine with which commonly supported patterns inter-organizational collaboration can be established. Finally, besides IKWs, different types of users of a pattern meta-model based repository exist, e.g., an administrator, users who submit patterns, pattern reviewers, and so forth. A meta model must capture information of different user types for managing access rights to pattern information. The following subsection uses UML notation to first group the pattern meta-model into packages and relates them. The content of the packages are presented in PatternModelPackages. These packages encapsulate classes that are refined in TaxonomyClasses, PatternClasses, SupportClasses, UserManagementClasses.\n
The left side of the figure below depicts a model of packages that are related to each other. These packages encapsulate classes that are refined in TaxonomyClasses, PatternClasses, UserManagementClasses, SupportClasses. The center of the package-model is named //Pattern//, which contains all classes that capture information for specifying a patterns. In the //Taxonomy// package, classes are contained that capture information about DIBPM perspectives. This package contains classes that create a taxonomy into which patterns can be embedded. The //Support// package encapsulates classes for managing information about technologies that support patterns. Finally, the //User Management// package captures information of different users of the pattern repository, e.g., administrator, reviewer, pattern submitter, and so on. \n\n[img[pattern packages|packagesPatternClass.jpg]]\n\nOn the right side of the figure above, the core class of the Pattern package is depicted, which is also named //Pattern//. The attributes of this class form the main description template of a pattern specification. A pattern has a //version// and a //name// that should be meaningful. Furthermore, a pattern has an //author// and a //creationDate// for every version. The //description// of a pattern mentions the inherent pattern properties and describes the relationship between them. Furthermore, the //intuitiveVisualization// contains a model that helps to support the comprehensibility of the pattern description. The //problem// of a pattern is a statement describing the context of pattern application. In this context conflicting environmental objectives and their constraints are described. The application of a pattern in that context should result in an alignment of the given objectives. Next, the //context// states a precondition, which is the initial configuration of a system before the pattern is applied to it. On the other hand, the //resultingContext// describes the postcondition and possible side-effects of pattern application. Finally, the //forces// describe trade-offs, goals and constraints, motivating factors and concerns for pattern application that may prevent reaching the described postcondition.
In an analogy to earlier analysis of [[control-flow, data-flow, exception handling, and the resource perspective|]] of [[business processes|]], a [[pattern|]] based exploration of eSourcing is proposed. In the case of the control-flow perspective, a pattern-based analysis has resulted in the development of [[XML-based|]] languages like [[XRL|]] and [[YAWL|]] that have strong control-flow expressiveness. By pursuing a deeper understanding of eSourcing with a pattern-based analysis approach, an important step is taken to make the concept of eSourcing operational. The pattern-based analysis is also used for the specification of a reference architecture for setting up and enacting eSourcing configurations. \n\nIn the figure below, an activity diagram shows the lifecycle of a pattern, which starts with an initial pattern proposal that is submitted to the knowledge base by a user who has the appropriate authorization level. This initial version of a pattern needs to go through a process of quality assurance before it may be accessible to inter- and intra-organizational knowledge workers (IKWs) who want to search for quality pattern information. Without a review procedure for patterns, the pattern content of the knowledge base may lack quality. \n\n\n[img[token-messaging pattern|patternLifeCycle.jpg]]\n\nThus, a knowledge-base user with the authorization of leading a review proposes the pattern for a review process. Repository users with the right skills may volunteer for a review or be explicitly invited by the review leader. Based on a defined review rule, a certain number of review results needs to be submitted for determining whether the pattern is accepted or not. If the review rule is not satisfied, the pattern is rejected and needs to be rewritten as a new proposal. If the review rule is satisfied, the pattern proposal is officially accepted and experiences a status change. Thus, it turns into a quality pattern that is exposed to IKWs for searching. \n\nOther relevant patterns for [[DIBPM]] are among others:\n*[[Enterprise Integration Patterns|]]\n*[[Service Interaction Patterns|]]
''Problem:'' The service provider has to forward information to the consumer domain that should immediately be answered by a response. Such an exchange should not violate the correct termination of an eSourcing configuration.\n''Description:'' A sending conjoinment node that initiates information exchange to the domain of the service consumer is part of the consumer sphere, the contractual spheres, and the consumer. Such a sending conjoinment node is connected to a port at the border of the sphere through which information is exchanged to the domain of the service consumer. The port is connected to a bi-directional conjoinment node that is part of an in-house process outside of the consumer sphere. This bi-directional node receives the delivered information and responds with sending information back to the domain of the service provider through another sphere port. Finally, a receiving conjoinment node that is replicated in all spheres of an eSourcing configuration serves as a recipient for the information sent through the response port.\n[img[bi-directional provider initiated pattern|biDirectionalProviderConsumerProvider.jpg]]\n''Examples:''\n*A local service provider is booking a hotel room according to special requirements of a customer. Those requirements are delivered by a travel agency that sources in the service of booking a hotel room. Since the payment format should be kept flexible, the provider must be able to ask the travel agency during enactment how the customer would like to pay for a particular hotel room. The response from the travel agency should be received immediately by the service provider in order to finalize the hotel booking.\n*In the top of the figure above the depicted consumer sphere contains a sending and receiving conjoinment node in the sphere. The first node carries an //S// label and the latter and //R// label. The sending conjoinment node has a passive output node that is an \semph{out}-labeled interface place, which serves an an input node for the bi-directional node in the in-house process. This //B//-labeled conjoinment node produces an immediate response during the exchange. For this reason one passive output node of the bi-directional conjoinment node is an //in//-labeled interface place. Consequently, that interface place is a passive input node for the //R//-labeled receive node contained in the consumer sphere.
''Problem:'' During build time of an eSourcing configuration a construct is required that allows the service consumer and provider to reach consensus on an exchange of information directed from the provider domain to the consumer domain. The created exchange should permit the checking of correct termination.\n''Description:'' All spheres of an eSourcing configuration have a port through which information leaves towards the domain of the service consumer. This port has an input node for triggering the sending of information. In the domain of the service consumer an output node of the port receives the delivered information. This receiving conjoinment node is part of an in-house process outside of the consumer sphere.\n[img[one-directional provider initiated pattern|oneDirectionalProviderInitiated.jpg]]\n''Examples:''\n*A service provider in the automobile industry agrees to supply an engine to an original manufacturer (OEM) of trucks. The OEM demands process mirroring for achieving a tight integration with the provider. Whenever the production of an engine is completed, the OEM demands to have the resulting data from the quality checks delivered for evaluation and controlling purposes.\n*An abstract example is depicted at the top of the figure above where a conceptual-level process in the consumer domain is depicted. The consumer sphere contains a sending conjoinment node connected to an //out//-labeled interface place. These two nodes are replicated in all other spheres that are part of the same eSourcing configuration if they are projected to the consumer's contractual sphere. The in-house process of the figure above has an //R//-labeled conjoinment node that uses the interface place as an input node. Since the enactment of the sending conjoinment node takes place in the domain of the service provider, an exchange from provider to consumer takes place via the external level.
In the domain of //service-oriented business integration//, web service composition languages ([[WSCL|]]) have emerged for supporting process specifications, e.g., [[BPEL|]]. Such languages compose services in a workflow, offering a complex service that carries out activities. However, [[WSCLs|]] merely choreograph the execution of composite services that remain a black box to each other. Thus, the existing [[WSCLs|]] are not suited for a client-server type of process-oriented [[B2B|]] collaboration. Generally, these languages are semantically ambiguous and therefore lack expressive rigor for verifying correct termination in advance of enactment.
The gray depicted components of the eSRA reference architecture of the FirstLevel is refined on a second level. The following refinements are available: ExternalLevelRefinement, TranslationExternalInternalRefinement, SetupRefinement, InternalLevelRefinement. The component in focus is visualized by grey shading. In contrast, the translator component is not gray shaded as it is refined in a later figure. In all figures of this subsection the refined components of focus are depicted with their exchanges to bordering components.
''Problem:'' An organization is involved in tight supply-chain integration where parts of an overall service are Sourced. While it is important that a service is sourced, it is not clear which organization can offer guaranteed collaboration.\n''Description:'' Before the setup time of a service exchange begins, the number of organizations that are willing to collaborate is predetermined. When the service to be sourced is externalized to a broker, only the collaboration candidates may evaluate and engage in a bidding for the service. Any other organization that is not a predetermined candidate, is excluded. The service-externalizing organization chooses the offer and rejects all other. \n[img[semi-dynamic-assignment|semiDynamicAssignmentExample.jpg]]\n''Forces:'' Concerning the tight integration of service providers, the forces of StaticAssignmentPattern apply. With respect to using a publicly visible process broker and managing a bidding procedure, the forces of DynamicAssignmentPattern are applicable. The requirement of a notification system is specific for this semi-dynamic assignment pattern. Such a notification system is activated when the template process is committed to the public process broker by the service consumer. Since the template contains the set of predetermined service providers, the broker should notify those providers so that they may engage in the bidding.\n''Examples:''\n*An insurance company evaluates claims resulting from car crashes. A part of the in-house process is concerned with evaluating the damage. However, the insurance company doesn't consider such an assessment its core business and therefore has external companies providing such assessment services. Those companies form a pool of competing service providers that are shared between a number of different insurance companies. Thus, it is never clear which company is available for performing a car-damage assessment.\n*An abstract example geared towards the creation of an eSourcing example is given in the figure above. First, a service consumer loads a template that contains definitions referring to a set of tightly integrated service providers. After that the consumer commits its sphere to a publicly available service broker. A //service provider N// is browsing the service broker and receives several processes in return. However, processes where the predetermined service-provider candidates are defined are not returned. Instead the service broker sends out notifications to those providers defined in the process. The notified providers engage in a bidding procedure after which a contracting phase follows with the providers that were chosen by the service consumer. Afterwards the service consumer requests a verification of the preliminarily defined eSourcing configuration. If the verification concludes with an approval, the monitoring of process nodes is negotiated. Eventually the service consumer requests from the middleware to enact the ready eSourcing configuration.
The service-broker refinement within the trusted third party of the figure below reveals a service-library database that stores contractual spheres of service consumers and providers via the template search engine. The latter component exchanges contractual spheres with the contracting client of the eSourcing middleware that is located on the external level of the collaborating parties. Furthermore, the template search engine exchanges data with the bid-manager component of the auction service. \n\n[img[eSRA_third_level|arch_3rd_broker.jpg]]\n\nThe notifier component checks contractual spheres that are stored in the service library for data about a collaborating party that needs to be informed. If such facts are defined, the notifier informs the specified contracting client of the respective parties about the submission of the contractual sphere. Consequently, informed parties check the contractual sphere and either engage in a bidding procedure or commit to the contractual sphere by instantaneously responding with committing a contractual sphere of equal content to the trusted third party.
In the figure below, the Sourcing-setup-support component is located on the conceptual level. The component has two core functions, namely modelling business rules and processes, and composing workflows that are on the one hand evaluated and on the other hand verified for correct termination. Thus, the rules modeler and the process modeler are responsible for the first function for which they are supported by a pattern knowledge base. In [[Documentation]] the pattern knowledge-base is presented in further detail. The second function is related to the workflow composition component. For composition, workflow sniplets or local processes are taken from a dedicated database, which are supplied by the process modeler. \n\n[img[eSRA_second_level|arch_2nd_setup.jpg]]\n\nA composed workflow is either an in-house process or a refined sphere and is checked internally in two ways. First, with respect to control flow, correct termination is verified by the tool [[Woflan|]] for which the process needs to be mapped to a place/transition net. If the net is a [[WF-nets|]], Woflan checks for structural conflicts, i.e., deadlocks or lack of synchronization. Thus, if the [[WF-nets|]] is verified to terminate correctly, it conforms to the notion of soundness, i.e., correct termination. Secondly, the in-house process or refined sphere needs to be verified for other conflicts, e.g., data-flow or resource. \n\nAlthough it is desirable to have verification tools for several workflow related perspectives, e.g., data-flow and resource, it is essential to validate the in-house process and refined spheres of an eSourcing configuration with an additional tool. Among other aspects, such a validation is meaningful for testing how the different perspectives fit together for workflow enactment, e.g., the correct functioning of web services that are orchestrated by the processes. In the Sourcing-setup-support component of the figure above, [[XRL/flower|]] is depicted as a validation tool. [[XRL/flower|]] uses XML technology and is implemented in Java on top of the Petri-net Kernel [[PNK|]]. Standard XML tools can be deployed to parse, check, and handle [[XRL|]] documents. The [[XRL|]] enactment application is complemented with a web server allowing actors to interact with the system through the internet.
electronic Sourcing for dynamic B2B collaboration
The section for value exchanges contains processes of the original equipment manufacturer (OEM) and suppliers. Below, the first line shows the starting line for the [[eSML schema]] definition of value exchanges.\n{{{\n<xs:element name="exchanged_value" type="value_types" minOccurs="2" maxOccurs="unbounded"/>\n\n<exchanged_value>\n <service>\n <!-- IntierWaterTankAssembly -->\n <process_section>\n <process tag_name="IntierWaterTankAssembly" process_id="Intier_WaterTank_Assembly">\n <sequence>\n <receive_task active_node_id="IntierAssembleWaterTankRequest" name="AssembleWaterTankRequest" executor="IntierWaterTankAssembler" address="[wService=JurimaSealingRing.wsdl portType=JurimaSealingRing operation=initiate]">\n <data>\n <data_flow_direction>output</data_flow_direction>\n <data_package_ref>JurimaSealingRingSpecificationRequest</data_package_ref>\n </data>\n </receive_task>\n <send_task active_node_id="IntierAssemblyComplete" name="AssemblyComplete" executor="IntierWaterTankAssembler" address="[wService=JurimaSealingRing.wsdl portType=JurimaSealingRing operation=initiate]">\n <data>\n <data_flow_direction>input</data_flow_direction>\n <data_package_ref>IntierWaterTankAssemblyResponse</data_package_ref>\n </data>\n </send_task>\n </sequence>\n </process>\n <active_node_label_mapping>\n <consumer_process>VE_WaterTank_Assembly</consumer_process>\n <consumer_active_node>VE_AssembleWaterTankRequest</consumer_active_node>\n <provider_process>Intier_WaterTank_Assembly</provider_process>\n <provider_active_node>IntierAssembleWaterTankRequest</provider_active_node>\n </active_node_label_mapping>\n <active_node_label_mapping>\n <consumer_process>VE_WaterTank_Assembly</consumer_process>\n <consumer_active_node>VE_AssemblyComplete</consumer_active_node>\n <provider_process>Intier_WaterTank_Assembly</provider_process>\n <provider_active_node>IntierAssemblyComplete</provider_active_node>\n </active_node_label_mapping>\n </process_section>\n </service>\n</exchanged_value>\n}}}\nFollowing the [[eSML schema]] definition line, an example of a value exchange definition is contained. Essentially, the value exchange contains a process definition that needs to match with the definition of the collaborating counterpart. Thus, the value-exchange definition of the OEM contains one process in which spheres are nested. Those nested spheres are matched in content by the suppliers' processes in the value-exchange definitions. A consensus is only reached when all the processes in the nested Spheres of the OEM match with the process definitions of the suppliers.
''Problem:'' Due to market pressures a company is involved in optimized production\ncycles of complex industrial goods with very small order numbers. To reach the objective,\nit is critical that a signicant part of the overall production needs to origin from an\nexternal source that can guarantee high quality and time precision.\n''Description:'' Before the setup phase of a [[B2B|]] collaboration begins, a service consumer and a service provider limit their collaboration choice to one candidate. The provision candidate must be able to guarantee the consumer the capability of offering an agreed upon service. The sourced service is formulated as a template and externalized to initialize the setup interaction between collaborating parties with the objective to receive a service of predictable time precision and agreed upon quality.\n[img[static-assignment pattern|staticAssignmentExample.jpg]]\n''Forces:'' Achieving tight integration between a service consumer and a provider might\nfail for different reasons. For example, if a provider is not capable of performing the\nagreed upon service, it fails to be a credible candidate. Furthermore, failing technological\nintegration attempts between provider and consumer are a potential obstacle. The\nprovider might not be able to offer requested quality standards of services.\n''Examples:''\n*A truck manufacturer has a competitive advantage by delivering according to customer specifications within 17 working days. Such prompt delivery is only assured when the truck manufacturer consumes clearly defined, external services that are reliably available. Therefore, there exists one specially prepared supplier who is capable of performing a mirroring of externalized consumer-processes. Since the chosen supplier happens to possess crucial production know how without which the truck manufacturer isn't able to reach his deadlines, the consumer is interested in a very tight supply-chain integration.\n*An abstract example of static assignment that focusses on eSourcing is given in the figure above. The a priori tight integration efforts between service consumer and provider are abstracted from. Instead the sequence of interaction starts with a service consumer loading the predefined template resulting from earlier integration efforts. The template represents a consumer sphere that is integrated into the consumer's in-house process. Next, the consumer projects its sphere to the middleware situated between the consumer and the service provider. Consequently, the service provider is informed by the middleware about the committed consumer's contractual sphere. The provider responds with a sphere projection to the middleware. If the respective contractual spheres don't match, the projection procedures need to be repeated until the respective contractual spheres match and a consensus is created. The contracting phase of interacting is ended after the middleware informs the collaborating parties about the shared consensus and when the provider has created its refined sphere. Next, the service consumer requests the middleware to perform a verification of control-flow and data-flow properties of the eSourcing configuration. In order to keep each other's processes secret from each other, the collaborating parties supply the in-house process and the refined sphere to the middleware that performs all checks. The results are sent out to the collaborating parties. If the verification succeeds, the collaborating parties may engage in negotiating the monitorability aspect of the eSourcing configuration. Finally, the service provider sends a message to the middleware that enactment should commence.
Control-flow is one fundamental perspective of inter-organizational business-process collaboration. Here also other related perspectives are discussed. Informally, a perspective is a particular angle from which a certain domain is regarded. The figure below relates eSourcing to other essential perspectives of inter-organizational business-process collaboration. To the very left and right of the figure, factory symbols represent a service consumer and provider where internal and conceptual-level processes are located. eSourcing rests on other relevant perspectives depicted as pillars in the center of the figure below where external-level processes are located. The listed pillar-perspectives are considered the most significant for [[DIBPM]] without claiming completeness. \n\nIn an eSourcing configuration, other [[patterns|]] for perspectives like data flow is essential as input and output of information during the enactment of service provision steps. Data flow focuses on the various ways in which data is represented and utilized in business processes. The provision and consumption of services involves human or non-human resources, e.g., machines, production material, office space, and so on. Thus, the resource pillar deals with the way how the involvement of such resources is represented and utilized. Finally, the enactment of an eSourcing configuration must offer a degree of certainty. By including a transaction pillar, enacted eSourcing steps are secured and exceptional situations are handled and compensated if required. \n\n[img[pattern packages|knowledgeWorker.jpg]]\n\nFor eSourcing the objective is pursued to realize expressive and suitable applications that support collaborating organizations in setting up and enacting eSourcing configurations in an automated way. Here, the setup phase focuses on specifying an inter-organizational business process template and linking the information infrastructure of the respective collaborating parties according to the three-level framework (see [[eSourcing example]]), i.e., the legacy systems on the respective internal levels are not directly linked with each other. For the enactment phase an instance of a specified inter-organizational business process template is used to orchestrate the collaboration of a service consumer and a service provider. \n\nA well-structured approach is needed to explore the features of the perspectives contained in the figure above, in order to create a foundation for developing a suitable language for eSourcing. The problem must be tackled of having to deal with a high degree of complexity that results from a heterogeneous system environment of collaborating business parties. \n\nOn top of the figure above, two inter- and intra-organizational knowledge workers (IKWs) are depicted that each belong to a collaborating organization. The IKWs support collaborating organizations in submitting process models to an eSourcing configuration that involves the depicted perspectives. Although the creation of eSourcing configurations should be carried out fully automated, it is realistic that IKWs are involved for the foreseeable future. For carrying out their work effectively and efficiently the support of a knowledge base that contains perspective-specific patterns for intra- and inter-organizational business process management is important. \n\nTo explore the eSourcing perspective for its setup phase and for its construction elements, the following method is chosen. DIBPM contains several feature dimensions in the form of axes that create a multi-dimensional space. On every axis, dimension values are located that detail the [[DIBPM]] feature an axis represents. By taking a subset of axes, a logical space is created that represents a particular DIBPM perspective. \n
In the figure below, a package called //Support// is depicted containing classes for capturing technology information of patterns. On top of the figure below the //Pattern// package is shown with the subset of contained classes that have relationships to classes from the //Support// package. Accordingly, a pattern example is visualized by an //Illustration// instance, a model is expressed in an instance of a //Language// subclass, and a pattern is supported by an //Artifact//. In the latter case an artifact can be of a complex nature, e.g., a software system that supports a standard language.\n\n[img[pattern packages|supportPackage.jpg]]\n\nInstances of the class //Illustration// contain a screenshot with textual description that shows how an artifact supports a pattern, e.g., a modeling element description. This screenshot is related to an instance of the association class //Support// that links a pattern instance with a particular technology, indicating to which degree the the pattern is supported, i.e., either fully, limited, or not at all. \n\nA //Model// can be represented in a language that consists of several elements. One hierarchy level lower, the figure above depicts several subclasses. An instance of //Formal Language// is, e.g., the Petri-net markup language [[PNML|]] that is based on Petri-net theory. Instances of //StandardLanguage// refer to languages that are, e.g., XML based and pursue the objective of supporting the modelling of business processes that are carried out with the help of web service orchestration. Examples of such XML-based standards are [[BPEL|]] or [[WSDL|]]. Instances of //ToolLanguage// are related to some software system, e.g., the workflow management system [[Staffware|]]. Next, an instance of //Software System// is an aligned set of programs and application software that perform a specific function directly for the user. Finally, a //Standard// is a prescription or regulation that is fixed by approved institutions. Standards achieve the unification of artifacts that are published in journals. Standards in the ICT domain are necessary for interworking, portability, and reusability. They may be de facto standards for various communities, or officially recognized national or international standards.
The figure below depicts the classes of the //Taxonomy// package. Creating a taxonomy is relevant for ordering patterns and relating them to each other. Additionally, a taxonomy helps to find patterns that are stored in the repository. In the depiction of package //Taxonomy//, the class named //Perspective// is central. Informally, a perspective can be seen as a particular angle from which a certain domain is perceived. To the left of the figure below, the relationship to the //Pattern// package is depicted. It shows that a pattern always only belongs to one perspective while a perspective possibly references many patterns.\n\n\n[img[pattern packages|taxonomyPackage.jpg]]\n\nPublications of pattern specifications contain groupings of patterns that share characteristics. For example, the WhiteBoxPattern, BlackBoxPattern, and GreyBoxPattern of the eSourcing [[Construction dimensions]] are in one group with the characteristic [[Contractual visibility]]. If a considerable amount of patterns is in the repository, a more detailed grouping of patterns is sensible to allow IKWs speedy pattern discovery. Therefore, the figure above shows a class called //CharacteristicCategory// that is assigned to one perspective. To permit recursive groupings of patterns, //CharacteristicCategory// instances may contain each other. For example, in the control-flow perspective the patterns are grouped in six characteristic categories, e.g., structural patterns and cancellation patterns. \n\nAlthough the figure above depicts a reference between the //CharacteristicCategory// and a //Pattern// by using an association class called //PatternCategoryLink//, a further refinement of the taxonomy with additional classes is realized. Thus, a class //Classifier// organizes a //CharacteristicCategory// with refining keywords that are commented for clear comprehension. For example, the eSourcing category called [[Contractual visibility]] is refined by the category keyword //projection//. This keyword indicates how much process content is projected to an external level where the collaborating counterpart can perceive it. Finally, the class //Assignment// is completing the taxonomy creation by allowing the assignment of a value to a pattern classifier that belongs to a special category. For example, the black-box pattern of the characteristic category with the value //contractual visibility// has the assignment value //none//.
On a third refinement level, the dark-gray shaded components of SecondLevel are further detailed according to the principles of functional decomposition. First the [[CE translator]] and [[CI translator]] are refined. Additionally the following gray-depicted components of the SecondLevel are refined: GlobalWFMS, LocalWFMS, ServiceBroker, AuctionService, VerifierComponent
''Problem:'' During the enactment of service provision, the consumer wants to observe certain provision states. Thus, state changes that occur in the provider sphere of the provider domain should be mirrored by the consumer sphere in the opposing domain.\n''Description:''The token-messaging mechanism is triggered when a source place experiences a change in the contained amount of tokens. A message delivers the new number of contained tokens to the target place. The target place evaluates if its contained token amount deviates from the number delivered in the received message. If the number deviates, the tokens contained in the target place are synchronized while the amount of tokens in the source place remain unchanged.\n[img[token-messaging pattern|runVisibilityTokenPropagation.jpg]]\n''Examples:''\n*The figure above depicts a token-messaging example for //in//-labeled interface places. The token-messaging direction must lead from the consumer sphere to the provider sphere. The reason for this linking direction is that an active input node belonging to the service consumer's in-house process puts a token into the consumer sphere. Consequently, the enactment of the consumer sphere is started. In order to start the enactment of the provider sphere, token messaging is required to put a token into the //in//-labeled interface place of the provider sphere. After token messaging, the input places of both spheres contain a token and the enactment of the eSourcing configuration may carry on.\n*To support monitorability for the service consumer, places in spheres that are not interface places can be linked in the direction from the provider domain to the consumer domain. Once the enactment of service provision is started, state changes are taking place in the provider sphere that should be monitorable in the consumer sphere. Thus, token messaging from the provider domain to the consumer results in having state changes of service provision followed for permitting consumer monitoring. In the figure above, corresponding examples are depicted.\n*Interface places with an //in//-label have an active input node from the in-house process outside of the consumer sphere. As the figure above shows, such a token enables the active receive nodes in the consumer sphere and the provider sphere. Therefore, token messaging is applicable in such a case with a linking direction from the consumer sphere to the provider sphere.
''Problem:'' During the enactment of an eSourcing configuration the opposing eSourcing parties want to monitor the progress of state changes. However, for economic reasons only some state changes are of relevance to an eSourcing party and are consequently mirrored according to the opposing domain.\n''Description:'' Places that belong to the domains of a service provider and consumer and that are not //out// interface places are linked with each other. Periodically the number of tokens contained in the respective places are checked. When the numbers deviate, the amount of tokens contained in the place of the polling domain is synchronized if it is less than in the target domain. Such synchronization does not affect the token amount contained in the place of the target domain.\n[img[token-takeover pattern|runVisibilityTokenTakeover.jpg]]\n''Forces:'' The proper setting of the polling interval is relevant for keeping the polling domain up to date with respect to state changes in the target domain. If the polling intervals are too long, state changes of the target domain can be miss. On the other hand, if the polling intervals are very short, the performance of the applications involved in the enactment of an eSourcing configuration are stressed unnecessarily. Furthermore, it must be stated that early tokens may occur in a linked place of a consumer sphere. Thus, such an early token only enables the output transitions of the place it resides in when the procedure of token polling results in a synchronization of the amount of tokens compared to the linked place in the provider sphere.\n''Examples:''\n*The //in//-labeled interface places of the figure above are linked with a token-polling arc from the domain of the service consumer to the provider. The token is produced by an active input node belonging to the consumer's in-house process and consumed by an active receive node that is located in the provider sphere.\n*Places that are not interface places are linked with token-polling arcs in the direction from service consumer to the provider domain. In the figure above the place between the //a// and //b//-labeled transitions of the provider sphere is polled for tokens. The linked place in the consumer sphere synchronizes its token number.
''Problem:'' During the enactment of an eSourcing configuration, tokens enter //out//-labeled interface places in the provider sphere that should trigger a message exchange with the in-house process. Since all places of the provider sphere must be empty after enactment, these tokens should be removed while the exchange between the provider sphere and the in-house process takes place. Additionally, the final token left in the //out//-labeled interface place of the provider sphere needs to be removed to complete enactment. \n''Description:'' This pattern links two equally labeled places from spheres that are not part of the same level in an eSourcing configuration. Thus, linked are two //out//-labeled interface places of the provider sphere, contractual sphere, and the consumer sphere. The propagation starts when a token arrives in the linked source place. In that case the token is passed on as a message to the linked target place in the different level. As a result the source place has that token removed and placed in the target place.\n[img[token-propagation pattern|runVisibilityTokenPropagation.jpg]]\n''Forces:'' A token already resides in the //out//-labeled interface place of the consumer sphere before token propagation takes place. Thus, this token may be ahead of the provider sphere's //out//-labeled interface place and as a result it still takes more time until a token-propagation message is triggered. Such an //early// token can't result in enabling a transition.\n''Examples:''\n*For //out//-labeled interface places, the eSourcing configuration depicted in the figure above shows an example. When a token enters the //out//-labeled interface place of the provider sphere, a propagation to the consumer sphere takes place. As a result, the enactment of the provider sphere is terminated and the rest of the service consumer's in-house process is carried out. \n*The //out//-labeled interface place of the provider sphere in the figure above is connected with a token-propagation arc. When a token is placed in the interface place, a message is sent to the equally labeled interface place of the consumer sphere. As a result the token is passed on across the eSourcing domains from one interface place to the other.
''Problem:'' A provider sphere needs to be cleared of tokens residing in places that do not serve as input nodes to any other transitions. However, the token clearing is triggered from the domain of the service consumer.\n''Description:'' The //out//-labeled interface places are linked in the direction from a consumer sphere to the corresponding provider sphere of a provider. A request is sent periodically from the domain of a service consumer to the equally labeled place of the provider sphere to check whether a token resides there. If the response is positive, the token is removed from the provider domain and placed in the target interface place of the consumer domain.\n[img[token-takeover pattern|runVisibilityTokenTakeover.jpg]]\n\n''Examples:''\n*The //out//-labeled interface place of the provider sphere in the figure above is connected to a token-takeover arc. When a token is placed in that interface place, token polling from the domain of the service consumer results in a positive response. As a result the token is taken over and placed in the equally labeled interface place of the consumer's domain. Consequently, the provider's //out//-labeled interface place is empty.
''Problem:'' An active node does not contain a lower-level life cycle (see LifeCycleMonitoring), i.e., it is a transition. An equivalently labeled transition in the consumer domain only has to be enacted when the linked transition in the provider sphere has fired.\n''Description:'' While a linked source transition fires, a message is sent to the equally labeled target transition. If the target transition is enabled, i.e., has a token in all its input places, the transition fires once the message from the equally labeled source transition arrives. Consequently, the target transition produces a token for all its output places.\n[img[transition-messaging pattern|lifeCycleMessaging.jpg]]\n''Examples:''\n*An example of transition messaging is depicted in the figure above in connection with active nodes that have life-cycles. When enabled, the consumer's life-cycle transitions can fire in sync with an equally labeled life-cycle transition of a service provider. The life-cycle transitions labeled //accept// and //complete// equally occur in active nodes of the service consumer and provider domain. Thus, these two nodes are suitable for linking with transition-messaging arcs directed from the service provider to the consumer.\n*Active nodes without a life cycle can be linked with a transition-messaging arc. These nodes must have equal labels and be mutually known, i.e., be part of the respective contractual spheres on the external level of a eSourcing configuration. Then the linking direction is from the domain of the service provider to the domain of the consumer.
''Problem:'' A service consumer wants to monitor when an enabled transition without a life cycle may fire in its domain.\n''Description:'' Two transition nodes with equal labels in opposing eSourcing domains are linked in the direction from service consumer to provider. When the consumer's transition is enabled, periodic polling takes place to check if the provider's linked transition has fired. If the response is positive, the consumer transition fires and the polling is stopped.\n[img[transition-polling pattern|lifeCyclePolling.jpg]]\n''Forces:'' The forces exerted on this pattern are comparable to the forces of the TokenPollingPattern during the enactment of an eSourcing configuration with respect to the alignment promptness of a source transition compared to the polled target transition.\n''Examples:''\n*An example of transition polling is depicted in the figure above in connection with transitions that have life-cycles. Both life-cycle transitions labeled //accept// and //complete// occur in transitions of the service consumer and provider domain. The equally labeled life-cycle transition of the service provider is periodically polled. If the response contains the message that firing has been carried out, the consumer transition fires, which results in a change of the life-cycle state.\n*Transitions without life cycles that are equally labeled in the domains of the service consumer and provider may be linked with transition-polling arcs. When the consumer's transition is enabled, polling of the target transition in the provider's domain starts to monitor its firing. This is periodically repeated until the response states firing occurred. As a result the consumer transition also fires to follow the provider domain and polling is stopped.
The translator contains two main translator components for transferring data between the external, conceptual and internal level. The CE translator component translates data from the conceptual to the external level and vice versa. The component is connected with the rules and process modelers of the Sourcing-setup-support component. The relationships between the CE translator and components contained in the Sourcing middleware is explained above. Two components exchange data between the CE translator and and CI translator, namely the worklfow/events data exchanger and the rules/events data exchanger. Those data exchangers contain information about where data needs to be routed to. For example, several instances of WFMSs and rules engines on the external and internal level may enact several instances of different Sourcing configurations. Furthermore, on the internal level several web services wrap legacy systems to which exchanged data needs to be routed to. \n\n[img[eSRA_second_level|arch_2nd_translator.jpg]]\n\nThe CI translator component translates data between components of the conceptual and internal levels. From the data-exchanger components, events-, rules-, and production data are translated bi-directionally to the local WFMS and rules engine on the internal level. Furthermore, the CI translator receives contractual rules from the rules modeler and in-house processes and refined spheres from the process modeler. They are translated to the local WFMS and rules engine on the internal level. \n
In the figure below the //User// package contains relevant classes for handling user and review-related information. On top of the figure the //Pattern// package contains class //Pattern//, which is the only connection between the two packages. The central class of the //User// package is called //RepositoryUser// and contains the attribute //volunteer// for indicating whether a user wants to be a reviewer or not. The user of a knowledge base may slip into several //Roles// which have different authorization levels included that influence how a user can interact with the pattern knowledge base. For example, an analyst is only allowed to browse for information but not allowed to edit a pattern. \n\n[img[pattern packages|userPackage.jpg]]\n\nThe model in the figure above also depicts the class //Qualification// that is referenced by //RepositoryUser//. The qualifications of a user are relevant for taking part in reviews. Users who do not have required qualifications can not be considered for reviewing patterns. Furthermore, if a user has the appropriate role assigned for leading a review, she can issue invitations for several reviews. Such a knowledge-base user also needs to define a //Rule// for a review if a predefined rule doesn't exist already. For example, a rule could state that four reviewers out of five must accept a pattern proposal in order to become a quality pattern while two rejections are enough to totally reject the pattern proposal without waiting for the results of the remaining reviewers.\n\nA //Review// is initiated by a knowledge-base user who has the role of a review leader. After assigning a rule to the review, the review leader must find review participants. First, a review leader can look in the pool of users who issued an entry in //Volunteer Review//. Provided a volunteers possess the appropriate qualifications, a review leader creates an entry in class //InvolvementInvatiation// and therefor establishes a relationship between a knowledge-base user and a pattern review. Secondly, if not enough volunteers are available, the review leader searches for rightly qualified knowledge-base users and issues a review-involvement invitation that is either accepted or rejected. If the knowledge base rejects the invitation, the entry created by the review leader is removed from class //InvolvementInvatiation//. Finally, once the required amount of review participants is established, entries in class //ReviewResult// are performed that indicate whether a knowledge-base user accepts or rejects a pattern proposal.
The soundness property (i.e., correct termination) and projection inheritance of [[WF-nets|]] can be verified with the analysis tool [[Woflan|]]. This way it is possible to detect modeling abnormalities, e.g., deadlocks, before workflow enactment, which helps to avoid costly run-time failures. This component offers a trusted third-party service, to which collaborating parties can independently submit their conceptual processes for verification without disclosing internal business details. Note that a verification of correct termination performed by a trusted-third-party component is necessary when a service consumer and a service provider agree on using black-box projection (see BlackBoxPattern) to the external level.\n\n[img[eSRA_third_level|arch_3rd_verifier.jpg]]\n\nIn the figure above, a process-communicator component receives a request from the contracting client belonging to the domain of a collaborating party to perform a verification of a created eSourcing configuration. The process communicator requests the conceptual-level processes of all collaborating parties and the contractual spheres from the eSourcing middleware. Next, the collected in-house process, the provider spheres, and the contractual spheres are delivered to a translator that converts the processes into a format the eSCtoIOWF-mapper component and [[Woflan|]] can process. The first component delivers the resulting IOWF-net (see Chapter 5 of my [[PhD thesis|]]) to a flattener component that creates a net, which Woflan verifies for soundness and projection inheritance. For the latter verification type the in-house process is compared with the flattened P/T-net.\n
Dynamic inter-organizational business process management ([[DIBPM]]) combines service-oriented business integration ([[SOBI]]) and [[workflow management|]] as a promising approach for supporting commercial business-to-business ([[B2B|]]) activities over web-based infrastructures. [[SOBI]] applies concepts from the field of service-oriented computing in the domain of dynamic business collaboration. Currently, [[SOBI]] technologies insufficiently support [[B2B|]] collaboration where dynamic matching of structures of service consuming and service providing processes is performed. Collaborating parties want to control how much process detail they expose and which parts of them are monitorable. [[SOBI]] technology should offer rigor that permits verification of desirable features before enactment, e.g., correct termination. Furthermore, current [[SOBI]] technologies lack concepts which are useful for specifying and implementing [[B2B|]] collaborations. Hence, several related critical issues are explored. \n*Firstly, how to manage the inherent conceptual, business, and technological complexity of such business collaboration. \n*Secondly, the issue is addressed of laying a foundation for rigor that is instrumental for verifying control-flow adherence and correct termination of coupled business processes. \nThese requirements need to be guiding for the development of specification languages of inter-organizational business processes and related middleware that enact them in a web-based way. Exploring these critical issues leads to the proposal of //eSourcing// that employs a [[three-level framework]] for tackling the complexity of dynamically matching a service consuming and a service providing process. Furthermore, eSourcing offers rigor by utilizing well explored process theory that results in improved control over inter-organizational business process structure. Finally, the issue of suitability is tackled by discovering inherent eSourcing features that permit the positioning of eSourcing configurations in differing perspectives. Those values are instrumental for subsequently discovering patterns that are translatable into a language for full-fledged [[DIBPM]] support.
The What part has two subsections: the //exchanged value// description and the corresponding //provisions// for the value exchange. In separate subsections in the exchange value section, the values provided by each party are listed. In a case of product exchange, the //product// is described by means of data constructs. In a case of service exchange, the //service// is described through a combination of data and process (workflow) constructs. The corresponding //financial reward// for the received value (in non-barter exchanges) uses the same constructs as a service description subsection. The value //exchange provisions// subsection requires the use of rule and process specification constructs.
The Where part contains provisions related to the context of the e-contract. Two basic aspects of the e-contract context are distinguished, namely the //business// context and the //legal// context. Furthermore, a third subsection can be defined to include //other// e-contract provisions that are not related to the legal and business context. Data item, rule, and process constructs are used in the three subsections.
''Problem:'' The service consumer demands an externalized service where the provider must strictly adhere to the requirements defined in the consumer sphere. Despite having strict service requirements imposed, the provider should still have the flexibility to adjust his service provision to internal requirements. However, these internal adjustments should remain hidden from the service consumer.\n[img[white-box pattern|buildVisibilityWhiteBox.jpg]]\n''Description:''A consumer sphere is fully projected to the external level of an eSourcing configuration. All labels are visible to the provider as they are fully projected to the consumer's contractual sphere. As a result the nodes and labels of the contractual sphere are all present in the provider sphere. However, it is possible for the service provider to insert additional transitions in the provider sphere without violating the agreed upon service behavior.\n''Forces:'' If projection inheritance (see [[eSourcing example]]) is used for provider sphere, it is not trivial for a service provider to adhere as the correct application of refinement rules requires deep knowledge of modeling formalisms when no tool support is available. However, with tool support projection inheritance can be verified by replacing the consumer sphere of the in-house process with the provider sphere. Projection inheritance is given when the resulting net is a subclass of the in-house process.\n''Examples:''\n*For a so-called original equipment manufacturer (OEM) in the automobile industry it is important to reduce the production time per truck to 14 working days. In order to achieve this objective, the OEM pursues a tight integration of suppliers. Given the complexity of producing a truck within the market-dictated time budget, the OEM demands that providers precisely mirror processes that are outsourced to avoid supply problems.\n*The figure above depicts that all nodes, control-flow constructs, and labels of the consumer and contractual sphere are similar and no deviations are contained. While the provider sphere at the bottom of the figure above contains all elements of the contractual sphere, many additional elements are depicted with transitions containing a //tau// label. This means the service consumer is not aware of these additional transitions during build and run time.
There are two types of //actors//, namely parties and mediators. //Parties// are actors that have rights and obligations that are listed in the e-contract. //Mediators// are actors that participate in the e-contract enactment but their rights/obligations are not stated in the e-contract unless they become a party. In that case their rights and obligations are stated in the same or in a separate contract. Finally, the //resource perspective// allows the definition of organizational fact within an actor and how that organization relates to resources. Examples of resources are space, machines, consumable goods, etc.
For CrossWork, eSML (''//e//lectronic //S//ourcing //M//arkup //L//anguage''), has been extended with elements that permit the formulation of business rules that are instrumental for formulating contractual clauses. At the highest level of abstraction of eSML, the contract answers three questions i.e., the [[Who]], [[Where]], and [[What]] question.\n[img[eSML contracting|eSMLoverview.jpg]]\nThe [[Who]] answer concerns the actors that participate in the contract establishment and enactment. The [[Where]] answer models the context of the contract. The [[What]] answer models the exchanged values and the exchange processes and rules. The figure below relates the mentioned elements to each other.\n
eSML contains [[eSourcing patterns]] as elements and attributes of the language schema, (see [[eSML schema]]). Furthermore, eSML covers the control-flow perspective by adopting [[XRL|]]. CrossWork has adopted XRL and its enactment application called [[XRL/flower|]]. [[Data flow|]] is realized by including in the eSML schema earlier specified patterns of this perspective. The [[resource perspective|]] of eSML is represented by adopting a model that permits the capture of organizational and production facts such as machine data, material, space, and so on. These facts are instrumental for achieving an intelligent distribution of tasks, i.e., by paying attention to resource availability and limitations. Code examples are available for the domains:\n*DefiningCollaboratingParties\n*DataDefinitions\n*SpecifyingValueExchanges
The full eSML schema is contained below:\n{{{\n<?xml version="1.0" encoding="uTF-8"?>\n<!-- edited with XML Spy v4.4 U ( by \nAlex Norta (Technische Universiteit Eindhoven) -->\n<xs:schema xmlns:xs="" \nelementFormDefault="qualified" attributeFormDefault="unqualified">\n <!-- PART 1 -->\n <!-- Next, the definition of the data types required in an \n e-contract language are provided. We use the built in the XML \n schema data types and extend them with the required additional \n attributes for a data item. The common attributes for all data \n items are listed in the group of attributes \n "common_var_attributes". We start with the definition of the \n standard data types and continue with the definition \n of the special data types . At the end of this part of the \n eSML schema, we list three predefined set types (i.e., \n "state_type", "constraint_type", "currency_type"). These constant \n sets are used as the data type of attributes of contract elements \n that are defined later on in the language schema. -->\n <!-- definition of standard Variable TYPES -->\n <xs:attributeGroup name="common_var_attributes">\n <xs:attribute name="tag_name" type="xs:string" \n use="required"/>\n <xs:attribute name="var_id" type="xs:ID" use="required"/>\n <xs:attribute name="owner" type="xs:IDREFS" \n use="optional"/>\n <xs:attribute name="changeable" type="xs:boolean" \n use="required"/>\n <xs:attribute name="properties" type="xs:IDREFS" \n use="optional"/>\n <xs:attribute name="enabled" type="state_type" \n use="required"/>\n <xs:attribute name="rules_for_change" type="xs:IDREFS" \n use="optional"/>\n </xs:attributeGroup>\n <!-- Tag "name" attribute is a name from an agreed \n ontology. "var_id" attribute is the unique identifier \n of the data item. "owner" attribute contains a \n reference to an owner of the data item who is allowed \n to update the value of the data item."changeable" \n indicates if the value of the data element can be changed. \n "properties" attribute indicates the properties a data \n element has. "enabled" attribute indicates if the data \n item is currently enabled. The value of this attribute \n is from the defined state_type."rules_for_change" attribute \n is used to indicate the rules in the contract that must \n evaluate to true in order a change to take place. It is \n optional and is used solely for improving the efficiency \n of the monitoring systems. -->\n <xs:complexType name="string_type">\n <xs:simpleContent>\n <xs:extension base="xs:string">\n <xs:attributeGroup ref="common_var_attributes"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <xs:complexType name="real_type">\n <xs:simpleContent>\n <xs:extension base="xs:decimal">\n <xs:attributeGroup ref="common_var_attributes"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <xs:complexType name="integer_type">\n <xs:simpleContent>\n <xs:extension base="xs:integer">\n <xs:attributeGroup ref="common_var_attributes"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <xs:complexType name="boolean_type">\n <xs:simpleContent>\n <xs:extension base="xs:boolean">\n <xs:attributeGroup ref="common_var_attributes"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <!-- Sample definition of data items from the List data type. \n Additional list types can be defined by designers in the schema \n or in the e-contract \n itself. -->\n <xs:simpleType name="list_of_strings_type">\n <xs:list itemType="xs:string"/>\n </xs:simpleType>\n <xs:complexType name="list_of_events_type">\n <xs:sequence>\n <xs:element name="event" type="event_type" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- For the definition of data items from the Record data \n type, contract designers can use the build in XML Schema \n Complex Type element. -->\n <!-- Definition of special data types -->\n <xs:complexType name="date_type">\n <xs:simpleContent>\n <xs:extension base="xs:date">\n <xs:attributeGroup ref="common_var_attributes"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <xs:complexType name="time_type">\n <xs:simpleContent>\n <xs:extension base="xs:time">\n <xs:attributeGroup ref="common_var_attributes"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <xs:complexType name="money_type">\n <xs:simpleContent>\n <xs:extension base="xs:decimal">\n <xs:attributeGroup ref="common_var_attributes"/>\n <xs:attribute name="currency" type="currency_type" \n use="required"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <xs:complexType name="event_type">\n <xs:simpleContent>\n <xs:extension base="xs:boolean">\n <xs:attributeGroup ref="common_var_attributes"/>\n <xs:attribute name="time_of_occurence" type="xs:time" \n use="optional"/>\n <xs:attribute name="date_of_occurence" type="xs:date" \n use="optional"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <!-- For either pushing out or pulling in external data -->\n <xs:simpleType name="access_type">\n <xs:restriction base="xs:string">\n <xs:enumeration value="push"/>\n <xs:enumeration value="pull"/>\n </xs:restriction>\n </xs:simpleType>\n <!-- For referencing variables that are defined in a data_package \n -->\n <xs:complexType name="external_resource_reference_type">\n <xs:simpleContent>\n <xs:extension base="xs:anyURI">\n <xs:attributeGroup ref="common_var_attributes"/>\n <xs:attribute name="access" type="access_type" \n use="optional"/>\n <xs:attribute name="resource_state" \n type="list_of_resource_types" use="optional"/>\n <xs:attribute name="is_legally_binding" \n type="xs:boolean" use="required"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <!--Documents may lso be a part of data packages for data flow. \n -->\n <xs:complexType name="document_type">\n <xs:sequence>\n <xs:element name="document_id" type="xs:ID"/>\n <xs:element name="name" type="xs:string" \n maxOccurs="unbounded"/>\n <xs:element name="file_format" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="uri" type="xs:anyURI" \n maxOccurs="unbounded"/>\n <xs:element name="var_section" \n type="variables_def_section" minOccurs="0"/>\n <!-- specify the structure of the document -->\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="document_def_section">\n <xs:sequence maxOccurs="unbounded">\n <xs:element name="document_read" type="document_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="document_create" type="document_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="document_update" type="document_type" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="list_of_documents">\n <xs:sequence maxOccurs="unbounded">\n <xs:element name="document" type="document_type"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="internal_resource_reference_type">\n <xs:simpleContent>\n <xs:extension base="xs:anyURI">\n <xs:attributeGroup ref="common_var_attributes"/>\n <xs:attribute name="referenced_package" \n type="xs:IDREFS" use="required"/>\n <xs:attribute name="referenced_variable" \n type="xs:IDREFS" use="required"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <!-- Snippets allow inclusion of predefined contract parts. -->\n <xs:complexType name="snippet_type">\n <xs:sequence>\n <xs:any maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attribute name="snippet_id" type="xs:ID" \n use="required"/>\n </xs:complexType>\n <!-- Definition of rule/process state type -->\n <xs:simpleType name="state_type">\n <xs:restriction base="xs:string">\n <xs:pattern value="enabled|disabled"/>\n </xs:restriction>\n </xs:simpleType>\n <!-- Definition of deontic operators -->\n <xs:simpleType name="constraint_type">\n <xs:restriction base="xs:string">\n <xs:enumeration value="must"/>\n <xs:enumeration value="may"/>\n <xs:enumeration value="may_not"/>\n </xs:restriction>\n </xs:simpleType>\n <!-- Definition of static constraints deontic operators -->\n <xs:simpleType name="static_constraint_type">\n <xs:restriction base="xs:string">\n <xs:enumeration value="must_observe"/>\n <xs:enumeration value="may_break"/>\n </xs:restriction>\n </xs:simpleType>\n <!-- Definition of currency types -->\n <xs:simpleType name="currency_type">\n <xs:restriction base="xs:string">\n <xs:enumeration value="USD"/>\n <xs:enumeration value="EUR"/>\n <xs:enumeration value="GBP"/>\n <xs:enumeration value="cAD"/>\n <xs:enumeration value="BGN"/>\n </xs:restriction>\n </xs:simpleType>\n <!-- Definition of resource state types -->\n <xs:simpleType name="list_of_resource_types">\n <xs:list itemType="resource_state_type"/>\n </xs:simpleType>\n <xs:simpleType name="resource_state_type">\n <xs:restriction base="xs:string">\n <xs:enumeration value="available"/>\n <xs:enumeration value="unavailable"/>\n <xs:enumeration value="changed"/>\n </xs:restriction>\n </xs:simpleType>\n <!-- PART 2 -->\n <!-- In the second part of the eSML schema, we provide \n the constructs required for the definition of the integrity, \n derivation, and reaction contract rules. The common for \n all three rule types attributes are extracted in the \n attribute group "common_rule_attributes". A sample set \n of operators that can be used in expressions is provided \n with an illustrative purpose (e.g., the "unary_operator" \n type). The complete set of operators must additionally be \n defined. -->\n <!-- Definition of common rule attributes. In addition to \n the attributes "tag_name", "rule_id", "changeable", \n "enabled" explained in the data item definition section, \n the following attributes are defined:\n The "overrides" attribute indicates which other rule are \n overridden by this rule if they fire together. -->\n <xs:attributeGroup name="common_rule_attributes">\n <xs:attribute name="tag_name" type="xs:string" \n use="required"/>\n <xs:attribute name="rule_id" type="xs:ID" \n use="required"/>\n <xs:attribute name="enabled" type="state_type" \n use="required"/>\n <xs:attribute name="changeable" type="xs:boolean" \n use="required"/>\n <xs:attribute name="overrides" type="xs:IDREFS" \n use="optional"/>\n </xs:attributeGroup>\n <!-- Definition of some operators used in expressions \n in rules. -->\n <xs:simpleType name="unary_operator">\n <xs:restriction base="xs:string">\n <xs:enumeration value="plus"/>\n <xs:enumeration value="minus"/>\n <xs:enumeration value="sqrt"/>\n <xs:enumeration value="percent"/>\n </xs:restriction>\n </xs:simpleType>\n <xs:simpleType name="unary_boolean_operator">\n <xs:restriction base="xs:string">\n <xs:enumeration value="not"/>\n </xs:restriction>\n </xs:simpleType>\n <!-- Next, we start with the definition of Integrity rules \n (distinguishing the two classes of integrity rules, namely \n the "state_constraint_rule_type" and the \n "dynamic_constraint_rule_type"). \n The state_constraint_rule_type construct is a simple \n Boolean expression. The "assigned_to" \n attribute indicates the party (if any) to which the \n constraint is assigned. The "type" attribute indicates if \n the rule obligates the assigned party to observe the rule \n or allows it to break the rule. \n The dynamic_constraint_rule_type construct consists of \n four elements. If the boolean expression evaluates to \n true the rule is in force and the referenced element \n "element_ref" (or attribute of the element \n "element_attribute_ref") may/may not (depending \n on the value of the value of the type attribute) receive \n a new value indicating its new state. The \n "restricted-nonrestricted_values" ellement contains a set \n of allowed/disallowed values. -->\n <!-- Definition of expressions in rule types. \n Expressions in rules are presented as strings that \n are to be parsed by the contract interpretation software \n in order to obtain an expression tree. The expression \n strings can be mixed with references to earlier defined \n variables. -->\n <xs:complexType name="expression" mixed="true">\n <xs:sequence>\n <xs:element name="expression_variable_ref" \n type="xs:IDREF" minOccurs="0" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Definition of the possible rule types and their \n sub-constructs -->\n <xs:complexType name="state_constraint_rule_type">\n <xs:sequence>\n <xs:element name="rule_conditions" \n type="expression"/>\n </xs:sequence>\n <xs:attributeGroup ref="common_rule_attributes"/>\n <xs:attribute name="assigned_to" type="xs:IDREF" \n use="optional"/>\n <xs:attribute name="type" \n type="static_constraint_type" use="optional"/>\n </xs:complexType>\n <xs:complexType name="dynamic_constraint_rule_type">\n <xs:sequence>\n <xs:element name="rule_conditions" \n type="expression"/>\n <xs:element name="element_ref" type="xs:IDREF"/>\n <xs:element name="element_attribute_ref" \n type="xs:IDREF" minOccurs="0"/>\n <xs:element name="restricted-nonrestricted_states" \n type="list_of_strings_type"/>\n </xs:sequence>\n <xs:attribute name="type" type="constraint_type"/>\n <xs:attributeGroup ref="common_rule_attributes"/>\n </xs:complexType>\n <!-- Next, we define the Derivation rule constructs \n (distinguishing the two types of derivation rules, namely \n "computational_derivation_rule_type" and \n "linguistic_derivation_rule_type". The "derived_variable_ref" \n attribute contains a reference to the data items the value \n of which is derived with this rule. "derivation_expression" \n contains a Boolean expression that when evaluating to true \n fires the rule. \n In "linguistic_derivation_rule_type", the \n "property_extended_variable_ref" contains a reference to the \n data item that is given a property when the rule fires. \n "property_to_be_added_ref" contains a reference to a data \n item that contains the property to be added. In this \n approach, we require the properties to be defined as data \n items in the e-contract, as in this way they can be \n referenced by many components and will be from a clearly \n defined data type. However, it is possible linguistic \n derivation rules to be completely replaced by copier reaction \n rules that simply state the new value to be given to the \n data item (in a string format). -->\n <xs:complexType name="computational_derivation_rule_type">\n <xs:sequence>\n <xs:element name="derived_variable_ref" \n type="xs:IDREFS"/>\n <xs:element name="derivation_expression" \n type="expression"/>\n </xs:sequence>\n <xs:attributeGroup ref="common_rule_attributes"/>\n </xs:complexType>\n <xs:complexType name="linguistic_derivation_rule_type">\n <xs:sequence>\n <xs:element name="derivation_expression" \n type="expression"/>\n <xs:element name="property_extended_variable_ref" \n type="xs:IDREF"/>\n <xs:element name="property_to_be_added_ref" \n type="xs:IDREF"/>\n </xs:sequence>\n <xs:attributeGroup ref="common_rule_attributes"/>\n </xs:complexType>\n <!-- Next, the eSML constructs for the support of Reaction \n rules follow. A reaction rule can be from one of the three \n subtypes, i.e., enabler, executive, and copiers. To support \n each of the three types, we provide three sub-constructs \n for each of them. Each reaction rule fires when its \n "rule_conditions" evaluates to true. \n The "enabler_action_type" has two ellements. The \n "target_element" contains a reference to the element the \n state of which will be changed. "new_state" indicates the \n new state that must be assigned to the element (enabled or \n disabled). The "type" attribute indicates the deontic \n assignment to a party (defined in the "assigned_to" \n attribute), i.e., if a party that is owner of the rule \n is obliged/allowed/forbidden to perform the update of the \n status of the element. The "executive_action_type" \n sub-construct indicates through the "Targets" element the \n execution of which process specifications must \n be/may be/cannot be started when the rule fires. The "type" \n attribute indicates the deontic assignment to a party, \n i.e., if a party (defined in the "assigned_to" attribute) \n is obliged/allowed/forbidden to start the execution of the \n process. The "copier_action_type" sub-construct indicates \n which element (the "target_element" element) or its \n attribute (the "target_attribute" attribute) is given \n a new value (the "new_value" attribute). Again the "type" \n attribute indicates the deontic assignment on the owner \n of the rule. -->\n <xs:complexType name="enabler_action_type">\n <xs:sequence>\n <xs:element name="target_element" type="xs:IDREF"/>\n <xs:element name="new_state" type="state_type"/>\n </xs:sequence>\n <xs:attribute name="type" type="constraint_type"/>\n <xs:attribute name="assigned_to" type="xs:IDREF" \n use="optional"/>\n </xs:complexType>\n <xs:complexType name="executive_action_type">\n <xs:sequence>\n <xs:element name="targets" type="xs:IDREFS"/>\n </xs:sequence>\n <xs:attribute name="type" type="constraint_type"/>\n <xs:attribute name="assigned_to" type="xs:IDREF" \n use="optional"/>\n <xs:attribute name="repeatable" type="xs:boolean"/>\n </xs:complexType>\n <xs:complexType name="copier_action_type">\n <xs:sequence>\n <xs:element name="target_element" type="xs:IDREF"/>\n <xs:element name="target_attribute" \n type="xs:string" minOccurs="0"/>\n <xs:element name="new_value" \n type="list_of_strings_type" minOccurs="0"/>\n <!-- besides the assignment of one value, a party \n can be allowed to set one of a set of values (for \n example in the control of a proces status). -->\n </xs:sequence>\n <xs:attribute name="type" type="constraint_type"/>\n <xs:attribute name="assigned_to" type="xs:IDREF" \n use="optional"/>\n </xs:complexType>\n <xs:complexType name="reaction_rule_type">\n <xs:sequence>\n <xs:element name="rule_conditions" type="expression"/>\n <xs:choice>\n <xs:element name="enabler_action" \n type="enabler_action_type"/>\n <xs:element name="executive_action" \n type="executive_action_type"/>\n <xs:element name="copier_action" \n type="copier_action_type"/>\n </xs:choice>\n </xs:sequence>\n <xs:attributeGroup ref="common_rule_attributes"/>\n </xs:complexType>\n <!-- Next, we provide the construct for free-text \n rules. -->\n <xs:complexType name="free_text_rule_type">\n <xs:simpleContent>\n <xs:extension base="xs:string">\n <xs:attributeGroup \n ref="common_rule_attributes"/>\n </xs:extension>\n </xs:simpleContent>\n </xs:complexType>\n <!-- PART 3 -->\n <!-- For the definition of process specification constructs \n in eSML we use as a foundation XRL (eXchangeable Routing \n Language). XRL is an instance-based workflow language that \n uses XML for the representation of process definitions and \n Petri nets for its semantics. A few modifications have been \n applied on XRL. These extensions are marked with \n commentaries. XRL is a prescriptive language which defines \n explicitly the control flow between activities. \n XRL was chosen as process specification language for several \n reasons. First, its XML representation and short schema \n definition allow easy integration and extension to suit the \n eSML goals. Second, the underlying Petri Net semantics in \n XRL allows the Petri net representation of an XRL process \n specification to be analyzed using state-of-the-art analysis \n techniques and tools. Finally, the experience and background \n of using XRL in the IS group at the Technical University \n of Eindhoven allowed easier implementation and maintenance \n in eSML. More information about XRL and its original \n DTD/schema can be found at: \n -->\n <xs:simpleType name="probability">\n <xs:restriction base="xs:decimal">\n <xs:minInclusive value="0"/>\n <xs:maxInclusive value="1"/>\n </xs:restriction>\n </xs:simpleType>\n <xs:attributeGroup name="logistic_attributes">\n <xs:attribute name="cost" type="xs:decimal" u\n se="optional"/>\n <xs:attribute name="min_duration" type="xs:time" \n use="optional"/>\n <xs:attribute name="max_duration" type="xs:time" \n use="optional"/>\n <xs:attribute name="avg_duration" type="xs:time" \n use="optional"/>\n <xs:attribute name="quality" type="probability" \n use="optional"/>\n <!-- quality is defined as how high is the probability \n that the active node (task, block, process) outputs \n the required data-->\n </xs:attributeGroup>\n <xs:attributeGroup name="contextual_information_attributes">\n <xs:attribute name="goal" type="xs:string" \n use="optional"/>\n <xs:attribute name="risk" type="xs:string" \n use="optional"/>\n <xs:attribute name="project_accomplishment" \n type="xs:string" use="optional"/>\n <xs:attribute name="handbook_reference" \n type="xs:anyURI" use="optional"/>\n </xs:attributeGroup>\n <xs:group name="common_elements">\n <xs:choice>\n <xs:element name="interface_in" \n type="interface_type"/>\n <xs:element name="interface_out" \n type="interface_type"/>\n <xs:element name="element_id" \n type="xs:ID" minOccurs="0"/>\n <xs:element name="task" type="task_type"/>\n <xs:element name="sequence" \n type="sequence_type"/>\n <xs:element name="any_sequence" \n type="any_sequence_type"/>\n <xs:element name="choice" type="choice_type"/>\n <xs:element name="condition" \n type="condition_type"/>\n <xs:element name="parallel_sync" \n type="parallel_sync_type"/>\n <xs:element name="parallel_no_sync" \n type="parallel_no_sync_type"/>\n <xs:element name="parallel_part_sync" \n type="parallel_part_sync_type"/>\n <xs:element name="parallel_part_sync_cancel" \n type="parallel_part_sync_cancel_type"/>\n <xs:element name="restricted_parallel_sync" \n type="restricted_parallel_sync_type"/>\n <xs:element name="wait_all" type="wait_all_type"/>\n <xs:element name="wait_any" type="wait_any_type"/>\n <xs:element name="while_do" type="while_do_type"/>\n <xs:element name="terminate" type="terminate_type"/>\n <xs:element name="send_task" type="send_task_type"/>\n <xs:element name="receive_task" type="task_type"/>\n <xs:element name="bi_directional_task" \n type="send_task_type"/>\n <xs:element name="send_transition" \n type="send_transition_type"/>\n <xs:element name="receive_transition" \n type="transition_type"/>\n <xs:element name="bi_directional_transition" \n type="send_transition_type"/>\n <xs:element name="sourcing_sphere" \n type="sourcing_sphere_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="data" type="data_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="lock_change" type="lock_change_type" \n minOccurs="0"/>\n <!-- By placing a data definition into the \n common_elements group, data visibility can be defined on \n a group level, e.g., a sequence, parallel_sync, etc. If the \n data definition takes place on a rout level, the range \n stretches over the entire process. -->\n <!-- Adding data definition in the common elements allows \n visibility on a process and block level. -->\n </xs:choice>\n </xs:group>\n <!-- The lock_type supports workflow data patterns 30 and 31. \n Locks that are initially set or not set when a data package is \n defined may be altered with the lock_change tag. -->\n <xs:complexType name="lock_change_type">\n <xs:sequence>\n <xs:element name="package" type="xs:IDREF" \n maxOccurs="unbounded"/>\n <xs:element name="variable" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="new_lock" type="lock_type"/>\n </xs:sequence>\n </xs:complexType>\n <!-- The lock_type supports workflow data patterns 29 \n and 30 -->\n <xs:simpleType name="lock_type">\n <xs:restriction base="xs:string">\n <xs:enumeration value="read_lock"/>\n <xs:enumeration value="write_lock"/>\n <xs:enumeration value="exclusive_lock"/>\n <xs:enumeration value="none"/>\n </xs:restriction>\n </xs:simpleType>\n <xs:complexType name="lock_definition_type">\n <xs:sequence>\n <xs:element name="lock_owner" type="xs:IDREFS" \n maxOccurs="unbounded"/>\n <xs:element name="lock" type="lock_type"/>\n <!-- A lock owner may be a resource or a modelling \n construct, e.g., a scope, a process, etc. -->\n </xs:sequence>\n </xs:complexType>\n <!-- Data-definition tags. -->\n <!-- A package of data may either be input or output. -->\n <!--May be used to support worflow data pattern 9 and 10. \n States whether a package is input, output, or in_out -->\n <xs:simpleType name="data_flow_direction_type">\n <xs:restriction base="xs:string">\n <xs:enumeration value="input"/>\n <xs:enumeration value="output"/>\n <xs:enumeration value="in_output"/>\n </xs:restriction>\n </xs:simpleType>\n <xs:complexType name="instance_type">\n <xs:sequence>\n <xs:element name="destination_instance" \n type="xs:IDREFS"/>\n <xs:choice>\n <xs:element name="all_instances" \n type="xs:boolean" minOccurs="0"/>\n <xs:element name="instance_number" \n type="xs:integer" minOccurs="0"/>\n <!-- Target all instances of a task \n -->\n <!-- Target a particular task-instance \n number -->\n </xs:choice>\n </xs:sequence>\n </xs:complexType>\n <!-- Packages can be either passed from a source or to \n a target. -->\n <!--A passing destination defines where a package is \n passed on to. -->\n <!-- Workflow data pattern 13 is supported by defining \n a destination case for a package that is valid in \n another case. -->\n <!-- Also workflow data patterns 11 and 12 are supported \n if the a data package passing from task to task is \n including a multiple-instance task. Such a task is \n located in a parallel_non_sync blok. -->\n <xs:complexType name="passing_type">\n <xs:choice>\n <xs:element name="aim_task" type="instance_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="aim_block" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="aim_scope" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="aim_sphere" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="aim_case" type="instance_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="aim_process" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:choice>\n </xs:complexType>\n <!-- Variables and their values of one package can be \n mapped to variables of a destination package. -->\n <xs:complexType name="variable_mapping_type">\n <xs:sequence>\n <xs:element name="from_variable_name" \n type="xs:IDREF"/>\n <xs:element name="to_variable_name" \n type="xs:IDREF"/>\n <xs:element name="transformation_function" \n type="xs:string" minOccurs="0"/>\n <!-- A variable that is mapped may first \n be transformed by a function. -->\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="package_mapping_type">\n <xs:sequence>\n <xs:element name="aim_package" \n type="xs:IDREF"/>\n <xs:element name="variable_mapping" \n type="variable_mapping_type" minOccurs="0" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Data may be visible in one or many cases. -->\n <xs:complexType name="case_visibility_type">\n <xs:sequence maxOccurs="unbounded">\n <xs:element name="case_id" type="xs:IDREFS"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Coverage of workflow data patterns 33 til including 36. \n -->\n <!--This tag is useful for active nodes to define as a \n precondition for enactment the existance of a particular \n variable. -->\n <xs:complexType name="data_existence_condition_type">\n <xs:sequence>\n <xs:element name="package" type="xs:IDREF"/>\n <xs:element name="variable" type="xs:IDREF" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Applicable in active nodes to check the value of a \n particular variable.-->\n <xs:complexType name="data_value_condition_type">\n <xs:sequence>\n <xs:element name="package" type="xs:IDREF"/>\n <xs:element name="value_check_statement" \n type="xs:string" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Below data-package definitions are given for supporting \n various data-flow patterns. -->\n <!--Workflow data pattern 2 is supported by defining data \n package visibility on a block level. -->\n <!-- Supports workflow data pattern 9. When no further \n explicit assignment definitions given, the third option \n of no data passing in workflow data pattern 9 is performed. \n That means all lower-level elements are automatically aware \n of the data package. If additional assignment tags are used, \n then either data passing is performed via a dedicated \n data channel or via an integrated control and data channel, \n i.e., in the latter case data flows along control flow.-->\n <!-- case_visibility supports workflow data pattern 5. \n Here it can be defined if a data package is visible in \n all current cases of a workflow process. -->\n <!-- With case_visibility_range a limitation in accordance \n with workflow data pattern 5 is achieved. The set of cases \n can be specified where a data package is equally visible.-->\n <!-- passing_destination supports workflow data pattern \n 8 for passing data patterns from task to task. -->\n <!--passing_destination is also useful for supporting \n workflow data pattern 9 and 10. When data_type definition \n is on block level. Then explicit data passing from a block \n level to a contained lower-level element can be performed. \n In case of supporting pattern 10, task-level data packages \n can be assigned explicitly to the higher level, e.g., \n a block.-->\n <!--control_flow_passing is useful for workflow data \n pattern 9. When data_types are defined on a block level, \n setting control_flow_passing to true means that an integrated \n control and data channel is used. That means data flows \n from one node to the next along control flow. -->\n <!--If workflow_visibility_range is true, a package is \n visible in all cases of a process for all active nodes \n contained. Supports workflow data pattern 6 -->\n <!--If case_visibility is true, a data package is \n visibility for all cases. Covers workflow data pattern 5. \n Comparable to class variables in OO.-->\n <!-- Workflow data pattern 4 is supported if a data \n package is defined for a task that is instantiated several \n times, e.g., when a task is part of a parallel_no_sync \n block. -->\n <!--Workflow data patterns concerned with internal and \n external data passing (patterns 8 - 25) can be supported \n with the tags passing_destination and passing_origin in \n combination with various tags concerned with visibility. \n -->\n <!--Workflow data patterns 26 and 27 are concerned with \n incoming and outgoing data transfer by value. Such support \n can be achieved when data packages are defined for respective \n tasks and cases. When data needs to be passed from one \n task to another by value, a mapping of a variable and value \n can first take place to a case package. Subsequently the \n variable mapping to a destination task can be repeated \n from a case level. -->\n <!--Workflow data patterns 27 is supported by using a \n data package on a case level from which variables are \n retrieved into a data package on a task level. The data \n with their values are placed back into the case data \n package when the task is near completion.-->\n <!--Workflow data patterns 25 and 26 are supported with \n using tags passing_destination and passing_origin.-->\n <!--Workflow data patterns 31 and 32 are supported with \n using destination_package_mapping and source_package_mapping. \n Instead of passing a data package per se, parts of a data \n package in one process node are mapped on properties of \n another data package at some other location. -->\n <!--Workflow data patterns 33 till 39 are covered by \n business rules data are not part of the data_type tag. -->\n <!--By using sub_level_visibility in combination with \n a data_package definition for a control-flow block element, \n it can be determined to which lower level the data_package \n is visible. For example, if a block has 5 lower levels of \n routing elements and level 4 is defined in a \n sub_level_visibility tag, then elements located on the \n lowest level don't have visibility of the data package, \n i.e., the 5th level below the definition level of the \n data package in question. -->\n <xs:complexType name="data_type">\n <xs:sequence>\n <xs:element name="data_flow_direction" \n type="data_flow_direction_type"/>\n <xs:element name="workflow_visibility_range" \n type="xs:boolean" minOccurs="0"/>\n <xs:element name="case_visibility" type="xs:boolean" \n minOccurs="0"/>\n <xs:element name="case_visibility_range" \n type="case_visibility_type" minOccurs="0"/>\n <xs:element name="passing_destination" \n type="passing_type" minOccurs="0"/>\n <xs:element name="passing_origin" \n type="passing_type" minOccurs="0"/>\n <xs:element name="control_flow_passing" \n type="xs:boolean" minOccurs="0"/>\n <xs:element name="destination_package_mapping" \n type="package_mapping_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="source_package_mapping" \n type="package_mapping_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="sub_level_visibility" \n type="xs:integer" minOccurs="0"/>\n <xs:element name="data_package_ref" \n type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <!-- A scope comprises of several active nodes on a process \n that share a set of data. It covers workflow data pattern 3 \n -->\n <xs:complexType name="data_scope_type">\n <xs:complexContent>\n <xs:extension base="data_type">\n <xs:sequence>\n <xs:element name="process" type="xs:IDREF"/>\n <xs:element name="active_nodes" \n type="xs:IDREFS" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <!-- The following definition creates packages of data that \n may comprise of variables together with their optional values \n and documents. -->\n <xs:complexType name="data_package_type">\n <xs:sequence>\n <xs:element name="package_id" type="xs:ID"/>\n <xs:element name="var_section" \n type="variables_def_section" minOccurs="0"/>\n <xs:element name="document_section" \n type="list_of_documents" minOccurs="0"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Conjoinment perspective supporting types. -->\n <!-- <xs:complexType name="conjoinment_base_type">\n <xs:sequence>\n <xs:element name="destination_URI" \n type="xs:anyURI"/>\n </xs:sequence>\n </xs:complexType> -->\n <xs:complexType name="send_task_type">\n <xs:complexContent>\n <xs:extension base="task_type">\n <xs:sequence>\n <xs:element name="destination_URI" \n type="xs:anyURI" minOccurs="0"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="send_transition_type">\n <xs:complexContent>\n <xs:extension base="transition_type">\n <xs:sequence>\n <xs:element name="destination_URI" \n type="xs:anyURI"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="sourcing_sphere_type">\n <xs:sequence>\n <xs:element name="sphere_id" type="xs:ID"/>\n <xs:element name="owner" type="xs:IDREF" \n minOccurs="0"/>\n <xs:element name="description" type="xs:string" \n maxOccurs="unbounded"/>\n <xs:element name="data" type="data_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="lock_change" \n type="lock_change_type" minOccurs="0"/>\n <xs:group ref="common_elements" \n maxOccurs="unbounded"/>\n <xs:element name="interface_in" \n type="interface_type"/>\n <xs:element name="interface_out" \n type="interface_type"/>\n <!-- should refer to a party -->\n </xs:sequence>\n <!-- When multi-lateral contracting takes place, \n the consumer process contains multiple Sourcing \n spheres. Each Sourcing sphere in the consumer \n process is complemented by a service providing \n process. In the latter case sphere comprises the \n entire service-provision process. -->\n </xs:complexType>\n <xs:complexType name="any_sequence_type">\n <xs:sequence>\n <xs:group ref="common_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attributeGroup \n ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="choice_type">\n <xs:sequence>\n <xs:group ref="common_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="condition_type">\n <xs:choice minOccurs="0" maxOccurs="unbounded">\n <xs:element name="true_branch" \n type="true_branch_type"/>\n <xs:element name="false_branch" \n type="false_branch_type"/>\n </xs:choice>\n <xs:attribute name="condition" \n type="xs:string" use="required"/>\n <xs:attribute name="description" \n type="xs:string"/>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="false_branch_type">\n <xs:sequence>\n <xs:group ref="common_elements"/>\n </xs:sequence>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="parallel_no_sync_type">\n <xs:sequence>\n <xs:group ref="common_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="parallel_part_sync_type">\n <xs:sequence>\n <xs:group ref="common_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attribute name="number" type="xs:NMTOKEN" \n use="required"/>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="parallel_part_sync_cancel_type">\n <xs:sequence>\n <xs:group ref="common_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attribute name="number" type="xs:NMTOKEN" \n use="required"/>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="parallel_sync_type">\n <xs:sequence>\n <xs:group ref="common_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="restricted_parallel_sync_type">\n <xs:sequence>\n <xs:group ref="common_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="sequence_type">\n <xs:sequence>\n <xs:group ref="common_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <!--data_existence_precondition supports workflow data \n pattern 34.-->\n <!--data_existence_postcondition supports workflow data \n pattern 36.-->\n <!--data_value_precondition supports workflow data pattern \n 35.-->\n <!--data_value_postcondition supports workflow data pattern \n 37.-->\n <xs:complexType name="transition_type">\n <xs:sequence>\n <xs:element name="event" type="event_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="data" type="data_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="lock_change" \n type="lock_change_type" minOccurs="0"/>\n <xs:element name="applied_rules" type="xs:IDREFS" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="data_existence_precondition" \n type="data_existence_condition_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="data_value_precondition" \n type="data_value_condition_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="data_existence_postcondition" \n type="data_existence_condition_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="data_value_postcondition" \n type="data_value_condition_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <!-- Support of workflow data pattern 1. Data block \n visibility for the task level.-->\n <!-- this tag covers pattern 1 of the workflow data \n patterns. That way data visibility is realized on a \n task level. -->\n </xs:sequence>\n <xs:attribute name="active_node_id" type="xs:ID" \n use="required"/>\n <xs:attribute name="name" type="xs:string" use="required"/>\n <xs:attribute name="address" type="xs:string" \n use="optional"/>\n </xs:complexType>\n <!-- interface_type is relevant for defining the interfaces \n for supporting a black box pattern -->\n <xs:complexType name="interface_type">\n <xs:complexContent>\n <xs:extension base="transition_type">\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="task_type">\n <xs:complexContent>\n <xs:extension base="transition_type">\n <xs:attribute name="owner" type="xs:IDREF" \n use="optional"/>\n <xs:attribute name="executor" \n type="xs:IDREF" use="optional"/>\n <xs:attribute name="responsible" \n type="xs:IDREF" use="optional"/>\n <xs:attribute name="necessary_resources" \n type="xs:IDREF" use="optional"/>\n <xs:attribute name="result" type="xs:string"/>\n <xs:attribute name="notify" type="xs:string"/>\n <xs:attribute name="enabled" type="state_type"/>\n <xs:attribute name="start_date" \n type="xs:date" use="optional"/>\n <xs:attribute name="start_time" \n type="xs:time" use="optional"/>\n <xs:attribute name="end_date" type="xs:date" \n use="optional"/>\n <xs:attribute name="end_time" type="xs:time" \n use="optional"/>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="terminate_type"/>\n <xs:complexType name="timeout_type">\n <xs:sequence>\n <xs:group ref="common_elements" minOccurs="0"/>\n </xs:sequence>\n <xs:attribute name="time" type="xs:string" use="required"/>\n <xs:attribute name="type" default="absolute">\n <xs:simpleType>\n <xs:restriction base="xs:NMTOKEN">\n <xs:enumeration value="relative"/>\n <xs:enumeration value="s_relative"/>\n <xs:enumeration value="absolute"/>\n </xs:restriction>\n </xs:simpleType>\n </xs:attribute>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="true_branch_type">\n <xs:sequence>\n <xs:group ref="common_elements"/>\n </xs:sequence>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="wait_all_type">\n <xs:choice maxOccurs="unbounded">\n <xs:element name="event_ref" type="xs:IDREF"/>\n <xs:element name="timeout" type="timeout_type"/>\n </xs:choice>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="wait_any_type">\n <xs:choice maxOccurs="unbounded">\n <xs:element name="event_ref" type="xs:IDREF"/>\n <xs:element name="timeout" type="timeout_type"/>\n </xs:choice>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="while_do_type">\n <xs:sequence>\n <xs:group ref="common_elements"/>\n </xs:sequence>\n <xs:attribute name="condition" type="xs:string" \n use="required"/>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n </xs:complexType>\n <xs:complexType name="route">\n <xs:sequence>\n <xs:group ref="common_elements"/>\n <xs:element name="data_scope" \n type="data_scope_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <!-- A Data_scope comprises of several active \n nodes, i.e., task, transition, and all active \n conjoinment nodes. Data_scopes cover workflow \n data pattern 3.-->\n </xs:sequence>\n <xs:attribute name="tag_name" type="xs:string" \n use="required"/>\n <xs:attribute name="process_id" type="xs:ID" \n use="required"/>\n <xs:attribute name="enabled" type="state_type"/>\n <xs:attribute name="created_by" type="xs:string"/>\n <xs:attribute name="date" type="xs:string"/>\n <xs:attributeGroup ref="logistic_attributes"/>\n <xs:attributeGroup \n ref="contextual_information_attributes"/>\n <!-- Control over the process and monitoring rights \n and obligations are specified through deontic \n assignments and reaction rules (executive for \n monitoring and copier reaction rules for control \n rights) -->\n <!-- extension -->\n </xs:complexType>\n <!-- PART 4 Syntax -->\n <!-- In this part, we provide the syntax definitions \n of eSML, i.e., the structure of eSML. First, we \n provide three basic structures, i.e., the Variable \n definition section, Rule definition section, and Process \n definition section. In each of these sections can \n respectively be defined data constructs, rule constructs, \n and process constructs. -->\n <xs:complexType name="variables_def_section">\n <xs:sequence maxOccurs="unbounded">\n <xs:choice>\n <xs:element name="string_var" \n type="string_type"/>\n <xs:element name="real_var" \n type="real_type"/>\n <xs:element name="integer_var" \n type="integer_type"/>\n <xs:element name="boolean_var" \n type="boolean_type"/>\n <xs:element name="date_var" \n type="date_type"/>\n <xs:element name="time_var" \n type="time_type"/>\n <xs:element name="event_var" \n type="event_type"/>\n <xs:element name="money_var" \n type="money_type"/>\n <xs:element \n name="external_resource_reference_var" \n type="external_resource_reference_type"/>\n <xs:element name="list_of_events_var" \n type="list_of_events_type"/>\n <xs:element name="list_of_strings_var" \n type="list_of_strings_type"/>\n <xs:any/>\n <!-- <xs:element \n name="internal_resource_reference_var" \n type="internal_resource_reference_type"/> \n -->\n <!--Supports workflow data pattern 7. \n This way environment data can be brought \n into a data package. -->\n <!-- Required to allow the definition of \n user-defined complex types and lists -->\n </xs:choice>\n <xs:element name="lock_definition" \n type="lock_definition_type" minOccurs="0"/>\n <!-- For data definitions of a data package \n an initial lock can be placed. -->\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="rule_def_section">\n <xs:sequence maxOccurs="unbounded">\n <xs:choice>\n <xs:element name="state_constraint_rule" \n type="state_constraint_rule_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="dynamic_constraint_rule" \n type="dynamic_constraint_rule_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="computational_derivation_rule" \n type="computational_derivation_rule_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="linguistic_derivation_rule" \n type="linguistic_derivation_rule_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="reaction_rule" \n type="reaction_rule_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="free_text_rule" \n type="free_text_rule_type" minOccurs="0" \n maxOccurs="unbounded"/>\n </xs:choice>\n </xs:sequence>\n </xs:complexType>\n <!-- Next, the monitorability patterns are defined.-->\n <xs:complexType name="sink_type">\n <xs:sequence maxOccurs="unbounded">\n <xs:element name="provider_sphere" \n type="xs:IDREF"/>\n <xs:element name="provider_active_node" \n type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="link_properties">\n <xs:sequence>\n <xs:element name="consumer_sphere" \n type="xs:IDREF"/>\n <xs:element name="consumer_active_node" \n type="xs:IDREF"/>\n <xs:element name="provider" \n type="sink_type"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="enactment_properties">\n <xs:sequence>\n <xs:element name="consumer_sphere" \n type="xs:IDREF"/>\n <xs:element name="provider_sphere" \n type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="lifecycle_link_properties">\n <xs:sequence>\n <xs:element name="consumer_sphere" \n type="xs:IDREF"/>\n <xs:element name="consumer_active_node" \n type="xs:IDREF"/>\n <xs:element name="consumer_lifecycle_node" \n type="xs:IDREF"/>\n <xs:element name="provider_sphere" \n type="xs:IDREF"/>\n <xs:element name="provider_active_node" \n type="xs:IDREF"/>\n <xs:element name="provider_lifecycle_node" \n type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="lifecycle_polling_patterns">\n <xs:sequence maxOccurs="unbounded">\n <xs:choice>\n <xs:element \n name="lifecycle_transition_polling" \n type="lifecycle_link_properties" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element \n name="lifecycle_state_polling" \n type="lifecycle_link_properties" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:choice>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="lifecycle_messaging_patterns">\n <xs:sequence maxOccurs="unbounded">\n <xs:choice>\n <xs:element \n name="lifecycle_transition_messaging" \n type="lifecycle_link_properties" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element \n name="lifecycle_state_messaging" \n type="lifecycle_link_properties" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:choice>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="polling_patterns">\n <xs:choice maxOccurs="unbounded">\n <xs:element name="enactment_takeover" \n type="enactment_properties" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="termination_takeover" \n type="enactment_properties" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="transition_polling" \n type="link_properties" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="lifecycle_polling" \n type="lifecycle_polling_patterns" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:choice>\n </xs:complexType>\n <xs:complexType name="messaging_patterns">\n <xs:sequence maxOccurs="unbounded">\n <xs:choice>\n <xs:element name="enactment_propagation" \n type="enactment_properties" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="termination_propagation" \n type="enactment_properties" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="transition_messaging" \n type="link_properties" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="lifecycle_messaging" \n type="lifecycle_messaging_patterns" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:choice>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="monitorability_patterns">\n <xs:sequence>\n <xs:element name="polling" type="polling_patterns" \n minOccurs="0"/>\n <xs:element name="messaging" \n type="messaging_patterns" minOccurs="0"/>\n </xs:sequence>\n </xs:complexType>\n <!-- The definition of life cycles is given. Life cycles may \n be present for a process level, or on a task level. A life \n cycle has control-flow too.-->\n <xs:complexType name="lifecycle_node_type">\n <xs:attribute name="name" type="xs:ID" use="required"/>\n <xs:attribute name="tag_name" type="xs:string" u\n se="required"/>\n </xs:complexType>\n <xs:complexType name="lifecycle_sequence_type">\n <xs:sequence>\n <xs:group ref="lifecycle_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- A nesting state contains further life-cycle nodes. -->\n <xs:complexType name="nesting_state_type">\n <xs:sequence>\n <xs:group ref="lifecycle_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="lifecycle_parallel_sync_type">\n <xs:sequence>\n <xs:group ref="lifecycle_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="lifecycle_parallel_no_sync_type">\n <xs:sequence>\n <xs:group ref="lifecycle_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="lifecycle_parallel_part_sync_type">\n <xs:sequence>\n <xs:group ref="lifecycle_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attribute name="number" type="xs:NMTOKEN" \n use="required"/>\n </xs:complexType>\n <xs:complexType \n name="lifecycle_parallel_part_sync_cancel_type">\n <xs:sequence>\n <xs:group ref="lifecycle_elements" \n maxOccurs="unbounded"/>\n </xs:sequence>\n <xs:attribute name="number" type="xs:NMTOKEN" \n use="required"/>\n </xs:complexType>\n <!-- Below, all elements of a life cycle are grouped \n together. -->\n <xs:group name="lifecycle_elements">\n <xs:choice>\n <xs:element name="transition" \n type="lifecycle_node_type"/>\n <xs:element name="nesting_state" \n type="nesting_state_type"/>\n <xs:element name="atomic_state" \n type="lifecycle_node_type"/>\n <xs:element name="lifecycle_sequence" \n type="lifecycle_sequence_type"/>\n <xs:element name="lifecycle_parallel_sync" \n type="lifecycle_parallel_sync_type"/>\n <xs:element name="lifecycle_parallel_no_sync" \n type="lifecycle_parallel_no_sync_type"/>\n <xs:element name="lifecycle_parallel_part_sync" \n type="lifecycle_parallel_part_sync_type"/>\n <xs:element name="lifecycle_parallel_part_sync_cancel" \n type="lifecycle_parallel_part_sync_cancel_type"/>\n </xs:choice>\n </xs:group>\n <xs:complexType name="lifecycle_details">\n <xs:sequence>\n <xs:group ref="lifecycle_elements"/>\n </xs:sequence>\n <xs:attribute name="process_id" type="xs:IDREF"/>\n </xs:complexType>\n <xs:complexType name="lifecycles">\n <xs:sequence>\n <xs:element name="process_lifecycle" \n type="lifecycle_details" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="active_node_lifecycle" \n type="lifecycle_details" minOccurs="0" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Next, the mapping of life-cycle stages is defined-->\n <xs:complexType name="lifecycle_mapping_details">\n <xs:complexContent>\n <xs:extension base="link_properties">\n <xs:attribute name="mapping_name" \n type="xs:ID" use="required"/>\n <xs:attribute name="node_type">\n <xs:simpleType>\n <xs:restriction base="xs:string">\n <xs:pattern \n value="lifecycle_transition|\n lifecycle_state"/>\n </xs:restriction>\n </xs:simpleType>\n </xs:attribute>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="mapping_details">\n <xs:sequence>\n <xs:element name="process_lifecycle_mapping" \n type="lifecycle_mapping_details" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="active_node_lifecycle_mapping" \n type="lifecycle_mapping_details" minOccurs="0" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="provider_type">\n <xs:sequence maxOccurs="unbounded">\n <xs:element name="provider_process" \n type="xs:IDREF"/>\n <xs:element name="provider_active_node" \n type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="active_node_label_mapping_type">\n <xs:sequence>\n <xs:element name="consumer_process" \n type="xs:IDREF"/>\n <xs:element name="consumer_active_node" \n type="xs:IDREF"/>\n <xs:element name="provider_process" \n type="xs:IDREF"/>\n <xs:element name="provider_active_node" \n type="xs:IDREF"/>\n <xs:element name="provider" \n type="provider_type"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Next, the resource-perspective definition for \n covering the organizational aspect. -->\n <!-- An organizational unit and its subclasses is \n defined. These subclasses are permanent_organizational_unit \n and temporary_organizational_unit -->\n <xs:group name="organizational_unit_elements">\n <xs:sequence>\n <xs:element name="name" type="xs:ID"/>\n <xs:element name="start_date" type="xs:date" \n maxOccurs="unbounded"/>\n <xs:element name="description" type="xs:string" \n maxOccurs="unbounded"/>\n <xs:element name="business_objectives" \n type="xs:string" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="temporary_organizational_unit_type">\n <xs:complexContent>\n <xs:extension base="organizational_unit_type">\n <xs:sequence>\n <xs:element name="end_date" type="xs:date"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="permanent_organizational_unit_type">\n <xs:complexContent>\n <xs:extension base="organizational_unit_type"/>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="organizational_unit_type">\n <xs:sequence>\n <xs:group ref="organizational_unit_elements"/>\n <xs:element name="resource_type" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="resource_nref" \n type="resource_nref_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="collection" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="individual_resource" \n type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="organizational_position_type">\n <xs:sequence>\n <xs:element name="description" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="organizational_unit" \n type="xs:IDREF" maxOccurs="unbounded"/>\n <xs:element name="actor" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="privilege" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Several resource_type may be part of organizational_units. \n A resource_type has subclasses, namely a role, a machine, \n space, and production_material. Furthermore, a resource_type \n is referred by a typed_collection. -->\n <xs:group name="resource_perspective">\n <xs:choice minOccurs="0" maxOccurs="unbounded">\n <xs:element name="machine_type" type="machine_type_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="production_material_type" \n type="production_material_type_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="space_type" type="space_type_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="capability" type="capability_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="privilege" type="privilege_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="power" type="power_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="power_delegation" \n type="power_delegation_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="concrete_collection" \n type="concrete_collection_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="mixed_collection" \n type="mixed_collection_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="typed_collection" \n type="typed_collection_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="resource_nref" \n type="resource_nref_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="available" type="available_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="space" type="space_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="production_material" \n type="production_material_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="containment_type" \n type="containment_type_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="machine" type="machine_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="capacity" type="capacity_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="rate_of_usage" \n type="rate_of_usage_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="actor" type="actor_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="role_delegation" \n type="role_delegation_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="appointment" \n type="appointment_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="correlation" \n type="correlation_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="hierarchy_relationship" \n type="hierarchy_relationship_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="temporary_organizational_unit" \n type="temporary_organizational_unit_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="permanent_organizational_unit" \n type="permanent_organizational_unit_type"\n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="organizational_position" \n type="organizational_position_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="role" type="role_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="connection_relationship" \n type="connection_relationship_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="resource_type" \n type="resource_type_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="collection" \n type="collection_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="individual_resource" \n type="individual_resource_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="non_actor" type="non_actor_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="consumable_resource" \n type="consumable_resource_type" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="organizational_unit" \n type="organizational_unit_type" minOccurs="0" \n maxOccurs="unbounded"/>\n </xs:choice>\n </xs:group>\n <xs:group name="resource_type_elements">\n <xs:sequence>\n <xs:element name="name" type="xs:ID"/>\n <xs:element name="description" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="resource_type_type">\n <xs:sequence>\n <xs:group ref="resource_type_elements"/>\n <xs:element name="typed_collection" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="machine_type_type">\n <xs:complexContent>\n <xs:extension base="resource_type_type"/>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="production_material_type_type">\n <xs:complexContent>\n <xs:extension base="resource_type_type">\n <xs:sequence>\n <xs:element name="production_material" \n type="xs:IDREF"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="space_type_type">\n <xs:complexContent>\n <xs:extension base="resource_type_type">\n <xs:sequence>\n <xs:element name="space" type="xs:IDREF"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <!--A role definition and all related entities.-->\n <xs:group name="role_elements">\n <xs:sequence>\n <xs:element name="qualifications_required" \n type="xs:string" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="skills_required" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="role_type">\n <xs:complexContent>\n <xs:extension base="resource_type_type">\n <xs:sequence>\n <xs:group ref="role_elements"/>\n <xs:element name="power" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="capability" \n type="xs:IDREF" minOccurs="0" \n maxOccurs="unbounded"/>\n <!-- this is refering to required \n capabilities for a certain role -->\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:group name="feature_elements">\n <xs:sequence>\n <xs:element name="name" type="xs:ID"/>\n <xs:element name="description" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="capability_type">\n <xs:sequence>\n <xs:group ref="feature_elements"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="privilege_type">\n <xs:sequence>\n <xs:group ref="feature_elements"/>\n <xs:element name="role" type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="power_type">\n <xs:sequence>\n <xs:group ref="feature_elements"/>\n <xs:element name="capability" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="privilege" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="power_delegation_type">\n <xs:sequence>\n <xs:group ref="timing_elements"/>\n <xs:element name="superior_role" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="inferior_role" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="power" type="xs:IDREF" \n minOccurs="0"/>\n </xs:sequence>\n </xs:complexType>\n <!--The definition of a collection and all subclasses. \n These subclasses are mixed_collection, concrete_collection, \n and typed_collection -->\n <xs:group name="collection_elements">\n <xs:sequence>\n <xs:element name="name" type="xs:ID"/>\n <xs:element name="description" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="collection_type">\n <xs:sequence>\n <xs:group ref="collection_elements"/>\n <xs:element name="organizational_unit" \n type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="concrete_collection_type">\n <xs:complexContent>\n <xs:extension base="collection_type">\n <xs:sequence>\n <xs:element name="individual_resource" \n type="xs:IDREF" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="mixed_collection_type">\n <xs:complexContent>\n <xs:extension base="collection_type">\n <xs:sequence>\n <xs:element name="resource_nref" \n type="resource_nref_type" maxOccurs="unbounded"/>\n <xs:element name="individual_resource" \n type="xs:IDREF" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="typed_collection_type">\n <xs:complexContent>\n <xs:extension base="collection_type">\n <xs:sequence>\n <xs:element name="resource_nref_type" \n type="resource_nref_type" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="resource_nref_type">\n <xs:sequence>\n <xs:element name="resource_type_ref" \n type="xs:IDREF"/>\n <xs:element name="number" type="xs:integer"/>\n <xs:element name="typed_collection_reference" \n type="xs:IDREF"/>\n <xs:element name="mixed_collection_reference" \n type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Resource related definitions. -->\n <xs:group name="individual_resource_elements">\n <xs:sequence>\n <xs:element name="name" type="xs:ID"/>\n <xs:element name="address" type="xs:string" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="individual_resource_type">\n <xs:sequence>\n <xs:group ref="individual_resource_elements"/>\n <xs:element name="available" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="concrete_collection" \n type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="mixed_collection" \n type="xs:IDREF" minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="organizational_unit" \n type="xs:IDREF" maxOccurs="unbounded"/>\n <xs:element name="capability" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:group name="available_type_elements">\n <xs:sequence>\n <xs:element name="number" type="xs:ID"/>\n <xs:element name="start_date" type="xs:date" \n minOccurs="0"/>\n <xs:element name="start_time" type="xs:time" \n minOccurs="0"/>\n <xs:element name="end_date" type="xs:date" \n minOccurs="0"/>\n <xs:element name="end_time" type="xs:time" \n minOccurs="0"/>\n <xs:element name="status" type="xs:string" \n minOccurs="0"/>\n <xs:element name="reserved_for" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="available_type">\n <xs:sequence>\n <xs:group ref="available_type_elements"/>\n <xs:element name="individual_resource" \n type="xs:IDREF" minOccurs="0"/>\n </xs:sequence>\n </xs:complexType>\n <!-- non_actor definition with their subclasses. -->\n <xs:group name="non_actor_elements">\n <xs:sequence>\n <xs:element name="description" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="contact" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="phone" type="xs:integer" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="non_actor_type">\n <xs:complexContent>\n <xs:extension base="individual_resource_type">\n <xs:sequence>\n <xs:group ref="non_actor_elements"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:group name="space_elements">\n <xs:sequence>\n <xs:element name="building_number" \n type="xs:string"/>\n <xs:element name="room_number" \n type="xs:string"/>\n <xs:element name="description" \n type="xs:string" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="capacity" type="xs:string"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="space_type">\n <xs:complexContent>\n <xs:extension base="non_actor_type">\n <xs:sequence>\n <xs:group ref="space_elements"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="consumable_resource_type">\n <xs:complexContent>\n <xs:extension base="non_actor_type"/>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="production_material_type">\n <xs:complexContent>\n <xs:extension \n base="consumable_resource_type"/>\n </xs:complexContent>\n </xs:complexType>\n <xs:complexType name="containment_type_type">\n <xs:sequence>\n <xs:element name="superior_production_material" \n type="xs:IDREF"/>\n <xs:element name="inferior_production_material" \n type="xs:IDREF"/>\n <xs:element name="description" type="xs:string" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="connection_relationship_type">\n <xs:sequence>\n <xs:element name="source_production_material" \n type="xs:IDREF"/>\n <xs:element name="target_production_material" \n type="xs:IDREF"/>\n <xs:element name="description" type="xs:string" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="machine_type">\n <xs:complexContent>\n <xs:extension base="consumable_resource_type">\n <xs:sequence>\n <xs:element name="number" type="xs:string" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:extension>\n </xs:complexContent>\n </xs:complexType>\n <xs:group name="capacity_elements">\n <xs:sequence>\n <xs:element name="amount" type="xs:decimal"/>\n <xs:element name="unit" type="xs:string"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="capacity_type">\n <xs:sequence>\n <xs:group ref="capacity_elements"/>\n <xs:element name="machine" type="xs:IDREF"/>\n <xs:element name="production_material" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:group name="rate_of_usage_elements">\n <xs:sequence>\n <xs:element name="usage_quantity" type="xs:decimal"/>\n <xs:element name="usage_period" type="xs:decimal"/>\n <xs:element name="period_unit" type="xs:string"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="rate_of_usage_type">\n <xs:sequence>\n <xs:group ref="rate_of_usage_elements"/>\n <xs:element name="machine" type="xs:IDREF"/>\n <xs:element name="production_material" type="xs:IDREF" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- actor definition with their subclasses. -->\n <xs:group name="actor_elements">\n <xs:sequence>\n <xs:element name="actor_id" type="xs:ID"/>\n <xs:element name="first_name" type="xs:string"/>\n <xs:element name="last_name" type="xs:string"/>\n <xs:element name="email" type="xs:string" \n maxOccurs="unbounded"/>\n <xs:element name="login_id" type="xs:string"/>\n <xs:element name="phone" type="xs:string" \n maxOccurs="unbounded"/>\n <xs:element name="qualification" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="skill" type="xs:string" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="previous_work_experience" \n type="xs:string" minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="held_responsibility" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="actor_type">\n <xs:sequence>\n <xs:group ref="actor_elements"/>\n <xs:element name="role" type="xs:IDREF" minOccurs="0" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:group name="timing_elements">\n <xs:sequence>\n <xs:element name="description" type="xs:string" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="start_date" type="xs:date" \n minOccurs="0"/>\n <xs:element name="start_time" type="xs:time" \n minOccurs="0"/>\n <xs:element name="end_date" type="xs:date" \n minOccurs="0"/>\n <xs:element name="end_time" type="xs:time" \n minOccurs="0"/>\n </xs:sequence>\n </xs:group>\n <xs:complexType name="role_delegation_type">\n <xs:sequence>\n <xs:group ref="timing_elements"/>\n <xs:element name="source_actor" type="xs:IDREF"/>\n <xs:element name="target_actor" type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="appointment_type">\n <xs:sequence>\n <xs:group ref="timing_elements"/>\n <xs:element name="actor" type="xs:IDREF" \n maxOccurs="unbounded"/>\n <xs:element name="task" type="xs:IDREF" \n maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <!-- The relationships of organizational_unit entities \n to each other is established. That includes hierarchy \n relationships in terms of superior and inferior, and \n a correlation of one organizational_unit to another one, \n e.g., a relationship exists because bith are involved \n in the same project or in the same business process, \n etc.-->\n <xs:complexType name="correlation_type">\n <xs:sequence>\n <xs:element name="description" type="xs:string" \n maxOccurs="unbounded"/>\n <xs:element name="related_to" type="xs:IDREF"/>\n <xs:element name="relation_source" type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="hierarchy_relationship_type">\n <xs:sequence>\n <xs:element name="description" type="xs:string" \n maxOccurs="unbounded"/>\n <xs:element name="superior" type="xs:IDREF"/>\n <xs:element name="inferior" type="xs:IDREF"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Next, the process definition wraps up all respective, \n available elements. -->\n <xs:complexType name="process_def_section">\n <xs:sequence>\n <xs:element name="process" type="route" \n maxOccurs="unbounded"/>\n <xs:element name="lifecycle_definitions" \n type="lifecycles" minOccurs="0"/>\n <xs:element name="lifecycle_mappings" \n type="mapping_details" minOccurs="0"/>\n <xs:element name="active_node_label_mapping" \n type="active_node_label_mapping_type" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="monitorability" \n type="monitorability_patterns" minOccurs="0"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Next, we define the possible combinations of data \n constructs, rule constructs and process constructs that \n can be used in an e-contract sub-structure. -->\n <xs:complexType name="only_vars_section">\n <xs:sequence>\n <xs:element name="var_section" \n type="variables_def_section"/>\n <xs:element name="process_section" \n type="process_def_section" minOccurs="0"/>\n <xs:element name="snippet_section" \n type="snippet_type" minOccurs="0"/>\n <!-- required to support the inclusion of \n externally defined data items. -->\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="vars_and_processes_section">\n <xs:sequence>\n <xs:element name="var_section" \n type="variables_def_section" minOccurs="0"/>\n <xs:element name="process_section" \n type="process_def_section" minOccurs="0"/>\n <xs:element name="snippet_section" \n type="snippet_type" minOccurs="0"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="all_section">\n <xs:sequence>\n <xs:element name="var_section" \n type="variables_def_section" minOccurs="0"/>\n <xs:element name="rule_section" \n type="rule_def_section" minOccurs="0"/>\n <xs:element name="process_section" \n type="process_def_section" minOccurs="0"/>\n <xs:element name="snippet_section" \n type="snippet_type" minOccurs="0"/>\n </xs:sequence>\n </xs:complexType>\n <!-- definition of contract sub-structures of \n the 4W structure-->\n <xs:complexType name="resource_section_type">\n <xs:sequence>\n <xs:group ref="resource_perspective" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:sequence>\n </xs:complexType>\n <xs:complexType name="company_info">\n <xs:sequence>\n <xs:element name="company_data" \n type="only_vars_section"/>\n <xs:element name="company_contact_data" \n type="only_vars_section"/>\n <xs:element name="resource_section" \n type="resource_section_type" minOccurs="0"/>\n <xs:element name="context_section" \n type="only_vars_section" minOccurs="0"/>\n </xs:sequence>\n <xs:attribute name="local_language" \n type="xs:string"/>\n </xs:complexType>\n <xs:complexType name="value_types">\n <xs:choice>\n <xs:element name="product" \n type="vars_and_processes_section" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="service" \n type="vars_and_processes_section" \n minOccurs="0" maxOccurs="unbounded"/>\n <xs:element name="financial_reward" \n type="vars_and_processes_section" \n minOccurs="0" maxOccurs="unbounded"/>\n </xs:choice>\n </xs:complexType>\n <xs:complexType name="list_of_data_packages">\n <xs:sequence maxOccurs="unbounded">\n <xs:element name="data_package" \n type="data_package_type"/>\n </xs:sequence>\n </xs:complexType>\n <!-- Finally, we define the root element of \n the schema and the complete contract \n structure -->\n <xs:element name="contract">\n <xs:complexType>\n <xs:sequence>\n <xs:element name="party" \n type="company_info" \n maxOccurs="unbounded"/>\n <xs:element name="mediator" \n type="company_info" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="data_definition_section" \n type="list_of_data_packages" minOccurs="0"/>\n <xs:element name="business_context_provisions" \n type="all_section" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="legal_context_provisions" \n type="all_section" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="other_context_provisions" \n type="all_section" minOccurs="0" \n maxOccurs="unbounded"/>\n <xs:element name="exchanged_value" \n type="value_types" minOccurs="2" \n maxOccurs="unbounded"/>\n <xs:element name="exchange_provisions" \n type="all_section" minOccurs="2" \n maxOccurs="unbounded"/>\n <xs:element name="agreed_ontology" \n type="external_resource_reference_type" \n maxOccurs="unbounded"/>\n <!--WHO Section contains the description \n of the parties and the possible mediators. \n -->\n <!--WHERE Section contains the description \n of the context of the agreement. -->\n <!--WHAT Section contains the description \n of the exchanged goods/services and the \n conditions for the exchange. -->\n </xs:sequence>\n <xs:attribute name="contract_id" type="xs:ID"/>\n <xs:attribute name="global_language" type="xs:string"/>\n <xs:attribute name="web_service_uri" type="xs:string"/>\n </xs:complexType>\n </xs:element>\n</xs:schema>\n}}}
A reference architecture for supporting electronic interaction between business parties provides the major design principles and specifies the functionalities that must be delivered by such an e-collaboration system. Thus, a reference architecture serves as a starting point for software developers who are occupied with designing and implementing an information system for supporting the automated setup and enactment of business collaboration.\n\nSoftware development consists of three main phases, the analysis, design, and implementation phases . This section presents a conceptual (also known as a logical architecture) reference architecture for collaboration setup and enactment that facilitate the understanding of the interactions between components and the functionalities provided by the system, and are consequently a good technique for the definition of reference architectures. \n\nThe eSourcing reference architecture (eSRA) is designed in accordance with the principle of functional decomposition of a system. This decomposition is also known as separation operation and based on the part-whole principle. Thus, at each refinement level of the eSRA, the identified components provide functionalities that do not overlap with the remaining components that are located at the same level. To achieve completeness, eSRA is designed in a top-down way, i.e., the components on the first level are decomposed into detailing components. eSRA is refined on three levels:\n*FirstLevel\n*SecondLevel\n*ThirdLevel\n
The figure contained in the [[eSourcing example]] needs further control-flow related explanation that is presented informally. The provider contractual sphere is complemented with a provider sphere on the conceptual level of the service provider. Compared to the provider contractual sphere additional nodes are contained on the provider sphere. In the figure refinement is depicted by unlabeled active nodes in the provider sphere that do not exist in the provider's contractual sphere. Such refinement of the service provider's conceptual-level process must be in accordance with //projection inheritance//. That way the service consumer has assurance the provider sphere does not violate the desired service-provision behavior during enactment. Projection inheritance is informally defined as follows:\n\n//If it is not possible to distinguish the behaviors of processes x and y when arbitrary active nodes of x are executed, but when only the effects of active nodes that are also present in y are considered, then x is a subclass of y.//\n\nThus, process //x// inherits the projection of the process definition //y// while process //x// conforms to the dynamic behavior of its superclass by //hiding// active nodes new in //x//. Furthermore, processes in an inheritance relation always have the same termination options. For example, in the figure the refining nodes in the provider conceptual level are visualized as unlabeled nodes that represent, for example, back office tasks. During enactment of the eSourcing configuration in the figure, the service consumer only perceives the behavior of the process defined on the external level without having awareness of the refining nodes. \n
eSourcing within the framework of [[DIBPM]] is essential for the automatic, structural matching of parties who wish to collaborate. The following definition of eSourcing is used: \n\n//In the context of [[DIBPM]], eSourcing is a framework for harmonizing on an external level the intra-organizational [[business processes|]] of a service consuming and one or many service providing organizations into a [[B2B|]] [[supply-chain|]] collaboration. Important elements of eSourcing are the support of different visibility levels of corporate process details for the collaborating counterpart and flexible mechanisms for service monitoring and information exchange.// \n\nThe definition of eSourcing takes into account requirements stemming from surveying the way industrial partners collaborate in the ongoing CrossWork project.
The example of figure below is modelled using labelled [[Petri nets|]]. Squares are denoted as active nodes as they propel the net and circles are denoted as passive nodes representing states. Furthermore, active nodes are always equipped with labels. In a Petri net, passive nodes may contain tokens and active nodes consume these tokens from states. Active nodes are enabled when all their passive input nodes contain at least one token. Such an enabled, active node consumes one token from each of its passive input nodes during firing. After firing, an active node produces tokens that are placed into all its passive output nodes. Arcs in a Petri net do not link two active nodes or two passive nodes with each other. The special type of Petri nets used in Sourcing, namely [[WF-nets|]], has one unique passive input node and one unique passive output node. Furthermore, all other active and passive nodes in a [[WF-net|]] contribute to its processing.\n[img[example of eSourcing|sourcingThreeLayerMonitoring.jpg]]\nThe eSourcing example is modeled within a [[three-level framework]]. In the center of the figure above, the external level is stretching across the respective domains of eSourcing parties where inter-organizational business process matching takes place. Parts of the respective conceptual-level processes are projected to the external level for performing matching to realize automated and dynamically forged collaboration between partners. A matching is successful when the projected processes of a service consumer and a service provider are isomorph. \n\nFurthermore, the figure shows relevant parts of an eSourcing configuration. Starting with the domain of the service consumer, an in-house process is depicted on the conceptual level that is a [[WF-net|]]. The in-house process contains a subnet that is termed a consumer sphere, which is visualized with a grey ellipse. On the border of the consumer sphere, labeled passive nodes are called interface places. Only one interface place is //i//-labeled and only one is //o//-labeled. The other interface places are either //in// or //out//-labeled to represent that exchange direction between the in-house process and its contained consumer sphere. Furthermore, the labeling implies whether an interface place has an input arc or an output arc in the sphere. If an interface place is //i// or //in//-labeled, it has one output arc to an active node in the sphere. If an interface place is //o// or //out//-labeled, it has one input arc from an active node in the spheres.\n\nThe in-house process is mapped to the internal level where legacy systems are located. The consumer sphere is enacted by a different party and therefore projected to the external level to become the consumer contractual sphere. From the opposite eSourcing domain a complementary provider contractual sphere is projected to the external level. Since the respective contractual spheres in the figure are isomorph, a contractual consensus is given between the eSourcing parties, which is the prerequisite for a contract. The [[eSourcing control-flow specifics]] describe further details about the figure above.\n\nFinally, the eSourcing configuration in the figure includes one service consumer and one service provider. However, eSourcing may be extended for multi-party contracting where many providers offer their services to one consumer. Such multi-party eSourcing is realized by nesting consumer spheres. Thus, a global consumer sphere contains nested consumer spheres that are embedded in control flow. The nested consumer spheres are filled with provider spheres from service providers.
[[Patterns|]] for the control-flow, data-flow, exception handling, and resource perspective were discovered empirically after evaluating several workflow management systems and [[WSCLs|]]. However, as the perspective of eSourcing is novel and no supporting systems exist yet, a special approach needs to be taken for discovering patterns.\n\n//A pattern for eSourcing represents a top-down discovered technology independent structure that exists across multiple applications and that has the purpose of offering a predefined, conceptual solution to recurring problems which inter- organizational business process developers are confronted with.//\n\nBy employing the perspective of eSourcing, business processes bridge organizational domains for realizing [[B2B|]] collaboration. Developers of such eSourcing configurations must understand the concept well. Such developers are likely to be repeatedly confronted with particular questions. How should a problem be solved and what are the pros and cons of a particular solution? Which solution should be chosen and how can the solution be realized? How does the selected solution relate to other potential solutions? Since such questions occur repetitively, developers should not have to consistently reinvent the solutions. Instead, developers of eSourcing configurations should have a set of patterns available that offer standard solutions to problems that keep reoccurring.\n\nFor eSourcing, two categories of patterns are specified that are discovered in a top-down way by first creating logical spaces of dimensions:\n*[[Interaction dimensions]]: they focus on the setup-phase of an eSourcing configuration\n*[[Construction dimensions]]: they specify elements that are used for constructing an eSourcing configuration\nThese dimensions lead to the deduction of patterns.
Using several levels for establishing inter-organizational business processes allows to manage the conceptual, business, and technological complexity involved in [[DIBPM]]. \n[img[three-level framework|threeLayerModel.jpg]] \n*The bottom level of the figure above shows the //internal level// where processes are directly enactable by process management applications, e.g., by workflow management systems. Using an internal level in the domains of a service consumer and provider caters towards a heterogenous system environment. \n*On the //conceptual level//, the business processes are designed independent from infrastructure and collaboration specifics. Conceptual processes are mapped to their respective internal level for enactment. A language used on the conceptual level should have clearly defined semantics. \n*The //external level// stretches across the domains of process initiator and responder. Parts of the conceptual processes are projected to the external level to support automated and dynamically forged, process-based collaboration.