connect communicate collaborate The GEMBus Way Delivering the Promise of the Internet of Services Diego R. Lopez, RedIRIS

connect communicate collaborate 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…

connect communicate collaborate The Composition Landscape Service Components  AutoBAHN DM  perfSONAR MA  eduGAIN AuthN  Composite Services  e-science workflow  A&H performance  eduGAINized repositories  … Service Frameworks  Other NRENs  Governmental  Commercial  … AutoBAHN eduGA IN Grid GÉBusCLARINAPANI2ESNetIPSphereOGSATelcosCanarie Interface descriptions Compositional procedures and orchestration Standard interfaces and support for policy agreements

connect communicate collaborate Composable Network Services The 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

connect communicate collaborate 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)

connect communicate collaborate 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

connect communicate collaborate 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

connect communicate collaborate Service Interfaces The 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

connect communicate collaborate 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

connect communicate collaborate A Tour through Use Cases Live Performance Distribution

connect communicate collaborate A Tour through Use Cases Digital Repositories

connect communicate collaborate A Tour through Use Cases GÉANT Service Composition Client Path Reservation Service AutoBAHN Service PerfSONAR Service AutoBAHN Services (IDM) PerfSONAR services (LS, MP, MA) GEMBUS

connect communicate collaborate A Tour through Use Cases Autonomous Services

connect communicate collaborate A Tour through Use Cases Workflow (CLARIN)

connect communicate collaborate A Tour through Use Cases Real Time Collaboration

connect communicate collaborate 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

connect communicate collaborate 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

connect communicate collaborate 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)

connect communicate collaborate 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

connect communicate collaborate 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

connect communicate collaborate 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?

connect communicate collaborate 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/…

connect communicate collaborate (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

connect communicate collaborate 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”