1 Advanced SCA Michael Rowley, Ph.D. Director, Technology Office of the CTO April 28, 2008 TS-3765

1

Advanced SCA

Michael Rowley, Ph.D.Director, TechnologyOffice of the CTO

April 28, 2008

TS-3765

Outline

Quick review of SCA

Advanced Construction Techniques Local-Only Services Conversations Callbacks Components created using Spring

Advanced Assembly Techniques Autowire Include Constraining Types

Packaging and Deployment

Configuring Infrastructure Services using Policy

Goals of the Service Component Architecture (SCA)

A development and deployment model for SOA

Service-based models for:

Construction

Assembly

Deployment

In a heterogeneous environment of

multiple languages

multiple service access methods

Construction – Component Implementation

Provides code necessary to execute componentExamples:

JavaTM class BPEL process definition C++ class SCA Composite

May be used by multiple components

Declares SCA visible features Services References Properties Required Policy Intents

Service and references declarations are typed by interface Interface may be Remotable or Local-Only

Construction with Java

@Remotable public interface AccountService{

public AccountReport getAccountReport(String customerID);}

public class AccountServiceImpl implements AccountService {

@Property private String currency = "USD";

@Reference private AccountUpgradeService accountUpgradeService; @Reference private StockQuoteService stockQuoteService;

public AccountReport getAccountReport(String customerID) { … }

…}

Construction with BPEL

Service Interfaces

Service Interfaces in multiple interface languages E.g. WSDL 1.1, WSDL 2.0, Java, C++, etc.

All interfaces used by remotable interfaces must be translatable into WSDL 1.1 No translation need actually happen

Advanced (SCA-Specific) interface extensions Local-Only vs. Remotable Interfaces Conversational Interfaces

Session identifying information will be sent in headers Bi-Directional Intefaces

Interface with companion callback interface

Assembly – Composite

Composite A

ComponentAService

BindingWeb ServiceSCAJCAJMSSLSB…

BindingWeb ServiceSCAJCAJMSSLSB…

ComponentB

Service- Java interface- WSDL PortType

Reference- Java interface- WSDL PortType

Wire WireWire

Reference

Propertysetting

Properties

SCA Deployment

Components are deployed into an SCA Domain Represents a region of configuration and administrative control In general an SCA run-time is distributed and heterogeneous Defines the scope of what can be connected by SCA wires

Final overrides made at deployment time Bindings and endpoint URIs for published services Bindings and EPRs of external services Properties Concrete policy sets Similar goals to WL Deployment Plans

Simplifications when within one SCA Domain SCA wiring used for communication No binding necessary Required runtime capabilities specified with high-level “intent” statements, not

complete policy statements

Outline

Quick review of SCA





Local & Remotable Services

Local-Only Services Fine-grained, tightly coupled

interfaces

Interface may be language specific (e.g. Java or C++)

Parameters & return values by-reference

Client must be local (same address space)

Remotable Services Coarse-grained, loosely coupled interfaces

Interface must be representable with WSDL (possibly generated)

Parameters & return values by-value

Client may be remote

SCA promotes coarse-grained services by supporting tightly-coupled assembly in addition to loosely-coupled assembly.

The term “service” is possibly confusing for local-only services, but,other than the differences listed above, they are treated identically.

Conversational Services

Support for long-running conversations (often bi-directional)

Correlation information not specified in message body (i.e. not in parameters)

Example:

package com.bigbank;

@Conversational @Remotable public interface LoanService { public void apply(LoanApplication application); public void changePoints(double points); public String getLoanStatus(); @EndsConversation public void cancelApplication(); }

Conversation protocol specified by Policy Eg. WS-Context, WS-ReliableMessaging, WS-Conversation, JMS Correlation Header, etc.

@EndsConversation means no further operations will be called. Conversations can also end by timing out, with a timeout possibly specified in days.

Conversation Lifetimes

Conversations start on the client side when

A @Reference to a conversational service is injected; or

A call is made to CompositeContext.getServiceReference

and then a method of the service is called.

The conversation ends when:

Server @EndsConveration operation called

Callback @EndsConversation called

Server’s conversation lifetime timeout occurs

Client calls Conversation.end()

A non-business exception is thrown by a conversational operation

Scopes

Available in Java and C++ implementation types

Infrastructure instance management Persist appropriately and route requests to the right instances

Different lifetime & instance granularity: Composite – One per domain (semantically) Process – One per runtime process (e.g. JVM)

(not yet part of the spec) Conversation – One per client instance Request – One while handling a remote request Stateless – New every time

