Transcript slides - Events

www.oasis-open.org
SCA: Flexible and Agile
Composition of Distributed
SOA Applications
Simplicity, Consumability, Agility
OpenCSA Member Section – Service Component Architecture
Mike Edwards - IBM
Hursley Lab, England
1
Agenda




Customer scenario
SCA overview
SCA details
Web 2.0 & SCA
OpenCSA Member Section – Service Component Architecture
2
Customer scenario

A bank implemented a pilot project using SCA and SDO

Growing presence in multiple countries

Wide variety of technologies in use:


Unix Mid Range, AS400, Mainframe, WebSphere / WebLogic, Java /
.NET, Kitchen Sink
The group that sponsored the project is responsible for
Retail Banking Channel – Presentation and Service Tier

Rollout of "Official" SOA strategy

Set the standards for future initiatives within the Bank
OpenCSA Member Section – Service Component Architecture
3
Problem: Lack of an
enterprise-wide SOA framework



Proliferation of standards and frameworks

WS-*

Apache SOAP

Apache AXIS

XFire

IBM Web Services Runtime

Open source frameworks

Custom built frameworks
Never ending cycle of migration and reinventing the wheel

Hurting time to market

Extra costs to maintain
Need to simplify service development

Allow service developers to focus on business logic

Make it easy to reuse services
OpenCSA Member Section – Service Component Architecture
4
Key features of the
customer’s infrastructure





Service Platform – WS-I Basic compliant, Java-based
client invocation and service endpoint framework
Expose services using different interfaces, multiple
invocation mechanisms (local, WSDL/schema, JMS...)
Service Lifecycle Events – Logging, Caching, Business
Validation, Error Handling...
Enable POJO programming model for developing services
Requirements, design, development, operational and other
processes to support SOA approach
OpenCSA Member Section – Service Component Architecture
5
Key features of the
customer’s infrastructure

Enterprise adoption:



Development, Deployment, Operational, Governance
Capabilities
Service development training material
Collaborative, shared ownership


All process, technical and other documentation placed
in a Wiki, open to contributions
Improvements took place using an "open source"
model, allowing any resource to contribute to code
base, with select group controlling commits
OpenCSA Member Section – Service Component Architecture
6
Thin
Client
Browser / AJAX
Rich
Client UI
IVR
Mobile
Web User Interface Components
Service Platform
Component
properties
Component
properties
Component
properties
properties
Component
Different Heterogeneous Backend Systems
OpenCSA Member Section – Service Component Architecture
7
Layers in the infrastructure

Access layer:




Middle tier:




Spring Framework (AOP, IOC) for applications,
IFX (Interactive Financial Exchange) for schemas and
interfaces
SCA/SDO to access services & data sources
WebSphere, Spring, JMS
Services built with SCA assembly model
IFX data packaged with SDO
Back end:

The usual suspects (transaction servers, mainframes,
relational databases, packaged apps)
OpenCSA Member Section – Service Component Architecture
8
Infrastructure based on
three open standards

SCA/SDO:





Becoming widely
recognized as a standard
Support for multiple
bindings configurable at
runtime
Configuration based
assembly of components
using dependency injection
Components can be
implemented using many
languages/technologies
Multiple implementations to
choose from
OpenCSA Member Section – Service Component Architecture

Interactive Financial
Exchange (IFX)


Standards-based data
exchange format for
business banking
Spring


AOP for lifecycle events
(Logging, Caching, Error
Handling, etc.)
Finer grained
dependency injection
9
Selling SCA

SCA, SDO enabled business to build service
platform with low barriers to adoption:




POJO components
Evolutionary SOA adoption
Open communities
Some original applications used POJOs. To
moving to an SOA, applications changed to use
SCA services

For now, the SCA services are just POJOs. When they
need to use other kinds of (SCA) services, they don’t
have to make any changes
OpenCSA Member Section – Service Component Architecture
10
The future


Future enhancements to infrastructure will take
advantage of wider features of SCA and SDO:

WS-Policy/WS-Security

Other implementations (COBOL)

Asynchronous invocation (JMS)

Presentation layer (AJAX, JSONRPC)

BPEL orchestration
Using these features will require very few
changes (if any) to their applications
OpenCSA Member Section – Service Component Architecture
11
Agenda




Customer scenario
SCA overview
SCA details
Web 2.0 & SCA
OpenCSA Member Section – Service Component Architecture
12
What SCA is

executable model for assembling services



handles service dependencies
Simplified component programming model for
implementing services


composites provide language to compose and
configure service components
BPEL processes, Java POJOs, EJBs, COBOL,
PHP scripts, C++ apps, JavaScript & AJAX, XSLT…
Late binding of policy and communication
methods, with distributed deployment model
OpenCSA Member Section – Service Component Architecture
13
Why SCA makes life simpler



