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 - Haleh

Many articles have been written about SOA and Service Component Architecture already. We are not about to repeat the same story here. You can refer to any of the references below 1 to learn more about Service Component Architecture or simply search the web. Instead, this article focuses on a real, available, open source implementation for Service Component Architecture that provides a simple way to implement SOA solutions. This free open source project is called the Apache Tuscany. The project started in 2006 and is being used by many who are looking for a simple SOA infrastructure. Apache Tuscany release 1.0 which was announced in September 2007 supports Service Component Architecture specification 1.0, but an interesting aspect of Tuscany is that in addition to implementing the SCA specification, Tuscany 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 avaialable in Apache Tuscany. For example, support for Ruby, JavaScript, Xquery, web 2.0, distribution and management are currently extensions beyond the specification.

This article will walk you through what is available in Apache Tuscany, and therefore it highlights SCA benefits, with real use case scenarios.

Using samples from Tuscany.

Using Tuscany SCA

A Common Approach To Application Construction and Deployment - Haleh

The increasingly diverse integration market is influenced by technology choices, regulations, competition and expectations for responsiveness to change. Enterprises need the flexibility to adopt new business practices (like outsourcing of mortgage handling by a bank), enforce new regulations and extending or down-sizing without much cost (M & A). In addition, as the complexity of the enterprise grow, a common management paradigm becomes a necessaity for managing the business. Service Component Architecture provides a simple programming model to address these challenges. SCA's simple language maps easily to business model questions. Let's consider we are building a banking application. The following business level questions might come up and the table below shows how the questions are answered using SCA as the programing paradigm.

What are the choices for technology?

The rest to be done .....

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 define an XML description of assembled services which separates service implementation from the technologies used to connect them together into a working application. For example, here is a Java class which implements an account service to provide a getAccountTotal() operation in accordance with the AccountService interface.

@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;
    }
}

Here SCA is asked to make this AccountService available over the JSONRPC protocol.

<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, this could range from dictating which communications should be encrypted to describing what level of monitoring and logging 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. This is not much of a hurdle though as Tuscany SCA has a straightforward extensibility model so new or proprietary technologies can easily be included.

The following sections describe Tuscany SCA in the context of a number of familiar use cases.

Enterprise Applications - Raymond

Believe or not, the SCA idea orginally comes from the business integration space. I think that's natural because in a typical enterprise, business functions are implemented using various technologies, business data are represented in different ways and business services are communicated using heterogeneous protocols. To have all the applications in an enterprise talk to each other is a big challenge. On one hand, it's such a pain to learn, develop, deploy and integrate with all kinds of technologies. On the other hand, it's also impossible to converge all the applications into one stack such as web services.

Having a neutral layer beyond the traditional hardware, software and network and a unified programming model that works with all kinds of existing technologies will be ideal for business integrations. We should be able to adapt to the heterogenious infrastrcuture instead.

How SCA works with existing technologies. One solution that works with everything.

There are different patterns to support the smooth integration:

• Wrap the legacy application as a service component
• Invoke the lagacy application using an existing protocol
• Expose the new business functions over an existing protocol

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.

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
    targetNamespace="http://bigbank" xmlns:bb="http://bigbank" name="BigBank">

    <component name="AccountServiceComponent">
        <implementation.java class="bigbank.account.AccountServiceImpl" />

        <service name="AccountService">
            <tuscany:binding.jsonrpc uri="/AccountJSONService" />
            <binding.ws wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)" />
            <binding.sca />
        </service>

        <reference name="accountDataService" target="AccountDataServiceComponent" />
        
        <reference name="calculatorService">
            <tuscany:binding.rmi host="localhost" port="8099" serviceName="CalculatorRMIService" />
        </reference>
        
        <reference name="stockQuoteService">
            <binding.ws uri="http://localhost:8081/services/StockQuoteWebService" />
        </reference>

        <property name="currency">EURO</property>
    </component>

    <component name="AccountFeedComponent">
        <implementation.java class="bigbank.account.feed.AccountFeedImpl" />
        <service name="Collection">
            <tuscany:binding.rss uri="/rss" />
            <tuscany:binding.atom uri="/atom" />
        </service>
        <reference name="accountService" target="AccountServiceComponent" />
    </component>

    <component name="AccountDataServiceComponent">
        <implementation.composite name="bb:AccountData" />
    </component>

    <component name="WebResourceComponent">
        <tuscany:implementation.resource location="web" />
        <service name="Resource">
            <tuscany:binding.http uri="/" />
        </service>
    </component>