Initialization hooks for instance creation and destruction At the beginning and end of the scope, respectively Stateless is different from JavaEE stateless session beans, which are initialized

at server startup, not on every call.

LoanService with Conversational Scope

@Scope(CONVERSATIONAL) public class LoanServiceImpl implements LoanService { private String status; public void apply(LoanApplication application) { … status = “Not Yet Approved”; } public String getLoanStatus() { return status; } … }

APIs To Help When Not Using Conversational Scope

public interface ComponentContext {

ServiceReference getServiceReference(String referenceName);

…

}

public interface RequestContext {

ServiceReference getServiceReference();

…

}

public interface ServiceReference {

Conversation getConversation();

Object getCallbackID();

Object getConversationID();

void setConversationID(Object conversationId);

void setCallbackID(Object callbackID);

Object getCallback();

void setCallback(Object callback);

…

}

LoanService with Stateless Scope

@Scope(STATELESS) public class LoanServiceImpl

implements LoanService {

@Context private RequestContext request; … public void apply(LoanApplication application) { … String applicationID = requestContext.getConversationID();

application.setStatus(“Not Yet Approved”); persistenceHelper.store(approvalID, application); } public String getStatus() { String approvalID = requestContext.getConversationID(); Application application = persistenceHelper.find(approvalID); return application.getStatus(); } … }

Callbacks

Bidirectional interfaces have one interface for outbound, and a second interface that should be implemented by clients.

@Callback(ApprovalCallback.class) public interface LoanApproval { public void approve(LoanApplication application); }

public interface ApprovalCallback { public void answer(String approval); }

● AccountData● Service● Component

LoanService Approver

Approve

Answer

Conversational Callback Client

@Scope(CONVERSATIONAL) public class LoanServiceImpl

implements LoanService, ApprovalCallback {

@Reference protected LoanApproval approver; protected String status;

public void apply(LoanApplication application) { … status = “Not Yet Approved”; approver.approve(application); } public String getLoanStatus() { return status; } public String answer(String approval) { return status = approval; } … }

Stateless Callback Client

If the client is stateless, then the callback operation will go to a new (or pooled) instance. The client instance cannot maintain state related to the callback. Must store & retrieve state explicitly.

@Scope(STATELESS) public class LoanServiceImpl

implements LoanService, ApprovalCallback {

@Context private RequestContext request; @Reference protected ServiceReference<LoanApproval> approver; … public void apply(LoanApplication application) { String applicationID = requestContext.getConversationID();

application.setStatus(“Not Yet Approved”); persistenceHelper.store(approvalID, application); approver.getService().approve(application); String approvalID = approver.getCallbackID(); persistenceHelper.store(approvalID, application); } public String answer(String approval) { String approvalID = requestContext.getCallbackID(); Application application = persistenceHelper.find(approvalID); application.setStatus(approval); pesistenceHelper.store(application); } … }

Constructing Components with Spring

A Spring Application Context defines a composite Usable as the implementation of a coarse-grained component in SCA

SCA resolves wires from Spring beans to SCA components

SCA provides policies and bindings for services implemented in Spring

Two Spring Modules in one SCA Domain

SCA Domain

Application Context A

BeanX

DeclaredService

ReferenceAs A Bean

BeanY

Use of Spring ModuleA

Use of Spring ModuleB

Spring Application Context B

BeanZ

DeclaredService

BeanW

ServiceBinding

Spring App

Spring App

Spring Context A - XML File

<sca:service name=“X” type=“com.foo.BeanX” target=“beanX”/>

<sca:property name=“timeout” type=“Integer”/>

<bean id=“beanX" class=“com.foo.BeanXImpl"> <property name=“beanY”> <ref local=“beanY"/> </property> <property name=“timeout”> <ref>timeout</ref> </property> </bean> <bean id=“beanY" class=" com.foo.BeanYImpl "> <property name=“anSCAService"> <ref local=“mySCAService"/> </property> </bean>

<sca:reference name=“mySCAService” type=“com.foo.BeanZImpl”/>

Use of Spring Composite

<composite name=“SubsystemFoo”> <component name=“SpringComponent1”> <implementation.spring module=“SpringApplicationA” location=“archive/path”/> <references> <reference name=“myService”> SpringComponent2 </reference> </references> </component> <component name=“SpringComponent2”> <implementation.spring module=“SpringApplicationB” bundle=“archive2/path”/> </component> </composite>

Outline

Quick review of SCA





Allows component references to be wired to component services automatically (without explicit wires)

Matches references to services based on compatible interfaces, bindings, policy intents/sets

