Common Understanding Wiki

Common Understanding Wiki

A Common Knowledge Source of Terms and Definitions

Back

CloudSocket Common Understanding Wiki

(You are viewing an archived version of this page. (5.1), Go to the latest version.)
Wiki: General

Common Technical Understanding of Business Process as a Service #

This wiki tries to achieve a common technical understanding of Business Process as a Service including the intended usage. involved persons (roles), and technical requirements/constraints. In all cases, we strictly separate the use of the platform from the technical concepts that realise its functionality. This section also introduces a set of abbreviations that are summarised on the Glossary page.

Business Processes vs Workflows #

Business Processes are seen as a sequence of manual, semi-automatic and automatic actions with the aim to achieve an organisational goal.

The focus is to align all actions within an organisation with the business goals, independent if they are performed by machines, humans or a group consisting of several machines and / or several humans. Actions are typically described in time, role and place dependent, hence every "hand-over" of a task, or any "reminder" to again come back to a task is seen as the border of an activity.

There is a set of different application field for business processes such as but not limited to quality management, risk management, re-engineering, continues improvement, documentation, training but also model driven architecture and requirement analysis. The first set of application fields have clearly the model as "Information Value Provider" in mind, hence graphical models are not seen as some necessary step to move on to concrete sofware code, but are seen as an independent document type that is necessary to perform day to day work within the organisation.

The second set of application fields is concerned with, the model driven architecture, software requirement analysis, configuration of software components or software design. In such application scenarios the so-called business and IT alignment must be performed by bridging form the domain centric business process towards the technology centric workflows.

Workflows are seen as a sequence of executable software components that are interpreted as a configuration set for a workflow engine, which automatically invokes the sequence of software components.

Bridging from business towards workflows hence means to bridge the semantic distance from domain knowledge to technical configuration.

Business Process as a Service #

Business Process as a Service (BPaaS) represents an Internet-based service where different users (so far unspecified) can register business processes, register implementations for business processes, select, annotate, and enact these processes or groups thereof.

From the view of the NIST definition, BPaaS is either a special form of Software as a Service or a very limited form of Platform as a Service (cf. Cloud Service Models and NIST Standard).

CloudSocket #

In that sense, CloudSocket is a software platform that enables BPaaS.

A cloud providers that offers the CloudSocket service runs a CloudSocket Instance and is called CloudSocket ProviderFrom a functional point of view, CloudSocket is equipped with a Business Process Marketplace (Design Repository) that provides access to existing pre-defined business processes as well as to implementations thereof. The CloudSocket platform consists of four key environments: design, allocation, execution, evaluation. 

Design Environment #

A graphical modeller provides access to business processes from the design repository and enables the semantic annotation of Busines Process Models, as well as workflows.The semantic annotations capture for instance the possibility to impose performance constraints and further non-functional requirements on the business process as well as on individual tasks within this process. This environment either outputs a modelled abstract business process with semantic annotations to the allocation environment or an executable business process directly to the execution environment.  

The model will typically be defined in BPMN, BPMN 2.0, or as Abstract BPEL programmes; the executable business process will be defined in BPEL or as an Executable Business Process Model.  

Allocation Environment #

The allocation environment receives as an input workflow descriptions together with references to extenal third party services to use as well as high-level deployment configuration settings. It then packages up these artefacts into a self-contained, user-manageable Cloudlet

Execution Environment #

The Execution Engine takes a Cloudlet and is instantiated leading to a Cloudlet Instance. This requires that the following steps be executed.

  1. The Cloudlet needs to be instantiated in the sense that its management becomes possible. This requires that the necessary resources to manage the Cloudlet and the workflows it runs be acquired: be it on IaaS platforms such as Amazon EC2 or be it with other third party service providers.In particular, the management interface of the Cloudlet needs to be bound to an accessible URI and necessary triggers to start workflows need to be instantiated.
  2. The Cloudlet needs to be bound to third party (Web) service instances it requires to perform the workflows. 
  3. Monitoring tools have to be established.

Evaluation Environment #