One way to look at SCA is that it takes details of

access methods and endpoints

implementations and configuration

policy such as encryption, authentication
…and moves them into middleware layer
Application developers write business logic: code
that actually builds value for your organization



details of using services are handled by SCA
late binding: as details change, applications (and
developers who wrote them) aren’t affected
"no plumbing in the code"
OpenCSA Member Section – Service Component Architecture
14
Why SCA makes life simpler


SCA gives developers a
single programming model for using services
for all aspects of service lifecycle:
–
Construction
–
Assembly
–
Deployment
As your SOA gets more complex, developers
have to learn more and more interfaces
–

In Java alone: EJBs, RMI, JCA, JAX-WS, JMS
Similarly, SDO gives developers a single
programming model for using data sources
OpenCSA Member Section – Service Component Architecture
15
SCA is not…


…tied to a specific programming language,
protocol, technology, runtime
…a workflow model


…Web services



Use BPEL for that
SCA can access local objects, avoiding the overhead
of Web services
of course, many SCA applications will use Web
services
…an ESB


to program an ESB from scratch, SCA fits perfectly
but SCA is more than an ESB
OpenCSA Member Section – Service Component Architecture
16
SCA assembly
RMI/IIOP
AccountsComposite
Payment
Service
Order
Processing
Service
Payments
Component
External
Banking
Reference
OrderProcessing
Component
Accounts
Ledger
Component
Java EE
BPEL
SOAP/HTTP
Multi-level
composition
External
Warehouse
Reference
WarehouseComposite
Warehouse
Service
Warehouse
Broker
Component
Mixed:
- technologies
- app locations
Warehouse
Component
JMS
C++
OpenCSA Member Section – Service Component Architecture
Shipping
Reference
17
Agenda




Customer scenario
SCA overview
SCA details
Web 2.0 & SCA
OpenCSA Member Section – Service Component Architecture
18
Simple Example
bigbank.accountcomposite
Reference
StockQuote
Service
Service
AccountService
AccountService
Component
AccountData
Service
Component
OpenCSA Member Section – Service Component Architecture
19
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="bigbank.accountcomposite" >
<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>
StockQuote
bigbank.accountcomposite
</component>
Reference
StockQuote
Service
AccountService
Service
<component name="AccountDataServiceComponent">
Component
AccountService
<implementation.bpel process=“QName"/>
<service name="AccountDataService">
<interface.java interface="services.accountdata.AccountDataService"/>
</service>
</component>
AccountData
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>
<composite>
OpenCSA Member Section – Service Component Architecture
20
Java Implementation Example:
Service Interface
package org.example.services.account;
Interface is callable
remotely
eg. as a Web service
@Remotable
public interface AccountService {
public AccountReport getAccountReport(String customerID);
}
OpenCSA Member Section – Service Component Architecture
21
Java Implementation Example (1)
package org.example.services.account;
import org.osoa.sca.annotations.*;
@Service(interfaces = AccountService.class)
public class AccountServiceImpl implements AccountService {
private String currency = "USD";
private AccountDataService accountDataService;
private StockQuoteService stockQuoteService;
Annotation for the
service offered by
this class
Constructor with
annotations for
injected property
and references
public AccountServiceImpl(
@Property("currency") String currency,
@Reference("accountDataService") AccountDataService dataService,
@Reference("stockQuoteService") StockQuoteService stockService) {
this.currency
= currency;
this.accountDataService = dataService;
this.stockQuoteService = stockService;
}
OpenCSA Member Section – Service Component Architecture
22
Java Implementation Example (2)
public AccountReport getAccountReport(int customerID)
throws AccountDataUnavailableException {
Get the basic account
report using the
account data service
AccountReport accountReport =
accountDataService.getAccountReport(customerID);
List<Stock> stocks = accountReport.getStocks();
Obtain up to date stock
values using the stock
List<StockValues> stockValues =
quote service
stockQuoteService.getValues( stocks, currency );
accountReport.setStockValues( stockValues );
return accountReport;
}
} // end class
OpenCSA Member Section – Service Component Architecture
Update the account
report with the latest
stock values
23
Associating Policies with
SCA Components



