List of Figures

Chapter 1. Introducing Tuscany and SCA

Figure 1.1. A web shopping application built from cooperating services showing the typical variety of technologies use to implement and connect services

Figure 1.2. The Payment and CreditCardPayment components from the web shopping application presented as SCA components in order to show the main artifacts of the SCA Assembly Model

Figure 1.3. The main building blocks of the Tuscany SCA Java runtime

Figure 1.4. An overview of the initial travel-booking application showing those components that will be implemented using SCA as solid boxes and those components that are outside SCA as dashed boxes

Figure 1.5. The components, services, and references of the travel-booking application

Figure 1.6. The configuration of the first GoodValueTrips TripProvider component we’ll build

Figure 1.7. The TripBooking and ShoppingCart components shown wired together inside the Tours composite

Figure 1.8. A test client component being used to test the TripBooking and ShoppingCart components we’ve built

Chapter 2. Using SCA components

Figure 2.1. An SCA component implemented using a Java class and another SCA component implemented using a BPEL process

Figure 2.2. SCA component definitions aren’t tied to any specific container technology, unlike components defined by other technologies such as EJB and Spring.

Figure 2.3. An SCA component implementation that’s been configured using two different component definitions to produce two SCA components. The numbered arrows represent different kinds of relationships between the objects shown in the figure.

Figure 2.4. TripBooking is an SCA component with one service named Bookings.

Figure 2.5. TripBooking is an SCA component with one service and three references.

Figure 2.6. The SCA references in the TripBooking component have wires connecting them to SCA services in other SCA components: CarPartner, FlightPartner, and HotelPartner.

Figure 2.7. The CarPartner component has a reference cars with multiplicity 1..n and another reference luxuryCars with multiplicity 0..n.

Figure 2.8. The cars reference of CarPartner is wired to two car vendor components: JoesCars and KensCars. The other reference, luxuryCars, is left unwired.

Figure 2.9. A currency converter component with two properties, fromCurrency and toCurrency

Figure 2.10. The Bookings service is configured with Web Services and JMS bindings, the cars reference is configured with a Web Services binding, and the flights reference is configured with an EJB binding.

Figure 2.11. Two SCA domains containing components, showing how the components are connected. Wires (shown as solid lines) are used for connections inside each domain, and bindings (shown as broken lines with arrows) are used for connections that cross a domain boundary.

Chapter 3. SCA composite applications

Figure 3.1. The sample composite application consists of three composites and four components, with wires connecting the component references to services in other components.

Figure 3.2. Exporting an XML namespace from the payment-bpel-process contribution and importing the same namespace into the payment-bpel contribution

Figure 3.3. A local domain with a single execution node and a distributed domain with a domain manager and multiple execution nodes. The contents of the domain are the same in both cases.

Figure 3.4. Running the deployed composites Tours and Trips on two computers with hostnames tuscanyscatours.com and goodvaluetrips.com

Figure 3.5. The sample application running in a distributed configuration, with three execution nodes coordinated by a separate domain manager

Figure 3.6. Adding a contribution to the domain using the Contributions page of the Domain Manager GUI

Figure 3.7. The Contributions page of the Domain Manager GUI after all the contributions for the introductory travel-booking application have been installed in the domain

Figure 3.8. The Composites page of the Domain Manager GUI showing the contents of the entry fields for deploying a composite to the domain

Figure 3.9. The Composites page of the Domain Manager GUI after all the composites in the application have been deployed

Figure 3.10. The Cloud page of the Domain Manager GUI showing an example of what would be entered to add an execution node for a deployed composite

Figure 3.11. The Cloud page of the Domain Manager GUI after defining all the execution nodes

Figure 3.12. The Tours composite can be used as a component implementation, with composite services BookTrip and Checkout, a composite reference trips, and a composite property currency.

Figure 3.13. The Tours composite is used as the implementation of the MyTours component in the ToursImpl composite.

Chapter 4. Service interaction patterns

Figure 4.1. Remote interactions between components in separate Java virtual machines. The components communicate using the web service binding.

Figure 4.2. Local interactions between components within a single Java virtual machine

Figure 4.3. A request response message flowing between the InteractionRequestResponseClient and CurrencyConverter components. The flow of execution is depicted using the dashed line. Program execution at the client waits until the request completes and the response is returned.

Figure 4.4. The InteractionOneWayCallbackClient component sends a search request to the Hotel component using a oneway interaction pattern. The flow of execution is depicted using the dashed line. This diagram doesn’t show how the results are retrieved from the Hotel component.

Figure 4.5. A bidirectional service combines both forward and callback interfaces. The flow of execution is depicted using the dashed line. The InteractionOneWayCallbackClient component makes a request through the forward interface to the Hotel component and continues processing immediately. The Hotel component processes the request and sends the results back via the callback interface.

Figure 4.6. The forward and callback interfaces and bindings in bidirectional interfaces. The flow of execution is depicted by the dashed line.