The evaluation environment first collects data logs from all involved services and normalises them. Furthermore, it then maps the collected information to semantic properties of the business processes contained in the Design Repository. The results from this monitoring will then be taken into account when the very same Business Process is enacted for the next time.

Users and Roles #

Multiple types of persons/users are involved in the entire CloudSocket environment. These are depicted on a separante page. The most important are briefly classified, named, and described here.

  1. CloudSocket Provider: runs an instance of CloudSocket and offers the service to the other parties.
  2. Business Process Modeller: uses the graphical modelling interface to define busines process
  3. Executable Business Process Modell Publisher: provides executable processes; multiple EBPMs may match a single Business process.
  4. Business Process Operator: User of CloudSocket in the sense that it specifies requirements and has the platform create a Cloudlet. Is the instance to be billed by the CloudSocket Provider.
  5. Business Process User: The actual person/set of persons interacting with the Business Process realised through the Cloudlet, e.g. a case worker in a personnal department. Very likely that this person belongs to the same institution as the operator.

Where is the Cloud in CloudSocket? #

Besides the aaS naming that is typically used for anything that is (supposed to be) offered in a cloud-like manner, cloud systems are commonly defined by capabilities beyond the naming. The main feature of these is elasticity/scalability of the entities provided as a service. For CloudSocket elasticty plays a role with respect to.

Cloud service What you get ...how to scale?
IaaS Virtual Machine more virtual machines
bigger virtual machines
PaaS Run-time environment application instances
SaaS Application <not possible>
BPaaS Business process (Cloudlet) use other (more scalable) remote services?
run Cloudlet on bigger virtual machine?
run multiple Cloudlet instances?
spawn orchestration engine on further virtual machines.

Managed Entities and Lifecycles #

The overall set-up and functionality as described above yields several entities that require an individual management including their own lifecycle.

  1. Business Process Modell whose lifecylce is managed by the Design Environment and changed by he Business Process Modeller
  2. Executable Business Process Modell whose lifecycle is managed by the Design Environment and changed by the Executable Business Process Model Publisher
  3. Cloudlet, i.e. Workflow including management interface. It is created by the Allocation Environment and later changed/configured by the Execution Environment 
  4. Business Process/Workflow instances are created by the Cloudlet and orchestrated by the orchestration engine contained in the Cloudlet

MISC\\ #

T2.2 Common Technical Understanding of Business Process as a Service [UULM]
This task is concerned with creating documents like public WIKI pages, BPaaS taxonomies and explaining background material in order to create a common understanding with respect to technical realisation for business process as a service in the cloud. The starting point is the Business-process and IT alignment Wiki based on the Zachmann framework and describing business process and IT relevant modelling languages. This addresses four communities: (1) the business process management community addressing BPaaS - Design by providing definitions, standards tools, approaches and samples. Business and IT alignment aspects are considered via semantic lifting of business process models, IT infrastructure model, workflow models and cloud service component models; (2) for the BPaaS Allocation a model-driven approach in order to create BPaaS Cloudlets is described by elaborating the use of UML concept models, semantics and smart mechanisms to check the consistency and correctness. (3) for the BPaaS execution the workflow and SOA community providers the computer orchestration view point with standards and tools. Multi-cloud access and the service management across several cloud-infrastructures are described and approaches are pointed out; (4) the BPaaS Evaluation Environment defines how QoS and SLA need to be lifted to QoBP and how meta model extraction can be used for process monitoring in a multi-Cloud environment.


In addition the concept of “Conceptual Analytics” that uses any semantically lifted conceptual meta model to map extracted meta data form process monitor logs is elaborated. The aim of this task is create a starting point for creating a common understanding. Hence main effort is to collect, describe and explain all used concepts not only for the consortium members but mainly for other cooperative projects, so that applied principles, methods and approaches are clearly explained to be easily identified for other projects and third party member.


This Wiki offers a BPaaS taxonomy as well as an explanation of background material in order to create a common understanding with respect to technical realisation for business process as a service in the cloud.



6 Attachments
11574495 Views
Average (1 Vote)
Comments
No comments yet. Be the first.