Chapter 7. Connecting components using bindings
This chapter covers
- Connecting services and references using SCA bindings
- Exposing SCA services using Web Services, CORBA, RMI, and JMS
- Integrating services exposed using Web Services, CORBA, RMI, JMS, or as EJBs from SCA
By this stage in the book you know how to implement SCA components and wire them together to create SCA applications. It’s now time for you to shift your focus and look outside the world of SCA and see how you can integrate your SCA applications with the rest of the world.
Often an SCA application will need to expose its services to existing business applications or make use of the services offered by them. This is done over a communications channel and protocol that’s understood by both parties. These existing business applications typically make use of a variety of communications protocols such as SOAP, CORBA, RMI, JMS, and so on.
This chapter is all about SCA bindings. You’ll see how SCA hides some of the complexities of handling communications protocols from the SCA application developer using SCA bindings. You’ll also see how SCA bindings allow the communications protocols to be changed with little effort.
This chapter uses components from the SCA Tours application to show how you can make services available to non-SCA applications using Tuscany SCA bindings. We’ll also demonstrate how other applications can expose their services to SCA components so their services can be invoked using Tuscany SCA bindings.
This chapter is about the bindings that Tuscany supports. Some of these are described by the SCA specification, such as
- Web Services binding (SOAP)
- JMS binding
- EJB session binding
Tuscany also supports additional bindings that have been defined based on the Tuscany community’s demand, such as
- CORBA binding
- RMI binding
By the end of this chapter, you’ll know how to integrate SCA services and references with the wider world of non-SCA applications using SCA bindings. Let’s start with a quick review of SCA bindings in general.
7.1. Introduction to SCA bindings
SCA supports many communications protocols. In SCA terms, these are called bindings. Bindings encapsulate the complexities of the communications protocols and enable components to be implemented and wired together without a direct dependency on the communications protocol(s) used.
What does this mean in reality? It means that an SCA developer can implement a component without polluting the business code with details of how the communication between components will be handled. This separation of concerns has the added advantage of making the communications protocol a pluggable entity that can be changed at any time based on how and where the component is deployed. For example, suppose you want to make the TuscanySCATours currency converter a web service. Simple—you add the SCA Web Services binding to the service defined in the composite XML file. Suppose you then want to make the TuscanySCATours currency converter an RMI service as well. Simple—you add the SCA RMI binding to the service defined in the composite XML file. You can do both of these changes without modifying the component implementation code for the currency converter. We’ll cover both of these examples later in this chapter.
As discussed in section 2.5.1, SCA bindings can be added to a composite application either on an SCA service or on an SCA reference. The following subsections provide a quick overview of these two usage patterns. We’ll discuss specific bindings in more detail later in this chapter.
7.1.1. Using SCA bindings on an SCA service
One or more SCA bindings can be used on a service to allow the service to be invoked over each binding’s protocol. To illustrate this, listing 7.1 shows the Payment composite with an SCA Web Services binding and an SCA RMI binding on the Payment service.
Listing 7.1. Payment composite XML file with Web Services and RMI bindings
By adding the Web Services binding 
and the RMI binding 
, the Payment service can be invoked over both SOAP and RMI.
7.1.2. Using SCA bindings on an SCA reference
SCA references describe the dependencies that an SCA component has on other services. Multiple bindings can be assigned to a single reference, each enabling communication over a different type of protocol. Listing 7.2 shows how the Payment component can invoke the CustomerRegistry service over the Web Services binding and CreditCardCORBAService over the CORBA binding.
Listing 7.2. Payment composite with various SCA bindings on the references
The customerRegistry reference on the Payment component has a Web Services binding . This is indicated by the <binding.ws> element, which specifies the location of the customer registry web service using the uri attribute.
The creditCardPayment reference on the Payment component has a CORBA binding . This is indicated by the <binding.corba> element, which specifies the host and port number as well as the CORBA service name of the card payment service.
Looking at the emailGateway reference, did you notice that no binding is listed? So which SCA binding is used for this reference? The answer is that if a service or reference doesn’t specify a binding, then the SCA default binding is used.
Before we move on to look at some SCA bindings, let’s spend a few moments introducing the SCA components we’ll use to demonstrate the SCA bindings.
7.2. Demonstrating SCA bindings
Throughout this chapter, we’ll demonstrate how to use bindings on services with the CurrencyConverter component and on references with the Notification component. Let’s have a quick look at the CurrencyConverter and Notification components before we move on to look at specific bindings.
7.2.1. Overview of the currency converter
The CurrencyConverter is a simple component that can be used to calculate the value of one currency in a different currency. For example, it can be used to calculate the value of $100 U.S. in sterling. Figure 7.1 shows an overview of the currency converter.
Figure 7.1. The currency converter with its single CurrencyConverter service
The composite definition for the currency converter SCA component can be found in the contributions/currency directory of the SCA Tours application and is shown here.
Listing 7.3. The currency converter composite XML file
<composite name="currency-converter" ...>
<component name="currencyconverter">
<implementation.java class= "com.tuscanyscatours.currencyconverter.impl.CurrencyConverterImpl" />
<service name="CurrencyConverter">
<interface.java interface= "com.tuscanyscatours.
</service>
</component>
</component>
As you can see from the XML in listing 7.3, the currency converter is implemented using the Java implementation type. It exposes a single service that’s defined by the CurrencyConverter Java interface, as shown in the following listing.
Listing 7.4. The currency converter Java interface
@Remotable
public interface CurrencyConverter {
double getExchangeRate(String fromCurrencyCode,
String toCurrencyCode);
double convert(String fromCurrencyCode, String toCurrencyCode,
double amount);
}
Listing 7.4 shows the Java interface that defines the methods on the currency converter service. It has two methods, getExchangeRate and convert.
The CurrencyConverterLauncher in the launchers/currency-converter directory of the SCA Tours application can be used to test the currency converter. When it’s run, it will load the currency converter contribution into Apache Tuscany and perform a quick test, producing the following output:
Quick currency converter test
USD -> GBP = 0.5
100 USD = 50.0GBP
Because we haven’t specified any bindings on the services or references, Tuscany will use the SCA default binding to wire the components together.
7.2.2. Overview of the Notification service
The Notification service is a simple component that can be used as part of an SCA application to send notifications to users. For the SCA Tours application, it could be used to send notifications such as “credit card payment accepted.” The Notification service acts as a façade that hides how the notification is sent to the user. In this basic implementation, the Notification service sends notifications via SMS to the user’s mobile phone. The Notification service doesn’t contain the code to send the SMS. To send the SMS, it invokes an external SMS gateway service. Figure 7.2 shows an overview of the Notification service.
Figure 7.2. Invoking the Notification service will cause it to invoke the SMS gateway web service.
The composite definition for the Notification component is shown in here.
Listing 7.5. The notification composite XML file
<composite name="notification" ...>
<component name="Notification">
<implementation.java class="com.tuscanyscatours.notification.
<service name="Notification">
<interface.java interface="com.tuscanyscatours.
</service>
<reference name="smsGateway">
<interface.java
interface="com.tuscanyscatours.smsgateway.SMSGateway"/>
...
</reference>
</component>
</composite>
The Notification service is implemented using the Java implementation type. It exposes a single service that’s defined by the Notification Java interface. It also has a reference to the SMS gateway.
The Notification Java interface is used to define the methods on the Notification service:
public interface Notification {
boolean notify(String accountID, String subject, String message);
}
It has a single method called notify that will
- Look up the mobile phone number associated with the specified account ID
- Send an SMS to the user’s mobile phone that contains the specified subject and message
The Notification service assumes that there is a mobile phone number associated with the specified account ID.
The SMS gateway is a non-SCA application that exposes a service that can be used to send SMS messages to mobile phones. It represents an existing business application, not written using SCA, which we’ll want to integrate into our SCA application.
The interface of the service that’s exposed by the SMS gateway is shown here:
public interface SMSGateway {
boolean sendSMS(String fromNumber, String toNumber, String text);
}
The SMSGateway Java interface for the SMS gateway has a single method called send-SMS that will send an SMS message containing the given text to the specified number. We won’t really send SMS messages from our sample code, but we’ll write the message that would be sent to the console.
Now that you have an overview of the currency converter and Notification components, let’s move on and look at our first binding, the SCA default binding.
7.3. Connecting component services with binding.sca
As you’ve seen, an SCA binding is required for communication between components. You saw how you can assign a binding to a service or a reference. It’s also possible to omit the binding, which means Tuscany will use the default SCA binding. You can also tell Tuscany to use a default binding explicitly by using the <binding.sca/> element on a reference or service.
It’s expected that for most wires between SCA components, no binding will be specified because the default SCA binding will automatically be used. After all, most of the time a developer doesn’t care how two SCA components are physically connected as long as one can invoke the other. It’s only mandatory to specify a binding when you want to connect an SCA component to an application running outside the SCA domain.
The default SCA binding is defined by the SCA Assembly specification as a binding that can be used to wire together components within a single SCA domain. It’s not designed to wire together components that exist in multiple SCA domains or are external to the SCA domain. If a service needs to be invoked from outside the SCA domain, or a reference needs to invoke a service outside the SCA domain, then an interoperable binding (such as the Web Services or JMS binding) must be used. We’ll move on in a moment to look at some of these interoperable SCA bindings that Tuscany provides.
In Tuscany, the communications protocol used by the default binding will depend on whether the service and reference are in the same node or in different nodes. If they’re in different nodes, Tuscany will use SOAP/HTTP for the default binding. If they’re in the same node, Tuscany will use Java method invocations via a Java proxy because the target will always be in the same JVM. This use of proxy calls within the same node happens with both local and remotable interfaces. The composite XML in the next listing shows how the default SCA binding can be used.
Listing 7.6. Payment composite with various usages of the SCA default binding
The customerRegistry reference doesn’t list any bindings, so the SCA default binding will be used. The creditCardPayment reference explicitly specifies the SCA default binding . This isn’t strictly necessary because it will automatically be added by Tuscany because there are no other bindings specified.
The emailGateway reference has an SCA Web Services binding and an SCA default binding 
. For this reference, if the SCA default binding wasn’t explicitly listed, it wouldn’t be automatically added by Tuscany because
the reference already has an SCA Web Services binding.
In the previous example, we mentioned the SCA Web Services binding, binding.ws, so let’s move on and have a look at it now.
7.4. Connecting component services with web services
In this section, we’ll look at how the SCA Web Services binding, binding.ws, can be used to expose SCA services as web services and how you can access web services via SCA references.
The term web service is generally used to describe an interface that’s provided by a software application that’s callable over the network. More recently, the term has come to be used to specifically describe services provided over a network using the SOAP over HTTP protocol. SOAP started life as an acronym for Simple Object Access Protocol (some say Service Oriented Access Protocol) and describes an XML-based format for passing messages from a client to a service and back. The XML is simple and defines an envelope that holds a body, the message itself, and a header that contains metadata about the message. Running SOAP over HTTP means POSTing SOAP-formatted XML to an HTTP server where special software, such as Apache Axis, reads the XML and calls the right service operation with data from the message.
Several libraries available today allow a developer to author and consume SOAP/HTTP web services. Many of them require you to either code to the library’s API or use a tool to generate service stubs and client proxies that hide the library API from you. Tools are often also provided for tasks like generating WSDL descriptions from service interfaces. Such tools are useful, but Tuscany makes SOAP/HTTP even easier to use. The Tuscany component developer adds the <binding.ws> element to a component’s services or references, and the job’s done. It’s worth mentioning that Tuscany 1.x implements the OSOA SCA specifications that are based on WSDL 1.1. Tuscany 1.x uses Apache Axis 2 as its SOAP stack.
Let’s start by looking at using binding.ws on a component service.
7.4.1. Exposing an SCA service as a web service
Let’s first look at how to expose an SCA component as a web service using the SCA Web Services binding and then create a web service client to access it. We’ll be adding the <binding.ws> element to the composite XML file.
Using the SCA Web Services Binding on a Service
To expose the currency converter as a web service, you’ll need to add the SCA Web Services binding to the <service> element in the composite XML file. The code for this can be found in the contributions/currency-ws directory of the SCA Tours application and is shown in the following listing.
Listing 7.7. Currency converter component with SCA Web Services binding
<component name="CurrencyConverter">
<implementation.java
class="com.tuscanyscatours.currencyconverter.impl.
<service name="CurrencyConverter">
<binding.ws />
</service>
</component>
Listing 7.7 shows the currency converter component XML with the addition of the SCA Web Services binding. But wait a minute; you may wonder if we’ve really turned the currency converter into a web service by adding one line to an XML file. The answer is yes; let’s run the example to demonstrate this.
Running the Currency Converter Web Service Launcher
The currency converter web service launcher (CurrencyConverterWSLauncher) in the launchers/currency-converter-ws directory of the SCA Tours application can be used to test the currency converter using the Web Services binding. When it’s run directly (or via Ant run), it produces the same output as previous runs of the currency converter. But the currency converter now has a web service interface. How can you verify that it does? You could write a web service client to access it. You’ll be doing that later, but there’s an easier way using a web browser. When the Web Services binding is used with a service, it generates and publishes a description of the service using WSDL (Web Services Definition Language.) To view the currency converter WSDL while it’s running, point your browser at the following URL: http://localhost:8080/CurrencyConverter? wsdl. In Firefox, the WSDL will be displayed. In Safari, you must use the View > View Source menu to see the WSDL.
WSDL stands for Web Services Definition Language and is an XML language that can be used to describe the interfaces provided by a web service. It allows the functionality of an interface of a web service to be described in terms of the operations it provides and the physical details of where the web service is hosted.
The following listing shows a fragment of the WSDL document for the currency converter. Because it’s quite long, we’ve removed the less-relevant details to keep it short.
Listing 7.8. Part of the WSDL for the currency converter service
The header of the WSDL document shows that this is the WSDL for our currency converter service. The WSDL specifies the SOAP
document binding and lists the getExchangeRate and convert methods of the currency converter. The URL that’s used to publish the currency converter is also listed in the WSDL. The IP address in the URL is likely to be different in your WSDL because it will match the IP
address of your computer.
Accessing the Currency Converter SCA Web Service Using a Java Client
Now that the currency converter is exposed as a web service, let’s write a non—SCA client that will make use of it. The code for the non-SCA client can be found in the clients/currency-converter-ws-jaxws directory of the SCA Tours application. To simplify creating the client, we’ll use the wsimport tool from the Sun JDK version 1.6 or above to convert the currency converter WSDL into Java classes by using the following command:
wsimport —p com.tuscanyscatours.client
As an alternative to using Sun JDK 1.6, we could have installed Apache Axis2 and used the wsdl2java command that it provides to convert the WSDL into Java classes.
You can now use the generated Java classes to write an application to use the currency converter web service. The following code uses these generated Java classes to invoke the currency converter web service.
Listing 7.9. Fragment of the currency converter web service client
public static void main(String[] args) throws Exception {
CurrencyConverterService service
= new CurrencyConverterService();
CurrencyConverter converter
= service.getPort(CurrencyConverter.class);
System.out.println("USD -> GBP = "
+ converter.getExchangeRate("USD", "GBP"));
System.out.println("100 USD = "
+ converter.convert("USD", "GBP", 100.0) + "GBP");
}
The client uses the classes generated by the wsimport command to connect to the currency converter web service and does a quick test of the currency converter. Running this code, you’ll see the following output:
USD-> GBP = 0.5
100 USD = 50.0 GBP
You’ve just invoked the currency converter service as a web service over the SCA Web Services binding.
One final point before we move on: You could have written the client to access the currency converter web service in a language other than the Java programming language. It would be relatively simple to use the WSDL produced by the Web Services binding to create clients in languages such as Microsoft C# or Visual Basic.
Now let’s look at how to use SCA references to invoke services that are outside the SCA domain.
7.4.2. Accessing a web service using the SCA Web Services binding
It’s possible to invoke an existing web service from an SCA application by using the SCA Web Services binding on a reference. It doesn’t matter whether the web service is an SCA component or implemented in some other technology besides SCA.
Connecting an SCA Reference to the SMS Gateway Web Service
You’ll now need to wire the SMS gateway reference in the Notification service to the web service exposed by the SMS gateway. This is done by adding the <binding.ws> element to the reference. The code for this can be found in the contributions/notification-ws directory of the SCA Tours application and is shown in the following listing.
Listing 7.10. The SMS gateway reference with SCA Web Services binding
<composite name="notification" ...>
<component name="Notification">
<service name="Notification">
...
</service>
<reference name="smsGateway">
<interface.java
interface="com.tuscanyscatours.smsgateway.SMSGateway"/>
<binding.ws
uri="http://localhost:8081/SMSGatewayService"/>
</reference>
</component>
</composite>
When adding the Web Services binding to a reference, you’ll need to tell Tuscany the URL of the web service using the uri attribute of the <binding.ws> element. For the SMS gateway, the URL is http://localhost:8081/SMSGatewayService.
Running the Notification Service Connecting to the SMS Gateway Web Service
Before you can run the Notification service, you’ll need to ensure that the SMS gateway web service is running using the launcher in the services/smsgateway-jaxws directory of the SCA Tours application. Once it’s running, you can run the Notification service using the launcher in the launchers/notification-ws directory of the SCA Tours application and connect to the web service of the SMS gateway. It will produce the following output on the console:
Quick notification test
Sending SMS to +44(0)7700900812 for accountID 1234
Node started - Press enter to shutdown.
The following output will also be displayed on the console where the SMS gateway was started:
Sending SMS message
From: +44(0)2079460723
To: +44(0)7700900812
Message: Holiday payment taken. Payment of £102.37 accepted...
As you can see from the two outputs, the Notification service has looked up the mobile phone number for account ID 1234 and used the web service interface of the SMS gateway to send the user an SMS.
Up to this point, you’ve used only the default configuration options for the Web Services binding. Let’s see what other configuration options are supported.
7.4.3. Configuration options for the SCA Web Services binding
The Web Services binding supports several configuration options that allow you to customize how a service is exposed as a web service. The following listing shows the schema for the Web Services binding.
Listing 7.11. Schema for the SCA Web Services binding
<binding.ws
name="NCName"
uri="anyURI"
wsdlElement="xs:anyURI"
wsdlLocation="list of xs:anyURI"
requires="sca:listOfQNames"
policySets="sca:listOfQNames">
<wsa:EndpointReference>
...
</wsa:EndpointReference>
<binding.ws/>
Table 7.1 further describes the list of configuration options that are available for customizing a Web Services binding.
Table 7.1. Options for the SCA Web Services binding
|
Option |
Optional |
Description |
|---|---|---|
| name | Yes | The name for this binding. |
| uri | Yes | For services, the URI where the service should be published. For references, the URI of the service to connect to. |
| wsdlElement | Yes | The URI of a WSDL element. |
| wsdlLocation | Yes | The location of the WSDL document that describes this web service. |
| requires | Yes | Any required intents for this binding. |
| policySets | Yes | Any policy sets for this binding. |
| EndpointReference | Yes | WS-Addressing EndpointReference that specifies the endpoint for the service. |
We’ll briefly discuss the main usage scenarios of these options; see the OSOA SCA Web Services Binding specification for a complete description of all the usage scenarios. You can download it from http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications.
Using the SCA Web Services Binding with Existing WSDL Documents
The Web Services binding makes extensive use of WSDL to describe the interfaces exposed by services and invoked by references. The Web Services binding can use an existing WSDL document. This is often called WSDL-First because the WSDL document is created before the service is written. A common scenario for WSDL-First is where the SCA application needs to use an existing web service, such as in a cloud computing environment.
You can specify the WSDL document for a web service in a number of ways using the wsdlElement and wsdlLocation attributes of the Web Services binding. The simplest option is to use the wsdlElement attribute to refer to a specific service in a WSDL document, as illustrated in the following XML fragment:
<service name="CurrencyConverter">
<interface.java interface="com.tuscanyscatours.currencyconverter.
<binding.ws wsdlElement="http://localhost/CurrencyConverterService#
</service>
Another typical usage scenario is where the location of the WSDL document is specified using the wsdlLocation attribute, as illustrated in the following XML fragment:
<service name="CurrencyConverter">
<interface.java interface="com.tuscanyscatours.currencyconverter.
<binding.ws wsdlElement="http://localhost/CurrencyConverterService#
</service>
Both of these examples showed using the wsdlElement and wsdlLocation attributes of binding.ws on services. Note that they can both be used in the same manner for references.
Using the SCA Web Services Binding Without Exisitng WSDL Documents
The SCA web service can be used to expose a service without requiring a WSDL document to be provided. If a WSDL document isn’t provided, then Tuscany will automatically generate a WSDL document from the Java interface of the service. This process is often called WSDL-Last because the WSDL document is produced after the implementation code.
The examples from earlier in this section used WSDL-Last because they used <binding.ws> without any of its attributes. The WSDL document can be retrieved by adding ?wsdl to the end of the URL for the service. For example, if a web service is accessible at http://localhost:8080/CurrencyConverter, then its WSDL document can be retrieved from http://localhost:8080/CurrencyConverter?wsdl.
Using Intents and Policy Sets with the SCA Web Services Binding
Like all SCA bindings, the Web Services binding can have SCA intents and policy sets. As an example, the SOAP.1_1 intent could be specified, and that would require the binding to use SOAP 1.1, as shown in the following XML fragment:
<service name="CurrencyConverter">
<interface.java interface="com.tuscanyscatours.currencyconverter.
<binding.ws requires="SOAP.1_1"/>
</service>
For more information on using SCA intents and policy sets, see chapter 10.
At this point, you know how to use the SCA Web Services binding on services and references. Let’s move on and look at a different binding, the SCA CORBA binding.
7.5. Connecting component services with CORBA
In this section we’ll look at how you can use the Tuscany SCA CORBA binding, binding.corba, to expose services as CORBA services and how you can invoke existing CORBA services from an SCA application. Feel free to read this section later if you’re currently not planning to use CORBA in your SCA applications.
The Common Object Request Broker Architecture (CORBA) specification allows applications to communicate with each other over the network. It defines a standard protocol that allows programs that use CORBA to invoke each other regardless of the programming language they’re written in or the operating system they’re running. For example, a COBOL application running on Linux could expose a CORBA service, and it could be invoked by a Java application running on Microsoft Windows.
Tuscany makes it easy to call CORBA services. All you’ll need to do is to add the <binding.corba> element to your component’s services and references as appropriate. Let’s start by looking at using binding.corba on a component service.
7.5.1. Exposing an SCA service as a CORBA service
In this section we’ll show how the currency converter can be invoked as a CORBA service. See section 7.2.1 for an overview of the currency converter.
Using the Tuscany SCA Corba Binding on a Service
In order to expose a service as a CORBA service, you’ll need to add the Tuscany CORBA binding to the <service> element in the composite XML file. The code for this can be found in the contributions/currency-corba directory of the SCA Tours application and is shown here.
Listing 7.12. The currency converter component with an SCA CORBA binding
Listing 7.12 shows the currency converter composite XML that includes the SCA CORBA binding . Because the CORBA binding is a Tuscany binding, you’ll need to import the Tuscany XML namespace and prefix the binding.corba with tuscany. The host and the port numbers must be specified to configure the host and port numbers for the CORBA service. In this example,
you used localhost as the host and port 5080. The final attribute is the name attribute, which is used to specify the name that should be associated with the CORBA service and in this case is CurrencyConverterCORBAService.
Running the Currency Converter CORBA Service Launcher
You can use the currency converter CORBA launcher in the launchers/currency-converter-corba directory of the SCA Tours application to test the currency converter using the CORBA binding. When it’s run, it produces the same output as previous runs of the currency converter. But this time the currency converter is exposed as a CORBA service. How can you verify that it does? The best way is to write a CORBA client that will access it. Let’s do that now.
Accessing the Currency Converter SCA CORBA Service Using a Java Client
For any CORBA service, there’s an associated Interface Definition Language (IDL) file that describes the CORBA service and the methods it exposes. This is similar in concept to WSDL, which is used to describe web services.
Typically when creating a CORBA client, you’d start from the IDL file for the CORBA service that you want to access. How do you obtain the IDL file for the currency converter CORBA service? Unfortunately, unlike with web services, there’s no easy way to download the IDL file. It’s possible to convert a Java interface to an IDL file using a Java-to-IDL compiler, but to keep things simple, you’ll create the IDL file by hand. The IDL file for the currency converter CORBA service can be found in the clients/currency-converter-corba directory of the SCA Tours application and is shown in the following listing.
Listing 7.13. Currency converter CORBA service IDL file
module com {
module tuscanyscatours {
module currencyconverter {
interface CurrencyConverter {
double getExchangeRate(in string fromCurrencyCode,
in string toCurrencyCode);
double convert(in string fromCurrencyCode,
in string toCurrencyCode, in double amount);
};
};
};
};
The IDL document begins with the module definitions. These are functionally equivalent to Java package definitions. This IDL defines a module called com.tuscanyscatours.currencyconverter. In this module structure is the interface declaration of the CurrencyConverter CORBA service. This interface declaration is used to describe the methods on the CORBA service, in this case, the getExchangeRate() and convert() methods.
Now that you have the IDL for the currency converter CORBA service, you’ll need to convert it into a form that can be used in a Java application. To do this, you’ll use an IDL-to-Java compiler, which converts an IDL file into Java source code that can be used to access the CORBA service described in the IDL. The JDK comes with an IDL-to-Java compiler called idlj, and the following command converts our currency converter IDL into Java code (from the src/main/resources directory).
idlj –fclient -td idlj_output currency-converter.idl
This idlj command reads the currency-converter.idl file and converts it to Java source code in the idlj_output directory. The -fclient option is used to tell idlj to generate the files required for a CORBA client.
You can now use the Java classes generated by idlj to write an application that will use the currency converter CORBA service. The following code shows such a CORBA client.
Listing 7.14. Fragment of the currency converter CORBA client
The first thing that the currency converter CORBA client does is to initialize the CORBA ORB (Object Request Broker) with
the port number 5080. This is the same port number that we specified in the CORBA binding. Next, the code constructs a CORBA
Interoperable Object Reference (IOR) and uses it to look up the currency converter CORBA service . The IOR that we’ll use consists of four parts:
- corbaname—The type of the IOR that we’ll be using
- localhost—The host where the CORBA service is running
- 5080—The port where the CORBA service is running
- CurrencyConverterCORBAService—The name of the CORBA service
Once the currency converter CORBA service has been looked up, it’s then used to do some test currency conversions .
A CORBA Interoperable Object Reference is a reference that defines the address of a CORBA service. A CORBA client can use an IOR to look up a CORBA service so that it can invoke operations on it.
A CORBA IOR can be used to look up CORBA services across different programming languages (for example, a Java client can look up a COBOL server) and across different CORBA vendor implementations. This is why it’s an interoperable object reference.
Running your currency converter CORBA client will produce the following output to the console:
USD-> GBP = 0.5
100 USD = 50.0 GBP
This output shows that you’ve been able to invoke the currency component service exposed using the SCA CORBA binding. Let’s now look at using the CORBA binding with references.
7.5.2. Accessing a CORBA service using the SCA CORBA binding
Suppose that you wanted to access an existing CORBA service from an SCA application. How would you do this? The answer is to use the SCA CORBA binding on a reference. To illustrate this, you’ll again use the Notification service and this time add a Tuscany CORBA binding to the SMS gateway reference. See section 7.2.2 for an overview of the Notification service.
Connecting an SCA Reference to the SMS Gateway CORBA Service
To connect the Notification service to the SMS gateway CORBA service, we’ll add a CORBA binding to the reference.
Listing 7.15 shows the XML composite file for the notification contribution with the CORBA binding. The code for this can be found in the contributions/notification-corba directory of the SCA Tours application.
Listing 7.15. Notification composite XML with SMS gateway reference CORBA binding
The Notification component has a reference to the SMS gateway. This reference is declared as having a CORBA binding that refers to a CORBA service running on host localhost on port 5080 called SMSGatewayCORBAService.
Running the SMS Gateway CORBA Service
Before you can start your SMS gateway CORBA service, you’ll need to ensure that the CORBA Name Service is running so the SMS gateway can register its CORBA services. To simplify starting the SMS gateway CORBA service, the launcher in the services/ smsgateway-corba directory of the SCA Tours application will start both the JDK CORBA Name Service and the SMS gateway CORBA service.
The CORBA Name Service is a standard CORBA service that’s used as a registrar for discovering CORBA services based on a service name.
When a CORBA service starts, it can register itself with the CORBA Name Service using a name. A client can then use the CORBA Name Service to look up the CORBA service by using the name that the CORBA service registered with the CORBA Name Service.
When it’s run, it displays the following output:
Starting transient name server process (port=5080)
tnameserv: Initial Naming Context:
Initial Naming Context:
IOR:000000000000002b49444c3a6f6d67......
TransientNameServer: setting port for initial object references to: 5080
Ready.
Publishing SMS Gateway Service as a CORBA service
CORBA server running - waiting for requests
At this point, the CORBA Name Service has started and the SMS gateway CORBA service is running and waiting for requests to process.
Running the Notification Service Connecting to the SMS Gateway CORBA Service
Finally, let’s put all the pieces together and get the Notification service to invoke the SMS gateway CORBA service. You’ll use the Notification service CORBA launcher from the launchers/notification-corba directory of the SCA Tours application. When it’s run, you’ll see the following output on the console:
Quick notification test
Sending SMS to +44(0)7700900812 for accountID 1234
Node started - Press enter to shutdown.
In addition, the following output will be displayed on the console that started the SMS gateway CORBA service:
Sending SMS message
From: +44(0)2079460723
To: +44(0)7700900812
Message: Holiday payment taken. Payment of £102.37 accepted...
As you can see from this output, you’ve been able to successfully invoke the SMS gateway using the SCA CORBA binding from an SCA application.
7.5.3. Configuration options for the SCA CORBA binding
In this section, we’ll briefly explore the configuration options for the SCA CORBA binding. The schema for the CORBA binding is shown in here.
Listing 7.16. Schema for the SCA CORBA binding
<binding.corba
name="NCName"
host="anyURI"
port="int"
uri="anyURI"
requires="sca:listOfQNames"
policySets="sca:listOfQNames">
<binding.corba/>
The SCA CORBA binding has the options shown in table 7.2.
Table 7.2. Options for the SCA CORBA binding
|
Option |
Optional |
Description |
|---|---|---|
| name | Yes | The name for this CORBA binding. |
| host | Yes | The name of the host on which the CORBA service is running. |
| port | Yes | The port number on which the CORBA service is running. |
| uri | Yes | The URI of the CORBA service. |
| requires | Yes | Any required intents for this binding. Not currently supported. |
| policySets | Yes | Any policy sets for this binding. Not currently supported. |
You can specify the location of the CORBA service in one of two main ways. It can be specified using the uri attribute of <binding.corba>, as shown here:
<service name="CurrencyConverter">
<interface.java interface=
"com.tuscanyscatours.currencyconverter.CurrencyConverter" />
<tuscany:binding.corba
uri="corbaname::localhost:5080/NameService#
</service>
Or it can be specified using the host, port, and name attributes of <binding.corba>, as follows:
<service name="CurrencyConverter">
<interface.java interface=
"com.tuscanyscatours.currencyconverter.CurrencyConverter" />
<tuscany:binding.corba
host="localhost" port="5080"
name="CurrencyConverterCORBAService"/>
</service>
These two <binding.corba> definitions can be used interchangeably because they both specify the same location for the CORBA service.
At this point, you’ve been able to use the SCA CORBA binding on services and references, and you also understand the configuration options available for it. Let’s move on and have a look at another binding, the SCA RMI binding.
7.6. Connecting component services with RMI
In this section we’ll look at how the SCA RMI binding, binding.rmi, can be used to expose services over RMI and how you can access RMI services in SCA. Feel free to read this section later if you’re currently not planning to use RMI in your SCA applications.
The Java Remote Method Invocation (RMI) API allows Java applications to invoke operations on objects in another JVM that have been exposed as RMI services. This is often referred to as a Remote Procedure Call (RPC).
The typical usage scenario is where a Java server application exposes one or more objects as remote objects that can be accessed by RMI clients. Once the server has exposed these remote objects, it typically waits for clients to invoke them. A Java client looks up these remote objects in the RMI registry and invokes operations on them. The server receives the requests and performs the required business logic, returning any results to the client.
RMI is provided as a core part of the Java language.
The Tuscany RMI binding doesn’t have an associated SCA specification. Tuscany implements the RMI binding using the extensibility features from the SCA specifications. As a result, this binding is Tuscany-specific and may not be available on other SCA implementations.
Outside of Tuscany and SCA, RMI is specific to the Java programming language and is provided as part of the JDK you’ll use to write Java programs. To write Java clients and services that exploit RMI, you’ll use the Java API for declaring remote interfaces, exposing them for use, and for finding them in the RMI registry on the client side.
With Tuscany, the component developer doesn’t use these APIs but adds the <binding.rmi> element to a component’s services and references as appropriate. This process is the same as for any SCA binding, and binding.rmi isn’t restricted to components using the Java implementation.
Let’s start by looking at using binding.rmi on a component service.
7.6.1. Exposing an SCA service as an RMI service
Let’s explore how the currency converter component can be exposed as an RMI service using the RMI binding.
Using the Tuscany SCA RMI Binding on a Service
To expose the currency converter as an RMI service, you’ll need to add the Tuscany RMI binding to the <service> element in the composite XML file. The code for this can be found in the contributions/currency-rmi directory of the SCA Tours application and is shown next.
Listing 7.17. Currency converter composite with Tuscany SCA RMI binding
Listing 7.17 shows the modified currency converter composite XML file with the Tuscany RMI binding added. You’ll need to import the Tuscany
XML namespace because the RMI binding isn’t defined by an SCA specification. Because it’s part of the RMI binding, you’ll
need to specify the host and the port details and the service name for the RMI service. These details will be used by any RMI clients to look up the currency converter RMI service.
Let’s move on to create an RMI client to check that the service has been exposed as an RMI service.
Accessing the Currency Converter SCA RMI Service Using a Java Client
Writing RMI clients is relatively simple and involves looking up the RMI service to get a proxy to the service and then invoking operations on that proxy. The following listing shows the currency converter RMI client that will invoke the currency converter over RMI. The code can be found in the clients/currency-converter-rmi directory of the SCA Tours application.
Listing 7.18. Fragment of the currency converter RMI client
To look up an RMI service, the client needs to use the RMI registry where the RMI services are registered. To obtain the RMI
registry, the client calls the getRegistry() method on LocateRegistry and specifies the same hostname and port as specified in the currency converter composite XML file.
Each service in the RMI registry is registered against a unique name. This name is required to look up an RMI service. In
our case, the RMI binding on the currency converter component used the service name CurrencyConverterRMI .
Running this currency converter RMI client will produce the following output. (Note: make sure the currency converter RMI SCA service launcher, launchers/ currency-converter-rmi, is running first.)
USD -> GBP = 0.5
100 USD = 50.0GBP
This output shows that you’ve successfully invoked the currency converter service over RMI. Let’s now look at using the RMI binding on references.
7.6.2. Accessing an RMI service using the SCA RMI binding
By using the RMI binding on a reference, it’s possible to invoke an existing RMI service from an SCA application. In this section, we’ll use the Notification service from section 7.2.2 again but this time add an RMI binding to the SMS gateway service.
Connecting an SCA Reference to the SMS Gateway RMI Service
Let’s update the Notification service composite XML file so that it can invoke the SMS gateway over RMI. To do this, you’ll need to add the <binding.rmi> element to the reference. The code for this can be found in the contributions/notification-rmi directory of the SCA Tours application and is shown here.
Listing 7.19. The SMS gateway reference with SCA RMI binding
The reference to the SMS gateway in the Notification component now uses an RMI binding. Because the RMI binding is in the
Tuscany XML namespace, you’ll need to import it. The RMI binding has attributes that define the host and port and the service name that should be used to connect to the SMS gateway RMI service.
Running the SMS Gateway RMI Service
Before you can use the SMS gateway RMI service in your SCA application, you’ll need to ensure that it’s running using the launcher in the services/smsgateway-rmi directory of the SCA Tours application. When started, the SMS gateway RMI service will display the following output:
Publishing SMS Gateway Service as a RMI service
RMI server running - waiting for requests
Press enter to shutdown.
The SMS gateway RMI service has been started and is listening on its RMI interface for requests to send SMS messages.
Running the Notification Service Connecting to the SMS Gateway RMI Service
Let’s see whether your Notification service application with the RMI binding can invoke the SMS gateway RMI service. To do this, we’ll run the Notification service RMI using the launcher in the launchers/notification-rmi directory of the SCA Tours application, which will produce the following console output:
Quick notification test
Sending SMS to +44(0)7700900812 for accountID 1234
Node started - Press enter to shutdown.
In addition, the following output will be displayed on the console where you started the SMS gateway RMI service:
Sending SMS message
From: +44(0)2079460723
To: +44(0)7700900812
Message: Holiday payment taken. Payment of £102.37 accepted...
As you can see from the output, you’ve been able to successfully invoke the SMS gateway using the SCA RMI binding from an application.
7.6.3. Configuration options for the SCA RMI binding
In this section, we’ll briefly explore the configuration options for the SCA RMI binding. The schema for the RMI binding is shown in the following listing.
Listing 7.20. Schema for the SCA RMI binding
<binding.rmi
name="NCName"
uri="anyURI"
host="anyURI"
port="int"
serviceName="anyURI"
requires="sca:listOfQNames"
policySets="sca:listOfQNames">
<binding.rmi/>
The RMI binding has the following options, as shown in table 7.3.
Table 7.3. Options for the SCA RMI binding
|
Option |
Optional |
Description |
|---|---|---|
| name | Yes | The name for this binding. |
| uri | Yes | The URI of the RMI service. |
| host | Yes | The name of the host on which the RMI service is running. |
| port | Yes | The port number on which the RMI service is running. |
| serviceName | Yes | The name of the RMI service to connect to. |
| requires | Yes | Any required intents for this binding. Not currently supported in Tuscany. |
| policySets | Yes | Any policy sets for this binding. Not currently supported in Tuscany. |
The location of the RMI service can be specified in one of two main ways. It can be specified using the uri attribute of <binding.rmi>, as shown here:
<service name="CurrencyConverter">
<interface.java interface=
"com.tuscanyscatours.currencyconverter.CurrencyConverter" />
<tuscany:binding.rmi
uri="rmi://localhost:8099/CurrencyConverterRMI"/>
</service>
Or it can be specified using the host, port, and serviceName attributes of <binding. rmi> as follows:
<service name="CurrencyConverter">
<interface.java interface=
"com.tuscanyscatours.currencyconverter.CurrencyConverter" />
<tuscany:binding.rmi
host="localhost" port="8099"
serviceName="CurrencyConverterRMI"/>
</service>
These two <binding.rmi> definitions can be used interchangeably because they both specify the same location for the RMI service.
You now know how to use the RMI binding to expose services as RMI services and how to invoke RMI services using references. Let’s look at the SCA JMS binding next.
7.7. Connecting component services with JMS
So far we’ve concentrated on technologies where a request is sent and a response is received. SCA also defines bindings for message-oriented technologies like JMS, where the protocol’s interaction pattern is designed to be asynchronous. Feel free to read this section later if you’re currently not planning to use JMS in your SCA applications.
The Java Message Service (JMS) API allows Java applications to send and receive messages. It allows applications to communicate using asynchronous messages containing business events or data.
The beauty of using SCA is that the JMS binding, binding.jms, is applied to composite applications in the same way as any other binding. Without SCA and Tuscany, the Java language-specific JMS API is used directly from your Java programs to place messages onto queues and retrieve messages from queues. When using Tuscany, it’s not necessary to use the JMS API. The addition of the <binding.jms> element to a component’s services and/ or references is sufficient to enable asynchronous, message-based communication.
The JMS API provides numerous configuration options, and, as you shall see later in this section, binding.jms offers many of these options. But let’s start by looking at using binding.jms on a component service.
7.7.1. Exposing an SCA service using JMS
In this section we’ll show how the currency converter component from section 7.2.1 can be exposed as a JMS service using the SCA JMS binding and access it using a JMS client.
This will involve adding the <binding.jms> element to the service element of the composite XML file.
Using the SCA JMS Binding on a Service
Let’s see how the JMS binding can be used to make services of the currency converter available to others. To do this, we’ll add the JMS binding to the <service> element of the currency converter composite XML file. The code for this can be found in the contributions/currency-jms directory of the SCA Tours application and is shown here.
Listing 7.21. Currency converter component with JMS binding added
Listing 7.21 shows how the currency converter component would look with the addition of the JMS binding . Unlike many of the other SCA service bindings, you’ll need to specify some configuration options to configure the JMS binding.
You’ll need to specify the class name of the JMS initial context factory that’s used to look up the JMS message broker and
the URL of the JNDI service that holds the JMS message broker objects. Tuscany uses Apache ActiveMQ (http://activemq.apache.org/) as the JMS message broker. Finally, you’ll need to configure the request queue that’s used to receive JMS messages and the
response queue that’s used to return response messages to the caller.
Accessing the Currency Converter SCA Service Using a JMS Client
You can send messages to the currency converter service through a JMS client that looks like the following listing. The code for the JMS client can be found in the clients/currency-converter-jms directory of the SCA Tours application.
Listing 7.22. Fragment of the currency converter JMS client
In listing 7.22, you first started the ActiveMQ session by calling the startActiveMQ-Session method (not shown) that connects to the JMS message broker and creates the request and response queues using the same queue names that you specified on the JMS binding on the currency converter.
The next step would be to create the JMS message body that contains the parameters for the convert request. When the default wire format is used for the JMS binding, XML is used to encode the request details in the message
body of the JMS message. Here you use Apache Axis Object Model (AXIOM) (http://ws.apache.org/commons/axiom/) for mapping objects to XML. You’ll first need to create an OMElement to represent the convert request, with the XML namespace matching the namespace of the currency converter. Next, you’ll need to add the parameters
for the convert request by adding a child OMElement (named arg0 arg1, arg2, ...) to the request for each parameter. To save duplicating the same code for each parameter, you’ll use the createArg helper method to add the parameters.
Now that you have the JMS message body, you’ll need to create the JMS message. SCA can use JMS text messages to send requests, so you’ll create a JMS text message that specifies the operation that you want to invoke (in this case convert) and attaches the message payload containing the parameters as XML from the OMElement request you created earlier.
AXIOM is an Apache project that provides an XML Infoset-compliant object model that can be used to convert Java objects into XML and back. It provides an API that allows primitive and complex object types to be converted and expressed as an XML Infoset. It can also perform the reverse conversion and convert an XML Infoset back into primitive and complex object types.
Your convert request has now been packaged as a JMS message and is ready to be sent to the currency converter service for processing.
This is done by using the producer to send the JMS message .
At this point, you’ll wait for the JMS message broker to deliver your JMS message to the Email Gateway component and for it
to reply with another JMS message. You’ll receive the JMS reply using the message consumer . The response will be in the form of more XML, so you’ll need to parse the returned XML to retrieve the return value before
you can display it on the console.
Before we run the currency converter JMS client, we’ll need to start the currency converter JMS server by using the launcher in the launchers/currency-converter-jms directory. When it is run, it will produce the following output:
ActiveMQ null JMS Message Broker (localhost) is starting
Starting node: currency-converter-jms.composite
JMS service 'CurrencyConverter' listening on destination RequestQueue
Node started - Press enter to shutdown.
The JMS client can be found in the clients/currency-converter-jms directory. When it is run, it produces the following output:
100 USD = 50.0GBP
It doesn’t look like much, but the JMS client did send a JMS message to the currency converter and received in reply another JMS message. You can verify this by stopping the JMS message broker and running the JMS currency converter client again. This time you should get a JMSException.
Now that you’ve mastered the JMS binding on a service, let’s move on to using the JMS binding on a reference.
7.7.2. Accessing a JMS service using the SCA JMS service binding
By using the SCA JMS binding on a reference, an SCA application can interact with JMS services using JMS messages. In this section, we’ll use the Notification service and update it so it can make use of an SMS gateway that exposes a JMS interface. See section 7.2.2 for an overview of the Notification service and SGS gateway.
Connecting an SCA Reference to the SMS Gateway JMS Service
Once again, let’s update the Notification service so that this time it will be able to invoke the SMS gateway using JMS. To do this, you’ll add the <binding.jms> element to the reference. The code for this can be found in the contributions/notification-jms directory of the SCA Tours application and is shown next.
Listing 7.23. SMS gateway reference with SCA JMS binding
<composite name="notification" ...>
<component name="Notification">
<service name="Notification">
...
</service>
<reference name="smsGateway">
<interface.java
interface="com.tuscanyscatours.smsgateway.SMSGateway"/>
<binding.jms
initialContextFactory
="org.apache.activemq.jndi.ActiveMQInitialContextFactory"
jndiURL="tcp://localhost:61619">
<destination name="SMSRequestQueue" create="ifnotexist"/>
<response>
<destination name="SMSResponseQueue" create="ifnotexist"/>
</response>
</binding.jms>
</reference>
</component>
</composite>
Listing 7.23 shows the currency converter composite with the addition of a JMS binding. You have to specify the JMS initial context factory and the URL of the JMS message broker. Finally, the request and response JMS queues are configured. Notice how easy this is compared to the complexities of using JMS in the non-SCA client code shown previously.
Running the Notification Service Connecting to the SMS Gateway JMS Service
Before running the Notification service, you’ll need to ensure that the JMS message broker and the SMS gateway JMS service are running using the launcher in the services/ smsgateway-jms directory of the SCA Tours application. Once it’s running, you can run the Notification service using the launcher in the launchers/notification-jms directory of the SCA Tours application. It will produce the following output on the console:
Quick notification test
Sending SMS to +44(0)7700900812 for accountID 1234
Node started - Press enter to shutdown.
The following output will also be displayed on the console where the SMS gateway was started:
Sending SMS message
From: +44(0)2079460723
To: +44(0)7700900812
Message: Holiday payment taken. Payment of £102.37 accepted...
As you can see from these two outputs, the Notification service has looked up the mobile phone number for account ID 1234 and used the JMS interface of the SMS gateway to send the user an SMS.
We’ve already used some of the configuration options that are available with the JMS binding. Let’s move on and look at them in a little more detail.
7.7.3. Configuration options for the SCA JMS binding
This section outlines the configuration options that are available for the JMS binding. We’ve not included the full schema because the JMS binding has many options, and to describe them all would require a whole chapter in its own right. See the OSOA SCA JMS binding specification for a full description of all the available JMS binding options. It can be downloaded from http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications.
The key elements of the schema for the JMS binding are shown here.
Listing 7.24. Schema for the SCA JSM binding
<binding.jms
name="NCName"
uri="anyURI"
initialContextFactory="anyURI"
jndiURL="anyURI"
...
>
<destination name="xs:anyURI" type="string" create="string">
...
</destination>
...
<response>
<destination name="xs:anyURI" type="string" create="string">
...
</destination>
...
</response>
...
requires="sca:listOfQNames"
policySets="sca:listOfQNames">
</binding.jms>
The JMS binding has the following configuration options, as shown in table 7.4.
Table 7.4. Configuration options for the SCA JMS binding
One of the more useful attributes of the destination and response elements is the create attribute. This is used to specify whether the JMS queues should be created or not when the SCA application is run. The default value is ifnotexist, which means that the JMS queue will be created if it doesn’t exist. It can be set to never, which means that the JMS queue won’t be created but must already exist for the application to run. It could be set to always, which means that the JMS queue will be created and must not exist for the application to run.
Now that you understand how a message-oriented binding can be used in SCA, let’s move on to our next SCA binding, the EJB binding.
7.8. Connecting to EJBs
In this section, we’ll examine how the SCA EJB binding, binding.ejb, can be used to invoke EJBs running on a Java Enterprise Edition server (such as Apache Geronimo) from an SCA application. Feel free to read this section later if you’re currently not planning to use EJBs in your SCA applications.
Enterprise JavaBeans (EJBs) are a server-side technology that provides a componentbased model for implementing business logic. EJBs run in an EJB server that provides a secure and scalable runtime, including infrastructure services such as transactions, data persistence, and so on that are designed to simplify the task of writing business logic.
Outside of SCA, EJB is a Java language—specific technology. Communicating with an EJB involves a protocol based on the Java language—specific RMI protocol we discussed earlier in this chapter. But when using Tuscany and SCA, you can add a <binding.ejb> element to a component reference in the same way that any other binding can be added. In this way you’re able to communicate with EJBs without having to worry about whether it has an EJB home interface (for EJB 2) or not (for EJB 3) or how to narrow remote object references. Let’s look at how binding.ejb is used with services and references.
7.8.1. Exposing an SCA service as an EJB
At the time of writing this book, the EJB binding in Tuscany doesn’t support exposing a service as an EJB. If you need this feature, check the Tuscany website for the latest development information.
7.8.2. Accessing an EJB using the SCA EJB binding
By attaching an SCA EJB binding to a reference, it’s possible to invoke an existing EJB running in a Java Enterprise Edition container from an SCA application. Let’s use the Notification service and add an EJB binding to the SMS gateway reference to access an EJB. See section 7.2.2 for an overview of the Notification service.
The EJB specification defines several types of EJBs, with stateless session beans, stateful session beans, and entity beans being the most common types. The EJB binding specification defines how the binding can be used to connect to stateless and stateful EJB session beans. It doesn’t support invoking EJB entity or message-driven beans.
Connecting an SCA Reference to the SMS Gateway EJB
To connect the Notification service to the SMS gateway EJB service, you need to add an SCA EJB binding to the reference in the Notification component. The code for this can be found in the contributions/notification-ejb directory of the SCA Tours application and is shown in this listing.
Listing 7.25. Notification composite XML with SMS gateway reference EJB binding
In listing 7.25, the SMS gateway reference of the Notification component has been updated to include the EJB binding by adding <binding.ejb> . The uri attribute of the EJB binding is used to specify the location of the EJB. Because in this example the EJB will be run with Apache OpenEJB, in this case we’re using the name of the remote interface of the SMS gateway EJB. If
you’re using a different EJB server, then the format of the uri attribute may be different. See your EJB server documentation for more detail.
Running the SMS Gateway EJB Service
The SMS gateway EJB is a stateless session bean that will simulate sending an SMS message. In order for the SMS gateway EJB service to be run, you need to use a Java Enterprise Edition container and deploy your SMS gateway EJB bean to it. In order to keep the EJB handling simple, you’ll use the Apache OpenEJB Java Enterprise Edition container that can be started in standalone mode. To start the OpenEJB server and deploy your SMS gateway EJB, you can run the launcher in the services/smsgateway-ejb directory of the SCA Tours application. When it’s run, it displays some standard OpenEJB startup messages and then displays the following output:
Publishing SMS Gateway Service as an EJB service
EJB server running - waiting for requests
At this point, the OpenEJB server is running, and the SMS gateway EJB has been deployed and is waiting for requests to process.
Running the Notification Service Connecting to the SMS Gateway EJB Service
Let’s use the EJB launcher from the launchers/notification-ejb directory of the SCA Tours application to run the Notification service. This will connect to the SMS gateway running as an EJB, and you’ll see the following on the console:
Quick notification test
Sending SMS to +44(0)7700900812 for accountID 1234
Node started - Press enter to shutdown.
In addition, the following output will be displayed on the console that started the OpenEJB server containing the SMS gateway EJB:
Sending SMS message
From: +44(0)2079460723
To: +44(0)7700900812
Message: Holiday payment taken. Payment of £102.37 accepted...
As you can see from this output, you’ve successfully invoked the SMS gateway using the SCA EJB binding from an SCA application.
7.8.3. Configuration options for the SCA EJB binding
The EJB binding has several options that can be used to configure it. These are shown in the schema in listing 7.26.
Listing 7.26. Schema for the EJB binding
<binding.ejb
name="NCName"
uri="anyURI"
homeInterface="NCName"
ejb-link-name="NCName"
session-type="stateful or stateless"
ejb-version="EJB2 or EJB3"
requires="listOfQNames"
policySets="listOfQNames">
<binding.ejb/>
The EJB binding has the following options, as shown in table 7.5.
Table 7.5. Options for the SCA EJB binding
|
Option |
Optional |
Description |
|---|---|---|
| name | Yes | The name for this binding. |
| uri | Yes | For services, the URI where the EJB should be published. For references, the URI of the EJB to connect to. |
| homeInterface | Yes | The EJB2 home interface. Not used for EJB3. |
| ejb-link-name | Yes | Used to link to an EJB in the same Java Enterprise Edition EAR. |
| session-type | Yes | Used to specify whether the session bean is stateless or stateful. If not specified, it will be deduced from the EJB interface. |
| ejb-version | Yes | EJB2 or EJB3. |
| requires | Yes | Any required intents for this binding. |
| policySets | Yes | Any policy sets for this binding. |
See the OSOA SCA EJB session bean binding specification for a more detailed description of all the options for the EJB binding. It can be downloaded from http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications.
This concludes our tour of some of the SCA bindings supported by Tuscany. Let’s move on and wrap up what you’ve learned in this chapter.
7.9. Summary
In this chapter, you’ve seen how, by using SCA bindings, you can expose an SCA service and access external services using a variety of communication protocols. Whether you want to interact with web services, CORBA services, RMI services, JMS, or EJB, there’s a binding that will help you.
The key point to take away from this chapter is that you’ve been able to add one or more SCA bindings without changing the component implementation code. The binding approach provides a clean separation between the application logic contained with the component implementation and the communication protocols used to wire them together.
At this point, it’s a good time to shift our focus toward the exciting world of web clients and Web 2.0 to see what Tuscany and SCA offer. You’ll find a few more webrelated bindings lurking among the information in the next chapter.