Figure 4.7. Multiple conversational calls to the CartStore component can be correlated so that each message is processed by the same component instance. The flow of execution is depicted using the dashed lines.

Chapter 5. Implementing components using the Java language

Figure 5.1. The Java implementation (PaymentImpl) provides the business logic for a component, providing services and using references and properties.

Figure 5.2. The Payment Java component connected to the other components that it depends on

Figure 5.3. Mapping the Java implementation class to an SCA component type using SCA annotations

Figure 5.4. Two different payment components are wired to the same bidirectional service of a credit card payment component.

Figure 5.5. Two different client components are processing payments for Jim and John using the same CreditCardPayment component. For each payment authorization request, a different instance of the CreditCardPayment component is created. Each instance of CreditCardPayment gets the appropriate callback proxy injected and can use this to make callbacks to the correct client component.

Figure 5.6. Two different client components are processing payments for Jim and John using the same CreditCardPayment component. For each payment authorization request, the same instance of the CreditCardPayment component is used. The injected callback proxies overwrite each other in the CreditCardPayment instance, and the callback is made to the wrong client component.

Figure 5.7. By using service references passed between SCA components, the CreditCardPayment component can be asked to call the EmailGateway component.

Chapter 6. Implementing components using other technologies

Figure 6.1. The Payment component implemented using implementation.spring, which, in turn, references a Spring application context, called Payment-context.xml, containing three beans

Figure 6.2. The mapping between the unannotated Spring Payment bean and SCA services, references, and properties

Figure 6.3. The mapping between the modified Spring application context and SCA services, references, and properties

Figure 6.4. Implementation.bpel provides a WS-BPEL implementation for an SCA component.

Figure 6.5. Mapping partner links to SCA component services and references

Figure 6.6. Mapping between SCA service and references and BPEL partner links

Figure 6.7. The mapping between partner link roles and SCA interfaces on services and references

Figure 6.8. Implementation.script allows SCA components to be implemented using those scripting languages supported by the Bean Scripting Framework from the Apache Jakarta project.

Chapter 7. Connecting components using bindings

Figure 7.1. The currency converter with its single CurrencyConverter service

Figure 7.2. Invoking the Notification service will cause it to invoke the SMS gateway web service.

Chapter 8. Web clients and Web 2.0

Figure 8.1. Overview of a currency converter servlet connected to the currency converter SCA component

Figure 8.2. Currency converter servlet viewed through a web browser

Figure 8.3. Currency converter servlet converted $600 U.S. to sterling

Figure 8.4. Currency converter JSP viewed through a web browser

Figure 8.5. Currency converter JSP converted 100 U.S. dollars to sterling.

Figure 8.6. The TuscanySCATours HTML page as an SCA component implementation

Figure 8.7. Screenshot of the TuscanySCATours help pages

Figure 8.8. Screenshot of the TuscanySCATours blog Atom feed

Figure 8.9. Screenshot of the TuscanySCATours blog RSS feed

Chapter 9. Data representation and transformation

Figure 9.1. The Payment and CreditCardPayment components that Bob and Mary are working on

Figure 9.2. Visualization of the XML schema definition for CreditCardDetailsType

Figure 9.3. As a message passes from component reference to component service, its data is represented in several different formats depending on whether the message is in the component, in the binding, or being passed on the wire.

Figure 9.4. Interface information can be configured through reference and service interfaces in the component type. It can also be configured through interface elements in the reference and service elements of a component in the composite file. Interface configuration can also be imposed by some bindings.

Figure 9.5. Component interaction and data flow for the credit card payment sample

Figure 9.6. Automatic data transformation between Payment and CreditCardPayment components

Figure 9.7. The Tuscany databinding framework uses a graph of transformers (1–6) to find a path (1) to transform data from JAXB to AXIOM for the Payment component reference using binding.ws.

Chapter 10. Defining and applying policy

Figure 10.1. An SCA component with intents and/or policy sets attached to enforce quality of service. The intents and policy sets are read in from one or more definitions.xml files.

Figure 10.2. A high-level view of how the Tuscany runtime uses message interceptors strung out along a chain to allow policy function to be plugged in. There’s an interceptor chain for each operation within each component service and reference.

Figure 10.3. The Trip component providing Search and Book services. Messages flow from the service bindings to the implementation, as shown by the solid lines with arrows.

Figure 10.4. The result of applying the logging policy to the Trip component implementation is that the Tuscany runtime creates a JDKLoggingPolicyInterceptor. The chains aren’t shown here, but the diagram indicates that the interceptor is applied to all operations of all services provided by the implementation of the Trip component.

Figure 10.5. The Payment component is wired to the CreditCardPayment component, and the reference and service are configured to use the Web Services binding. Messages flow through the reference and service, as shown by the solid line with the arrow.

