...

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

Enabling Web 2.0

A typical Web2.0 application will reference several services in the organization and integrate the provided data in the browser. Tuscany SCA enables 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" 6. There is a guide which walks through the steps required to build this sample 7.

Image Removed

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.

Another feature of SCA that enables this separation is the support for policy and policy intents that allow organisation wide statements of intent to be made about the way that an application will behave.

For example, the helloworld-ws-service-secure sample ? shows how the intention that clients accessing a service must be authorized to do so can be expressed. From this sample you can see a Catalog component providing a service to the Web2.0 application over JSONRPC. The Catalog 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 SCA the components Java implementation is associated with the JSONRPC binding (binding.jsonrpc).

<component name="CatalogHelloWorldServiceComponent">
    <implementation.java class="serviceshelloworld.CatalogImplHelloWorldImpl" /> 
    <service name="CatalogHelloWorldService" requires="authentication">
        <t:binding.jsonrpc<interface.wsdl interface="http://helloworld#wsdl.interface(HelloWorld)" />
    </service>
     ...
</component> 

Based solely on this information Tuscany 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 access this service directly using either the generated JSONRPC proxy or whatever JSONRPC client the application developer is familiar with, for example, the store sample uses the following javascript:

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 then available to these services. For example, our Catalog service could easily be exposed as a web service (binding.ws) by extending the SCA description of the service.

<binding.ws uri="http://localhost:8085/HelloWorldService"/>
    </service>
 </component>

Note that the <service> element carries an intent that interactions require "authentication". How authentication is actually implemented is then a matter of policy with the organization. Again this brings consistency of operation and understanding across and organization.

Enabling Web 2.0

A typical Web2.0 application will reference several services in the organization and integrate the provided data in the browser. Tuscany SCA enables 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" 6. There is a guide which walks through the steps required to build this sample 7.

Image Added

From this sample you can see a Catalog component providing a service to the Web2.0 application over JSONRPC. The Catalog 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 SCA 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 Tuscany 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 access this service directly using either the generated JSONRPC proxy or whatever JSONRPC client the application developer is familiar with, for example, the store sample uses the following javascript:

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

function catalog_getResponse(items) {
    var catalog = "";
    for (var i=0; i<items.length; i++)

    ...
    <service name="Catalog">
        <t:binding.jsonrpc/>
        <binding.ws/>
    </service>
catalog += '<input name="items" type="checkbox" value="' + 
			 items[i] + '">' + items[i]+ ' <br>';
        document...

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

SCA has provided services to the Web2.0 application with very little effort on behalf of the developer. What effort is expended is not particular to supporting Web2.0 applications as the services
are now part of the wider enterprise service orientation approach.

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 8 provides binding.dwr to implement a Direct Web Remoting 9 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.

Image Removed

TODO - move policy stuff here.

Data integration

On of the main values of an SOA environment is to support a consistent framework for data exchange between business services. Business data comes from many different sources and is presented in many different formats. Tuscany SCA provides several features to ease data integration.

Let's look at a simple scenario that deals with aggregation of XML data from different sources. This demo didn't make it into the V1.0 Tuscany SCA release but it is expected to be in a future release. The business function here calculates the total value of all the accounts (checking, saving and stock) that a customer owns.

Image Removed

1) Use an RSS feed to retrieve the currency exchange rates from the web and exact the rate for a given currency.
2) Load the account data for a customer from an XML file or database.
3) Invoke a live web service to get the quotes for a list of symbols.
4) Calculate of the total value by joining the XML data from 2 and 3.

In this case, data are loaded/received from various data sources and manipulated as XML. As business data may be represented in many different ways even they are for the same infoset Tuscany SCA provides a number of different databindings . For example, we can model a Customer business object as:

• • JavaBeans
  • SDO
  • JAXB
  • XMLBeans
  • DOM

Different protocol implementation stacks also 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 also 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 without being driven by the above concerns. Tuscany SCA provides suitable data transformation mediations which are attached automatically the wires between components to take account of the difference choices that the component developer and deployer may make.

In the sample here the exchange rate is retrieved (step 1) using the feed binding (binding.rss) as follows.

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

Step 3 uses the web service binding (binding.ws) to retrieve stock from the internet.

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

The various XML data are joined together using XQuery (implementation.xquery) in step4. XML is most popular data representation in the SOA world. XQuery is becoming the most applicable language for extracting and transforming XML data. Its SQL-like syntax is relatively easy to learn. 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 the capability of an XQuery can be extended by invoking other SCA components.

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 then available to these services. For example, our Catalog service could easily be exposed as a web service (binding.ws) by extending the SCA description of the service.

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

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

SCA has provided services to the Web2.0 application with very little effort on behalf of the developer. What effort is expended is not particular to supporting Web2.0 applications as the services
are now part of the wider enterprise service orientation approach.

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 8 provides binding.dwr to implement a Direct Web Remoting 9 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.

