Page History

...

A Common Approach To Application Construction and Deployment - Haleh

The increasingly diverse integration market is 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 extending or down-sizing without much cost (M & A). In addition, as the complexity of the enterprise growgrows, a common management paradigm becomes a necessaity necessasity for managing the business. Service Component Architecture provides a simple programming model to address these challenges. SCA's simple language maps easily to the business model questions. Let's consider we are building a banking application that handles account inquiries. The following table maps business level questions might come up and the table below shows how the questions are answered using SCA as the programing paradigmto SCA.

What are the choices for technology?

The next qustion might be if the existing IT infrastructure and skills can be used? The flexibility of SCA allows any implementation language or protocol to be used. Apache TUscany has a very extendible architecture thatThe 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.

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.

This separation of business logic from the details of how a running application is assembled and deployed leads to a 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.

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.

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

...