Download - 1 Advanced SCA Michael Rowley, Ph.D. Director, Technology Office 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) { … }
…}
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
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
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
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
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 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
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
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
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
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.