PaymentsComponent

PaymentService

AccountsCompositeExternal Banking Service

AccountsLedger

Component

ProductPricing

Component

Customer Account

Component

AutoWiring

Inclusion

X

Service A B

C

Y

Ref2B

C

Ref1

Includes

X

Service A

CRef1

B Ref2

Inclusion Recursive composition Implementation reuse through configurable

components Reusing composite configuration through

composite-level references and properties. Reusable bindings (See JMS binding spec)

Reuse in SCA

constrainingType Implementation independent Specifies the shape -- constraints in terms of

services/references/properties composites, components, componentType and

implementations can be constrained using the “constrainingType” attribute

Allows an architect to specify constrainingTypes which can be used by developers as a template

SCA provides runtime validation of artifacts with its constrainingType

Top-Down Design: ConstrainingType

<constrainingType name=“myCT” ... > <service name="MyValueService"> <interface.java interface="services.myvalue.MyValueService"/> </service> <reference name="customerService"> <interface.java interface="services.customer.CustomerService"/> </reference> <property name="currency" type="xsd:string"/> </constrainingType>

<component name="MyValueServiceComponent" constrainingType="myns:myCT” > <implementation.bpel process=“..."/> <service name=“MyValueService”> <interface.java interface="services.myvalue.MyValueService"/> <binding.jms .../> </service> <reference name="customerService" target="CustomerService"> <binding.ws ...> </reference> <property name="currency">EURO</property></component>

constrainingType Example

Outline

Quick review of SCA





Packaging and Deployment: DomainsComposites deployed, configured into SCA Domain Defines the boundary of visibility for SCA Typically an area of functionality controlled by single

organization/division

E.g.: accounts

Configuration represented by virtual composite potentially distributed across a network of nodes contains components, services, references, wires configured using composites

Composites make deployment simpler individual composites created, deployed independently may contain only wires or components or externally provided

services or references

Abstract services provided for management of the domain

Deployment: Domain-Level Composite

Composite Y

ComponentB

ComponentA

Composite AComposite B

Service

Composite X Composite Z

implementationimplementation

WireWireWire

Domain

Reference

Packaging and Deployment: Contributions

Contributions hold artifacts available for use in the Domain

Package containing artifacts necessary for SCA SCA defined artifacts

E.g.: composites, constrainingType, etc Non-SCA defined artifacts

E.g.: WSDL, XML schema, Java classes, object code etc

Packaging must be hierarchical

Metadata included in the “META-INF” directory

<contribution xmlns=http://www.osoa.org/xmlns/sca/1.0>

<deployable composite="xs:QName"/>*

<import namespace="xs:String" location=”xs:AnyURI”?/>*

<export namespace="xs:String"/>*

</contribution>

Interoperable packaging format: ZIP

Other formats possible: filesystem directory, OSGi bundle, JAR file

SCA Runtime Example

SCA PHP Container

Assigned to be hosted by SCA Java container Assigned to be

hosted by SCA CPP container

Runtime Topology

DeploymentMapping

Service Compositions

SCA Domain

bigbank.accountmanagement

bigbank.stockquote

SCA JEE Containers SCA CPP Containers…

SCA Java Containers

SCA BPEL Container

Outline

Quick review of SCA





Generalizing Policy

WS-Policy is sometimes used for configuration but is not designed for it

WS-Policy is for external clients Must provide all details, so is necessarily complex

Runtime configuration needs those details plus additional information E.g. key store information, logging targets, etc

SCA Policy is for configuration

But, it can use defaults & reuse not available to external clients.

SCA Policy

SCA allows a few acceptable configurations to be created and used throughout

A policy intent is named for some capability, e.g. “confidentiality”

Each binding has PolicySets for how that policy intent is achieved. E.g. Binding.WS has WS-Policy assertions that configure “confidentiality” with

encryption

Service and references may require the capability by just naming it: <service name="myService" type="myType" requires="confidentiality"…

Policy Administrator

Policy Administrator defines the intent: <intent name=“confidentiality” constrains=“sca:binding”> <description> 3rd parties should be unable to read the messages </description> </intent>

…and policySets that achieve it

<policySet appliesTo=“binding.ws” provides=“confidentiality”> <wsp:PolicyAttachment> ... Standard WS-Policy </wsp:PolicyAttachment> </policySet

<policySet appliesTo=“binding.ejb” provides=“confidentiality”> <some bit of IIOP configuration> </policySet>

Attaching Profiles and mapping to PolicySets

Module

Profile

Interaction Policy

Interaction Policy

