A new book by Simon Laws, Mark Combellack, Raymond Feng, Haleh Mahbod and Simon Nash Tuscany SCA in Action provides a simple step-by-step guide on how to develop applications leveraging SCA and Apache Tuscany.
This practical book is comprehensive, hands-on guide to Service Component Architecture, Apache Tuscany’s specific SCA implementation (based on Java SCA v1.x) and the ways to use Tuscany to build applications. The books starts by explaining main concepts of SCA including components, services, references and composite applications and the way they are used for implementing SOA-based solutions. It then introduces a travel booking example, used throughout the book to explain details of SCA/Tuscany-based implementations. The book covers a wide variety of topics from implementing and binding SCA components, including data representation and transformation and invocation policies to deploying Tuscany-based applications to Tuscany runtime architecture, including ways to extending and embedding Tuscany’s runtime
Manning Publications provided InfoQ readers with an excerpt Introduction to SCA bindings from Chapter 7 of the book.
InfoQ readers - use ' tuscinfoq40' code to get 40% discunt off the book when purchasing at Manning.com
InfoQ spoke with the book authors to learn the motivations behind the book and their experience with SCA in general and Tuscany specific usage.
InfoQ: In the beginning of the book you are positioning both SCA and SOA in general as a better approach to the application’s development. If this is the case, then what is the real difference between component-based development and SOA? Is it just a set of technologies used?
People’s definitions of components and services vary. In the context of software development people often look to components to provide a separation of concerns. Component builders define an interface and create business logic behind that interface. In this way users of a component can make calls to the component without worrying about how it actually does its thing. Multiple components are combined together to create a working application. This is analogous to the electrical component you might use to build a hardware circuit. As long as you put the right voltages on the right pins at the right time the component does its thing. You don’t really have to worry about how it works.
So what of services? Services are often described as more coarse grained applications that provide functions to other applications with an emphasis on remote hosting. SOA promotes the construction of applications by wiring multiple services together. SOA, as a set of design principles, doesn’t prescribe how you actually implement services or indeed how you could formally describe the relationships between services that are wired together.
Service Component Architecture (SCA) is a standards based way of doing both of these things. A programming model for SOA if you like. From its name you may have guessed that SCA combines the concepts of both components and services.
In SCA, a component’s business logic is provided by its implementation. A SCA component also provides one or more services which define how other components can access this business logic. This separation of concerns allows components to be wired and re-wired together without affecting a component’s implementation.
SCA provides an assembly model that allows you to describe how components are wired together, via the services they provide, into what it calls composite applications. SCA places no restrictions on the size or scope of a composite application. So, for example, you could use SCA to build a simple application out of a small number of SCA components with Java implementations that runs in a single JVM. More importantly you can use the same SCA assembly model to describe an application comprising many components implemented using a variety of technologies running across a number of hardware nodes and communicating using a variety of communication protocols.
InfoQ: A set of terms used by SCA was always confusing to me. According to SCA “A component is a configured instance of some business logic. It provides services and can use services.” Everywhere else a service is some business logic, while components are used to build services. Do you think we will ever agree on definitions for both components and services?
Yes, there may very well be a difference between the way that SCA defines the term Component and the way that other component and service models use it. For example, some people believe that services are built from multiple components and others that a single component provides multiple services. Fortunately the SCA specifications are specific in their definition of these terms.
A component has an implementation (the business logic) and provides services (the interfaces, protocols and policies that are used to interact with the business logic). A component can of course use the services provided by other components and this is how components are wired together, or assembled, into working applications.
The “configured instance” part from the definition you quoted sounds like the most complicated part but all it means is that components can have properties that allow you to control the implementation, for example, to change things like which other components the component is wired to.
This seems to fit very firmly into the “single component provides multiple services” category. However SCA can easily satisfy those who believe services are built out of multiple components. Just consider an application built of SCA components as a service in its own right, in this case a coarse grained service is made up of individual components that are assembled together. The SCA assembly model makes it very easy to build coarse grained components out of finer grained components.
InfoQ: SCA model is surprisingly similar to a CORBA component architecture, which was introduced by OMG in the late 90s and was never used in any real implementation due to its complexity. What do you think will change the situation for SCA? Replacing CORBA with new technologies? SCA assembly model? Better support from vendors?
The CORBA component architecture required all components in an application to use the same interface definition language (OMG IDL) and the same communication protocol (IIOP). SCA is much more flexible because it embraces different interface definition languages and communication protocols. This makes it much easier for SCA components to be used together with existing components that weren't designed specifically with SCA in mind. This flexibility and interoperability means that non-SCA components can be migrated to SCA gradually over time rather than requiring a "big bang" approach where everything would need to be converted to use SCA before it could be used together.
InfoQ: With the growing popularity of REST, are there any plans to support REST binding in both SCA and Tuscany?
Yes. In the 1.x version of the Tuscany Java SCA runtime, on which the book is based, the Tuscany community has added support for various REST related technologies. Tuscany has bindings for HTTP, ATOM and RSS and a simple programming model for building services that respond to requests to manipulate resources. There are plans to do more in future versions of Tuscany and of course the Tuscany community welcomes input from anyone interested in getting involved.
InfoQ: You give a very good explanation on how Tuscany can coexist with ah ESB. One question still remains. An important element of ESB is service registry. Can Tuscany assembly leverage service registry to locate the service?
SCA has its own concept of service registry which it calls the Domain. This is effectively the pool of all component services that are available to be wired together in order to create a composite application. If you want to use the same service registry that an ESB might be using there are two approaches. The most straightforward is to configure an SCA component reference to connect to an existing ESB and let that do the look up for you. Closer integration could be achieved by writing a new binding for Tuscany which integrates more directly with an ESB and its service registry. We don't have such a binding at the moment but if someone were interested in coming to the community to construct one they would be more than welcome.
InfoQ: A definition in the book “The SCA approach to components is very different from other component technologies such as EJB, Microsoft® .NET, and Spring. In SCA, any container-specific dependencies are encapsulated in the implementation type (for example, EJB or Spring) instead of being part of the component definition.” seems to create even more confusion between components and services. Would you agree that SCA components are effectively service implementations as defined in other SOA publications?
Yes, an SCA component implementation provides the business logic for one or more services. SCA additionally allows an assembly of components to be used to provide the implementation of a component. In this way coarse grained component services can be constructed by composing finer grained component services together.
The container dependencies of each component are implied by the implementation type that a component uses. For example, a component implemented using implementation.bpel will rely on the implementation.bpel infrastructure to run the component's BPEL based business logic inside a BPEL container.
InfoQ: Introduction of local and remote interfaces in SCA make it closer to the EJB (component) realm than to a service one – one of the SOA tenets – “Service boundaries are explicit”. This again brings up the question of whether SCA is an SOA or component-based framework.
There's a purity versus pragmatism trade-off here. In the early days of EJBs everything was remote (a pure SOA model), and local interfaces were added later because people found that they were needed for practical reasons. In SCA the architectural model was designed to include both remotable interfaces (for pure SOA modeling) and local interfaces (for pragmatic situations such as accommodating legacy code).
InfoQ: Although Bidirectional and Conversational interactions are very important for BPEL-based implementations directly supporting threading and “session” (process instance), their usage in Java-based or C++ -based components is not very intuitive. I understand that SCA 1.1 removes conversations from the spec, but don’t you think it should be limited to a certain types of components implementations?
In effect it is at the moment because only implementation.java supports conversations in the Tuscany runtime. The SCA specifications do support bidirectional interactions, otherwise known as callbacks, and conversations in other implementation types, such as implementation.bpel, but the Tuscany community hasn't got around to implementing them yet. Conversations have been removed from the most recent versions of the SCA specifications that are being developed at OASIS, as you say. We don't expect more work to be done on conversations in the runtime. We would though expect callback support to be added to other implementation types in future versions of the runtime.
InfoQ: Component references in SCA are effectively a “dependency injection” implementation, which is a foundation of extremely successful Java frameworks like Spring and Juice. Can you elaborate on how this approach is really important for service-based implementation? Can you compare it with the binding based on the centralized service registry?
SCA does support injection of component references. This is really important in that it emphasizes the separation of concerns. The writer of the business logic (the component implementation) that uses the injected reference doesn't worry about how the reference is wired to a target service. When the component is wired and re-wired to other components none of the business logic is affected. It is simply written to use the injected reference. The infrastructure worries about how to create that reference.
As an alternative to injection you can call an SCA API to retrieve component references. The separation of concerns still holds true in that you, as a business logic developer, are not aware of how the reference is wired to a target component service.
Whichever approach is used to obtain a component reference, either via injection or via the SCA API, the runtime is responsible for ensuring that the reference points to the required target component service. When using the default SCA binding the Tuscany runtime can use a centralized representation of the SCA Domain (similar to a registry) to achieve this wiring. However this wiring doesn't necessarily require a centralized registry and you can configure applications in Tuscany so that each component reference has all the information it needs to contact the target services without looking the service up in a centralized registry.
InfoQ: Although component properties in SCA seem like a viable solution, they again move SCA more towards components framework then the service one. Properties configurations means that SCA component is reused as a code (separate deployment) and not as a service (centralized deployment).
We wouldn't necessarily relate the properties feature of SCA with the mechanism by which services are deployed. An SCA composite application is described in XML as a collection of wired components. In this description the component implementation is identified and any required property configuration is provided. Two different components in the composite application which share an implementation may be configured with different property values.
The previous discussion of components and services is important here. People often use the term component to describe software components that are combined to form a working application that runs in a single process and can be deployed one or more times. Often the term service is used to describe an application which provides services for others to use. SCA and Tuscany provide a programming model for doing both of these things. An SCA assembly can be used to compose components and build an application running in a single process. More importantly though the composition of coarse grained services running on separate nodes in the network can also be described using an SCA assembly.
InfoQ: Chapter 3 of the book provides a very good description of composite application detailing SCA domains and domain manager. The issue is that with a java example one has to wonder how Tuscany is better compared to an application server. It does not seem to bring much while loosing transactional support, JNDI-based load balancing, declarative security (replaced with policy frameworks), etc. Why would I move from application server based implementation to Tuscany?
The benefit of using SCA is that SCA components and services can be used in application servers and also in many other hosting environments including clients and standalone unmanaged applications. When using SCA in an application server, all the capabilities provided by the application server are available to SCA Java implementations. The other side of this picture is making all SCA capabilities (such as transaction policies) available in the application server. This requires application servers to provide native support for SCA, and this should happen in the fairly near future. We've done some investigations and prototyping for how to provide this level of integration using Tuscany but the work isn't far enough along yet
to release this as a supported capability.
SCA provides a consistent service-based architecture and programming model across a variety of deployment and hosting environments which makes it easier for architects and designers to focus on the "what" (the business services) rather than the "how" (the deployment topology for these services). If the business services have been designed using SCA then it's easy to either
deploy them in an application server or host them elsewhere as needed.
InfoQ: In chapter 4 of the book you are writing “Remote interaction pattern is vital to assembling coarse-grained, loosely-coupled and distributed components”. Do you believe that remote invocation automatically means loose coupling?
No, but flipping this round, if you don’t design loosely coupled services then remote invocations are likely to be over complex.
InfoQ: When describing local binding, you are first stating that “This may be useful for fine-grained composition”, and then continue by saying “The default binding, binding.sca, works with both local and remote services… This brings a lot of flexibility to your application. In this way components can be deployed in different configurations within the SCA Domain without having to change the binding configuration within the composite.” If we are talking about fine grained components, under which circumstances would you suggest invoking them using remote interfaces?
Local and remote service interfaces exhibit different semantics in that local interfaces are pass by reference while remote interfaces (Java interfaces marked with @Remotable) are pass by value. SCA's default binding, binding.sca, will work with both local and remote service interfaces.
A service with a local interface will only ever be able to communicate with other component services running within a single JVM. On the other hand services with remote interfaces can communicate with other component services either in the same JVM or in different JVMs. SCA's binding.sca makes this difference transparent.
Hence, for components with remote service interfaces, you can compose and deploy an application in a single JVM and then, at some future time, deploy the same application across multiple JVMs while binding.sca handles all the complexities of making this transition.
InfoQ: When using @service annotation in the Java SCA implementation, an interface is defined as a java class. Does this mean a very tight coupling?
No, it just means that the Java class or Java interfaces can be used to define the component’s service interfaces. For SOA it's important to make sure that the Java interfaces used are suitable, i.e. that they don't imply tight coupling.
InfoQ: In chapter 5 you have a great description of advanced callback and conversation implementations in Java. The implementation seems to provide a lot of flexibility and greatly simplified programming model hiding a lot of complexities. Is, in your opinion, Java components are the best place for implementing such constructs, or they should be factored out in a BPEL-based component, which seems to be better suited for these purposes.
A good point. The answer is probably yes that an implementation type such as implementation.bpel is more suited to complex and potentially long running interaction patterns. However currently implementation.java is the most complete specification in terms of support for the various features of the programming model and hence that gets most coverage in the book.
InfoQ: In the example in section 7.3 reference to the "emailGateway" component defines two potential bindings. How does SCA resolve the actual binding in this case?
It depends what bindings the target component service supports. A reference with multiple bindings is saying that it can be wired to a service that uses either, or both, of these bindings. In the case that the service is also configured with multiple bindings the first matching binding is chosen.
InfoQ: In section 7.4 you write “More recently the term has come to be used to specifically describe services provided over a network using the SOAP over HTTP protocol.” Would you agree that this is not quite correct .and Web services describe services provided over a network using the SOAP over any transport?
To a certain extent this is true but, based on the users in the Tuscany community, by far the most widespread deployment of web services is with SOAP over HTTP.
InfoQ: Unlike other binding types, JMS binding requires centralized JNDI. Why use registry for JMS binding, but not have it as an option on the other types?
Some technologies, like JMS, rely on underlying mechanisms to map one end of a communication with another. Others, like Web services, don't. This is the advantage of SCA in that it can encapsulate many different technologies which take many different approaches within a single simple programming model.
InfoQ: You discuss exposing a SCA service as an EJB in future Tuscany releases. What is the utility of such capability?
It would primarily be a point of integration with an EJB container. In this way an EJB can be used as an implementation for an SCA component. The draft SCA JEE specification describes how this is done in SCA. The Apache Geronimo project has prototyped a Tuscany plugin that allows JEE EAR, WAR and JAR artifacts to be used with SCA. In this way JEE artifacts such as EJBs, Servlets or even entire JEE applications can take part in an SCA assembly.
InfoQ: The “implementation.widget” description is very confusing. HTML pages have nothing/very little to do with components/services. What is the motivation behind introduction of this implementation type.
The motivation for implementation.widget is to present Javascript running on a browser as a component in an SCA composite application. In this way the Javascript based component can be wired to other components using the same SCA defined techniques that any other type of SCA component uses.
InfoQ: Section 9.4 presents a very good explanation of data format conversion during SCA component interaction. It seems like as data payload grows, these transformations will create significant impact on both memory requirements and execution performance. What, if any can be done to minimize this impact?
This hasn't been an issue for Tuscany users so far. The databinding framework has mechanisms to optimize the transformation path so that the minimum number of transformations is performed. If bespoke transformation mechanisms are required then the databinding framework is pluggable and hence easily extensible.
InfoQ: Is there any reason why in the policy security example you are using HTTP security implementation rather the WS-Security? Is there a way to use WS-Security withut writing custom implementor?
The configuration is more straightforward. We do support WS-Security in Tuscany 1.x.
InfoQ: Does Tuscany deployment support load balancing and/or failover of the components deployed in a given domain? Is there any way to control load balancing beyond round robin?
Not out of the box at the moment. In the Tuscany community we have experimented a little with this where the Tuscany runtime is run in a cluster of Tomcat services with Apache HTTPD load balancing across them.
InfoQ: In chapter 12 you are writing “We’ve found that the bottom up approach works well when prototyping a single component.” Are you suggesting that service development should be done bottom up? Doesn’t this go against service design best practices, which recommends designing service interface before service implementation?
In reality a bit of both occurs. What we’re pointing out is that when designing and refining a service interface Tuscany is a powerful tool for building a prototype. You can start bottom up for prototyping and switch to top down before completing the final version.
InfoQ: When discussing recursive composition in chapter 12 you are recommending recursive composition, but do not provide any recommendations on minimal sizes of composable SCA components. Is it Java class? Several Java classes?
SCA allows either and which is best depends on the application. At the lowest level it could be a single class but as you go up the levels of recursion then it will get larger and encompass several classes.
InfoQ: The book does not talk at all about usage of the Eclipse SCA plugin for Tuscany-based development. Would you recommend its usage?
The Eclipse plugin in the 1.x version of the Tuscany runtime adds a couple of simple features to Eclipse which can help with the development of SCA applications. There is code completion for the manual editing of SCA composite files based on the XSD that ships with the Tuscany runtime. There is also the ability to right click on a composite file and run it. Having said that the development of the Eclipse plugin didn't keep pace with the development of the domain support in the runtime and so it wasn't used during the writing of the book. It is useful from the code completion point of view but the "run as" support is a bit unpredictable at the time or writing. Another area for improvement if people are interested in getting involved in the Apache Tuscany project.
There are other tools that can help when building SCA applications. For example the Eclipse STP project provides an SCA editor and several vendors have commercial SCA based tools on offer.