Work In progress
Audiance
New user
Its ready to useful things
Target
SOA World on line initially
October 15th
Issues
What demo app are we going to use this time round? I've just dropped some bits of XML to demonstrate the point but am not wedded to them.
How to refer to Tuscany Java SCA and be consistent
Contents
Intoduction - Haleh
- What is SCA
- What is Tuscany project
- Summary of V1.0 - status and what's in it
Applying Tuscany SCA To SOA
- Common Model For SOA - Simon
- Enterprise Integration - Raymond
- Web 2.0 - Simon
- Data Integration - Raymond
- Deployment and Distribution - Simon
Getting started with your own project
- First steps to Using Tuscany
- Walk through 1 or 2 of the samples
- Pointers to useful information
- How to get involved in the project
- You can extend it but details are a different paper
Summary - Haleh (first draft)
- Its ready to use
Introduction
There are has been many articles on SOA and Service Component Architecture. We are not about to repeat the same story. You can refer to any of the references below 1 to learn more about Service Component Architecture. Instead, let's focus on a real, available, open source implementation for Service Component Architecture that provides a simple way to implement SOA solutions. This open source solution is called Apache Tuscany. It has been around for a while and is getting a real use by many adopters. Apache Tuscany release 1.0 which was announced in September 2007 supports Service Component Architecture specification 1.0, but the interesting aspect of Tuscany is that in addition to the spec implementation, it is also an implementation nursery for new ideas that are not part of the specification yet. Some of these ideas will find their way to the specifications and some will be regarded as extensions. For example, support for Ruby, JavaScript, Xquery, web 2.0, distribution and management. This article will walk you through what is available in Tuscany, and therefore SCA benefits, with real use case scenarios.
Using Tuscany SCA
A Common Approach To Application Construction and Deployment
One of the less obvious benefits of a service orient approach and of the Service Component Architecture in particular is the potential to shrink the gap between the business and the IT organization which supports it, or even between different parts of the same IT organization.
Using a consistent model of applications and of the components from which they are constructed provides a common terminology and supports a common understanding of applications and they way that they work together. This common model provides the hook for tooling, governance, monitoring and management in the service oriented world.
There is no magic bullet but the use of common terminology and semantics encourages good service design. Using Tuscany SCA to build and assemble components suggests a contract led and technology and protocol independent approach. This in itself tends to lead to cleaner more business aligned components that can be improved, repurposed and reused with less effort than if the components had been written with specific technologies in mind.
This separation of business logic from the details of how a running application is assembled and deployed leads to a degree of software portability. More importantly though it leads to portability of ideas and a shared understanding of the capabilities and construction of the software.
Tuscany SCA achieves these benefits with a fairly light touch. The SCA specifications defines an XML description of assembled services which separates the component implementation;
@Service(AccountService.class) public class AccountServiceImpl implements AccountService { @Reference protected AccountDataService accountDataService; public double getAccountTotal(String customerID) { CheckingAccount checking = accountDataService.getCheckingAccount(customerID); SavingsAccount savings = accountDataService.getSavingsAccount(customerID); // Calculate the total balance of all accounts and return it double balance = checking.getBalance() + savings.getBalance(); return balance; } }
from the technologies used to connect them together;
<component name="AccountServiceComponent"> <implementation.java class="bigbank.account.AccountServiceImpl"/> <service name="AccountService"> <tuscany:binding.jsonrpc uri="/AccountJSONService"/> <binding.ws /> </service> </component>
The precise relationship between the abstract components and runtime infrastructure is further refined using policy statements to apply organizationally agreed constrains on the behaviour of the application in its deployed environment, for example, from dictating which communications should be encrypted to describing the level of monitoring and logging that is required.
Tuscany SCA does not define new technologies for component implementations and message exchange. It neither requires you to learn a new programming language or communications protocol. You are free to leverage you existing investment in applications and technology with the one proviso that a suitable binding exists in Tuscany SCA. Tuscany SCA though has a straightforward extensibility model so new or proprietary technologies can be included.
The following sections describe Tuscany SCA in the context of a number of familiar use cases.
Enterprise Integration
Let's think in SOA. Leave the IT things such as hardware, software and networks on side and think from the business perspectives. First, we need to identify the business functions and model them as service components. And then define the relationship between business functions. For example, Order Processing needs to deal with Inventory and Shipment. These dependencies are captured as references and services.
Business Functions |
Services Provided |
Services Consumed |
Order Processing |
Process Orders |
Check Inventory, Collect Payment, Arrange Shipments |
Inventory |
Check Inventory |
Warehouse |
Payment |
Collect payment |
Credit Card Authorization, PayPal |
Shipment |
Ship the order |
Shippers such as UPS, USPS or Fedex |
Map into SCA terms
Business Functions |
Components |
What business functions are provided? |
Services |
What other business functions are consumed? |
References |
What can be customized in the business logic? |
Properties |
How is the business logic implemented? |
Implementation |
How are the depending services fulfilled? |
Wire |
How are the components communicated? |
Binding |
How are the quality of services enforced? |
Intent/Policy |
- Implement the business functions using the preferred languages
- Integrate with existing business functions
Once we have all the business logic implemented, we can then decorate the references and services with proper bindings so that they can collabrate over the networks.
In almost every enterprise today there is a requirement to have one computer system talk to another. For example, imagine the invoicing system wanting to get at the central CRM system
SCDL showing Invoicing talking to CRM over binding.ws
This XML SCA configuration language allows you to describe you loosly coupled enterprise component integration in the same way you do configure spring inside you applications.
With this in place we can;
Expose our existing enterprise application as a service using a variety of binding technologies
SCDL showing and extra binding.rmi added
Access enterprise services using a variety of binding technologies
The reference side with a binding.jms (JMS not in v1.0 though)
Create new components that direct the operation of services according to your business process regardless of the protocols that the services require
A simple Java component
TODO - bring in binding.ejb
<component name="AccountDataServiceComponent"> <implementation.java class="bigbank.accountdata.AccountDataServiceImpl" /> <reference name="brokerService"> <binding.ejb uri="corbaname:iiop:1.2@localhost:1050#BrokerServiceBean" /> </reference> </component>
TODO - Enabling B2B
- Providing and assembling the service behind your B2B exchanges
Enabling Web 2.0
A web2.0 style application's ability to present a dynamic and responsive interface relies on and organizations ability to provide services for the application to interact. As you might expect Tuscany SCA is ideally placed to provides those services using popular technologies such as JSON, XML, RSS, Atom.
SCDL showing component exposing JSON and RSS bound service
Here a browser based application can connect direct to the SCA sevices using the usual approach
A snippet of java script showing JSON request
Tuscany SCA support other modes of operation also, for example, Direct Web Remoting link is supported with bining.dwr. Using this binding service to browser communication is supported slongside browser to service communication.
Script language based components can also be used. Tuscany SCA provides implementation.script. Those developers comfortable with writing browser based scripts can, for example, write service base java script components
SCDL showing implementation.script
Simple javascript component
TODO - Policy driven approach
binding.ws
Data integration
In an SOA environment, business service collaborations are achieved by data exchanges between service components. Business data come from different sources and they are represented in different ways. Tuscany provides a few features in the data area to facilitate the data integrations.
Databindings (XML, SDO, JAXB, JSON ...)
In an SOA environment, business functions can be implemented in various technologies such as Java, C++, Scripting, BPEL, Spring, OSGi and XQuery. The business data can also be represented in different formats such as DOM, JAXB, SDO, AXIOM or POJO. Business services often communicate with each other on the network using various protocols such as RMI, RMI/IIOP, SOAP/HTTP, JMS, JCA, FEED and JSON-RPC. The service collaborations are achieved by data exchanges between service components. The SCA programming model defines an extension model for interface, implementation and binding types. The extensibility is essential to SOA as we need to be able to leverage and integrate all kinds of technologies. On the data side, we also need the extensibility for different formats so that we can flow any data type that is supported by both the client and the provider.
Business data are represented in different ways even they are for the same infoset. For example, we can model a Customer business object as:
-
- JavaBeans
- SDO
- JAXB
- XMLBeans
- DOM
And different protocol implementation stacks support different data representations. For example, in the Web Service domain, we have:
-
- Axis1 uses DOM
- Axis2 uses AXIOM
- JAX-WS uses JAXB
Implementation technologies may impose requirements on the data too. For example,
-
- Apache ODE BPEL engine only consumes/produces data using DOM
- SAXON XQuery engine consumes/produces data using NodeInfo
- DAS implementation requires SDO
- Script Implementation uses AXIOM
Application developers should have the freedom to choose their preferred data representation and components with compatible data should be able to interoperate without the intervention of the business logic. With the ability to attach data transformation mediations to wires, this actually becomes a requirement to support any data type that can be mapped from client to provider and back again.
Implementation/binding types for data access and data manipulation
-
- implementation.xquery
XML is most popular data representation in SOA world. XQuery is becoming the most applicable language for extracting and transforming data from any source that can be represented as a phsical or logical XML document. Its SQL-like syntax is relatively easy to learn and it already has a role in SOA for extracting and transforming data. The XQuery implementation type brings the power of XQuery and SCA together. With the help of the databinding framework, we can use the XQuery to mediate data from many services and we also extend the XQuery capability by invoking other SCA components.
- implementation.xquery
-
- implementation.data and implementation.das
- binding.ws
- binding.feed
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0" targetNamespace="http://bigbank" name="BigBank"> <component name="CustomerAsset"> <implementation.java class="bigbank.CustomerAssetImpl" /> <reference name="accountData" target="AccountData" /> <reference name="stockValue" target="StockValue" /> <reference name="exchangeRate"> <tuscany:binding.rss uri="http://ansuz.sooke.bc.ca/rippy/exchange/?M=R&B=USD&F=CAD,CNY,EUR&T=F&S=O&I=S" /> </reference> </component> <component name="AccountData"> <implementation.java class="bigbank.AccountDataImpl" /> </component> <component name="StockValue"> <tuscany:implementation.xquery location="stock.xq" /> <!-- <property name="currency">USD</property> --> </component> <reference name="StockQuoteReference" promote="CustomerAsset/stockQuote"> <binding.ws wsdlElement="http://swanandmokashi.com#wsdl.port(StockQuotes/StockQuotesSoap)" /> </reference> </composite>
Distribution
Getting Started With Your Own Project
The easiest way to get started with Tuscany SCA is to download the latest release and try some of the samples. You can get the latest release from here (http://incubator.apache.org/tuscany/sca-java-releases.html).
There is set of guides for the Tuscany Java SCA software here (http://incubator.apache.org/tuscany/java-sca-documentation-menu.html). In particular the User Guide provides a simple walkthough of the Tuscany Java SCA Calculator sample. There are many more samples provided. If you look in the "samples" directory you will find a wide range of different samples. The file samples/README gives and overview of each of them and each sample comes with its own README and a graphica representation (.png file) of the services that the sample is demonstrating.
Once you have a feel for how Tuscany operates you will likely want to build a project of your own.
Summary
V1.0 ready for prime time?
It is extensible so you can add to it (and contribute)
Old Words
Introduction
The Service Component Architecture would never claim to solve every one of your distributed computing problems, or even provide and answer to all of the questions you are likely to have about Service Oriented Architecutures. It does how ever provide a consistent component programming and assembly model that will pay dividends in lots of situations.
The most first benefit you will see when you start to use the Tuscay SCA implementation is that it removes the need to learn lots of different APIs for connecting to remove service or for exposing service for others to connect to.
Before SCA the typical mode operation for building a program that had to talk remotely to other programs was to read the SOAP, RMI, REST manual for the product of you choice.
You ended up with code like the following
// some business logic // some comms api logic // some business logic
With Tuscany SCA the application developers to focus on business logic and all other concerns to be addressed by the supporting runtime. There are many more benefits of course alongside conmmuncation technology abstraction
- Implement the business logic in your preferred programming language
- Externalize the dependencies to promote loose-coupling and use the dependency injection to
- Declarative bindings to eliminate the learning curve/coupling of technology APIs such as JAX-WS, EJB, JMS
- Declarative intents/policies to enforce the QoSs