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

connect • communicate • collaborate

The GEMBus WayDelivering the Promise of the Internet of Services

Diego R. Lopez, RedIRIS


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 servicesMulti-domain

XaaS: Everything as a Service

X can be Software, Storage, Network…


The Composition Landscape

Interface descriptions

Compositional procedures and orchestration

Standard interfaces and support for policy agreements


Composable Network ServicesThe GEMBus Promise

A framework to define, discover, access, and combine network servicesFrom the infrastructure up to application elementsFederated, multi-domain ESBAble to integrate any service within the GÉANT infrastructureFlexible negotiation of service provision capabilities

Addressed toNREN staffe-Science service providersand users!!

Collaborative architectureOpen to collaboration beyond the academic communityProsumer-oriented

– Plug-and-play plus Plug-and-be-played


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)


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


Compositional Styles

Lightweight SOARESTComposition based on the mash-up paradigmWeb 2.0

Heavyweight SOASOAPComposition based on formal languagesSemantic Web

Bundle platformsSoftware components kept in repositoriesLoaded an instantiated by the application using themOSGi

At least, the two first will be addressed


Service InterfacesThe MANA Approach

α-interfacesDirectly usable by applications

β-interfacesGovern systems and resources

γ-interfacesAbstract access to resources

δ-interfacesActual control over the resourcesSource: MANA Position Paper, 2009


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 platformAs required for direct integration supportUsable by individual services

Source: MANA Position Paper, 2009


A Tour through Use CasesLive Performance Distribution


A Tour through Use CasesDigital Repositories


A Tour through Use CasesGÉANT Service Composition

ClientPath Reservation

Service

AutoBAHNService

PerfSONARService

AutoBAHNServices (IDM)

PerfSONARservices (LS, MP, MA)

GEMBUS


A Tour through Use CasesAutonomous Services


A Tour through Use CasesWorkflow (CLARIN)


A Tour through Use CasesReal Time Collaboration


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


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


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)


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


On Accounting

Establish a common semantics of what to be logged at the α- and ß-interfaces

Define (at least) compatible syntaxesBuild aggregation systems

Explore how to propagate this down the service interface stackExternal logs can be incorporated in the reporting system

Extend these findings toMonitoringExtended helpdesk

Some promising results to incorporateFederation monitoring (eduroam, AAIEye,…)Grid coordinated accountingThe NREN DetectiveEDDY


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?


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/…


(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


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”

Documents

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