Intents and/or policySets can be associated with any SCA
component
At deployment time intents map to Policies contained in policySets
Examples attaching intents:
Confidentiality applied to
any use of the service
<service name="AccountService“ promote=“AccountServiceComponent”
requires="sca:confidentiality">
<interface.java interface="services.account.AccountService"/>
<binding.ws port="http://www.bigbank.com/AccountService#
wsdl.endpoint(AccountService/AccountServiceSOAP)"/>
</service>
<reference name="StockQuoteService“
promote=“AccountServiceComponent/ stockQuoteService”>
<interface.java interface="services.stockquote.StockQuoteService"/>
<binding.ws port="http://www.quickstockquote.com/StockQuoteService#
wsdl.endpoint(StockQuoteService/StockQuoteServiceSOAP)“#
requires=“sca:confidentiality”/>
Confidentiality applied to
</reference>
Web service binding
OpenCSA Member Section – Service Component Architecture
24
Policy Sets

Policy Sets contain concrete Policies
<policySet name="sca:userNameTokenHashPassword"
provides="sca:authentication"
appliesTo="sca:binding.ws">
defines intents provided
<wsp:Policy>
<sp:SupportingToken>
<wsp:Policy>
<sp:UserNameToken>
what this policy applies to
<wsp:Policy>
<sp:HashPassword>
</wsp:Policy>
</sp:UserNameToken>
</wsp:Policy>
</sp:SupportingToken>
</wsp:Policy>
</policySet>
OpenCSA Member Section – Service Component Architecture
25
Runtime Topology
SCA Runtime
SCA JEE Containers
SCA Java Containers
SCA PHP Container
Deployment
Mapping
Assigned to be
hosted by SCA
Java container
SCA CPP Containers
…
SCA BPEL Container
Assigned to be
hosted by SCA
CPP container
SCA Domain
bigbank.accountmanagement
bigbank.stockquote
Service Compositions
OpenCSA Member Section – Service Component Architecture
26
Agenda




Customer scenario
SCA overview
SCA details
Web 2.0 & SCA
OpenCSA Member Section – Service Component Architecture
27
Web 2.0 Composite Applications
“implementation.widget”
Web Server
HTML + JS
Services
“implementation.widget”
- HTML + Javascript with SCA reference wiring
- Access services from scripts – with async
OpenCSA Member Section – Service Component Architecture
28
Web 2.0 Gadgets meet SCA
“implementation.widget”
Web Server
Gadget + HTML + JS
Services
other
Widgets
can be any
gadget supporting
mashup technology
OpenCSA Member Section – Service Component Architecture
“implementation.widget”
- HTML + Gadgets with SCA reference wiring
- Access services from scripts – with async
- Link to other on-screen gadgets
29
HTML & JS SCA Implementation
Store Implementation
<html>
<head>
<title>Store</title>
<script type="text/javascript" src="store.js"></script>
<script language="JavaScript">
Defines references to services
//@Reference
var catalog = new Reference("catalog");
//@Reference
var shoppingCart = new Reference("shoppingCart");
//@Reference
var shoppingTotal = new Reference("shoppingTotal");
function catalog_getResponse(items) {…}
function shoppingCart_getResponse(feed) {…}
function init() {
catalog.get(catalog_getResponse);
shoppingCart.get("", shoppingCart_getResponse);
}
Call reference operations
</script>
</head>
<body onload="init()">
<h1>Store</h1>
…
</body>
</html>
OpenCSA Member Section – Service Component Architecture
30
HTML & JS Component Configuration
Store Configuration
HTML & JS implementation
<composite name="store" … >
<component name="Store">
<t:implementation.widget location="uiservices/store.html"/>
<service name="Widget">
<t:binding.http uri="/ui"/>
</service>
<reference name="catalog" target="Catalog">
<t:binding.jsonrpc/>
</reference>
<reference name="shoppingCart" target="ShoppingCart/Cart">
<t:binding.atom/>
</reference>
<reference name="shoppingTotal" target="ShoppingCart/Total">
<t:binding.jsonrpc/>
</reference>
</component>
HTTP binding & address
Catalog service via JSONRPC
Wire
<component name="ShoppingCart">
<implementation.java class="services.ShoppingCartImpl"/>
<service name="Cart">
<t:binding.atom uri="/ShoppingCart/Cart"/>
</service>
<service name="Total">
<t:binding.jsonrpc/>
</service>
</component>
…
</composite>
OpenCSA Member Section – Service Component Architecture
31
Summary

OASIS SCA is a great way to build
distributed services applications




Compose services
Develop service components
Apply policies and bindings
Agile and Flexible systems
OpenCSA Member Section – Service Component Architecture
32
Useful links









Articles about SCA:
http://www.infoq.com/articles/setting-out-for-sca
http://www.osoa.org/display/Main/SCA+Resources
Open Source implementation of SCA:
http://cwiki.apache.org/TUSCANY/
SCA Specifications in OASIS:
http://www.oasis-opencsa.org/
Email address:
[email protected]
OpenCSA Member Section – Service Component Architecture
33