Work In progress
Audiance
New user
Its ready to useful things
Target
SOA World on line initially
October 15th
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
Many articles have been written about SOA and Service Component Architecture already12. 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 Incubator project. The project started in 2006 and is being used by many who are looking for a simple SOA infrastructure. Apache Tuscany SCA version 1.0, which was released in September 2007, supports the Service Component Architecture specification 1.0. In addition to implementing the SCA specification, Tuscany is also a nursery for new ideas. Some of these ideas will find their way to the specifications and some will be regarded as extensions available in Apache Tuscany. For example, support for Ruby, JavaScript, Xquery, web 2.0 and distribution are currently extensions beyond the specification.
This article will walk you through what is available in Apache Tuscany, and therefore it highlights the benefits of SCA, using some familiar scenarios. The sample code and configuration used in this article can be found in the Tuscany SCA Java distribution 3 and is available under the Apache License 4.
Using Tuscany SCA
A Common Approach To Application Construction and Deployment
Enterprise software development is increasingly 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 extend or down-size without much cost (mergers and acquisitions). In addition, as the complexity of the enterprise grows, a common management paradigm becomes a necessity for managing business applications. Service Component Architecture provides a simple programming model to address these challenges. SCA's simple language maps easily to the business. Let's consider we are building a banking application that handles account inquiries. The following table maps business level questions to SCA.
Business question |
Banking example |
SCA concept |
What business functions are provided? |
define services or use existing services: stock quote, account balance, etc. |
Components/Services |
What dependencies are there between business functions? |
account balance depends on stock quote service |
References |
How to handle flexibility in business processes? |
ability to configure different currencies |
Properties |
How to handle regulations or quality of service? |
ability to handle account security |
Intent/policy |
What is the end to end solution? |
compose the services into a solution |
Composite/Wire |
SCA provides a consistent model of distributed applications and of the components from which they are constructed. This model explicitly separates business logic (Component/Services/References) from the details of how a running application is assembled (Composite/Wire) and deployed. This promotes a common terminology and supports a common understanding of the capability of applications and the way that applications work together. This common model also provides the hooks for tooling, governance, monitoring and management in the service oriented world.
When it comes to building a solution for real the next most important question is likely to be "how can existing IT infrastructure and skills be used?". Tuscany SCA does not invent new technologies for component implementations (Implementation) and message exchange (Binding). It neither requires you to learn a new programming language or communications protocol. You are free to leverage your existing investment in applications, technology and skills with the one proviso that suitable support 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 three familiar scenarios. It should be noted that Tuscany SCA is not restricted to these scenarios.
Enterprise Applications
In a typical enterprise, business functions are implemented using various technologies, business data are represented in different formats and business applications communicate using heterogeneous protocols. It is almost impossible to converge all applications onto one technology stack such as web services and so it remains difficult and costly to integrate different applications in an enterprise.
- Business applications are tightly-coupled with the IT infrastructure and early design decisions have to be made before real deployment.
- Application developers are forced to learn and understand many technologies beyond the business domain knowledge
- Business logic is polluted and coupled by various technology-specific API calls imposed by the IT infrastructure. It's not easy to write and not easy to change.
SCA separates business services from the concerns related to specific hardware, software and network protocols by providing a unified programming model which allows the SCA runtime to handle these seamlessly. Let's look at a simple business scenario to see how Tuscany SCA can help with enterprise application integration. The scenario here is the BigBank demo from the Tuscany distribution 5. As illustrated below, the application comprises a number of assembled components and ultimately returns a total account balance in response to account inquires. For demonstration purposes, the scenario uses a selection of implementation and binding options.
In the composite, basic units of business logic are modeled as SCA components, AccountComponent, StockQuoteComponent etc. Once all business logic is implemented, appropriate bindings are applied to references and services so that they can collaborate. The XML SCA configuration language, called Service Component Description Language (SCDL), describes loosely coupled enterprise component integration. It allows the developer to;
Expose services using a variety of binding technologies without changing the business logic. This allows business logic developers to build components without regard for the specifics of the particular infrastructure or network protocol to be used when the component is deployed.
<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> ... </component>
Invoke other services using different protocols without changing the business logic. Again this shows the separation between business logic and the network protocols to be used.
<component name="AccountServiceComponent"> ... <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> ... </component>
This very simple mechanism of applying bindings to the services and references defined by a component is at the root of SCA's ability to separate business logic from deployment concerns. It works regardless of whether the component implementation is brand new or wraps some existing business logic. It is also the mechanism by which SCA components communicate with services outside of SCA, i.e. bindings can be defined such that existing applications can access SCA services or so that SCA components can access existing applications. This flexibility allows the SCA approach to be introduced incrementally into an organization.
In the XML, implementation.java indicates that the business logic of the AccountServiceComponent is written in Java. Tuscany SCA provides support for a selection of languages for building business logic, for example, XQuery, BPEL, script. The BigBank demo implements the various operations of the calculator using scripting languages. Tuscany SCA's implementation.script currently supports Javascript, Groovy, Ruby and Python. Those developers comfortable with writing scripts can now provide server side component implementations also.
<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; }
<QUESTION: Where to talk about dependency injection? Raymond>
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.
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++) 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.
... <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.
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.
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) Use 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 a 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.
Databindings (XML, SDO, JAXB, JSON ...)
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
<component name="StockValue"> <tuscany:implementation.xquery location="stock.xq" /> </component>
-
- implementation.data and implementation.das
-
- binding.ws
<reference name="StockQuoteReference" promote="AccountService/stockQuote"> <binding.ws wsdlElement="http://swanandmokashi.com#wsdl.port(StockQuotes/StockQuotesSoap)" /> </reference>
- binding.ws
-
- binding.feed
<component name="ExchangeRate"> <implementation.java class="bigbank.ExchangeRateImpl" /> <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>
- binding.feed
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.
<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"/> </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.
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
SCA allows the location of target service to be described explicitly, for example, from the bigbank-account demo 6
<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 used for all reference and services, would mean that the SCA application requires changing as services are moved between nodes in a domain.
As a convenient alternative any service within the SCA Domain can be identified simply by name.
<component name="AccountServiceComponent"> <implementation.java class="bigbank.account.AccountServiceImpl"/> <reference name="stockQuoteService" target="StockQuoteServiceComponent/StockQuoteService"> <binding.ws/> </reference> ...
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 =
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 Real SOA - Web Services and Service Oriented Architecture, http://www.java.sys-con.com/read/299972.htm
2 What Is SCA, http://www.java.sys-con.com/read/325183.htm
3 Tuscany SCA Java downloads, http://incubator.apache.org/tuscany/sca-java-releases.html
4 Apache License Version 2.0 , http://www.apache.org/licenses/LICENSE-2.0
5 From the Tuscany SCA distribution 3 look for demos/bigbank-account
6 From the Tuscany SCA distribution 3 look for samples/store
7 Getting Started With SCA - Store - http://cwiki.apache.org/confluence/display/TUSCANY/Getting+Started+with+Tuscany+Release+1.0 - TODO - Needs linking into the web page
8 From the Tuscany SCA distribution 3 look for samples/chat-webapp
9 Direct Web Remoting - https://dwr.dev.java.net/
5 sample/helloworld-ws-service-secure
6 demo/bigbank-account
Acknowledgements
A big thank you to the Apache Tuscany Incubator community for working hard to get recent SCA, SDO and DAS releases out.
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