Introduction
Many articles have been written about SOA and Service Component Architecture already12. This article focuses on a freely available, open source implementation of the Service Component Architecture that provides a simple way to implement SOA solutions. This SCA implementation is being developed in the Apache Tuscany Incubator project. The project started in 2006 and is being used by many who are looking for a simple SOA infrastructure. The recent 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 into the specifications and some will be regarded as extensions available in Apache Tuscany. For example, support for Ruby, JavaScript, XQuery, Web2.0 and distribution are currently extensions beyond the specification.
This article will walk you through what is available in Apache Tuscany and therefore highlight the benefits of SCA.
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 is flexibility in business processes handled? | ability to configure different currencies | Properties |
How are regulations or quality of service issues handled? | ability to handle account security | Intent/policy |
What is the end to end solution? | independent banking functions working together | 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 those 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. The sample code and configuration used here can be found in the Tuscany SCA Java distribution 3 and is available under the Apache License 4.
Enterprise Applications
In a typical enterprise, business functions are implemented using various technologies, business data is 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. Enterprises face many challenges including the following.
- 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 issues seamlessly. Let's look at a simple business scenario to see how Tuscany SCA can help 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.
The use of the SCA programming model allows the BigBank developer to decouple the process of designing and creating the scenario from infrastructure concerns. In the BigBank composite, basic units of business logic are modelled as SCA components called AccountComponent, StockQuoteComponent etc. Their business logic is implemented using Java and various scripting languages. Components are assembled by wiring references to services. Once all business logic is implemented, appropriate bindings are applied to references and services to indicate how the components should communicate. The relationship between component references and services resolves to runtime proxies when the application is deployed. Where appropriate Tuscany SCA uses dependency injection to introduce proxies into each component's references.
The XML based SCA configuration language, called Service Component Description Language (SCDL), describes all of the information about loosely coupled enterprise services and the bindings to be used. Since binding information can be changed in the SCDL without changing the business logic, the implementation code is not polluted with protocol handling information and furthermore bindings can be changed during deployment without impacting the application.
The following SCDL shows the AccountService exposed using JSONRPC (binding.jsonrpc) and WebServices (binding.ws). The service can easily be made accessible over RMI by simply adding binding.rmi.
Code Block |
---|
<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)" />
</service>
...
</component>
|
The following SCDL shows bindings applied to component references. Again these bindings can be changed or augmented without changing the business logic.
Code Block |
---|
<component name="AccountServiceComponent">
...
<reference name="calculatorService">
<tuscany:binding.rmi host="localhost" port="8099" serviceName="CalculatorRMIService" />
</reference>
<reference name="stockQuoteService |
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
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 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 samples from Tuscany.
Using Tuscany SCA
A Common Approach To Application Construction and Deployment - Haleh
Let's consider business services and leave IT things such as hardware, software and networks on side for the moment. First, we need to identify the business functions and model them as service components. Secondly the relationship between business functions is described. 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 |
Not surprisingly these concepts map directly to terms used in Tuscany SCA.
Business Functions | Components |
What business functions are provided? | Services |
What 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
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 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.
Code Block |
---|
@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.
Code Block |
---|
<component name="AccountServiceComponent"> <implementation<binding.javaws classuri="bigbank.account.AccountServiceImpl"/> <service name="AccountService"> <tuscany:binding.jsonrpc uri="/AccountJSONService"http://localhost:8081/services/StockQuoteWebService" /> </reference> <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
How SCA works with existing technologies. One solution that works with everything.
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.
Code Block |
---|
SCDL showing OrderProcessing talking to Invetory and Shipping over binding.ws
|
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
Code Block |
---|
SCDL showing and extra binding.rmi added
|
Access enterprise services using a variety of binding technologies
Code Block |
---|
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
Code Block |
---|
A simple Java component
|
TODO - bring in binding.ejb
...
</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. Bindings can be defined such that existing applications can access SCA services or can be referenced by SCA services. This flexibility allows the SCA approach to be introduced incrementally into an organization.
SCA simplifies business logic development with dependency injection by providing an Inversion of Control (IoC) container. As you can see from the Java code snippet below, the component simply declares references and properties using java annotations. The account service talks to account data service, stock quote service and calculator service by making direct calls on the interfaces. The code here deals with business logic only and no traditional technology API calls are required. Tuscany handles how the services are located, who provides the services and how messages are delivered based on information in the SCDL.
Code Block |
---|
@Service(AccountService.class)
public class AccountServiceImpl implements AccountService {
@Reference
protected AccountDataService accountDataService;
@Reference
protected StockQuoteService stockQuoteService;
@Reference
protected CalculatorService calculatorService;
@Property
protected String currency;
public double getAccountReport(String customerID) {
|
Code Block |
<component name="AccountDataServiceComponent"> <implementation.java class="bigbank.accountdata.AccountDataServiceImpl" /> <reference name="brokerService"> <binding.ejb uri="corbaname:iiop:1.2@localhost:1050#BrokerServiceBean" /> <//reference> Get the </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. As you might expect Tuscany SCA is ideally placed to provide those services using popular technologies such as JSONRPC, XML, RSS and Atom. From the Tuscany Java SCA store sample (samples/store) you can see a catalog service providing a service over JSONRPC
Code Block |
---|
<component name="Catalog">
<implementation.java class="services.CatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<t:binding.jsonrpc/>
</service>
<reference name="currencyConverter" target="CurrencyConverter"/>
</component>
|
A browser based application can connect direct to such SCA sevices using a Javascript based JSONRPC proxy which Tuscany Java SCA will generate automatically.
Code Block |
---|
catalog = (new JSONRpcClient("../Catalog")).Catalog; checking, savings and stock accounts from the AccountDataservice component CheckingAccount checking = accountDataService.getCheckingAccount(customerID); SavingsAccount savings = accountDataService.getSavingsAccount(customerID); StockAccount stock = accountDataService.getStockAccount(customerID); // Get the stock price in USD double price = stockQuoteService.getQuote(stock.getSymbol()); // Convert to the configured currency if (currency.equals("EURO")) { // Use our fancy calculator service to convert to the target currency catalog.get(catalog_getResponse); |
Clearly any service your Web2.0 style application is required to communicate with can be built and contacted in the same way. This means that the services supporting your Web2.0 style applications are providedin the same consistent way that ervices are provided for other reasons in you enterprise. Hence Web2.0 service become part of the wider enterprise service orientation story.
Tuscany SCA supports other modes of operation also, for example, the Tuscany Java SCA Chat sample (samples/chat) uses binding.dwr to provide a Direct Web Remoting (https://dwr.dev.java.net/) connection between the Javascript browser application and an SCA service. Using this binding, service to browser communication is supported alongside browser to service communication.
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.
price = calculatorService.multiply(price, 0.70);
System.out.println("Converted to " + currency + ": " + price);
}
...
}
}
|
SCA also provides a mechanism to separate organizational infrastructure concerns from business logic through policy statements which enable agreed to constraints to be applied at deployment time. This could range from dictating which communications should be encrypted to describing what level of monitoring and logging is required. For example, the helloworld-ws-service-secure sample 6 shows how to express the intention that clients accessing a service must be authenticated before doing so.
Code Block |
---|
<component name="HelloWorldServiceComponent">
<implementation.java class="helloworld.HelloWorldImpl" />
<service name="HelloWorldService" requires="authentication |
Code Block |
<component name="AddServiceComponent"> <tuscany:implementation<interface.scriptwsdl scriptinterface="calculatorhttp://AddServiceImpl.js"helloworld#wsdl.interface(HelloWorld)" /> </component> |
Here is and example of a component implemented using Javascript.
Code Block |
---|
function add(n1, n2) { <binding.ws 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
- 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
uri="http://localhost:8085/HelloWorldService"/>
</service>
</component>
|
Note that the <service> element carries a policy intent that interactions require "authentication". How authentication is actually implemented is then a matter of policy within the organization.
We have demonstrated how the flexibility of the SCA programming model helps address enterprise challenges. Another area to point out is the ability to use any implementation language and therefore leverage existing skills and investments. Tuscany SCA provides support for a selection of languages for building business logic, for example, XQuery, BPEL, script, Spring and OSGi. 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. In the SCDL example below, implementation.script indicates that the business logic of the AccountServiceComponent is written in Javascript.
Code Block |
---|
<component name="AddServiceComponent">
<tuscany:implementation.script script="calculator/AddServiceImpl.js"/>
</component>
|
The combination of implementation types available, in particular Spring and OSGi, offers powerful capabilities for building service implementations from sets of simple Java Beans using very few APIs, with managed dependencies, version control and dynamic update capabilities. Such implementations can easily be composed with other service components written in Java or in other languages and all components are deployed consistently in a distributed network of Tuscany SCA runtimes with the full range of communication methods made available to them.
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" 7. There is a guide which walks through the steps required to build this sample 8.
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 Catalog component's Java implementation is associated with the JSONRPC binding (binding.jsonrpc).
Code Block |
---|
<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:
Code Block |
---|
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 SCDL description of the service.
Code Block |
---|
...
<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 9 uses binding.dwr to implement a Direct Web Remoting 10 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
In a typical enterprise, business data comes from many different sources and is presented in many different formats. Tuscany SCA provides a databinding framework which seamlessly handles data format mapping and therefore freeing the developers from such concerns.
Let's look at a simple scenario that deals with aggregation of XML data from different sources. This demo will be available in a future release of Tuscany. The business function here calculates the total value of all the accounts (checking, saving and stock) that a customer owns.
In this scenario, data is received from various data sources and manipulated as XML. The following data exchanges are occuring.
1) Use an RSS feed to retrieve the currency exchange rates from the web
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.
Handling of different data formats in the enterprise can be complex. For example, business data may be represented in many different ways, even if they are for the same infoset. A Customer business object can be defined as JavaBean, SDO, JAXB, XMLBeans or DOM. At the same time, protocol implementation stacks require different data representations. For example, in the Web Service domain, Axis1 uses DOM, Axis2 uses AXIOM ad JAX-WS uses JAXB. Implementation technologies may also impose requirements on the data as well; for example Apache ODE BPEL engine consumes/produces data using DOM, SAXON XQuery engine consumes/produces data using NodeInfo and script Implementation uses AXIOM.
Application developers should have the freedom to choose their preferred data representation without being restricted by the above concerns and worrying about the mappings. Tuscany SCA automatically handles this for them. Tuscany provides the most poplular databindings including SDO, JAXB, XMLBeans, AXIOM, JSON, DOM, SAX and StAX. There are more than 50 transformers to convert data between the databindings. With the transformer graph, we support not only point-to-point transformations but also multiple-hop transformations. This approach greatly reduces the number of transformers required and makes it possible to transform data without direct transformation logic. It's very common that some databindings will be required as the intermediaries, for example, the XML String, DOM Node and StAX XMLStreamReader are very populate in the XML world.
In the sample here the exchange rate is retrieved (step 1) using the feed binding (binding.rss) as follows.
Code Block |
---|
<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>
|
Step 3 uses the web service binding (binding.ws) to retrieve stock from the internet.
Code Block |
---|
<reference name="StockQuoteReference" promote="AccountService/stockQuote">
<binding.ws wsdlElement="http://swanandmokashi.com#wsdl.port(StockQuotes/StockQuotesSoap)" />
</reference>
|
The java interface is interesting. The example uses StAX to streamline XML data exchange over web services. Thanks to the databinding framework, the component developer can choose their preferred XML java databinding technology such as JAXB, SDO, DOM or StAX no matter how the SOAP message is represented in the web services stack (AXIOM is used by Axis2).
Code Block |
---|
@Remotable
public interface StockQuote {
public XMLStreamReader GetStockQuotes(XMLStreamReader input);
}
|
The various XML data are joined together using XQuery (implementation.xquery) in step4. XML is most popular data representation in the SOA world. The XQuery implementation type brings the power of XQuery and SCA together. With the help of the databinding framework, we can use XQuery to mediate data from many services and the capability of an XQuery can be extended by invoking other SCA components.
Code Block |
---|
@Remotable
public interface StockValue {
double calculate(XMLStreamReader quotes, XMLStreamReader accounts);
}
|
Code Block |
---|
<component name="StockValue">
<tuscany:implementation.xquery location="stock.xq" />
</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.
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 services to be described explicitly, for example, from the bigbank-account demo 5
Code Block |
---|
<component name="AccountServiceComponent">
<implementation.java class="bigbank.account.AccountServiceImpl"/>
<reference name="stockQuoteService |
Code Block |
<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 <binding.javaws class="bigbank.AccountDataImpl" uri="http://localhost:8081/services/StockQuoteWebService"/> </component>reference> <component name="StockValue"> <tuscany:implementation.xquery location="stock.xq" /> <!-- <property name="currency">USD</property> ... |
This is very useful for contacting external services or, in the case of services, for exposing SCA service to external applications. As this approach requires that explicit endpoint information is provided reference and service bindings are likely to require 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.
Code Block |
---|
<component name="AccountServiceComponent"> --<implementation.java class="bigbank.account.AccountServiceImpl"/> </component> <reference name="StockQuoteReferencestockQuoteService" promotetarget="CustomerAssetStockQuoteServiceComponent/stockQuoteStockQuoteService"> <binding.ws wsdlElement="http://swanandmokashi.com#wsdl.port(StockQuotes/StockQuotesSoap)" /> </reference> </composite>reference> |
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,
Code Block |
---|
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.
Code Block |
---|
target based reference
|
...
|
Tuscany SCA will automatically 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 infrastructure can be adjusted and the components redeployed without having changing the SCDL.
Choosing how to run the Tuscany SCA runtime depends on your local environment but there are several options currently supported. The Tuscany SCA runtime can be embedded or run with any available web application server. The Tuscany V1.0 release has been tried with Tomcat, Apache Geronimo and IBM® WebSphere® application servers. There is work ongoing in the Apache Geronimo project to provide deeper integration between the Tuscany SCA runtime and the Geronimo Management Console.
It is also straightforward to use the Tuscany SCA runtime directly in your applications. It is simply a matter of starting the runtime and providing SCDL and associated component implementations collected together in what SCA calls a contribution (a jar file or directory)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
...
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
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
Code Block |
---|
// 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
release 3 and try some of the samples.
The Java SCA web page 11 provides user documentation and extension guides. The User Document provides a simple walkthrough of the Tuscany Java SCA Calculator sample. There is also a paper giving detailed instructions of how to build the simple Web2.0 application described in this paper8.
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. You can of course take a suitable sample and use that as a starting point.
Returning to the business questions we discussed earlier in the paper your application development process will involve some of the following steps. The order of the steps can vary since Tuscany SCA allows a top-down or bottom-up development approach.
Model the application in SCDL
- Identify what business functions are required and describe them using SCA components and services
- Identify what dependencies each component has and provide each component with suitable SCA references.
- Introduce SCA Properties for any values that will have to change as the application is reconfigured or redeployed.
- Compose the services within an SCA composite structure and connect references to services using wires
Provide business logic
- Implement each component and reference the implementation from the component in the SCDL. The implementation may simply wrap existing application logic or maybe completely new.
Provide deployment specific information
- Describe any specific protocols that need to be used using bindings. References and services without bindings will automatically adopt a default communication strategy
- Attach organizational policy intents to the model, for example, security intents such as authorization or confidentiality
The application model and its component implementation dependencies can now be deployed to the Tuscany SCA runtime.
Summary
In this paper, we selected a 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 the 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 easily 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. You are welcome to come and try the software and contribute to the project.
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 sample/helloworld-ws-service-secure
7 From the Tuscany SCA distribution 3 look for samples/store
8 Getting Started With SCA - Store - http://incubator.apache.org/tuscany/sca-java-10-incubating-release-summary.data/getting-started-1.0.pdf
9 From the Tuscany SCA distribution 3 look for samples/chat-webapp
10 Direct Web Remoting - https://dwr.dev.java.net/
11 From the SCA distribution3 look for Documentation
Acknowledgements
A big thank you to the Apache Tuscany Incubator community.
IBM and WebSphere are trademarks of International Business Machines Corporation in the United States, other countries, or both.
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.
...