Technical Architecture #

Meanwhile the WP2 finishes the analysis of requirements, we can start to work with the definition of the environments based on the involved tools. Afterward, we can review and map the different requirements with the functionalities. The idea is to advance as much as possible in parallel with the definition of the stakeholders and requirements.

You can see here a draft structure of the architecture definition

Vision #

This section provides a general vision and summaries of our objectives. This allow us in the second cycle to review these and analyze the results.

• CloudSocket Architecture consist of four main building blocks:
  • Business Process Design Environment
  • Business Process Allocation Environment
  • Business Process Execution Environment
  • Business Process Evaluation Environment

• Each Building Block is autonomous and loosely coupled with other building blocks
• Main functional capability of each building block is described to that extend that is necessary for the other components
• Data exchange format and APIs are described in detail
• Building blocks are intentend to be realised by different applications, hence a vendor lock is avoided as any solution can be exchanged by another one that follows the same data exchange format and provides the same APIs.

Architecture #

This section will present the CloudSocket architecture, and the introduction of the four environments which it is composed of, their roles, interfaces and interchanging messages. So, the following subsections will discuss an overview of the architecture in the context of the BPaaS life cycle. Finally, we should include the future steps to implement the architecture are outlined.

#

ApproachRequirements and stakeholders. #

They will come from the analysis of the WP2, we need to identify both technical and business requirements (these one are more complicated, but it will great to do the exercise).

Scenarios and functions. #

Through the inputs of the WP2, we can derive a set of usage scenarios (UML notation, use case scenarios) that provides high-level coverage for the principal functionalities should offer to stakeholders. The identified functionalities should be covered by the different environments

• Broker is designing a Business Process in order to offer those on the marketplace. Hence the broker uses the BPaaS Desinger to design business processes.
• Broker and Process Provider are allocating necessary resources for Cloud deployment. Hende the broker with the help of the process provider or service provider are allocating the process by adding deployment relevant information such as data structure of controll flow.
• Process Provider offers processes in the cloud in form of a market place to the end user. The market place for the end user offere a set of different processes the user can select from. Each Broker has its own marketplace, hence this is a front end device offered by the process provider and hosted by the broker
• Service Provider offers services as part of the process to the process provider
• Broker uses the evaluation environment to access log data from the process provider. Those evaluation data are then offered to the end end users as additional service to optimize the SLA.

CloudSocket architecture. #

After this analysis (previous sections), we will be able to include the general picture, which includes the high-level interactions of all environments. It is separated into four distinct environments layers.

#

Building Block Interaction #

1) BPaaS Design Package #

This is a package consiting of Interfaces that provide

• Business Process in BPMN format
• Annotations according the BPaaS ontology for deployment in RDFS format

The following picture explains the approach by using two interaction channels. First interaction channell is concerned with the exchange of content in a well-known format. In this case BPMN notation is used to describe the business process. As current existing standards - such as BPMN in that particular case - are not developed for the purpose applied in CloudSocket, there is the necessity to extend those standards. In order to be flexible in those extensions, tool and standard independent, a so-called "semantic lifting" approach had been selected. This appraoch introduces a second channel, the so called "Meta-Data" channel that transport those elements that are not able to be transported in the original content channel. Semantic lifting means that the business process model is annotated by referecing to semantic concepts of a central concept reference ontology, hence they are lifted from traditional expression to an extended - semantic - expression refering to the meaning of the central reference ontolgoy. Those concepts are transfered in a separate channel, wherease the reference from individual objects of the business process specified in BPMN format in the content channel and the corresponding additional semantic descriptions, can be resvolved, by the resulting two data streams.

The interaction is triggered on demand by invoking the method:

• getBPaaSDesignPackageContent(int id), to receive a BPMN file, as well as
• getBPaaSDesignPackageMetaData(int id), to recieve the corresponding meta data to the identified id.
• getAllBPaaSDesignPackages() return a list of all ids, the business process names, a business process description and the meta data properties that presents the semantic lifting of the whole business process.

2) BPaaS Execution Strategy

This is a package of Interfaces that provide

• Busienss Process in BPMN format, as an image as well as additional xml format for specific content.
• Annotation according BPaaS ontolgoy for data schema, data types and execution startegy

The BPaaS Design Environment is the direct user inteface to the business end users. Hence it is likely that in addition to orchestration information - such as the alingment of workflows to business processes - there are also additional requests that need to be considered by the operating workflow middleware.

Hence the data channel provides the same Business Process Model in BPMN format than in the aforementioned Design Package. This information is not only necessary to identify the process id, but additional information is required to create the BPaaS markeplace. This marketplace for business processes that are capable to be run within the Cloud are represented in the way the end users is used to see the process (in BPMN notation), hence the original representation must be provided. In addition to the business process format, a picture of the business process is provided, to ease the development of the BPaaS marketplace, by displaying the image, rather than interpreting the whole business process. Additional xml file is expected to deliver marketplace relevant information, that are not covered in the typical BPMN format.

The second channel - the meta data channel - provides again a semantic lifting to the central reference ontolgy, with respect to deployment and execution startegies.

3) BPaaS Cloudlet

....@ FHOSTER please add

4) BPaaS Monitoring

....@ FORTH please add

5) BPaaS Findings

This is a package of Interfaces that provide

• QoS ontology in RDFS / OWL (?) format

CloudSocket Environments #

We need to decide the level of details to describe the environments?

• Mapping requirements with functionalities.
• Internal architecture.
• Identification and high-level description of the different components.
• Base line technologies.
• Components diagrams.
• Sequence diagrams.
• External interfaces and the common message MetaData. They will cover the interaction between the different environments

Every environment is composed by components/modules. We have to provide the information on each component. But, which level of description do we need to introduce in the different components?

• including descriptions of features.
• implementation level detail in the form of UML diagrams?
• Include the state of the art within the introduction of each component?

Design environment #

Allocation environment #

Execution environment #

Evaluation environment. #