Image Added

TODO - move policy stuff here.

Data integration

On of the main values of an SOA environment is to support a consistent framework for data exchange between business services. Business data comes from many different sources and is presented in many different formats. Tuscany SCA provides several features to ease data integration.

Let's look at a simple scenario that deals with aggregation of XML data from different sources. This demo didn't make it into the V1.0 Tuscany SCA release but it is expected to be in a future release. The business function here calculates the total value of all the accounts (checking, saving and stock) that a customer owns.

Image Added

1) Use an RSS feed to retrieve the currency exchange rates from the web and exact the rate for a given currency.
2) Load the account data for a customer from an XML file or database.
3) Invoke a live web service to get the quotes for a list of symbols.
4) Calculate of the total value by joining the XML data from 2 and 3.

In this case, data are loaded/received from various data sources and manipulated as XML. As business data may be represented in many different ways even they are for the same infoset Tuscany SCA provides a number of different databindings . For example, we can model a Customer business object as:

• • JavaBeans
  • SDO
  • JAXB
  • XMLBeans
  • DOM

Different protocol implementation stacks also 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 also 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 without being driven by the above concerns. Tuscany SCA provides suitable data transformation mediations which are attached automatically the wires between components to take account of the difference choices that the component developer and deployer may make.

In the sample here the exchange rate is retrieved (step 1) using the feed binding (binding.rss) as follows.

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

Step 3 uses the web service binding (binding.ws) to retrieve stock from the internet.

    <reference name="StockQuoteReference" promote="AccountService/stockQuote

    <component name="StockValue">
        <tuscany:implementation<binding.xqueryws locationwsdlElement="stock.xqhttp://swanandmokashi.com#wsdl.port(StockQuotes/StockQuotesSoap)" />
    </component>

Assembling and Deploying Tuscany Solutions - Simon

SCA promotes a clear distinction between the construction of business logic and the assembly and deployment of these component implementations into working applications.

Another feature of SCA that enables this separation is the support for policy and policy intents that allow organisation wide statements of intent to be made about the way that an application will behave.

For example, the helloworld-ws-service-secure sample 5 shows how the intention that clients accessing a service must be authorized to do so can be expressed.

reference>

The various XML data are joined together using XQuery (implementation.xquery) in step4. XML is most popular data representation in the SOA world. XQuery is becoming the most applicable language for extracting and transforming XML data. Its SQL-like syntax is relatively easy to learn. 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 the capability of an XQuery can be extended by invoking other SCA components.

    <component name="StockValue"

<component name="HelloWorldServiceComponent">
    <implementation.java class="helloworld.HelloWorldImpl" />
    <service name="HelloWorldService" requires="authentication">
        <interface.wsdl interface="http://helloworld#wsdl.interface(HelloWorld)" />
        <binding.ws uri="http://localhost:8085/HelloWorldService"<tuscany:implementation.xquery location="stock.xq" />
    </service>
 </component>

...

component>

Deploying Tuscany Solutions

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.

...

SCA allows the location of target service to be described explicitly, for example, from the bigbank-account demo 6 5

 <component name="AccountServiceComponent">
     <implementation.java class="bigbank.account.AccountServiceImpl"/>
     <reference name="stockQuoteService">
         <binding.ws uri="http://localhost:8081/services/StockQuoteWebService"/>
     </reference>
 ...

This is very useful for contacting external services but, if very useful for contacting external services or, in the case of services, for exposing SCA service to external applications. If this approach is used for all reference and services , would mean that the SCA application requires within an SCA Domain then reference and service bindings are likely to require changing as services are moved between nodes in a domain.

...

Tuscany SCA will use a default binding to communicate with the target service regardless of whether the service is local or remote to the calling component. In this way the infrastruture can be adjusted and the components redeployed without having to change any .composite file information.

= Move to deployment section =
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.
= end move to deployment section =

file information.

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 WAR file contributed to a suitable web application server
• As a plugin to the Geronimo application server (available as an plugin to Geronimo and not part of the Tuscany SCA V1.0 release)

Getting Started With Your Own Project

...

The easiest way to get started with Tuscany SCA is to download the latest release 3 and try some of the samples.

...

The application model and its component implementation dependencies can now be contributed to the Tuscany SCA runtime.

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

...

Summary

In this paper, we selected few scenarios to demonstrate some of the powerful aspects of SCA programming model and how it applies to the real world. Apache Tuscany currently implements version 1.0 of the specification and extends SCA programming model with its support for many different protocols (bindings), different component implementation types and runtime environments. It can be embedded as a solution or run standalone. Apache Tuscany's modular and extensible architecture makes it possible to further incorporate new ideas. Many businesses are using Apache Tuscany and their feedback is helping to solidify Apache Tuscany as a simple SOA infrastructure as well as making it a nursery for new ideas.

...