Technical Architecturehttps://site.cloudsocket.eu/web/guest/common-understanding-wiki/-/wiki/3308022024-03-28T18:00:04Z2024-03-28T18:00:04ZFrontPage 1.3Wilfrid Utzhttps://site.cloudsocket.eu/web/guest/common-understanding-wiki/-/wiki/330802/FrontPage2016-09-19T13:01:15Z2016-09-19T13:01:15Z<h1 id="section-FrontPage-Technical+Architecture"> Technical Architecture <a class="hashlink" href="#section-FrontPage-Technical+Architecture">#</a></h1><p>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. </p><p>You can see here a draft structure of the architecture definition </p><h2 id="section-FrontPage-Vision"> Vision <a class="hashlink" href="#section-FrontPage-Vision">#</a></h2><p>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. </p><ul><li>CloudSocket Architecture consist of four main building blocks:<ul><li>Business Process Design Environment</li><li>Business Process Allocation Environment</li><li>Business Process Execution Environment</li><li>Business Process Evaluation Environment</li></ul></li></ul><ul><li>Each Building Block is autonomous and loosely coupled with other building blocks</li><li>Main functional capability of each building block is described to that extend that is necessary for the other components</li><li>Data exchange format and APIs are described in detail</li><li>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.</li></ul><h2 id="section-FrontPage-Architecture"> Architecture <a class="hashlink" href="#section-FrontPage-Architecture">#</a></h2><p>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. </p><h3 id="section-FrontPage-"> <a class="hashlink" href="#section-FrontPage-">#</a></h3><h3 id="section-FrontPage-ApproachRequirements+and+stakeholders."> ApproachRequirements and stakeholders. <a class="hashlink" href="#section-FrontPage-ApproachRequirements+and+stakeholders.">#</a></h3><p>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). </p><h3 id="section-FrontPage-Scenarios+and+functions."> Scenarios and functions. <a class="hashlink" href="#section-FrontPage-Scenarios+and+functions.">#</a></h3><p>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 </p><ul><li> <strong>Broker </strong>is designing a Business Process in order to offer those on the marketplace. Hence the broker uses the BPaaS Desinger to design business processes.</li><li>Broker and <strong>Process Provider</strong> 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.</li><li>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</li><li> <strong>Service Provider</strong> offers services as part of the process to the process provider</li><li>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.</li></ul><p><img src="http://20.0.1.43:9785/c/wiki/get_page_attachment?p_l_id=50776&nodeId=25641&title=FrontPage&fileName=Marketplace.png" /> </p><h3 id="section-FrontPage-CloudSocket+architecture."> CloudSocket architecture. <a class="hashlink" href="#section-FrontPage-CloudSocket+architecture.">#</a></h3><p>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. </p><h3 id="section-FrontPage-"> <img src="http://20.0.1.43:9785/c/wiki/get_page_attachment?p_l_id=50776&nodeId=25641&title=FrontPage&fileName=Architecture-HighLevel-v1.0-20150318.png" /> <a class="hashlink" href="#section-FrontPage-">#</a></h3><h3 id="section-FrontPage-Building+Block+Interaction"> Building Block Interaction <a class="hashlink" href="#section-FrontPage-Building+Block+Interaction">#</a></h3><h4 id="section-FrontPage-1)+BPaaS+Design+Package"> 1) BPaaS Design Package <a class="hashlink" href="#section-FrontPage-1)+BPaaS+Design+Package">#</a></h4><p>This is a package consiting of Interfaces that provide </p><ul><li>Business Process in BPMN format</li><li>Annotations according the BPaaS ontology for deployment in RDFS format</li></ul><p>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. </p><p>The interaction is triggered on demand by invoking the method: </p><ul><li>getBPaaSDesignPackageContent(int id), to receive a BPMN file, as well as</li><li>getBPaaSDesignPackageMetaData(int id), to recieve the corresponding meta data to the identified id.</li><li>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.</li></ul><p><img src="http://20.0.1.43:9785/c/wiki/get_page_attachment?p_l_id=50776&nodeId=25641&title=FrontPage&fileName=BPaas-DesignPackage.png" /> </p><p>2) BPaaS Execution Strategy </p><p>This is a package of Interfaces that provide </p><ul><li>Busienss Process in BPMN format, as an image as well as additional xml format for specific content.</li><li>Annotation according BPaaS ontolgoy for data schema, data types and execution startegy</li></ul><p>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. </p><p>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. </p><p>The second channel - the meta data channel - provides again a semantic lifting to the central reference ontolgy, with respect to deployment and execution startegies. </p><p><img src="http://20.0.1.43:9785/c/wiki/get_page_attachment?p_l_id=50776&nodeId=25641&title=FrontPage&fileName=ExecutionStrategy.png" /> </p><p>3) BPaaS Cloudlet </p><p>....@ FHOSTER please add </p><p><img src="http://20.0.1.43:9785/c/wiki/get_page_attachment?p_l_id=50776&nodeId=25641&title=FrontPage&fileName=BPaaS-Cloudlet.png" /> </p><p>4) BPaaS Monitoring </p><p>....@ FORTH please add </p><p>5) BPaaS Findings </p><p>This is a package of Interfaces that provide </p><ul><li>QoS ontology in RDFS / OWL (?) format</li></ul><h2 id="section-FrontPage-CloudSocket+Environments"> CloudSocket Environments <a class="hashlink" href="#section-FrontPage-CloudSocket+Environments">#</a></h2><p>We need to decide the level of details to describe the environments? </p><ul><li>Mapping requirements with functionalities.</li><li>Internal architecture.</li><li>Identification and high-level description of the different components.</li><li>Base line technologies.</li><li>Components diagrams.</li><li>Sequence diagrams.</li><li>External interfaces and the common message MetaData. They will cover the interaction between the different environments</li></ul><p>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? </p><ul><li>including descriptions of features.</li><li>implementation level detail in the form of UML diagrams?</li><li>Include the state of the art within the introduction of each component?</li></ul><h3 id="section-FrontPage-http://Design+environmentDesign+environment"> <a href="http://Design environment">Design environment</a> <a class="hashlink" href="#section-FrontPage-http://Design+environmentDesign+environment">#</a></h3><h3 id="section-FrontPage-Allocation+environment"> Allocation environment <a class="hashlink" href="#section-FrontPage-Allocation+environment">#</a></h3><h3 id="section-FrontPage-Execution+environment"> Execution environment <a class="hashlink" href="#section-FrontPage-Execution+environment">#</a></h3><h3 id="section-FrontPage-Evaluation+environment."> Evaluation environment. <a class="hashlink" href="#section-FrontPage-Evaluation+environment.">#</a></h3>Wilfrid Utz2016-09-19T13:01:15ZAdapter Framework 1.1Wilfrid Utzhttps://site.cloudsocket.eu/web/guest/common-understanding-wiki/-/wiki/330802/Adapter+Framework2016-09-19T13:00:19Z2016-09-19T13:00:19Z<table id="toc"> <tr> <td> <ul> <li><a href="#Adapter_Framework"><span class="tocnumber">1</span> <span class="toctext">Adapter Framework</span></a><ul> <li><a href="#Overview"><span class="tocnumber">1.1</span> <span class="toctext">Overview</span></a><ul> <li><a href="#Challenges"><span class="tocnumber">1.1.1</span> <span class="toctext">Challenges</span></a></li> <li><a href="#Ambition"><span class="tocnumber">1.1.2</span> <span class="toctext">Ambition</span></a></li> </ul></li> <li><a href="#Implementation"><span class="tocnumber">1.2</span> <span class="toctext">Implementation</span></a><ul> <li><a href="#RESTFul_Web_Services"><span class="tocnumber">1.2.1</span> <span class="toctext">RESTFul Web Services</span></a><ul> <li><a href="#Functional"><span class="tocnumber">1.2.1.1</span> <span class="toctext">Functional</span></a></li> </ul></li> <li><a href="#Plugins"><span class="tocnumber">1.2.2</span> <span class="toctext">Plugins</span></a></li> </ul></li> <li><a href="#Standards"><span class="tocnumber">1.3</span> <span class="toctext">Standards</span></a><ul> <li><a href="#OData"><span class="tocnumber">1.3.1</span> <span class="toctext">OData</span></a><ul> <li><a href="#OData_CSDL_-_Common_Schema_Definition_Language"><span class="tocnumber">1.3.1.1</span> <span class="toctext">OData CSDL - Common Schema Definition Language</span></a></li> </ul></li> <li><a href="#RESTdesc"><span class="tocnumber">1.3.2</span> <span class="toctext">RESTdesc</span></a></li> <li><a href="#Hydra_-_Hypermedia-Driven_Web_APIs"><span class="tocnumber">1.3.3</span> <span class="toctext">Hydra - Hypermedia-Driven Web APIs</span></a></li> <li><a href="#JSON-LD"><span class="tocnumber">1.3.4</span> <span class="toctext">JSON-LD</span></a></li> <li><a href="#LDP_-_Linked_Data_Platform"><span class="tocnumber">1.3.5</span> <span class="toctext">LDP - Linked Data Platform</span></a></li> <li><a href="#RDF_-_Resource_Description_Framework"><span class="tocnumber">1.3.6</span> <span class="toctext">RDF - Resource Description Framework</span></a></li> <li><a href="#OWL_-_Web_Ontology_Language"><span class="tocnumber">1.3.7</span> <span class="toctext">OWL - Web Ontology Language</span></a></li> <li><a href="#RIF_-_Rule_Interchange_Format"><span class="tocnumber">1.3.8</span> <span class="toctext">RIF - Rule Interchange Format</span></a></li> <li><a href="#SPARQL_-_SPARQL_Protocol_and_RDF_Query_Language"><span class="tocnumber">1.3.9</span> <span class="toctext">SPARQL - SPARQL Protocol and RDF Query Language</span></a></li> <li><a href="#WADL_-_Web_Application_Description_Language"><span class="tocnumber">1.3.10</span> <span class="toctext">WADL - Web Application Description Language</span></a></li> </ul></li> </ul></li> </ul> </td> </tr> </table> <a name="Adapter_Framework"></a><h1><span>Adapter Framework</span></h1> <p><b>Goal:</b> Unified Adapter Framework for SaaS for syntactical integration</p> <a name="Overview"></a><h2><span>Overview</span></h2> <a name="Challenges"></a><h3><span>Challenges</span></h3> <p><b>Cloud Service and Component Interoperability</b>.</p> <p>Flexible definition of BPaaS requires plug-and-play of identified Cloud services or Cloud application components. Hence, it must overcome vendor lock and consider interaction frameworks and implement adapters enabling the data exchange during an orchestration.</p> <p>The Challenge is in <b>developing interfaces and adapters</b> to existing Cloud services for interoperability.</p> <p><b>Execution Phase</b>. First, common adapters and interfaces need to be established, second common data streams need to be applied, before the process Orchestrator can run workflows within a multi-Cloud environment, performing self-adaptive deployment and managing the BPaaS quality</p> <a name="Ambition"></a><h3><span>Ambition</span></h3> <p><b>Heterogeneous Cloud capable BPaaS Execution Environment</b></p> <p>Current SaaS Adapter frameworks only deal with service provisioning and single-sign on and do not aim to expose the specific behaviour of each such solution (e.g. managing customers in CRM, uploading documents in ECM, exporting Excel data in Office365). Furthermore financial management (e.g. metering, chargeback) and service-level agreements are concerns not typically approached in a unified and generic manner.</p> <p>The CAMP (Cloud Application Management for Platforms) (CAMP 2012) Technical Committee aims at defining models, mechanisms and protocols for the management of applications in, and their use of, a PaaS environment. The focus of the TC is to develop an interoperable protocol for PaaS (self-service) management interfaces for cloud users to use in developing, deploying and the administration of their applications. The TC aims at defining interfaces for self-service provisioning, monitoring and control. CAMP is only a protocol specification; therefore it needs to be implemented by parties adopting the protocol.</p> <p>The OASIS TOSCA (“Topology and Orchestration Specification for Cloud Applications”) (TOSCA 2012) Technical Committee aims at enhancing the portability of cloud applications and services. The main aim of TOSCA is to enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behaviour of these services, independently from the supplier creating the service, and any particular cloud provider or hosting technology. By increasing service and application portability in a vendor-neutral ecosystem, TOSCA aims at enabling portable deployment to any compliant cloud, smoother migration of existing applications to the cloud, as well as dynamic, multi-cloud provider applications.</p> <p><b>Our proposal:</b> A generic framework to adapt Cloud service solutions and provide a unified approach for service integration, delivery and composition. This framework will cover the entire lifecycle of such a product, from provisioning of tenants, users and applications, going through management of such entities and enriching these with product specific behaviours and operations abstracted in a generic way, all the while proving information about monitoring and metering events.\\</p> <p>It will consist of a set of generic programming contracts and set of APIs, based on REST and JSON, easily extensible with metadata specific to each provider. These APIs will deal with use cases like: Single Sign On, Provisioning of Tenant, Users and Subscription, Metering, Monitoring and can be extended to implement SaaS provider specific use cases.</p> <p>Three sets of APIs to be implemented:</p> <ol> <li><b>Provisioning and Management APIs</b>: deals with Tenant, User, Application provisioning/deprovisioning and management.\\</li> <li><b>Monitoring and Metering APIs</b>: in order to receive events, either correlated to the outbound request or uncorrelated related to metering and monitoring.</li> <li><b>Generic Functional APIs</b>: will deal with abstracting the solution specific behaviours: create, read, update delete operations specific for each SaaS product.</li> </ol> <a name="Implementation"></a><h2><span>Implementation</span></h2> <a name="RESTFul_Web_Services"></a><h3><span>RESTFul Web Services</span></h3> <a name="Functional"></a><h4><span>Functional</span></h4> <ol> <li>Service Definition</li> <li>Service Discovery</li> <li>Service Security</li> <li>Service Policy (QoS)</li> <li>Service Management</li> </ol> <a name="Plugins"></a><h3><span>Plugins</span></h3> <a name="Standards"></a><h2><span>Standards</span></h2> <a name="OData"></a><h3><span>OData</span></h3> <p><a class="externallink" rel="nofollow" href="http://www.odata.org/">http://www.odata.org/</a></p> <p>An open protocol to allow the creation and consumption of queryable and interoperable RESTful APIs in a simple and standard way. OData (Open Data Protocol) is an OASIS standard that defines the best practice for building and consuming RESTful APIs.</p> <p>OData RESTful APIs are easy to consume. The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools. Some of them can help you interact with OData even without knowing anything about the protocol.</p> <a name="OData_CSDL_-_Common_Schema_Definition_Language"></a><h4><span>OData CSDL - Common Schema Definition Language</span></h4> <p><a class="externallink" rel="nofollow" href="http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part3-csdl.html">http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part3-csdl.html</a></p> <p>OData services are described by an Entity Data Model (EDM). Common Schema Definition Language (CSDL) defines an XML-based representation of the entity model exposed by an OData service. An OData service SHOULD provide a CSDL description of its entity model when a client requests a description of the entity model by sending a GET request to /$metadata.</p> <a name="RESTdesc"></a><h3><span>RESTdesc</span></h3> <p><a class="externallink" rel="nofollow" href="http://restdesc.org/about/descriptions">http://restdesc.org/about/descriptions</a></p> <p>Semantic descriptions for hypermedia APIs. Simply describe functionality. Functionality captures the essentials of APIs, and RESTdesc aims to describe this. Resources and their hyperlinks make up the cornerstones of descriptions.</p> <a name="Hydra_-_Hypermedia-Driven_Web_APIs"></a><h3><span>Hydra - Hypermedia-Driven Web APIs</span></h3> <p><a class="externallink" rel="nofollow" href="http://www.markus-lanthaler.com/hydra/">http://www.markus-lanthaler.com/hydra/</a></p> <p>Hydra is an effort to simplify the development of interoperable, hypermedia-driven Web APIs. The two fundamental building blocks of Hydra are JSON‑LD and the Hydra Core Vocabulary.</p> <p>JSON‑LD is the serialization format used in the communication between the server and its clients.</p> <pre> The Hydra Core Vocabulary represents the shared vocabulary between them. By specifying a number of concepts which are commonly used in Web APIs it can be used as the foundation to build Web services that share REST's benefits in terms of loose coupling, maintainability, evolvability, and scalability. </pre> <p>Furthermore it enables the creation of generic API clients instead of requiring specialized clients for every single API.</p> <a name="JSON-LD"></a><h3><span>JSON-LD</span></h3> <p><a class="externallink" rel="nofollow" href="http://json-ld.org/">http://json-ld.org/</a></p> <p>JSON for Linking Data. JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale. Linked Data empowers people that publish and use information on the Web. It is a way to create a network of standards-based, machine-readable data across Web sites. Describes a method of publishing structured data so that it can be interlinked and become more useful through semantic queries.</p> <a name="LDP_-_Linked_Data_Platform"></a><h3><span>LDP - Linked Data Platform</span></h3> <p><a class="externallink" rel="nofollow" href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a></p> <p>Linked Data Platform (LDP) defines a set of rules for HTTP operations on web resources, some based on RDF, to provide an architecture for read-write Linked Data on the web.</p> <a name="RDF_-_Resource_Description_Framework"></a><h3><span>RDF - Resource Description Framework</span></h3> <p><a class="externallink" rel="nofollow" href="http://www.w3.org/RDF/">http://www.w3.org/RDF/</a></p> <p>The Resource Description Framework (RDF) is a specifications originally designed as a metadata data model. It has come to be used as a general method for conceptual description or modeling of information that is implemented in web resources, using a variety of syntax notations and data serialization formats.</p> <p>RDF is a standard model for data interchange on the Web. RDF has features that facilitate data merging even if the underlying schemas differ, and it specifically supports the evolution of schemas over time without requiring all the data consumers to be changed.</p> <a name="OWL_-_Web_Ontology_Language"></a><h3><span>OWL - Web Ontology Language</span></h3> <p><a class="externallink" rel="nofollow" href="http://www.w3.org/TR/owl2-overview/">http://www.w3.org/TR/owl2-overview/</a></p> <p>Knowledge representation languages for authoring ontologies.</p> <p>OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents.</p> <a name="RIF_-_Rule_Interchange_Format"></a><h3><span>RIF - Rule Interchange Format</span></h3> <p><a class="externallink" rel="nofollow" href="http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/">http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/</a></p> <p>RIF focused on exchange rather than trying to develop a single one-fits-all rule language because, in contrast to other Semantic Web standards.</p> <a name="SPARQL_-_SPARQL_Protocol_and_RDF_Query_Language"></a><h3><span>SPARQL - SPARQL Protocol and RDF Query Language</span></h3> <p><a class="externallink" rel="nofollow" href="http://www.w3.org/TR/sparql11-overview/">http://www.w3.org/TR/sparql11-overview/</a></p> <p>A RDF query language, that is, a semantic query language for databases, able to retrieve and manipulate data stored in Resource Description Framework (RDF) format.</p> <a name="WADL_-_Web_Application_Description_Language"></a><h3><span>WADL - Web Application Description Language</span></h3> <p><a class="externallink" rel="nofollow" href="https://wadl.java.net/">https://wadl.java.net/</a></p> <p>Machine-readable XML description of HTTP-based web applications (typically REST web services)</p> <p><br /> \\</p>Wilfrid Utz2016-09-19T13:00:19ZDesign Environment 1.1Wilfrid Utzhttps://site.cloudsocket.eu/web/guest/common-understanding-wiki/-/wiki/330802/Design+Environment2016-09-19T12:57:04Z2016-09-19T12:57:04Z<h1 id="section-Design+Environment-Design+Environment"> Design Environment <a class="hashlink" href="#section-Design+Environment-Design+Environment">#</a></h1><p>The design environment consists basically of: </p><ul><li>a meta modelling platform</li><li>the corresponding Web-GUI environment</li><li>the BPaaS Modeller that is build on top of the meta modelling platform</li><li>interface enabling the access of the design environment</li></ul><p>In addition to this common meta model based design envirionment approach, the BPaaS Design Environment has additionally: </p><ul><li>the Semantic Kernel.</li></ul><p>The functional capabilities, apart from obviously designing abstract and concrete business process, include visualizing, querying, and simulating these two types of business process. Another offered functional capability involves the transformation of an abstract business process model to a concrete one. In addition, the environment offers capabilities to compose meta-data and to define KPIs in a top-down manner. The actual KPI definition involves 4 main layers: (i) the layer of tasks (e.g., 10 euros per process), (ii) the layer of process (e.g., data in Europe), (iii) the virtual layer (e.g., deadlines posed for particular BP parts) and (iv) the concrete layer (mapping to a specific concrete and deployable business process model) (e.g., response time for particular services realizing BP tasks). A final functional capability involves the semantic annotation of abstract & concrete business process models with ontology concepts from business, IT & QoS/QoB ontologies. (note: I am not in favour of having these four layers as they are right now - I would recommends the following 4 alternatives ones: (a) abstract BP layer, (b) concrete BP layer, (c) service layer and (d) infrastructure layer with just a question mark of whether we go at a higher-level to map to generic organisational strategic (non-functional) goals). </p><p>Four main roles are involved in the operation of the Design Environment. The business process designer is responsible for modelling abstract business processes, while the technical business process designer is responsible for the modelling of concrete/technical business process models (possibly out of abstract ones if no automatic transformation is suppored or cannot be performed). The reviewer is a role responsible for annotating business process models and reviewing the business process models defined (note: this is what I understand from the meaning of "reviewer" - someone who reviews the design process and has also capabilities of annotating the models - if the latter can be attributed as a capability of the designers, then I can drop it). Finally, the IT infrastructure designer is responsible for the design of particular services or internal components that might be needed for the realization of the business process under specification and their storage in the service/component catalogue (note: as I understand it here, the IT infrastructure designer is responsible for the glueing between the BP and IT layer by realizing or requiring the realization of particular missing functionality either in the form of a service or component). </p><p>The result of a BP design is a set of models that are made available to the next step in the life-cycle of a BPaaS which maps to its allocation supported by the Allocation Environment. The models produced are the following: (a) a conceptual business process model in any kind of form (e.g., pictures/figures) along with additional information pertaining to the description of the organisation, its non-functional requirements and its main business objectives, (b) the conceptual business process model is the typical form of a BPMN model along with RDFS-based semantic annotations to business & IT ontology concepts, (c) the concrete business process model in BPMN again along with RDFS-based semantic annotations and (d) the definition of KPIs in a language to be specified or adopted by the consortium (can be based on OWL-Q). </p><p>When deploying the Design Environment, we can distinguish between the following components to deploy and have operating: (a) a web-based modeller offered in the form of a SaaS or web application which enables conceptual and concrete BP designers to design their business processes, (b) a business process repository which is responsible for the management & retrieval of abstract business process models assisting in the task of the designer to compose a business process out of business process fragments constituting previous design knowledge, (b) an executable business process repository with the similar focus as with respect to the previous type but concerning the handling of executable/concrete business process models, (c) catalogs for services and components responsible for the management and retrieval of the respective service/component descriptions - such catalogs can enable the technical business process designer to find those services or components which can realize the tasks of the technical business process being designed and (d) the KPI repository which will contain the description of well-known KPIs (actually of BP metrics which can be used in forming KPIs as KPIs are regarded as conditions on such type of metrics) (note: need to consider whether the BP repositories stick to the functional aspect or also consider the non-functional one. If not, then the KPI repository could contain these requirements and their mapping to the functional description of the business processes). </p><p><img src="http://20.0.1.43:9785/c/wiki/get_page_attachment?p_l_id=50776&nodeId=25641&title=Design+Environment&fileName=Design-Env-BB.png" /> </p><h2 id="section-Design+Environment-BPaaS+Design+Repository"> BPaaS Design Repository <a class="hashlink" href="#section-Design+Environment-BPaaS+Design+Repository">#</a></h2><p>The BPaaS Design Repository is a relational database, realising the meta model. Hence, .... </p><h2 id="section-Design+Environment-Meta+Model+Kernel"> Meta Model Kernel <a class="hashlink" href="#section-Design+Environment-Meta+Model+Kernel">#</a></h2><p>The meta model kerne is a model-aware middle ware that accesses the repository..... </p><h2 id="section-Design+Environment-Hybrid+BPaaS+Modeller"> Hybrid BPaaS Modeller <a class="hashlink" href="#section-Design+Environment-Hybrid+BPaaS+Modeller">#</a></h2><p>The hybrid BPaaS Modeller consists of... </p><ul><li>BPMN modelling elements</li><li>Additional Cloud releated deployment elements</li><li>Semantic Lifting</li></ul><h2 id="section-Design+Environment-Semantic+Kernel"> Semantic Kernel <a class="hashlink" href="#section-Design+Environment-Semantic+Kernel">#</a></h2><p>The semantic kernel enables the interface to ontology managemet systems to conceptuall lift the models in the repository. </p><p>This semantic kernel implements the mechanisms of annotating business processes and individual concepts of a business process with .... </p><h2 id="section-Design+Environment-Web+Modeller"> Web Modeller <a class="hashlink" href="#section-Design+Environment-Web+Modeller">#</a></h2><p>The Web-Modeller consists mainly of the Graphical User Interface to.... </p><h2 id="section-Design+Environment-API"> API <a class="hashlink" href="#section-Design+Environment-API">#</a></h2><p>The API provides a set of interaction methods that enables to import or export data through specifically designed interaction channels. </p><p>Relevant input / output channels had already been discussed. .... </p><h2 id="section-Design+Environment-Component+View"> Component View <a class="hashlink" href="#section-Design+Environment-Component+View">#</a></h2><p>This high level view on the major building blocks can be further broken down into .... </p><p><img src="https://www.cloudsocket.eu/c/wiki/get_page_attachment?p_l_id=25623&nodeId=25641&title=FrontPage&fileName=MCR-Architecture_v1.1_20121112-NE.png" /> </p><p>???? </p><p>Is there any format how to proceed with the descirption of the individual Components ? </p>Wilfrid Utz2016-09-19T12:57:04Z