Appendix B. What’s next?
You may not be surprised to hear that the Tuscany community has already started implementing the next version of the Tuscany software, building on the 1.x code base, user feedback, and experience gained. We’d like to share the highlights of the future direction of Tuscany 2.x with you, especially if you’re interested in participating in the development of this next Tuscany version.
If you have Tuscany 1.x applications that you want to run using the evolving Tuscany 2.x runtime, you need to make a few changes and you need to be aware of a few differences in the runtime. You can see instructions about what to do on the Tuscany website at http://tuscany.apache.org/documentation-2x/converting-tuscany-1x-applications.html.
Tuscany has been a major contributor to the development of the SCA specifications that are now being standardized at OASIS. Therefore, one focus is to move to the standardized version of the SCA specifications. Future releases of Tuscany will continue adding support for new technologies and will integrate with OSGi for improved modularity. It’s also becoming clear that Tuscany and SCA offer a service model that’s well aligned with the emerging idea of cloud computing. That’s another area where we’ll see further development and innovation. Let’s take a closer look at some of these ideas.
B.1. Support for OASIS Open CSA SCA standards
As part of the standardization process of SCA, OASIS Open CSA is taking the current OSOA SCA version 1.0 specifications as a basis for creating the SCA version 1.1 standards. This work is being done by several OASIS technical committees that are refining and clarifying the SCA 1.0 specifications. Some of the authors of this book are actively involved in the development of SCA standards.
Most of the SCA 1.0 concepts and structures will be retained in the SCA 1.1 standard—implementations, components, composites, services, references, properties, and so on. But applications will need a degree of modification to be converted from SCA 1.0 to SCA 1.1 because some of the XML schemas and the SCA API Java package names have changed.
The SCA 1.1 standards also include a compliance test suite to ensure that SCA runtimes comply with the standards. Work is currently under way in the Apache Tuscany project to demonstrate compliance with the new SCA 1.1 compliance test suites.
See http://www.oasis-opencsa.org/committees for more information on the OASIS Open CSA SCA 1.1 standards.
B.2. OSGi enablement for the Tuscany runtime
The Tuscany runtime is architected to be modular and extensible. In 1.x, Tuscany uses Maven to achieve this. Maven helps to manage and validate the dependencies between Tuscany modules at build time. Maven’s control stays at the JAR level, and it doesn’t impose any runtime constraints, so it’s difficult to handle versioning of dependencies. This can leave the door open to unnecessary dependencies being introduced, sometimes unknowingly.
Tuscany 2.x adopts OSGi, which helps to formally define Tuscany runtime modules and enforce SPI package dependencies across modules. OSGi also helps Tuscany handle versioning across dependencies. This is a complicated problem because Tuscany integrates with many technologies that can each have dependencies on different versions of the same type of software. Therefore, proper handling of dependency versioning helps ensure predictable behavior.
OSGi also adds dynamicity to the Tuscany runtime so that extensions can be added, updated, or removed without restarting the JVM.
It’s worth pointing out that Tuscany continues to work in both OSGi and non-OSGi environments. We don’t introduce any hard dependencies on OSGi APIs for the nonOSGi-specific modules.
B.3. Enhanced SCA domain and node support
The Tuscany community continues to enhance Tuscany to ease the development of distributed composite applications. For this reason, there’ll be enhancements to the various domain features.
The idea is to allow multiple nodes to be started and automatically form a domain without the need for a separate domain manager. This doesn’t mean that the idea of a domain manager won’t be supported, but we’re trying to make the runtime easier to use in the case where you just want to start a few nodes and have them cooperate without further configuration.
For example, imagine you have one node running in a web application, another node running from the command line, and yet another node running as part of some other software container such as an application server. All of these nodes will be able to exchange metadata about the services they’re providing within the domain, and so cross-node domain wires can be created without the need for a central manager.
B.4. Implementation of OSGi remote services with SCA
Outside the world of SCA, OSGi is being enhanced to provide an Enterprise Java programming model. The basic OSGi framework decouples service providers and consumers via a local service registry, where a service is an object that one bundle registers and another bundle retrieves. With the introduction of remote services in OSGi release 4.2, OSGi services running on different framework instances can now talk to each other.
With its declarative binding and policy capabilities, SCA fits very well with OSGi remote services. The new version of Tuscany introduces implementation.osgi, which can encapsulate one or more OSGi bundles.
The overall architecture is shown figure B.1. The references of an SCA OSGi component represent the OSGi services to be consumed by the bundles. The services of an SCA OSGi component represent the OSGi services provided by the bundles.
Figure B.1. An SCA domain can be used to provide the inter-bundle wiring of a distributed OSGi application.
Following this approach, implementation.osgi can provide the metadata and infrastructure to enable the distribution of OSGi services, and Tuscany enables OSGi bundles to participate in the SCA assembly.
Tuscany also supports the OSGi-centric view. It implements the OSGi Remote Service Admin and SCA Configuration Type specifications (to be published as part of the OSGi R4.2 Enterprise release). With these capabilities, OSGi Enterprise applications can start to leverage the declarative protocols and polices from Tuscany SCA. Tuscany is the reference implementation chosen by the OSGi alliance for the SCA Configuration Type specs.
B.5. Running Tuscany in the cloud
Cloud computing is an internet-based development model where users rely on the cloud platform, or cloud software provider, to run their business applications. Cloud computing typically means the provisioning of dynamically scalable and often virtualized resources as a service over the internet. Tuscany and SCA’s loosely coupled service architecture makes it a good programming model for developing applications in the cloud.
SCA separates all the infrastructure concerns from business logic and makes infrastructure choices declarative. Such declarations make it possible to replace standard infrastructure with cloud infrastructure without changing the business logic.
The cloud is a naturally distributed environment. SCA describes how services can be composed or assembled to create composite applications. Such assembly describes the various natural groups of functions in the application. The cloud infrastructure can take advantage of this information and provision separate groups of functions to different parts of the cloud.
Pulling this together, we can use SCA to remove infrastructure concerns from the application itself. The SCA assembly model can hide the details of the particular cloud infrastructure that’s chosen. SCA also provides the opportunity to unify any infrastructure services as reusable SCA components. In this way the differences between different cloud providers can potentially be hidden.
Figure B.2 illustrates some ideas about how the Tuscany domain manager can be enhanced to support provisioning of an SCA domain in the cloud.
Figure B.2. An SCA domain is provisioned to the cloud with multiple Tuscany runtimes that host nodes to run a group of components.
The SCA domain can be partitioned into one more nodes that together run a group of components. The infrastructure requirements can be calculated from the composite, and a customized Tuscany runtime can be composed based on the technology extensions needed. The nodes can be provisioned to the cloud based on the infrastructure requirements calculated from the composites.
We’re making good progress in all these areas in the Tuscany 2.x code base. At the time of writing, four milestone releases have been made available. You can find the latest code at http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/. Please come and join us to further improve and advance the project: using the code, reporting issues, sharing your requirements, bringing in ideas, fixing bugs, implementing features, or improving documents. You can help, contribute, and be part of the next version of Tuscany SCA.