The GEMBus Way Delivering the Promise of the Internet of Services

1. The GEMBus WayDelivering the Promise of the Internet of Services Diego R. Lopez, RedIRIS

2. The Zen of GEMBus Middleware is the layer connecting the stuff to the rest of the world in a seamless manner Our stuff is academic and research network services Multi-domain XaaS: Everything as a Service X can be Software, Storage, Network…

3. The Composition Landscape Standard interfaces and support for policy agreements Compositional procedures and orchestration Interface descriptions

4. Composable Network ServicesThe GEMBus Promise • A framework to define, discover, access, and combine network services • From the infrastructure up to application elements • Federated, multi-domain ESB • Able to integrate any service within the GÉANT infrastructure • Flexible negotiation of service provision capabilities • Addressed to • NREN staff • e-Science service providers • and users!! • Collaborative architecture • Open to collaboration beyond the academic community • Prosumer-oriented • Plug-and-play plus Plug-and-be-played

5. What GEMBus Intends to Offer • Mechanisms for enabling user applications to use networked services and compose them • Within a distributed and federated infrastructure, avoiding central services as much as possible • A set of common services  for: • Describing and finding service endpoints (registry) • Routing requests and responses (messaging) • Keeping a log of the interactions, for traceability and diagnostics (accounting)  • Defining how and when component services are called inside a composed one (mediation) • Establishing rights for the user services (access control)

6. What GEMBus Intends to Use • Whatever service endpoints that any participant is willing to offer • Driven by already identified use cases • With the hope of additional ones rising from the user communities • A set of rules for integrating services into the framework, according to:  • Web-Service endpoint definitions • Service wrappers • Registration interfaces • APIs using common standards (JBI, OSGi...) • Possibly, reflection interfaces • Recommendations, best practices and experience

7. Compositional Styles • Lightweight SOA • REST • Composition based on the mash-up paradigm • Web 2.0 • Heavyweight SOA • SOAP • Composition based on formal languages • Semantic Web • Bundle platforms • Software components kept in repositories • Loaded an instantiated by the application using them • OSGi • At least, the two first will be addressed

8. Service InterfacesThe MANA Approach • α-interfaces • Directly usable by applications • β-interfaces • Govern systems and resources • γ-interfaces • Abstract access to resources • δ-interfaces • Actual control over the resources Source: MANA Position Paper, 2009

9. What Service Interfaces • GEMBus will provide a set of α-interfaces • Plus the corresponding mediation systems • Specify how β-interfaces have to be published and registered • From individual GÉANT (and external) services • A management platform • As required for direct integration support • Usable by individual services Source: MANA Position Paper, 2009

10. A Tour through Use CasesLive Performance Distribution

11. A Tour through Use CasesDigital Repositories

12. A Tour through Use CasesGÉANT Service Composition AutoBAHN Service GEMBUS AutoBAHN Services (IDM) Path Reservation Service Client PerfSONAR Service PerfSONAR services (LS, MP, MA)

13. A Tour through Use CasesAutonomous Services

14. A Tour through Use CasesWorkflow (CLARIN)

15. A Tour through Use CasesReal Time Collaboration

16. On α-Interfaces • Two initial models being addressed • OGSA • NREN natural environment • IPSphere • Network gear manufacturers • Telcos and ISPs • More to explore as service matures • Cloud RESTish interfaces look promising • Lots of hype noise here

17. On ß-Interfaces • Three initial use cases being considered for implementation • PerfSONAR and AutoBAHN integration • Autonomous Computing • E2E network SLA • Analysis on how decoupling impacts on service interface design • A wrapper cannot be enough in certain cases • Additional metadata services can be a solution

18. On Registries • Support for several compositional styles • Heavy- and light-weight SOA • Richer metadata set • Semantic description • No central service repository • Distributed publish-and-subscribe • Data-driven update • Several interesting choices • Semantic WS (RDF + WSDL 2) • Data-driven architectures (a-la-OM2) • Flow-oriented protocols (a-la-Wave)

19. On Messaging • Protocol and platform neutrality • Several ESB frameworks under evaluation • Plans are not to mandate a single one • SOAP/XML and REST/JSON over HTTP(S) are the obvious first choices • Wrappers already provided by frameworks • Supported by all conceivable implementation languages • Minimize initial integration costs • Other paths to explore • Maximize transparency to application • Enhance formalization without affecting simplicity • Highly dependent on registry capabilities • The metadata issue again

20. On Accounting • Establish a common semantics of what to be logged at the α- and ß-interfaces • Define (at least) compatible syntaxes • Build aggregation systems • Explore how to propagate this down the service interface stack • External logs can be incorporated in the reporting system • Extend these findings to • Monitoring • Extended helpdesk • Some promising results to incorporate • Federation monitoring (eduroam, AAIEye,…) • Grid coordinated accounting • The NREN Detective • EDDY

21. On Mediation • Choreography • P2P • Control shared by the services • Enforced by the requesting application • Orchestration • Centralized • Control exercised by an orchestration engine that receives the request • Better suited for user-oriented service creation • What about a distributed orchestration?

22. On Access Control • All requests and responses include identity information • With persistent unique identifiers • Service endpoints explicitly state their security requirements in their definition • Including integrity checking and encryption • Support for different syntaxes for security statements • Plus a common GEMBus Security Token (GST) • Optional use for encryption and integrity checking in protocols and channels • But security statements must be integrity protected • WS-Security seems the obvious choice • And we have to explore RESTish interfaces: OAuth/OpenID/InfoCard/…

23. (More) On Access Control • The GEMBus security architecture envisages: • A common token format to guarantee interoperability at the security level • A STS in order to have at least a source of such tokens and provide a way to translated other token formats into the common format • An AS able to validate security tokens and provide authorization decisions • eduGAIN WE token format plus • WebSSO to provide access to STSes • MDS to bootstrap ASes

24. On Time (I Hope) • GEMBus intends to be the next natural step in multi-domain middleware services • Blurring the line between network and application • XaaS • Applying in a wider environment what we have learned so far • Generalizing the federation methods and principles • Trying to satisfy a demand from the user community • Better integration of whatever the infrastructure • Several real projects already identified • And following the path to the Future Internet • The network becomes a “global virtual resource”