Service Engines are pluggable components which connect to the Normalized Message Router (NMR) to perform business logic for clients. Binding components are also standard JSR 208 components that plug in to NMR and provide transport independence to NMR and Service Engines. The role of binding components is to isolate communication protocols from JBI container so that Service Engines are completely decoupled from the communication infrastructure. For example, BPEL Service Engine can receive requests to initiate BPEL process while reading files on the local file system. It can receive these requests from SOAP messages, from a JMS message, or from any of the other binding components installed into JBI container.
Binding Component is a JSR 208 component that provides protocol independent transport services to other JBI components.
The following figure shows how binding components fit into the JBI Container architecture:
In this figure, we can see that the role of BC is to send and receive messages both internally and externally from Normalized Message Router using protocols, specific to the binding component. We can also see that any number of binding components can be installed into the JBI container. This figure shows that like Service Engines (SE), binding components do not communicate directly with other binding components or with Service Engines. All communication between individual binding components and between binding components and Service Engines is performed via sending standard messages through the Normalized Message Router.
NetBeans Support for Binding Components
The following table lists which binding components are installed into the JBI container with NetBeans 5.5 and NetBeans 6.0:
<!--[if gte mso 9]>
<!--[if gte mso 10]>
As is the case with Service Engines, binding components can be managed within the NetBeans IDE. The list of Binding Components installed into the JBI container can be displayed by expanding the Servers | Sun Java System Application Server 9 | JBI | Binding Components node within the Services explorer.
The lifecycle of binding components can be managed by right-clicking on a binding component and selecting a lifecycle process—Start, Stop, Shutdown, or Uninstall.
The properties of an individual binding component can also be obtained by selecting the Properties menu option from the context menu as shown in the following figure.
Now that we've discussed what binding components are, and how they communicate both internally and externally to the Normalized Message Router, let's take a closer look at some of the more common binding components and how they are accessed and managed from within the NetBeans IDE.
File Binding Component
The file binding component provides a communications mechanism for JBI components to interact with the file system. It can act as both a Provider by checking for new files to process, or as a Consumer by outputting files for other processes or components.
The figure above shows the file binding component acting as a Provider of messages. In this scenario, a message has been sent to the JBI container, and picked up by a protocol-specific binding component (for example, a SOAP message has been received). A JBI Process then occurs within the JBI container which may include routing the message between many different binding components and Service Engines depending upon the process. Finally, after the JBI Process has completed, the results of the process are sent to File Binding Component which writes out the result to a file.
The figure above shows the file binding component acting as a Consumer of messages. In this situation, the File Binding Component is periodically polling the file system looking for files with a specified filename pattern in a specified directory. When the binding component finds a file that matches its criteria, it reads in the file and starts the JBI Process, which may again cause the input message to be routed between many different binding components and Service Engines. Finally, in this example, the results of the JBI Process are output via a Binding Component.
Of course, it is possible that a binding component can act as both a provider and a consumer within the same JBI process. In this case, the file binding component would be initially responsible for reading an input message from the file system. After any JBI processing has occurred, the file binding component would then write out the results of the process to a file.
Within the NetBeans Enterprise Pack, the entire set of properties for the file binding component can be edited within the Properties window. The properties for the binding component are displayed when either the input or output messages are selected from the WSDL in a composite application as shown in the following figure.
The entire set of properties that are configurable for an instance of a file binding component is shown in the next screenshot. You probably won't need all of the properties within your applications, so we've described some common properties that you will probably need to access in applications where you use file binding components.
- fileName: Specifies the input or output filename (depending on whether the binding component is acting as a consumer or a provider). If the fileNameIsPattern property is set to true, the markers %d, %u and %t can be specified within the filename to represent numbers, uuid's, and date and times respectively. These file patterns act differently when the file binding component is being used in a consumer or provider capacity.
Replaced by sequential integer starting at 0.
Replaced by a generated UUID
Replaced by current timestamp (yyyyMMdd-HH-mm-ss-SSS)
- pollingInterval: Specifies the time in milliseconds between polling the file system when acting as a consumer. The default time is always set to 1s.
- multipleRecordsPerFile: When acting as a consumer, the property specifies whether there are multiple messages in the input file. When acting as a provider, this property specifies whether multiple output messages will be stored within the output file by appending messages to the output file every time they are generated.
- archive: Specifies whether input messages are archived to the archiveDirectory after being processed.
SMTP Binding Component
The SMTP Binding Component provides email services to the JBI Server and can act as either a provider by receiving inbound SMTP messages or as a consumer by sending SMTP email to external email addresses.
Neither NetBeans Enterprise Pack 5.5 nor the NetBeans 6 SOA pack provide inbuilt support for the SMTP binding component. This support can be downloaded from the OpenESB project website (http://open-esb.dev.java.net/Downloads.html).
To add support for the SMTP binding component, the following packages need to be downloaded:
- smtpbc.jar: The actual SMTP binding component.
- org-netbeans-modules-wsdlextensions-smtp.nbm: NetBeans Module Support allowing SMTP binding editing for WSDL files.
- javax-mail.nbm: NetBeans Modules Support for email.
Smtpbc.jar can be downloaded from the Components section of the OpenESB project website, whereas the NetBeans modules can be downloaded from the Developer Tools section.
Install the binding component (smtpbc.jar) into the application server by right-clicking on Servers | Sun Java System Application Server 9 | JBI | Binding Components and selecting the Install New Binding Component menu option.
After installing the SMTP binding component into the application server, we can install developer support into the NetBeans IDE. This is done by installing the two new NetBeans modules (org-netbeans-modules-wsdlextensions-smtp.nbm and javax-mail.nbm) through the NetBeans Update Manager or Plugin Manager. This developer support allows SMTP to be chosen as the Binding Type for WSDL bindings.
When the binding component is acting as a Provider, standard properties (such as who the message is from, who it is addressed to, the subject and body of the message) can be read from the message and converted into a WSDL message. This then allows any of these properties to be used within a JBI process. For example, an input message sent via an email could be processed differently depending on who it is addressed to or what the subject of the email is. If the design time support for the binding component is installed into NetBeans (as discussed earlier in this section), then all of these email properties can be edited as part of the WSDL message structure, shown as follows:
If the binding component is acting as a Consumer, it is responsible for sending emails via SMTP. In this situation, the mailto: protocol (RFC 2368) is fully supported. This allows emails to be sent to specified email addresses and also sent to cc and bcc addresses. Support is also provided for SMTP servers that require authentication (in the form of the username and password parameters). SSL Support is also provided (useSSL) for situations where the remote email server requires the secure sockets layer.
When the design time modules for the binding component are installed into NetBeans, then the properties for outgoing SMTP messages can be edited within the WSDL message structure, shown as follows:
FTP Binding Component
The FTP binding component provides FTP transport services to the JBI container allowing messages to be received and sent via the FTP protocol. The component can act as a consumer or a provider and supports the FTP protocol as described by RFC 959.
When the binding component is acting as a consumer, it functions in a similar fashion to the file binding component in that it polls periodically for files based upon a given file name or file name pattern. The difference however, is that the FTP binding component polls specified FTP sites rather than the local file system. After a file is polled by the binding component, the contents of the file are routed as a standard message into the JBI framework. These inbound messages are then routed via the Normalized Message Router to other binding components and/or Service Engines as defined by the JBI process.
The binding component can also act as a provider and in this instance it is responsible for routing JBI messages to a specified FTP address. Depending upon the complexity of your JBI process, the FTP binding component can act as both a consumer and provider all within the same service assembly.
If you are running your SOA application behind a firewall, the FTP binding component can be configured to use a proxy server to allow access outside the firewall. The binding component supports SOCKS4 and SOCKS5 proxy servers. The proxy server support for the binding component is defined at a global level against the binding component itself, rather than defined within the WSDL bindings within a service assembly. The proxy is configured within NetBeans by setting the Proxy URL, Proxy User ID, and Proxy User Password properties on the binding component.
In addition to setting the proxy details, you can specify the maximum number of simultaneous threads the binding component can use. This can be done by using the Outbound Threads Number property. The default value for the number of threads is 10, but you will need to configure this value depending on the number of users accessing your SOA application, and the number of times that the FTP binding component is called.
Neither the FTP binding component nor the support for FTP binding within the WSDL editor is provided, by default, within the NetBeans 5.5 Enterprise Pack, or NetBeans 6 SOA pack. To add support for these components, the following files need to be downloaded from the OpenESB project website and installed in the same way that we installed the SMTP binding component earlier in this article (that is, to install the binding component into the application server and to install the FTP Binding support into the WSDL editor as a NetBeans plugin).
- ftpbc.jar: The actual FTP Binding Component.
- org-netbeans-modules-wsdlextensions-ftp.nbm: NetBeans Module Support allowing FTP binding editing for WSDL files.
Once we have installed these components into the Application Server and the NetBeans IDE, we can start using the FTP Binding Component. Within a service assembly, we can specify the WSDL binding to use the FTP binding component. The properties window within the IDE allows us to modify the properties for the FTP binding, enabling the connection details of the FTP connection to be specified, shown as follows. The url property allows the address of the FTP server to be specified in the standard ftp://username:password@host format. Several other properties are available to control the connection, however, the most common that you will probably need to modify are the dirListStyle and mode properties which allow the host type and connection mode (Binary or ASCII) to be set.
The FTP message properties within a WSDL message are displayed in the IDE properties window by selecting the operation within the WSDL bindings section of the WSDL editor. This property window allows the message properties to be set.
The common properties that you will probably need to set when using the FTP Binding Component are:
- messageRepository: directory name where messages are stored within the FTP server. This base directory must have an additional directory structure underneath it to enable the binding component to perform its processing. The following sub-directories must be available:
/inbox: directory where inbound messages are stored.
/instage: directory where inbound messages are stored before they are fully uploaded to the FTP server.
/inprotect: directory where inbound messages are stored to stop them from being overwritten.
/inarchive: directory where inbound messages are stored after they have been processed.
/outbox: directory where outbound messages are stored.
/outstage: directory where outbound messages are stored before they are fully uploaded to the FTP server.
/outprotect: directory where outbound messages are stored to stop them from being overwritten.
/outarchive: directory where outbound messages are stored after they have been processed.
- messageName: The name of the message file created within the messageRepository. Inbound messages are prefixed by the value held in the messageNamePrefixIB property, whilst outbound messages are prefixed by the value held in the messageNamePrefixOB directory.
- pollIntervalMillis: The time between polls of the FTP server in milliseconds.
- archive: Boolean indicating whether messages are archived or removed after being processed.
- protect: Boolean indicating whether existing messages are moved to a protected area before the current message is processed hence stopping the existing message from being overwritten.
SOAP Binding Component
The SOAP binding component (also known as the HTTP binding component) allows JBI messages to be sent and received using SOAP over HTTP and HTTPS. The component supports RPC Literal, RPC Encoded, and Document Literal encoding schemes.
The component can act as a consumer providing HTTP SOAP 1.1 Services externally. This is achieved by using the embedded Grizzly HTTP connector.
The component can also act as a provider and in this situation is capable of invoking external web services. The WSDL Editor within NetBeans provides support for editing the WSDL bindings and allows the address of remote SOAP servers to be specified.
In situations where the JBI container is running inside a firewall, the SOAP binding component can be configured to use a proxy server to enable remote web services outside the firewall to be accessed.
Many of the properties of the SOAP binding component are global to all service assemblies within the JBI container that make use of the binding component. NetBeans provides support for editing these properties directly within the IDE.
The most common properties that you will probably need to configure in your applications are:
- Default HTTP Port Number: The port number for inbound SOAP requests when the binding component is acting as a consumer of SOAP requests. The default port is 9080.
- Default HTTPS Port Number: The port number for inbound SOAP requests when HTTPS is being used as the transport mechanism instead of HTTP. The default port is 9181.
- Non proxy hosts: This is a pipe | separated list that contains all the hosts that will be contacted directly instead of through a proxy server if a proxy is enabled.
- Proxy Host: The specifies the name of the proxy server for outbound SOAP requests. If the proxy server requires authentication, then the Proxy user name and Proxy user password properties can be specified. The port number of the proxy server can be specified using the Proxy port property.
JDBC Binding Component
In some situations, you will find that you need to interact with a database as part of your JBI applications. When interacting with the database, we can use the SQL Service Engine. Alternatively, if you have more limited database needs, you can use the JDBC binding component.
The JDBC binding component can act as a provider or a consumer. When acting as a provider, the component can issue these different DML commands to the database either to select information from the database or to change data:
When acting as a consumer, the component can poll specified tables on the database to find newly inserted data. When new data is identified by the component, this data can be routed into the JBI framework as a standard WSDL message to other components. The JDBC Binding Component can connect to any database that conforms to the JDBC 3.0 specification and can be accessed via a JNDI datasource lookup.
The JDBC Binding Component is not supplied with the NetBeans 5.5 Enterprise Pack or with the NetBeans 6.0 SOA pack, and must be downloaded separately from the Open ESB project (http://open-esb.dev.java.net/Downloads.html). Similarly, WSDL editor support can be downloaded from the open ESB project website. To fully support the JDBC Binding Component, the following files must be downloaded:
- jdbcbc.jar: The actual JDBC binding component.
- org-netbeans-modules-wsdlextensions-jdbc.nbm: NetBeans Module support allowing JDBC binding editing for WSDL files.
These additional components can be installed into NetBeans in the same way we installed the SMTP binding component and WSDL support earlier in this article.
After installing the WSDL extensions for the JDBC Binding Component, you will find that visual editing is provided within NetBeans for both consumer and provider instances. The properties of the WSDL binding can be seen in the following figure:
The WSDL editor provides support for editing the different properties that can be specified for the binding component. The major properties that you will probably need to edit when using this component are described as follows:
- operationType: specifies what operation the binding component is performing—poll, insert, update, find, or delete.
- sql: sql that will be executed against the database. If the sql is a select statement, then the numberOfRecords property specifies how many rows are retrieved from the database.
- PollingPostProcessing: After the database has been polled for new records, the binding component can be requested to perform post processing on the rows that have been polled. The PollingPostProcessing property can be set to several different values:
Delete: polled rows are deleted after polling.
MarkColumn: The column specified by the MarkColumnName property on the polled rows will be updated to hold the value specified in the MarkColumnValue property. This property can be checked when the database is polled to ensure the existing data is not continually re-polled.
MoveRow: polled rows of data are moved to the table specified by the MoveRowToTableName property.
CopyRow: polled rows of data are copied to the table specified by the MoveRowToTableName property.
- PollMilliSeconds: time period in milliseconds between individual polls of the database.
- TableName: name of the database table that is being accessed in the binding operation.
JMS Binding Component
The final binding component we are going to discuss in detail is the JMS Binding Component.
The JMS Binding Component allows the JBI container to communicate with JMS message queues and topics. The component can act as a provider and/or as a consumer of JMS messages, and as such can subscribe to a topic and wait for JMS messages, or it can send messages to a predefined Queue or Topic.
A JMS Queue allows messages to be consumed by only one client and is a point to point type of messaging. A JMS Topic allows messages to be consumed by any number of clients and is a publish or subscribe type of messaging.
The binding component can send and receive JMS TextMessage's and MapMessage's.
The NetBeans Enterprise Pack provides design time support for the JMS Binding Component and allows the binding attributes to be defined graphically within the WSDL editor. The connection details of the JMS Message Server can be specified within the service of the WSDL file.
- connectionURL: This property allows the base address of the message server to be specified. This can be in the format mq:// for the Sun Java Message Queue system, or in the more generic jndi:// format where the message queue is obtained via a JNDI lookup. The username and password properties enable the connection details to be specified for the message server.
- connectionFactoryName: If JNDI is being used to look up the message server, then the connectionFactoryName property specifies the JNDI name of the connection factory to use. The initialContextFactory and providerURL properties provide the standard lookup configuration parameters for JNDI lookups. If access to the message server is secured using JAAS, then the securityPrincipal and securityCredential properties can be used to specify the caller.
For a specific JMS operation, it is necessary to specify whether the binding component is connecting to a queue or a topic and whether transaction support is to be used for the connection.
NetBeans provides editor support to enable these properties to be configured:
- destination: name of the queue or topic that the binding component is to receive messages from or send messages to.
- destinationType: indicates whether the destination is a Queue or a Topic
- transaction: specifies whether the JMS conversation will use NoTransactions or whether it will be enrolled in a XATransaction. XA transaction support is only enabled when the binding component is acting as a Consumer and is receiving inbound messages.
Finally, the payload and type of a JMS message can be configured for a given WSDL operation.
- messageType: type of the message being sent or received from the specified Queue or Topic. The messageType can be either TextMessage (for javax.jms.TextMessage type messages) or MapMessage (for javax.jms.MapMessage type messages).
Other Binding Components
Due to the standardized nature of the JBI Framework and JBI components, many other JBI binding components have been written by the developer community, all of which can be deployed to the Sun Java System Application Server or the GlassFish Server. One such source of JBI components can be found in the OpenESB project (https://open-esb.dev.java.net). The OpenESB project provides many different binding components such as:
- CICS Binding Component
- MSMQ Binding Component
- LDAP Binding Component
The full list of binding components available from the OpenESB project can be found at https://open-esb.dev.java.net/Components.html.
In this article, we've explored JBI framework and discussed Binding Components and their role within the JBI Container. We've seen how the Binding Component provides transport and protocol independence for other JBI components. We've seen how this enables the JBI container to provide a highly decoupled framework allowing developers and integrators to build resilient SOA applications.
We continued to discuss the different binding components (namely file, FTP, SOAP, JDBC, JMS and SMTP) that are either installed into the application server with the NetBeans Enterprise pack or can be downloaded directly from the OpenESB project web site. We also discussed that because binding components are developed to a standard set of interfaces, any JBI compliant binding component can be installed into the Application Server.