www cloud 4 soa eu Outline 1 Cloud

  • Slides: 27
Download presentation
www. cloud 4 soa. eu

www. cloud 4 soa. eu

Outline 1. Cloud 4 SOA at a glance 2. Motivation 3. Core functionalities 4.

Outline 1. Cloud 4 SOA at a glance 2. Motivation 3. Core functionalities 4. Cloud 4 SOA Architecture 5. Cloud 4 SOA’s solution timeline & availability 6. Correlation with CAMP 7. Leassons learnt 8. Questions

Cloud 4 SOA at a Glance q EU Funded Project q Research Programme: FP

Cloud 4 SOA at a Glance q EU Funded Project q Research Programme: FP 7 -ICT-2009 -5 - Objective 1. 2 q Project coordinator: ATOS (Spain) q Partners: (8 partners – 6 Countries) • National University of Ireland Galway (Ireland) • Singular. Logic (Greece) • Centre for Research and Technology Hellas (Greece) • Cloud. Control (Germany) • Cyntelix (NL) • Portugal Telecom Inovação (Portugal) • Fraunhofer FIT (Germany) • Rom. Telecom (Romania) 3

Cloud 4 SOA Motivation q Paa. S (Platform as a Service) is a new

Cloud 4 SOA Motivation q Paa. S (Platform as a Service) is a new paradigm that enables independent software vendors (ISVs) or organization to create (develop or integrate), deploy, execute, integrate and manage business applications, using a service provided by third party. q The actual Paa. S market is, quite young, chaotic and highly fragmented, and it is foreseen only a partial consolidation process in the next years. q Interoperability, in the close future would help market newcomers 4

Project Vision Cloud 4 SOA will support the application management, (deployment, start, stop etc)

Project Vision Cloud 4 SOA will support the application management, (deployment, start, stop etc) and migration by semantically interconnecting heterogeneous Paa. S offerings across different providers that share the same technology, and will facilitate the access and lifecycle management for Cloud-based application developers to the Paa. S offering that best matches their computational needs. The vision of Cloud 4 SOA is to open up the Cloud market to small and medium Platform as a Service (Paa. S) providers, strengthen their market position, and in parallel help to alleviate the vendor lock-in barrier for Cloud developers. The Cloud 4 SOA consortium. . . 5

Interoperability? The project examines semantic interoperability needs related to: the deployment of service instances

Interoperability? The project examines semantic interoperability needs related to: the deployment of service instances in several competitive platform offerings (Deployment) the migration of an instancethe federation and governance of run-time information between the (i. e. business logic and data)running instances in a harmonised between two competitive way (in order to be easily providers. comparable) 6

Cloud 4 SOA Show Cases 1) VPN Portal from Rom. Telecom 3) BSCW Shared

Cloud 4 SOA Show Cases 1) VPN Portal from Rom. Telecom 3) BSCW Shared Workspace System from FIT 7 2) Cloud-enabled SDF from Portugal Telecom

Use Case Model 8

Use Case Model 8

Cloud 4 SOA Architecture Formal representation of information by means of the Cloud 4

Cloud 4 SOA Architecture Formal representation of information by means of the Cloud 4 SOA ontology. Intelligent Interface to support the user understand the data presented by the interface and efficiently interact with the Toolbox that provides - Harmonized Application data presented. intelligent service publication, Monitoring discovery and matchmaking, - Application SLA Management recommendation and layer migration. Acts as an intermediary between the Cloud 4 SOA platform and the various Paa. S offerings allowing the applications to be independent from specific Paa. S offering implementations. CUSTOM ADAPTERS

Cloud 4 SOA Ontology (1/6) – The Cloud 4 SOA ontology defines the fundamental

Cloud 4 SOA Ontology (1/6) – The Cloud 4 SOA ontology defines the fundamental cloud entities and their core set of properties, together with main relations between them – The entities have been categorized into 5 correlated semantic layers: • User layer • Application layer • Enterprise layer • Platform layer

Cloud 4 SOA Ontology (2/6) – Infrastructure layer:

Cloud 4 SOA Ontology (2/6) – Infrastructure layer:

Cloud 4 SOA Ontology (3/6) – Platform layer:

Cloud 4 SOA Ontology (3/6) – Platform layer:

Cloud 4 SOA Ontology (4/6) – Enterprise layer:

Cloud 4 SOA Ontology (4/6) – Enterprise layer:

Cloud 4 SOA Ontology (5/6) – Application layer:

Cloud 4 SOA Ontology (5/6) – Application layer:

Cloud 4 SOA Ontology (6/6) – User layer:

Cloud 4 SOA Ontology (6/6) – User layer:

Ontology available under Creative Commons • http: //demo. cloud 4 soa. eu/ontology/

Ontology available under Creative Commons • http: //demo. cloud 4 soa. eu/ontology/

Matchmaking (autowiring …)

Matchmaking (autowiring …)

App Profile Editor. .

App Profile Editor. .

Cloud 4 SOA’s solution timeline & availability and IPR Cloud 4 SOA project finalizes

Cloud 4 SOA’s solution timeline & availability and IPR Cloud 4 SOA project finalizes full public release Beta program for public hosted (portal) and local versions (Git. Hub) Some functionalities already available to be consumed: i. e. matchmaking service on line IPR: open-source, looking to Apache licenses

Collaboration with CAMP (1/2) • Cloud 4 SOA has already created 'Adapters' for 6

Collaboration with CAMP (1/2) • Cloud 4 SOA has already created 'Adapters' for 6 Paa. S providers: AWS Beanstalk, Cloudbees, Heroku, Cloud. Control, Cloud. Foundry & Open. Shift Experience in existing diversities • A common API is already formulated that covers the needs of these 6 Act as Validation for a possible RI

Collaboration with CAMP (2/2)

Collaboration with CAMP (2/2)

Lessons Learnt (1/2) • Interoperability is inversely proportial to market adoption (to the insentive

Lessons Learnt (1/2) • Interoperability is inversely proportial to market adoption (to the insentive of Vocabularies adoption) -Baby -Paa. S-defined expressivity Adoption -RI varies -Loose Assertion (no-CAMP conformance) What is here? Interoperability -Fixed Vocabularies -Strongly Typed Models -RI capabilities are given -Strict Assertion Policies

Lessons Learnt (2/2) • Almost everything was ideal until we touched the issue of

Lessons Learnt (2/2) • Almost everything was ideal until we touched the issue of non-archive based devlopment – Injection of source code : inevitable (Openshift, Cloud. Control …) – Who takes the responsibility? • If SLA enforcement comes into play the challenge is even bigger – No concrete monitoring abstraction can be formulated (boundaries between Paa. S / Iaa. S)

Questions after reading the spec(1/2) • Why the Serialization format (JSON) imposes restrictions to

Questions after reading the spec(1/2) • Why the Serialization format (JSON) imposes restrictions to the expressivity model that a Paa. S provider should use? ? ? (reminds me of the OWL-S vs WSMO endless war) A reference to an RDF-S model would be satisfactory for the majority of the cases • The reasoning capabilities of each provider should be selected during the RI (WSDL-S analogy)

Questions after reading the spec(2/2) • Who defines CAMP-conformance ? And based on what

Questions after reading the spec(2/2) • Who defines CAMP-conformance ? And based on what criteria? • Security features? (Register public keys etc) • Scaling policies requires measuments of metrics that require Application patching (new Relic)

Consortium Follow us at the Linked. In Cloud 4 SOA group! www. cloud 4

Consortium Follow us at the Linked. In Cloud 4 SOA group! www. cloud 4 soa. eu