Implementation Policy

B

Module

Componentservice

Profile

Profile

reference

@requires=Authentication

messageIntegrityreliability

<PolicySet>@provides=“authenticationmessageIntegrity exactlyOnce”

Policieslocate

WS-Policy

Binding Web ServicesJCAJMS…

@appliesTo=“binding.ws”

Qualified Intents

Developers or assemblers may need to specify some aspect of how the intent is provided

Without specify everything, or even the binding to use

Example: Confidentiality could be provided with Message-level encryption

<service name="myService" type="myType" requires="confidentiality.message"…

Transport-level encryption <service name="myService" type="myType" requires="confidentiality.transport"…

An intent named A.B means: A is a Qualifiable Intent B is a Qualifier – one way of achieving A

Further Qualification is allowed: Requires=“confidentiality.message.body”

Profile Intents

Shortcut for specifying a group of other intents

Expands into a list of other intents

<intent name="sca:messageProtection" constrains="sca:binding" requires="sca:confidentiality sca:integrity">

<description> Protect messages from unauthorized reading or modification.

</description></intent>

Intents Provided by Bindings

The binding technology can satisfy intents E.g. JMS supports reliable messaging

Binding Type declarations specify intents satisfied

<bindingType type=“sca:binding.jms" mayProvide=“sca:atLeastOnce sca:atMostOnce sca:ordered"? alwaysProvides = “sca:jms"?/>

@type = the element name used for the binding@mayProvide = intents that are provided only if the service or reference requires it@alwaysProvides = intents that are always provided

The intents provided by a binding are vendor specific.

Configuring Infrastructure with Intents

Infrastructure provides configurable capabilities for communication:

Authentication Encryption Non-Repudiation Reliable Messaging

…as well as for hosting components Authorization Transactions Monitoring & Logging

Each is represented with intents, sometimes qualified

Reliability Intents

atLeastOnce Message MUST be delivered at least once. Duplicates are allowed.

atMostOnce Message MAY be delivered. Duplicates are NOT allowed.

exactlyOnce A profile intent that expands to “atLeastOnce atMostOnce”

Ordered For each sending component, the receiver MUST receive messages in

the order they were sent. No ordering is required between messages sent by different senders

Security Intents

authentication – Client must reliably identify the security subject (e.g. username / password)

confidentiality – Prevent unauthorized reading of message traffic (e.g. encryption)

integrity – Prevent unauthorized modification of messages (e.g. signing)

Each intent supports the following qualifiers:

transport – guarantee it at the transport layer.

message – guarantee it for the message (end-to-end)

Transaction Implementation Intents

managedTransaction – Some form of managed transaction must be used.

managedTransaction.global – A global transaction should be joined or started

managedTransaction.local – Local transactions for each resource should be used. Committed when the remotable method completes Multiple resources may be used, but no atomicity guarantee

noManagedTransaction – No managed transaction should be used. App code will demarcate transactions, or resource will commit after each method called on the it

(absent) – No requirement. Deployer or vendor runtime may choose any of the above strategies.

OneWay Transaction Intents

TransactedOneWay Send only at commit Receive is successful only if commit is successful

ImmediateOneWay Message sent immediately, not at commit Enables a send and corresponding receive within one txn

Transaction Interaction Intents

propagatesTransaction – Join the transaction of the client. Transactional clients can depend on atomicity.

suspendsTransaction – Don’t join any transactions. Suspend any existing transaction before making the call on this service

or reference.

Not relevant for OneWay, as txn is never propagated on OneWay

Other Intents

SOAP –The SOAP messaging model must be used by the binding. Without a qualifier, any version may be used.

Qualifiers: SOAP.1_1 – Must use SOAP v1.1 SOAP.1_2 – Must use SOAP v1.2

JMS – The binding must support JMS API Used to limit the bindings chosen when the sender or receiver needs to use the

JMS API

NoListener – For references only. The must not accept new inbound connections. Use a backchannel or polling.

BP.1_1 – Binding must conform to WS-I Basic Profile version 1.1.

Conversational – The binding must be able to generate and send conversation IDs.

SCA Policy Assertions for Authorization

A few policy assertions are also standardized in SCA

Policy assertions are used in Policy Sets

Allowed roles are specified with one of the following:

<allow roles="list of role NCNames"><permitAll/><denyAll/>

<runAs role="NCName">

Security Identity is specified with the runAs assertion By default, the service runs with the identity of the caller.

Documents

1 Advanced SCA Michael Rowley, Ph.D. Director, Technology Office of the CTO April 28, 2008 TS-3765