Figure 10.6. The result of applying the authentication policy to the Payment and CreditCardPayment components is that the Tuscany runtime creates a basic authentication interceptor in both reference and service chains and configures the Web Services binding to use the HTTP header to pass basic authentication credentials.

Chapter 11. Running and embedding Tuscany

Figure 11.1. SCA Composite applications managed by the SCA domain are run on Tuscany nodes.

Figure 11.2. The SCA domain is mapped to a set of Tuscany nodes to be run in different environments, which can use different ways to configure, create, start, and stop a node.

Figure 11.3. The Tuscany node launcher bootstraps the Tuscany runtime and creates a node to load and run the composite application.

Figure 11.4. Tuscany nodes can be programmatically configured and created. Application code uses the node APIs to start the node, look up a service, invoke it, and stop the node.

Figure 11.5. Tuscany runtime JARs are packaged in the WAR to allow the web application to run as an SCA contribution.

Figure 11.6. A managed container that embeds Tuscany and provides infrastructure for SCA. It calls Tuscany APIs to manage the configuration, creation, and lifecycle of the node.

Chapter 12. A complete SCA application

Figure 12.1. The front page of the TuscanySCATours travel-booking application

Figure 12.2. The first part of the TuscanySCATours travel-booking application up to and including the ShoppingCart component

Figure 12.3. The payment part of the TuscanySCATours travel-booking application

Figure 12.4. The fullapp-ui contribution provides the user interface for the TuscanySCATours application.

Figure 12.5. The TravelCatalog and TripBooking components coordinate communication with the services provided by the TuscanySCATours company’s business partners.

Figure 12.6. The components in the TuscanySCATours application are aligned with the kinds of departments that could be part of a travel-booking company.

Figure 12.7. The Shopping Cart composite containing the ShoppingCart component and the CartStore component that stores items added to the shopping cart

Figure 12.8. The Payment and CreditCardPayment composites showing the components that are used during payment processing

Figure 12.9. Running the TuscanySCATours travel-booking application across distributed nodes configured using the Tuscany domain manager

Figure 12.10. The layout of the self-contained payment-java contribution

Figure 12.11. The layout of the fullapp-bespoketrip contribution

Chapter 13. Tuscany runtime architecture

Figure 13.1. The high-level architecture view showing the Tuscany runtime reading an SCA composite application

Figure 13.2. Plugging the Web Services binding and Axis2 extension into the Tuscany runtime extension points

Figure 13.3. Key functional blocks in the Tuscany runtime

Figure 13.4. The contribution scanner extension point and contribution scanner extensions

Figure 13.5. The ExtensionPointRegistry contains pointers to extension points that support the various functional requirements of the extensions.

Figure 13.6. The service provider interface, implementation, and declaration

Figure 13.7. The Tuscany runtime’s service discovery and plug-in instantiation flow. In this flow the service provider refers to the plug-in code providing a service in the context of the JAR file service provider pattern.

Figure 13.8. The Tuscany runtime steps for starting and stopping an SCA composite application

Figure 13.9. Tuscany’s bootstrap sequence

Figure 13.10. Tuscany’s bootstrap sequence

Figure 13.11. Collaboration between extension points and plugins. The arrows with numbers show the sequence of lookups and delegations.

Figure 13.12. Tuscany uses the ModelResolverExtensionPoint and specific ModelResolver plug-in code to connect the WSDLInterface to a concrete WSDL portType object by QName.

Figure 13.13. Configuration inheritances following the structural and implementation hierarchies

Figure 13.14. The composite model runs through a set of builders to reconcile the configurations.

Figure 13.15. Runtime providers enable the Tuscany runtime to control the lifecycle of an SCA component, interact with communication protocols, invoke the business logic, transform data, and force quality of services. They connect the SCA programming model constructs to the plumbing technologies.

Figure 13.16. Interceptors and Invokers are ordered by phases in the invocation chain.

Figure 13.17. Implementation, Binding, and Policy extensions contribute Invokers to the invocation chains.

Figure 13.18. Dependency injection and proxy creation performed by JavaImplementationProvider for Java implementation classes

Figure 13.19. The invocation chain for an SCA reference binding

Figure 13.20. The invocation chains for an SCA service binding

Chapter 14. Extending Tuscany

Figure 14.1. An extension contributes various information to Tuscany extension points.

Figure 14.2. The XML and Java model for the POJO implementation type

Figure 14.3. The classes that describe the extension point and extensions that collaborate to define the implementation.pojo extension

Figure 14.4. The artifacts that together are used to describe and populate an in-memory model of the binding.echo extension

Figure 14.5. The different extension classes that collaborate and cooperate to support the our new binding type, binding.echo

Appendix A. Setting up

Figure A.1. The expanded Tuscany binary distribution on Windows

Appendix B. What’s next?

Figure B.1. An SCA domain can be used to provide the inter-bundle wiring of a distributed OSGi application.

Figure B.2. An SCA domain is provisioned to the cloud with multiple Tuscany runtimes that host nodes to run a group of components.