</composite>

        <reference name="stockQuoteService">
            <binding.ws uri="http://localhost:8081/services/StockQuoteWebService" />
        </reference>

This XML SCA configuration language allows you to describe you loosly coupled enterprise component integration in the same way you use Pring to configure components inside you applications.

With this in place we can;
Expose our existing enterprise application as a service using a variety of binding technologies

	    <service name="CalculatorService">
	        <tuscany:binding.rmi host="localhost" port="8099" serviceName="CalculatorRMIService"/>
	    </service>

    <component name="StockQuoteServiceComponent">
        <implementation.java class="stockquote.StockQuoteImpl" />
	    <service name="StockQuoteService">
	        <binding.ws uri="http://localhost:8081/services/StockQuoteWebService"/>
	    </service>
    </component>

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

TODO - Policy driven approach

binding.ws

Enabling Web 2.0 - Simon

A Web2.0 style application's ability to present a dynamic and responsive interface relies on an organization's ability to provide services for the application to interact with. A typical application will reference several services and integrate the provided data in the browser. As you might expect Tuscany SCA is ideally placed to enable such services using popular technologies such as JSONRPC, RSS and Atom protocols.

Tuscany demonstrates how a Web2.0 application and the services it relies on can be constructed using an internet shopping example called "Store" 2

From this sample 3 you can see a catalog component providing a service the Web2.0 application over JSONRPC. The calog component provides information about the products the store has for sale and has been constructed without regard for how it might be accessed. Using Tuscany the components Java implementation is associated with the JSONRPC binding (binding.jsonrpc).

<component name="Catalog">
    <implementation.java class="services.CatalogImpl"/> 
    <service name="Catalog">
        <t:binding.jsonrpc/>
    </service>
     ...
</component> 

Based solely on this information SCA makes three things available automatically;

• The Catalog JSONRPC service
• The JSONRPC service description (SMD)
• A generated Javascript JSONRPC proxy for accessing this service

A browser based application can now access this service directly using either the generated JSONRPC proxy or whatever JSONRPC client the application developer is familiar with, for example, from the sample;

catalog = (new JSONRpcClient("../Catalog")).Catalog;
catalog.get(catalog_getResponse);

function catalog_getResponse(items) {
    var catalog = "";
    for (var i=0; i<items.length; i++)
        catalog += '<input name="items" type="checkbox" value="' + 
			 items[i] + '">' + items[i]+ ' <br>';
        document.getElementById('catalog').innerHTML=catalog;
    }

Clearly this pattern can be extended to any service your Web2.0 style application is required to communicate with. The full range of SCA features is also available to these services so, for example, our catalog service could easily be exposed as a web service by extending the SCA description of the service.

    ...
    <service name="Catalog">
        <t:binding.jsonrpc/>
    </service>
    ...

Note that no changes to the Catalog component code are required. SCA is doing all the hard work.

The services supporting your Web2.0 style applications are now provided using a single, consistent, SCA based mechanism. The same mechanism by which services are provided for other reasons in the enterprise. Hence Web2.0 services become part of the wider enterprise service orientation solution.

Tuscany SCA supports other modes of operation that will be of interest to Web2.0 application developers. For example, the Tuscany Java SCA Chat sample 4 uses binding.dwr to provide a Direct Web Remoting (https://dwr.dev.java.net/) connection between a Javascript browser based application and an SCA service. Using this binding, service to browser communication is supported alongside browser to service communication.

TODO - the following diagram is the reality but is at odds with the diagram in the PDF which show what we would like it to be

TODO - we said we would move the following but it doesn't feel like there is a better home for it.

To provide consistency for Web2.0 style application developers script language based component implementations can also be used. Tuscany SCA provides implementation.script which currently supports Javascript, Groovy, Ruby and Python. Those developers comfortable with writing browser based scripts can now provide server side component implementations also. The Tuscany Java SCA Calculator Script (samples/calculator-script) shows scripts at work. Here is a component description.

<component name="AddServiceComponent">
    <tuscany:implementation.script script="calculator/AddServiceImpl.js"/>
</component>

Here is and example of a component implemented using Javascript.

function add(n1, n2) {
   return n1 + n2;
}

Data integration - Raymond

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

Let's look at a simple scenario that deals with aggregation of XML data from different sources. The business function is to calculate the total value of all the accounts (checking, saving and stock) that a customer owns.

1) A live feed to retrieve the exchange rate (binding.feed) and use XPath to
exact the rate for a given currency. I have to use Rome API to convert the
feed as our feed binding produces Feed objects.

