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 component Examples:  Java TM 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 public interface AccountService{ public AccountReport getAccountReport(String customerID); } public class AccountServiceImpl implements AccountService private String currency = private AccountUpgradeService 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

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; ۤ ۤ public interface LoanService { ۤ public void apply(LoanApplication application); ۤ public void changePoints(double points); ۤ public String getLoanStatus(); ۤ public void cancelApplication(); ۤ } Conversation protocol specified by Policy  Eg. WS-Context, WS-ReliableMessaging, WS-Conversation, JMS Correlation Header, 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 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: operation called 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 ۤ 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 ۤ public class LoanServiceImpl implements LoanService { 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. ۤ 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 ۤ public class LoanServiceImpl implements LoanService, ApprovalCallback { ۤ 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. ۤ public class LoanServiceImpl implements LoanService, ApprovalCallback { private RequestContext request; protected ServiceReference 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 Bean X Declared Service Reference As A Bean Bean Y Use of Spring Module A Use of Spring Module B Spring Application Context B Bean Z Declared Service Bean W Service Binding Spring App

Spring Context A - XML File ۤ ۤ timeout ۤ

Use of Spring Composite ۤ ۤ <implementation.spring module=“SpringApplicationA” ۤ location=“archive/path”/> ۤ ۤ SpringComponent2 ۤ ۤ <implementation.spring module=“SpringApplicationB” ۤ bundle=“archive2/path”/> ۤ

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

n Allows component references to be wired to component services automatically (without explicit wires) n Matches references to services based on compatible interfaces, bindings, policy intents/sets Payments Component Payment Service AccountsComposite External Banking Service Accounts Ledger Component Product Pricing Component Customer Account Component AutoWiring

Inclusion X Service A B C Y Ref2 B C Ref1 Includes X Service A C Ref1 B Ref2

n Inclusion n Recursive composition n Implementation reuse through configurable components n Reusing composite configuration through composite-level references and properties. n Reusable bindings (See JMS binding spec) Reuse in SCA

n constrainingType l Implementation independent l Specifies the shape -- constraints in terms of services/references/properties l composites, components, componentType and implementations can be constrained using the “constrainingType” attribute l Allows an architect to specify constrainingTypes which can be used by developers as a template l SCA provides runtime validation of artifacts with its constrainingType Top-Down Design: ConstrainingType

EURO 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: Domains Composites 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 Component B A Composite A Composite B Service Composite XComposite Z implementation Wire 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 * 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 Deployment Mapping Service Compositions SCA Domain bigbank.accountmanagement bigbank.stockquote SCA JEE ContainersSCA 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: ۤ ۤ 3 rd parties should be unable to read the messages ۤ …and policySets that achieve it ۤ ۤ... Standard WS-Policy ۤ ۤ </policySet ۤ

Attaching Profiles and mapping to PolicySets Module Profile Interaction Policy Implementation Policy B Module Component service Profile Authentication messageIntegrity messageIntegrity exactlyOnce” Policies locate WS-Policy Binding Web Services JCA JMS

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"> Protect messages from unauthorized reading or modification.

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 = = the element name used for the = intents that are provided only if the service or reference requires = 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: Security Identity is specified with the runAs assertion  By default, the service runs with the identity of the caller.