FI-WARE Apps/Services Ecosystem and delivery July 2011

1. High-level Description FI-WAREApps/Services Ecosystemand deliveryJuly 2011

2. Business Framework

3. USDL Repository and Registry • The USDL repository is a place to store service descriptions or parts of it. • The use of an USDL repository is required in order to prepare service descriptions to appear at a store, marketplace and other components of the business framework. • Existing (running) service endpoints as well as information to create an actual service instance and endpoint is registered in the USDL Registry. • Only if the service endpoint is registered it actually can be used for service composition and coordination.

4. Marketplace and stores • Marketplaces and stores are differentiated in FI-WARE • A marketplace is a platform for many stores to place their offerings to a broader audience and consumers to search and compare services and find the store, where to buy • The final business transaction (buying) is done at the store and the whole back office process is handled by the store. • The main focus in FI-WARE will be on developing the marketplace as a generic enabler and providing open standard interfaces enabling multiple stores to place their offering

5. Business Elements & ModelsProvisioning • The BE&BM ProvisioningGE allow app providers to define the manner in which services and applications can be sold and delivered to the final customers • While the published USDL description represents the public view of the business model offered to the customer, the business model defines the way in which: • customers pay for application and services • the incomes are to be split among the involved parties

6. RevenueSettlement and Sharing • A consumer may pay each time he/she: • buys an application or service • uses an application he/she has previously bought • The Revenue Settlement and Sharing GE supports: • Calculation of the right payment to the different application/service providers involved, dealing with situations where the application/service for which the end-user is charged is based on the composition of application/services coming from different providers • Sharing revenues among application/service providers and between them and the FI-WARE Instance (Business Framework) provider

7. SLA Management • This GE dealswithmanagement of thenegotiation of SLAsbythecustomers • The concept of SLA “templates” willbesupported, enablingapplicationproviderstoleaveparameters open so thatthey can becustomizedwhencreatingthecontractfor a givencustomer • Once in effect, the SLA guarantees must be monitored for violation, and any penalties paid(for this, the SLA management GE should implement interfaces to the Revenue Settlement and Sharing GE)

8. ServiceComposition and Mashup

9. ServiceComposition and Mashup • From the compositional perspective FI-WARE will differentiate two complementary perspectives: • front-end perspective – composed applications (or mashups) • back-end perspective – composite (backend) services • While back-end components are created by atomizing information processing, front-end components (referred also as widgets or gadgets) are created by atomizing information presentation and user interaction. • Another difference is that the creation and execution of the front-end components will heavily depend on the available runtime environment (e.g. web-browser, device OS), and the different presentation channels they are exposed through (Facebook, Yahoo Widgets). • We expect back-end composition editors to employ a more complex composition language and environment, mashup editors being more tailored to user interface designer or even consumers

10. Composition and mashupeditors • Editors provide an environment to combine and configure applications and services in graphical way. Some common functions: • Different editors could cater for different user expertise and roles (from composed service creators, to resellers and finally to prosumers) • Editors should support facilities for consistency checking of interfaces and simple debugging. They should connect to the Execution Engines allow testing, debugging, installing, executing, controlling and post execution analysis of the composed applications. • Edited/created composition and technical service descriptions should be stored/fetched in the Aggregator Repository. • When creating compositions/mashups editors might connect to the business infrastructure: • Marketplace to search for services • Shops to purchase component services them for testing /deployment, and to expose composed services for purchase • USDL Registry to browse business information related to services • Editors could be connected to a user and identity management service

11. Mashupeditors • Mashup editors enable to create applications built from discrete front-end components (e.g. gadgets/widgets, apps) and connected at the front-end layer • Functions comprised: • Creating an application front-end as a mashup built from gadgets/widgets that rely on a series of either plain or composed backend services. • Offering client-side inter-gadget communication facilities, including support for optional filters (wiring) • Offering design-time semi-assisted modelling aids, such as suggestions on relevant relationships amongst gadgets and mashups (e.g. consumed data vs. produced data). • Offering dynamic discovery facilities from the gadget/widget and mashup repository • Generating a MDL (Mashup Description Language) model from a mashup for persistence/sharing purposes.

12. Backendservicecomposition editor • Deployment features in service composition editors will support the translation of composition models into executable languages such as BPEL and BPMN 2.0 • Will support extensions for design-time service composition • Modelling workflow, supporting complex behavioural patterns, using modelling elements such as gateways (exclusive, parallel, loops, etc) • Modelling data flow, including support for complex data flow mapping, transformation and consistency check. • Modelling of orthogonal (independent) composition work and data flow. • Design-time semi-assisted (in opposition to manual modelling) modelling aids, such as dynamic binding, data flow generation, data flow mapping, data flow consistency, task expansion with matching composition (sub-processes), etc.

13. Backendservicecomposition editor • Will support extensions for design-time service composition • Creation of skeletons for composed services. The skeletons provide placeholders for the relevant services that are going to be resolved at runtime. • Specification of global (valid throughout the composition) and local (valid only on that template) constraints are used to decide which services can implement the skeleton at runtime. • Several services might be suitable to implement a placeholder template. These services can have different input and output parameters and the editor needs to offer the possibility to correctly map the different dataflow types, while providing an easy to use unified interface. • While the choice of relevant services can differ at runtime compared to design time, still for many cases the set available at runtime is a subset of the one available at design time. Thus the editor should apply smart constraint resolution also at design time to help the designer get an idea of what services might resolve at runtime, an help her prepare all the relevant inputs and outputs.

14. MashupExecutionEngine • The FI-WARE reference architecture should offer a mashup container able to execute applications built from discrete front-end components (e.g. gadgets/widgets, apps) and connected at the front-end layer. • Functionality: • Coordinating gadget execution and communication within the mashup • Creating the communication channels (data flow) between gadgets • Deployment and execution of mashups • Guaranteeing the mashup state persistence • Generating an executable mashup

15. ServiceCompositionEngine • For the dynamic late-binding composition, the composition engine creates a workflow on the fly from a matching skeleton. • The process is triggered by a composition execution agent (CEA) that receives a triggering event and requests the next step from the composition engine. • Based on what the triggering events was, the composition engine selects the matching skeleton and creates a new session. • Then, at each step it selects a suitable service that matches all the global and local constraints and serves it to the workflow agent to execute. • If several services are suitable to implement a certain step one of them is chosen. • Execution results from the previous steps together with potential external events can influence the constraint-based decision process selecting the service for the new step. • If a component service fails during execution, the next compatible one might be executed instead.

16. MediationGEs • Providing interoperability solutions is then the main functionality of the mediation functionality. • Several GEs are considered to perform different types of mediation: • Data Mediation • Protocol Mediation • Process Mediation.

17. Thank You !!