2) The account data for a customer is loaded from a XML file. (We can use
implementation.data once Sebastien's proposal is implemented).

3) A live Web Service invocation to get the quotes for a list of symbols.
Only XMLStreamReader is used as the input and output. (binding.ws)

4) The calculation of the total value is implemented using XQuery to join
the XML data from 2 and 3. (implementation.xquery)

• • 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.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="AccountService">
        <implementation.java class="bigbank.AccountServiceImpl" />
        <reference name="accountData" target="AccountData" />
        <reference name="stockValue" target="StockValue" />
        <reference name="exchangeRate" target="ExchangeRate"/>
        <property name="currency">EUR</property>
    </component>

    <component name="ExchangeRate">
        <implementation.java class="bigbank.ExchangeRateImpl" />
        <reference name="exchangeRate">
            <tuscany:binding.rss
                uri="http://ansuz.sooke.bc.ca/rippy/exchange/?M=R&amp;B=USD&amp;F=CAD,CNY,EUR&amp;T=F&amp;S=O&amp;I=S" />
        </reference>
    </component>

    <component name="AccountData">
        <implementation.java class="bigbank.AccountDataImpl" />
    </component>

    <component name="StockValue">
        <tuscany:implementation.xquery location="stock.xq" />
    </component>

    <reference name="StockQuoteReference" promote="AccountService/stockQuote">
        <binding.ws wsdlElement="http://swanandmokashi.com#wsdl.port(StockQuotes/StockQuotesSoap)" />
    </reference>

</composite>

Into The Enterprise - Simon

Distribution
Policy
Alternative impl Scripting BPEL

The service oriented approach to building applications promotes the benefits of deploying running solutions as a collection of loosely coupled services. Tuscany Java SCA provides a runtime that will host these loosely couple services in a single JVM or across multiple JVMs.

Tuscany Java SCA uses the term Node to describe a single Tuscany SCA runtime and the term Domain to describe a collection of nodes that together run related but distributed services in an SCA application

You will have see previously in this paper the use of specific binding configuration access remote services, for example,

binding.ws with uri set

Tuscany SCA brings an easier to use mechanism for providing communication with remote services within a domain. As Tuscany SCA knows where all services are in the domain you can simply refer to the target service by names and Tuscany SCA will use a default SCA binding to communicate with it regardless of whether the service is local or remote to the calling component.

target based reference

The benefit of this approach is that the infrastruture can be adjusted and the components redeployed without having to change any .composite file information.

Getting Started With Your Own Project - TBD

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 is also a link (http://incubator.apache.org/tuscany/sca-java-releases.data/onlineStore.pdf) to detailed instructions of how to build a simple Web2.0 application using Tuscany Java SCA.

There are many more samples provided in the "samples" directory of the release. The file samples/README gives an overview of each of them and each sample comes with its own README and a graphical 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. Yo can of course take a suitable sample and use that as a starting point. Primarily you application development process will involved the following steps.

• Identify the components in you application and the services that these components provide
• Identify the services that these components depend on. These are the components references.
• Build an XML (.composite) file describing the components, services, references and the relationships between them
• Build the component implementations
• Contribute the .composite file, the component implemenations and any dependencies to the Tuscany SCA runtime.

The order here varies as in may cases you may already have suitable component implementations that you just want to describe to Tuscany SCA.

Choosing how to run the Tuscany SCA runtime depends on you local environment but there are several options currently supported.

• Embedded into your own Java application.
• As a plugin to the Geronimo application server
• As a WAR file contributed to a suitable web application server

Summary

V1.0 ready for prime time?
It is extensible so you can add to it (and contribute)

References

1 general SOA and SCA papers
2 Getting Started With SCA - Store - http://cwiki.apache.org/confluence/display/TUSCANY/Getting+Started+with+Tuscany+Release+1.0 - Needs linking into the web page
3 http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/store/
4 http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/chat-webapp/

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.

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