CHAPTER 2: VIRTUAL ENTERPRISES
2.4 L IFE -C YCLE M ODEL FOR D YNAMIC V IRTUAL E NTERPRISE
A life-cycle model usually describes the key phases and activities required during the existent of an entity. According to ISO (ISO 91 and 94), a life cycle can be defined as “the finite steps a system may go through over its entire life history. The different life cycle phases define types of activities which are pertinent during the life cycle of the entity”. In our case, the VE life-cycle model consists of two key phases that should be followed for the establishment and management of a VE. Every phase consists of more specific steps that describe the main operations that should be done by different human roles from technical point of view. It should be noted that the following life-cycle model is best applied in the DVE model that is the core work of this thesis.
In order to better understand the life-cycle model, the following scenario is provided. A Company called On-line-Books sells books to customers on-line. Part of the book-selling business process is the distribution process, i.e. the delivery of the book to the customer. On-line-Books has not a particular way to distribute the books and looks for a logistic partner to outsource this process. The On-line Books company knows exactly the properties and attributes of the distribution process. In order to find potential partners with logistic capabilities, On-Line Books deploys a third party virtual marketplace that provides matchmaking services for logistic companies.
The virtual marketplace specified several logistic process templates for different logistic services. One of the logistic process templates is the book delivery process. This process template has, for example, as properties the destination, the price for the delivery, the payment method, when the payment should be done, delivery day, the guaranty in case of problems, etc.
Logistic companies, that can deliver books, use the standard book delivery process template and register their process offerings into a particular marketplace by specifying their terms and conditions.
When a customer orders a book from the On-line-Books, the company searches the marketplace, locates the potential logistic partners, negotiate with them about the price, location, delivery day, time, quantity, etc. and selects the most suitable one. The selection of the partner is highly associated with the characteristics of the customer, i.e. his location and preferences. Then, the Book-On-Line uses the logistic process provided by the selected partner and serves the customer. When a new customer comes and places a book order into the shopping system of the company, the company uses again the marketplace and locates, negotiates, and selects probably another logistic company that can better satisfy the requirements of the new customer.
The above scenario is a very typical, though simplistic, one that reveals most of the characteristics of the DVEs concept. In order to support a scenario like this, a management platform for the management of DVEs is required (Ouzounis 98d, Stricker 00, Camaritha-Matos 99). In more general terms , the following definitions and concepts are provided in relation to the life cycle model and this thesis specifically.
In general, a VE is a set of business domains that jointly and dynamically co-operate to provide value-added services to a customer in a transparent way, i.e. the customer does not know about the existence of the different business domains involved in the service provision. A business domain is a administrative domain that pose its own resources, infrastructure, and services and impose its own restrictions and regulations on them in terms of access control and authentication. Business domains jointly co-operate by sharing services, i.e. one business domain deploys services provided by one or more other business domains in a consistent and well-regulated way. Every request for a service deployment from one domain is checked for permission by the requested domain. The access control and authorisation of requests before the service provision is based on a temporary contract that has been agreed by both domains, i.e. by both the requestor and supplier. The business domain that requests a service by one domain is called the requestor while the domain that provides the service is called the supplier.
The technical representation of a service is a business process. The business process can be either, local or remote. All the processes provided in self -contained manner by this domain are called local processes. Therefore, a domain has full control of its own local processes and can impose any type of access control constraints. On the contrary, when a process could not be provided by one particular domain, but should be deployed by a remote one, is called remote. A process that is considered remote for domain A, is local for the supplier of this process. This means that local and remote processes can be represented technically in a similar way but they differentiate to the way that domains “look at and interpret ” them.
The domain that provides a service, i.e. a business process, directly to a customer is called the VE representative. The process that is provided by the VE representative to the customer is called VE process. The VE representative domain represents the VE in the outside world in a similar way like a normal company. The domains that participate in the provision of VE processes in the context of the VE are called VE partners. Initially, when the different business domains have no relationships among them, i.e. they do not share any processes, are called VE candidate partners. A VE candidate partner is becoming VE partner after a negotiation process that involves the potential requestor of the process and the potential supplier of the process.
When an agreement is reached then the potential supplier becomes a VE partner. This negotiation process is done dynamically and during the provision of VE process to the customer.
The agreement might last for only one business process deployment or for several ones.
A normal business domain becomes potential VE partner when it registers the business processes that can offer to a third party marketplace. In that case, the domain specifies which local processes can be provided to other domains and under which terms and conditions these processes will be provided, e.g. price. The virtual marketplace provider maintains for different processes different service templates that describe the service. A service template has a name, a set of named properties and can be associated with other existing service templates. When a VE candidate partner declares that can offer a particular service, it always associates this offer with an existing service template. When a service template is not available, a new one can be generated by the marketplace administrator for consistency. When a service can be provided by different VE candidate partners, then offers associated with this service are stored and managed by the marketplace. Each individual VE candidate partner can change dynamically the context of its own offer by updating or improving it.
Local and remote business processes are represented technically in the same way using for example a business process definition language. In general, a process has a name, a set of input parameters, a set of output parameters, a set of sub-processes, a set of tasks, and a set of
conditions. The input parameters are the input values to the process, while the output parameters are the output values of the process. A process might consist of sub-processes in a recursive manner. For every subprocess, in a similar manner like the process, a name, input and output parameters, sub-processes, sub-tasks and conditions can be specified. This leads to a directed acyclic graph of processes, subprocesses and tasks. A task is considered the final, unique, elementary piece of activity that can be included within a process. Actually, tasks are the computational elements of the process while processes and sub-processes orchestrating and co-ordinating the scenario of the process by scheduling the tasks based on conditions. With every process, sub-process, and task conditions can be associated. Conditions are logical expressions related to input, output, and external values with some logical operators. When a condition, which is related to a process or task, is true, then the associated process or task should be scheduled. By this decomposition of processes into sub-processes and tasks a complex service can be easily described. The specification of a business process could be done by using a business process definition language. This business process definition language provides all the necessary syntactic means to specify processes, sub-processes, tasks, and conditions.
When a process consists of sub-processes and tasks belonging to the same administrative domain and can be provided in an autonomous way by this domain, then the process is called local. If there is one sub-process that cannot be provided by this domain, then this sub-process is called remote and, in that case, a supplier domain should be found. If, for this remote process, one static supplier has been found, then the VE relationship is called static. If, for every remote process, a supplier is found dynamically during the process provision, then the VE relationship is called dynamic. If the partners of a VE have not static relationships among them, but on the contrary, they negotiate among each other during process execution then the VE is called dynamic VE.
From the above description and definitions, it is obvious that different administrative domains participate in the execution and management of dynamic VE services. These domains are the:
• Customer domain: this is the domain of the user that deploys the services of the VE. The user in this domain can start a service, suspend, resume, or terminate it. When the service is completed the results of the service are returned to the customer. Additionally, if, during the execution of the service, a critical situation occurs, the service is aborted and the customer is informed about the event.
• VE representative domain: this is the domain that the customer logs on and requests certain services. This is actually the domain that represents the VE to the external world. It executes and manages processes in a transparent to the customer way by deploying the capabilities of the marketplace and the remote processes of other business domains. The VE representative domain provides and manages the execution of the VE services by conducting the marketplace, locating candidate partners, negotiating with them, and selecting the best one for the execution of the remote processes,
• VE Candidate/Partner domain: this is the domain that offers a set of business processes to the marketplace community and registers certain offers related to specific service templates for potential co-operation with other domains. If this domain is finally selected after a negotiation process it becomes the VE partner domain that will provide the agreed processes to other domains,
• Virtual Marketplace domain: this is a third party domain that provides the service templates that the VE candidate partners use to register their offers. This domain manages
the service templates, the offers registered by the VE candidate domains, and provides retrieval services for the selection of VE candidate partners. This domain does not actively participate in the VE and thus does not provide any type of business process management services.
Having defined the key domains and the roles taking part in dynamic VEs, the lifecycle model finally consists of the following key phases:
• Business Process Specification and Registration Phase: during that phase the different business domains should specify their local and remote business processes. The specification of business process is performed by deploying a business process definition language. In the sequel, every domain registers for every local process corresponding offers to the virtual marketplace by declaring the terms and conditions under which these local processes will be offered to other domains,
• Business Process Management Phase: during that phase, a business domain offers services to customers by deploying the dynamic model of the marketplace. Whenever a customer requests a service, the corresponding domain initially starts the provision of the service. If the requested service consists of remote sub-processes, that should be provided by other domains, then the business domain conducts the marketplace, locates all the potential VE candidate partners, and negotiates with them dynamically in order to select the best one that satisfies certain selection and negotiation criteria. When a VE partner has been found, then the initial domain, that serves the customer, requests the remote process from the newly selected VE partner. The provision of the whole process is totally transparent for the customer. During the provision of the service, the customer can manage the service, i.e.
he can suspend, resume, or terminate the execution of it. Every management request from the customer, e.g. suspend, is forwarded to all VE partners, i.e. the management of VE services should be performed in a autonomous, distributed and cross-organisational way.