osgi remote services with sca

IBM Software Group

© 2010 IBM Corporation

OSGi + SCA = ???

Graham Charters

[email protected]

IBM Software Group

© 2010 IBM Corporation2 Jan 22, 2010

Agenda

OSGi Remote Services Overview

Service Component Architecture Overview

OSGi + SCA = ?

IBM Software Group


OSGi Remote Services History

OSGi R4 V4.1 mute on service remoting

Some projects had demonstrated possiblities

– Apache Tuscany (http://tuscany.apache.org/)

– R-OSGi (http://r-osgi.sourceforge.net/)

– Newton (http://newton.codecauldron.org)

– ...

Distribution seen as a core aspect of “Enterprise OSGi”

– Spec work started in 2008

http://tuscany.apache.org/

http://r-osgi.sourceforge.net/

http://newton.codecauldron.org/

IBM Software Group


Why standardise anything?

Consistency of configuration across implementations

– Remotability of a service

– Security requirements, reliability requirements, etc.

Consistency of behaviour

– Lifecycle, invocation semantics, etc.

IBM Software Group


OSGi Standards...thrice the fun

DistributedOSGi RFC

DistributedOSGi RFC

RemoteServices

RemoteServices

RemoteServicesAdmin

RemoteServicesAdmin

SCA RemoteServices

Configuration

SCA RemoteServices

Configuration

Compendium R4 V4.2(Chapter 13)

IBM Software Group


Framework

Local Services

Service ProviderBundle


Service Consumer

Bundle

Service Consumer

Bundle

Pass-by-referenceZero latencyReliable

Pass-by-referenceZero latencyReliable

IBM Software Group


Framework Framework

Remote Services



Service Consumer

Bundle

Service Consumer

Bundle

Pass-by-valueLatencyUnreliable

Pass-by-valueLatencyUnreliable

NetworkNetwork

IBM Software Group


Framework Framework

OSGi Remote Services



Service Consumer

Bundle

Service Consumer

Bundle

Remote ServicesProvider Configuration


Remote ServicesClient Configuration


NetworkNetwork

IBM Software Group


Framework Framework

OSGi Remote Services



Service Consumer

Bundle

Service Consumer

Bundle

DistributionProvider

DistributionProviderDistribution

ProviderDistribution

Provider



endpoint



NetworkNetwork

to endpoint

IBM Software Group


Remote Services Properties

Framework Framework



Service Consumer

Bundle

Service Consumer

Bundle

service.exported.interfaces

service.intents service.exported.intents service.exported.intents.extra

service.exported.configs

<other service properties>

service.exported.interfaces

service.intents service.exported.intents service.exported.intents.extra

service.exported.configs


objectClass

service.intents

service.imported.configs

service.imported


objectClass

service.intents

service.imported.configs

service.imported


endpoint

NetworkNetwork

to endpoint

IBM Software Group


Remote Services Intents

Describe an abstract requirement or capability

– Separation of concerns – statement of requirement/capability independent of implementation

Three properties

service.intent – provided by the service (local and remote)service.exported.intents – statically configured for remoteservice.exported.intents.extra – admin configured for remote

Inspired by SCA intents, examples include

– confidentiality, integrity, atLeastOnce, atMostOnce, SOAP.v1_1, etc.

IBM Software Group


Intents enable separation of concerns

There's bad people out there, so I want to

ensure the confidentiality and integrity of my really

secret messages

Mr President expresses his requirements in layman's terms

IBM Software Group



I can give you SSL, TripleDES, X.509, S-MIME, double

expresso, ...

The security expert understands these terms and maps them to an appropriate implementation choice.

IBM Software Group



Mr President doesn't really care how his requirements are satisfied.

Whatever...

IBM Software Group


Remote Service Configuration Types

Identifies a type of Distribution Provider specific configuration

Use reverse domain name scheme to avoid conflict

Property naming convention used for extra config

service.remote.configs = com.acme.configcom.acme.config.host = …com.acme.config.port = ...

IBM Software Group


OSGi Remote Service Summary

Standardised basic metadata for distribution

– Remote interfaces

– Default invocation semantics

– Place to hang QoS requirements (intents)

– Place to hang distribution provider configuration

Distribution provider treated like a 'black box'

– No standard way to influence topology

– No standard way to influence publication/discovery

IBM Software Group


Distribution Provider

Remote Services Admin: inside the 'black box'

Decomposes the role of Distribution Provider

RemoteServiceAdmin

RemoteServiceAdmin

NetworkNetworkDiscoveryDiscovery

EndpointListener

EndpointListener

RemoteServiceAdmin

RemoteServiceAdmin

Listener

ServiceProvider/

Consumer

ServiceProvider/

Consumer

ExportedService

ImportedService

TopologyManager

TopologyManager

endpointto endpoint/

IBM Software Group


Remote Services Admin Summary

Builds on Remote Services to standardise

– Control topology

– Administration of distribution provider

– Integration discovery

However...

– Distribution configuration details left to distribution provider

• Encryption, signing, protocols, reliability

– Full configuration not portable

– No standard way to configure for interoperability

IBM Software Group


SCA Remote Services Configuration

A Remote Services Configuration Type re-using SCA Bindings and Policy configuration

Service states use of org.osgi.sca configuration type

Service identifies binding(s) to use, by name

Bindings manage through configuration bundles

Framework



service.exported.configs = org.osgi.sca org.osgi.sca.bindings = OrderServiceBindingWS

service.exported.configs = org.osgi.sca org.osgi.sca.bindings = OrderServiceBindingWS

ConfigurationBundle

ConfigurationBundle



Extends BindingsPolicyIntents

<sca-config ...> <binding.ws name="OrderServiceBindingWS" uri="http://localhost:8086/OrderService" /> ...</sca-config>

endpoint

IBM Software Group


SCA Remote Services Configuration Summary

Standardized fully-portable distribution provider configuration

Based on SCA Bindings and SCA Policy

Configuration for interoperability through interoperable binding

IBM Software Group


OSGi Framework

Demo time...fingers crossed

CalculatorService

Implementation

CalculatorService

Implementation

service.exported.configs = org.osgi.sca org.osgi.sca.bindings = Calculator

service.exported.configs = org.osgi.sca org.osgi.sca.bindings = Calculator

CalculatorConfigurationCalculator

Configuration

TuscanyDistribution

Provider

TuscanyDistribution

Provider

Extends BindingsPolicyIntents

<sca-config ...> <binding.ws name="Calculator" uri="http://localhost:8086/CalculatorService" /> ...</sca-config>

endpoint

CalculatorService

Interface

CalculatorService

Interface

“Graham'sDIY runtime”

IBM Software Group


Service Component Architecture

That seems to work...but some hereticspeople want to explore the world outside OSGi...

IBM Software Group


What is the Service Component Architecture (SCA)?

Heterogeneous component assembly

Synchronous, asynchronous, event processing

Pluggable communications protocols

Think Blueprint Service or Spring Framework only with bigger components implemented using different stuff and able to talk to other different stuff...

IBM Software Group


SCA Overview

Composite A

ComponentAService

BindingWeb ServiceSCAJCAJMSSLSB…

BindingWeb ServiceSCAJCAJMSSLSB…

ComponentB

Service- Java interface- WSDL PortType

Reference- Java interface- WSDL PortType

WirePromotePromote

Reference

Implementation - Java - BPEL - Composite …

IBM Software Group


<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="bigbank.accountcomposite" >

<composite>

<service name="AccountService" promote="AccountServiceComponent"> <interface.java interface="services.account.AccountService"/> <binding.ws port="http://www.example.org/AccountService# wsdl.endpoint(AccountService/AccountServiceSOAP)"/> </service>

<component name="AccountServiceComponent"> <implementation.java class="services.account.AccountServiceImpl"/> <reference name="StockQuoteService"/> <reference name="AccountDataService" target="AccountDataServiceComponent/AccountDataService"/> <property name="currency">EURO</property> </component>

<component name="AccountDataServiceComponent"> <implementation.bpel process=“QName"/> <service name="AccountDataService"> <interface.java interface="services.accountdata.AccountDataService"/> </service> </component>

<reference name=“StockQuoteService" promote="AccountServiceComponent/StockQuoteService"> <interface.java interface="services.stockquote.StockQuoteService"/> <binding.ws port="http://example.org/StockQuoteService# wsdl.endpoint(StockQuoteService/StockQuoteServiceSOAP)"/> </reference>

IBM Software Group


OSGi + SCA = ???

It's all a matter of perspective

OSGi sees a Distribution Provider

SCA sees an OSGiImplementation Type

IBM Software Group


OSGi-centric View

Business as Usual for the OSGi Developer

Unaware of enclosing SCA Component

– Implementation detail of the SCA Distribution Provider

– Could be generated on-the-fly

(Optionally) Use SCA Remote Service Configuration Type to configure SCA runtime

This is what I demonstrated

Bundle

com.acme.Order

1.0.0

Bundle

com.acme.Order

1.0.0

OrderComponent

BindingsPolicyIntents

IBM Software Group


SCA-centric View

OSGi implementation type (implementation.osgi) identifies the bundle

Service and reference elements describe the remote services

Support OSGi Remote Services Metadata to ensure only 'remotable' services are distributed

Can then describe assembly with Java EE, BPEL, JavaScript, Spring, etc.

<composite xmlns...> <component name="OrderComponent"> <tuscany:implementation.osgi bundleSymbolicName="com.acme.Order" bundleVersion="1.0.0" /> <service name="OrderService" /> <reference name="creditReference" /> </component> ...</composite>

<composite xmlns...> <component name="OrderComponent"> <tuscany:implementation.osgi bundleSymbolicName="com.acme.Order" bundleVersion="1.0.0" /> <service name="OrderService" /> <reference name="creditReference" /> </component></composite>

Composite

Component WarehouseComponent(BPEL)

CustomerComponent

(POJO) OrderBundle

1.0.0

OrderBundle

1.0.0

IBM Software Group


Futures

Emergence of OSGi Application Models

Standardization of SCA/OSGi integration

BundleBundle

BundleBundle

BundleBundle

Component

“Application”

IBM Software Group


Summary

OSGi R4 V4.2 standardizes distribution of OSGi services

– OSGi metadata leverages SCA

SCA runtime can fulfill role of OSGi Distribution Provider (OSGi unaware of SCA)

OSGi bundles can participate in SCA applications (simple component assembly model) – integration with other component types, exploit SCA policy and bindings

Enterprise R4 V4.2 Draft Specification

– http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf

Apache Tuscany

– http://tuscany.apache.org/documentation-2x/

http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf

http://tuscany.apache.org/documentation-2x/

osgi remote services with sca

Technology