CloudSocket Process Terminology
CloudSocket Process Levels
CloudSocket distinguishes three levels of process definitions entitles Level-I to Level-III that are shown in the figure below. Each of these processes is created and consumed by one of the CloudSocket actors.
Level-I: Domain Specific Business Processes
Domain specific business processes that describe the business activities of a worker, which are – in the way they are presented – not executable, neither by a workflow engine within or outside the cloud.
The business process model is defined either by the web modeller or the hybrid BPaaS modeller. It contains a business process definition consisting of individual tasks. In accordance with the Business Process defintion, this model is business-oriented and does not contain any technical implementation or aspects.\\
This business process model is enriched with semantic annotations that eases the semantic lifting at later stages of the project.
Level-II: Executable Workflows
Executable workflows are represented by workflows that orchestrate the interaction between software services. It is expected that one domain specific business process maps typically to many executable workflows depending on the level of automation, the selected services and failure/ recovery/ variant handling.
The executable process model is defined in the Design Environment. Each Level-II process realises a Level-I process, but a Level-I process may be realised by more than one Level-II process (or none). A Level-II process has replaced business-oriented Tasks with technical-oriented orchestration of service invocations. The services have been defined in an abstract manner. That is, the service interface and the semantics have been fixed and so is the invocation sequence (order) of the services (better: service interfaces). At the same time, the actual service instance that shall be used when a process has been triggered and a process instance been created, is not defined yet.
Just as the Level-I business process can be enriched with semantic annotations, this is possible for the Level-II process as well.
Level-III: Cloud deployable Workflow Bundles
Deployable and executable workflows that are packaged for cloud deployment consisting of all relevant configurations, so that it can be deployed in the cloud on demand. It is expected that one executable workflow maps typically to many cloud deployable workflow bundles depending on different cloud providers, the selected SLAs and deployment management strategies and multi cloud deployment.
Such a workflow bundle is created in the Allocation environment. Here, the service interfaces from the Level-II process get bound to concrete service instances provided by third parties or to software components that provide the same interface, but have to be self-hosted by the execution environment together with the BPaaS hosting.
Also Level-III processes can be semantically enriched in order to help the execution environment when deploying them.
Level-IV: Deployed Workflow Bundle in Production
This reflects a bundle that has already been deployed in the cloud such that it can be exploited by the customer that has purchased it. The corresponding workflow of the bundle is ready to be instantiated and executed. One cloud deployable workflow bundle can map to many deployed workflow bundles in production.
Level-V: BPaaS Instance
This model reflects the state of the deployed workflow bundle. This phase of BPaaS is not yet fully elaborated by the consortium.
Funding Partners
Horizon 2020