Difference between revisions of "CarLogistics"
Bucchiarone (talk | contribs) (→How to use) |
Bucchiarone (talk | contribs) (→Basic technology) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
== Basic technology == | == Basic technology == | ||
| − | Adaptive and context-aware service-based systems are modeled by defining a set of entities. Each of them features its own business process and its provided services. Business processes are modeled as ''Adaptable Pervasive Flows'' (APFs) [ | + | Adaptive and context-aware service-based systems are modeled by defining a set of entities. Each of them features its own business process and its provided services. Business processes are modeled as ''Adaptable Pervasive Flows'' (APFs) [4], an extension of traditional workflow language (e.g., BPEL) which makes them more suitable for adaptation and execution in dynamic environments. In addition to the classical workflow language constructs, APFs add the possibility to model abstract activities. An abstract activity is defined at design time in terms of the goal it needs to achieve and is dynamically refined at run-time into an executable process, considering the set of available services, the current execution context and its goal. |
Each entity can provide a set of ''services'' to the other entities. We consider services to be stateful: they can expose complex protocols (e.g., BPEL) combining traditional service actions (i. e., sending/receiving messages to/from services) with control flow structures (e.g. switch, while, pick). | Each entity can provide a set of ''services'' to the other entities. We consider services to be stateful: they can expose complex protocols (e.g., BPEL) combining traditional service actions (i. e., sending/receiving messages to/from services) with control flow structures (e.g. switch, while, pick). | ||
| − | The ''application context'' is modeled as a set of context properties, each describing a particular aspect of an application domain. Every context property is modelled with a context property diagram, which is a state transition system capturing all possible property values and value changes. Each transition is labeled with a corresponding context event. A context property may evolve as an effect of service invocations, which corresponds to the normal behavior of the domain, but also as a result of volatile exogenous changes. | + | The ''application context'' is modeled as a set of context properties, each describing a particular aspect of an application domain. Every context property is modelled with a context property diagram, which is a state transition system capturing all possible property values and value changes. Each transition is labeled with a corresponding context event. A context property may evolve as an effect of service invocations, which corresponds to the normal behavior of the domain, but also as a result of volatile exogenous changes. |
== How to use == | == How to use == | ||
| − | The structure for | + | The structure for the artifacts repository is depicted below. |
<pre> | <pre> | ||
carlogistics | carlogistics | ||
| Line 33: | Line 33: | ||
| − | '''Entities (Entity Folder) | + | '''Entities (Entity Folder)''' |
| + | |||
| + | Our target applications are modeled defining a set of entities (as depicted in the following Figure). Each of them is specified considering its own ''business process'' and its ''provided services''. | ||
[[File:Artifacts.png|600px|thumb|center|Modeling Artifacts]] | [[File:Artifacts.png|600px|thumb|center|Modeling Artifacts]] | ||
| + | '''Services (Services Folder)''' | ||
| + | We consider services to be stateful. Statefulness implies that services can expose complex protocols (e. g., specified in BPEL). To model such services, we use state transition systems, where transitions correspond to service actions (i.e. sending/receiving messages to/from services or performing internal assignments and decisions). Each transition can be additionally annotated with context preconditions (P) and effects (E). Preconditions constrain execution of a service action to certain context configurations while effects are context events that are fired when the action is executed. | ||
| + | |||
| + | '''Context Properties (Object Folder)''' | ||
| + | The application context is modeled as a set of context properties, each describing a particular aspect of an application domain. Every context property is modeled with a context property diagram, which is a state transition system, capturing all possible property values and value changes. Each transition is labeled with the corresponding context event. | ||
| + | |||
| + | '''Business Processes (Processes Folder)''' | ||
| + | Business processes executed by each entity are modeled as Adaptable Pervasive Flows (APFs), an extension of traditional workflow language (i.e., BPEL) which make them more suited for adaptation and execution in dynamic environments. In addition to the classical workflow language constructs, APFs add the possibility to model abstract activities. An abstract activity is defined at design time in terms of the goal it needs to achieve and is dynamically refined at run-time into an executable process, considering the set of available services, the current execution context and its goal | ||
| Line 51: | Line 61: | ||
The specification of the CLS we used to evaluate our approach is composed by 29 entities, 69 services and 40 context properties. | The specification of the CLS we used to evaluate our approach is composed by 29 entities, 69 services and 40 context properties. | ||
Moreover to see the ASTRO-CAptEvo framework in action, one can download the complete demo and a video of a live demonstration from: http://www.astroproject.org/captevo. | Moreover to see the ASTRO-CAptEvo framework in action, one can download the complete demo and a video of a live demonstration from: http://www.astroproject.org/captevo. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Additional info == | == Additional info == | ||
Latest revision as of 13:44, 27 April 2012
Contents
Description
We present a logistic scenario, based on the sea port of Bremen, and a context-aware dynamic service-based system to support its operation. The scenario is based on the operation of the sea port of Bremen, Germany, where nearly 2 million new vehicles are handled each year; the business goal is to deliver them from a manufacturer to a dealer. Each car, depending on its brand, model and specific order, needs to follow certain customizable procedures during the delivery process. Cars arrive by ship and are unloaded and unpacked at a certain terminal. Each ship is able to approach and leave a gate interacting with the landing manager, which is in charge of coordinating and controlling the landing procedure for all the ships in the port. Once a car is unpacked to a terminal, a communication is established with the storage manager to book a place at storage facilities. The storage place is located in one of the available storage areas, each having its own parking procedure and suitable for a specific car type (e.g., covered/guarded areas for luxury cars). Once a stored car is ordered by a retailer, it continues its way towards the delivery. In particular, cars are treated at dedicated treatment areas (such as washing, painting, equipment, repairing) according to the details in the order. When a car is ready to be delivered, it is assigned to an available delivery gate and truck. The latter is responsible for loading a limited number or cars and deliver them to the dealer.
The goal is to develop an application (the Car Logistics System, CLS) to support the management and operation of the port as described above, where numerous actors (i.e., cars, ships, trucks, treatment areas, etc.) need to co-operate in a synergic manner respecting their own procedures and business policies. The system needs to deal with the dynamicity of the scenario, both in terms of the variability of the actors’ procedures (customizable processes), and of the exogenous context changes affecting its operation. Customization means that different brands and models of cars should be treated in a similar but customizable way. Moreover new car models, having specific requirements and procedures, must be easily integrated in the application. Similarly, the application needs to flexibly deal with changes in the procedures of external entities such as ships and trucks. Finally, the application needs to promptly implement changes in international regulations and laws.
Basic technology
Adaptive and context-aware service-based systems are modeled by defining a set of entities. Each of them features its own business process and its provided services. Business processes are modeled as Adaptable Pervasive Flows (APFs) [4], an extension of traditional workflow language (e.g., BPEL) which makes them more suitable for adaptation and execution in dynamic environments. In addition to the classical workflow language constructs, APFs add the possibility to model abstract activities. An abstract activity is defined at design time in terms of the goal it needs to achieve and is dynamically refined at run-time into an executable process, considering the set of available services, the current execution context and its goal.
Each entity can provide a set of services to the other entities. We consider services to be stateful: they can expose complex protocols (e.g., BPEL) combining traditional service actions (i. e., sending/receiving messages to/from services) with control flow structures (e.g. switch, while, pick).
The application context is modeled as a set of context properties, each describing a particular aspect of an application domain. Every context property is modelled with a context property diagram, which is a state transition system capturing all possible property values and value changes. Each transition is labeled with a corresponding context event. A context property may evolve as an effect of service invocations, which corresponds to the normal behavior of the domain, but also as a result of volatile exogenous changes.
How to use
The structure for the artifacts repository is depicted below.
carlogistics
|
`- artifacts
|-- Entities
|-- Services
|-- Objects
`-- Processes
The structure takes into account the Modeling artifacts that are explained below.
Entities (Entity Folder)
Our target applications are modeled defining a set of entities (as depicted in the following Figure). Each of them is specified considering its own business process and its provided services.
Services (Services Folder) We consider services to be stateful. Statefulness implies that services can expose complex protocols (e. g., specified in BPEL). To model such services, we use state transition systems, where transitions correspond to service actions (i.e. sending/receiving messages to/from services or performing internal assignments and decisions). Each transition can be additionally annotated with context preconditions (P) and effects (E). Preconditions constrain execution of a service action to certain context configurations while effects are context events that are fired when the action is executed.
Context Properties (Object Folder) The application context is modeled as a set of context properties, each describing a particular aspect of an application domain. Every context property is modeled with a context property diagram, which is a state transition system, capturing all possible property values and value changes. Each transition is labeled with the corresponding context event.
Business Processes (Processes Folder) Business processes executed by each entity are modeled as Adaptable Pervasive Flows (APFs), an extension of traditional workflow language (i.e., BPEL) which make them more suited for adaptation and execution in dynamic environments. In addition to the classical workflow language constructs, APFs add the possibility to model abstract activities. An abstract activity is defined at design time in terms of the goal it needs to achieve and is dynamically refined at run-time into an executable process, considering the set of available services, the current execution context and its goal
We have created a visualization environment enabling interaction between the framework and the user and simulating execution and adaptation of business processes in our case study. In particular, it can:
(i) run the CLS and simulate the execution and adaptation of each business process attached to each entity and
(ii) view the different adaptation strategies supported by our framework and how they are used during the scenario execution.
The goal of this demonstrator is to show the novel concepts and advantages of the ASTRO-CAptEvo Framework when applied to a real and complex pervasive system.
Download
All the artifacts of the Car Logistics Scenario (CLS) can be downloaded from: http://www.astroproject.org/downloads/artifacts.zip. The specification of the CLS we used to evaluate our approach is composed by 29 entities, 69 services and 40 context properties. Moreover to see the ASTRO-CAptEvo framework in action, one can download the complete demo and a video of a live demonstration from: http://www.astroproject.org/captevo.
Additional info
[1] F. Bose and J. Piotrowski. Autonomously controlled storage management in vehicle logistics applications of RFID and mobile computing systems. International Journal of RT Technologies: Research an Application, 1(1):57–76, 2009.
[2] A. Bucchiarone, M. Pistore, H. Raik, R. Kazhamiakin: Adaptation of service-based business processes by context-aware replanning. SOCA 2011: 1-8
[3] A. Bucchiarone, A. Marconi, M. Pistore, and H. Raik. CAptEvo: Context-aware Adaptation and Evolution of Business Processes. In Proc. ICSOC’11 - Demo, 2011.
[4] K. Herrmann, K. Rothermel, G. Kortuem, and N. Dulay. Adaptable Pervasive Flows - An Emerging Technology for Pervasive Adaptation. In Workshop on Pervasive Adaptation (PerAda). IEEE Computer Society, September 2008.
[5] A. Marconi, M. Pistore, and P. Traverso. Automated Composition of Web Services: the ASTRO Approach. IEEE Data Eng. Bull., 31(3):23–26, 2008.
