WSO2 ESB: The Windows ESB

You might have heard people talking about “Enterprise Service Bus” or ESB. Is this just another over-hyped acronym? What is an ESB exactly? In this article by Michael Galpin, we will learn a little about ESBs and why you would want to use one. More importantly, we will dispel the myth that there are no ESBs available for Windows. In fact we will see that the premier open source ESB from WSO2 is designed to bring the benefits of ESBs to Windows.

Table of Contents

• Pre-requisites
• What is an ESB?
• An ESB for Windows
• Install WSO2 ESB on Windows
• Running WSO2 ESB as a Windows Service
• Monitor WSO2 ESB with Windows Event Log
• Configuring the System
• Configuring WSO2 ESB
• Viewing WSO2 ESB Event Logs
• Customizing the ESB
• Summary
• About the Author

Pre-requisites

In this article we will use WSO2’s ESB, so you will need to download it. It has a few prerequisites, such as a Java development kit (JDK) 1.5.x and Apache Ant if you want to run the samples. In addition we will need Apache log4j to install an optional component for use with Windows. Finally, you will need a Windows NT based version of Windows such as Windows XP, Windows Server 2008 etc.

What is an ESB?

Enterprise Service Bus or ESBs are relatively new beasts. The term has only been in common use for the last three years or so. People often associate ESBs and Service Oriented Architecture (SOAs) but they are somewhat orthogonal concerns. However, like SOA, ESB is essentially a collection of enterprise architecture design patterns that is now implemented directly by many enterprise software products.

ESBs are part of an evolution of distributed computing. Early distributed computing involved pure point-to-point communication between systems. This was the simple, obvious way to create complex applications from distributed components. This is actually a reasonable solution when there are a small number of applications that need to work together. However, the number of point-to-point communications grows proportional to the square of the number of applications in the enterprise. This becomes unmanageable for a large enterprise.

The late 90’s saw the rise of Enterprise Application Integration (EAI) products. These aimed to allow enterprises to scale beyond the limitations caused by point-to-point integration solutions. The typical solution used a hub-and-spoke architecture. This is a solution still in use by many enterprises today. In a hub-and-spoke EAI, all communication is routed through a central hub. The number of point-to-point communications scale linearly with the number of enterprises, so this is a great improvement over point-to-point architectures. However, the hubs become bottlenecks in the system.

ESBs can be thought of as the next step in the logical progression described above. The ESB acts as a message broker to all applications in the enterprise. It allows for more granular, base functions to be exposed with orchestration provided as needed. This greatly improves the flexibility of the system and allows for more rapid and cheaper adaptation to changes. This all sounds great, right? But does such wonderful software really exist and is it available for Windows? The answer to both questions is yes.

An ESB for Windows

There are numerous ESB providers. In particular there is the WSO2 ESB. This is an open source ESB built on time-tested technologies from the Apache organization. What’s even better is that it provides integration into the Widows server environment, making it an attractive choice for Windows based systems. Let’s now look at setting up the WSO2 ESB on Windows.

Install WSO2 ESB on Windows

Installing the WSO2 ESB is straightforward. First, you need to make sure you have installed the prerequisites. The WSO2 ESB uses Java, so you need a Java development kit (JDK) installed. You need to create an environment variable called JAVA_HOME and set its value to the location of your JDK. Next, you need to put Java in your path. The best way to do this is to append %JAVA_HOME%\bin to your current path. Now you are ready to install the WSO2 ESB. To do this, simply expand the WSO2 ESB zip archive. You can create an environment variable for the installation directory of WSO2 ESB called ESB_HOME. It is optional, but we will use it in this article.

To test your installation, go to %ESB_HOME%\bin and run the wso2-esb.bat batch file. This will start the ESB. Open a browser to https://localhost:9444/esb and you should see the WSO2 ESB Management Console as shown in Figure 1.

Figure 1: Management Console

You can login using the default name and password (admin/admin) if you like. This is great for a test, but obviously you don’t want to have to login and run a batch file to run a valuable piece of infrastructure such as the WSO2 ESB. It is much more preferable for it to run as a Windows service.

Running WSO2 ESB as a Windows Service

Stop the instance of WSO2 ESB running for now. In the %ESB_HOME%\bin directory, run the install-wso2-esb-service.bat batch file. This file will install WSO2 ESB as a Windows service. After it is finished running, bring up the Windows Services console. You should see WSO2 Enterprise Service Bus (ESB) listed as shown in Figure 2.

Figure 2: Windows Services

You can edit the service as shown in Figure 3.

Figure 3: WSO2 ESB Service Details

You can start the service from this interface and be able to bring up the Management Console again. Now we have the WSO2 ESB running as a Windows service, so it will start up as soon as our system starts. If you no longer want to run it as a service, you can use %ESB_HOME%\bin\uninstall-wso2-esb-service.bat to remove the service completely. This is just one way that the WSO2 ESB integrates seamlessly in a Windows environment. Now we will look at another integration point via the Windows Event Log.

Monitor WSO2 ESB with Windows Event Log

Take a look at the %ESB_HOME%\logs directory. These are obviously log files created by WSO2 ESB. WSO2 ESB is designed to be cross platform, so of course logging is done through a least common denominator: text files. However it is easy to configure WSO2 ESB to make this much more Windows-friendly, i.e. to send logging information to the Windows Event Log.

Configuring the System

WSO2 ESB is built on numerous battle tested open source projects, and one of those is log4j. This is a highly successful logging library for Java that has even been ported to .NET as log4net. To integrate WSO2 ESB’s logging system with the Windows Event Log, we will need an additional log4j component that is not included with WSO2 ESB by default. All you need to do is download log4j (from http://logging.apache.org/log4j). It is distributed as a zip file, so just unzip it and look for the file called NTEventLoggerAppender.dll.

This DLL serves two purposes. It allows log4j, and thus WSO2 ESB, to publish events to the Event Log. Second, it allows the Windows Event Viewer to properly format the event details. Thus you need to make it available on a location in the Java runtime's 'java.lib.path'. The easiest way to do this is to drop this DLL into the “tomcat\lib” folder.

Configuring WSO2 ESB

To configure WSO2 ESB we simply need to alter it’s logging configuration. It is possible to update this configuration via the administration console easily. After logging into the admin console as user 'admin' and password 'admin', click on the 'Log Settings' tab.

Now replace the line:

log4j.rootCategory=ERROR, LOG_APPENDER, CONSOLE_APPENDER, LOG_MEMORYAPPENDER

with:

log4j.rootCategory=ERROR, LOG_APPENDER, CONSOLE_APPENDER, LOG_MEMORYAPPENDER, EVENT_LOG_APPENDER

And add the following lines at the very bottom, and press 'Save':

# A Windows Event Log that receives all of the general purpose logging sent to LOG_APPENDER
log4j.appender.EVENT_LOG_APPENDER=org.apache.log4j.nt.NTEventLogAppender
log4j.appender.EVENT_LOG_APPENDER.source=WSO2-ESB
log4j.appender.EVENT_LOG_APPENDER.layout=org.apache.log4j.PatternLayout
log4j.appender.EVENT_LOG_APPENDER.layout.ConversionPattern=%d{ISO8601} [%X{ip}-%X{host}] [%t] %5p %c{1} %m%n

The text in green, is where we configure the logging messages that will be sent to the Event Log. We have called this logger EVENT_LOG_APPENDER. You might notice that it is very similar to the LOG_APPENDER defined in the same file. The LOG_APPENDER is the general, multi-purpose logger in WSO2 ESB, so all we have done is create second log whose messages are identical but are sent to the Event Log instead of a file. The Event Log also takes a source attribute. If you are familiar with the Event Viewer, this is the value to be sent to the Source column. As you can see in Listing 1, we have set this to have the value “WSO2-ESB” so we can easily identify the logs from WSO2 ESB.

The section highlighted in blue adds the EVENT_LOG_APPENDER we defined to the list of root loggers used in the system. You could create much more exotic logging configurations, as log4j is extremely flexible and powerful. This will be sufficient for our purposes. We should now be able to view some logging messages sent from WSO2 ESB.

Viewing WSO2 ESB Event Logs

If WSO2 ESB was already started, you should now re-start the service so the new configuration can be picked up. Open up the Event View and you should see something similar to Figure 4.

Figure 5: Event View Showing WSO2 ESB Events

You should see a lot of events with WSO2-ESB in the Source column. You can double click on one of these and you should see something similar to Figure 6.

Figure 6: Event Log Details

Just like that and we have events being published from WSO2 ESB to the Windows Event Log. From here you can configure the Log4J settings to tweak the format of the messages, as well configure which messages are logged. The file above also describes how to create custom log messages for your custom applications that are deployed to WSO2 ESB. So now we can integrate WSO2 ESB within Windows, but what about customizing the ESB? After all, everyone always has their own special needs for any application, and ESBs are no different. Will using WSO2 ESB require you to learn a whole new programming language just to use it? Fortunately the answer is no.

Customizing the ESB

The WSO2 ESB uses a pipeline architecture. Each message sent to the ESB goes through a sequence of mediators. The mediators can common perform tasks like logging, validation, etc. The main way you will customize the ESB is by writing a custom mediator and making it part of a sequence. You can access the sequence configuration via the Management Console as shown in Figure 7.

Figure 7. List of Sequences

By default there are two simple sequences (main and fault). The ESB includes several standard mediators that can be configured, such as log, validate, and filter. Clicking on main you will see these as shown in Figure 8.

Figure 8: The main sequence

Click on the plus symbol to add a new mediator to the sequence as shown in Figure 9.

Figure 9: Adding a New Mediator

Notice that we picked Extension => Script. This allows us to write some code for our new mediator as shown in Figure 10.

Figure 10: Adding a JavaScript Mediator

You can actually reference an external JavaScript file if you like. A function called “mediate” will be used by default, or you can specify a function name to invoke. The function will have a MessageContext object passed into it that can be accessed implicitly as “mc”. The function can modify the MessageContext, and should return either true or false. If it returns false, then processing will halt, otherwise the next mediator in the sequence will be invoked.

Alternatively, you can do as we did in Figure 5 and specify the JavaScript directly inline. Notice the JavaScript syntax used in the example. The JavaScript interpreter used by the WSO2 ESB (Rhino) supports the EcmaScript for XML (E4X) standard that is part of the next generation JavaScript standard. This makes working with XML, and thus SOAP, very easy. In the example shown in Listing 3, we use E4X to parse the incoming message, and transform it to the format that our service is expecting. This is a common usage for custom mediators. There is also a standard mediator, the XSLT mediator, that lets you do the same thing with XSL. Finally, you can also use other scripting languages, such as Ruby and Python, for custom mediators. WSO2 ESB makes it easy to perform the kind of tasks that are commonly needed to customize an ESB.

Summary

An Enterprise Service Bus can dramatically improve the architecture of a large, distributed system. It can make it not only easier to put together such systems, but to maintain. The WSO2 ESB is designed to integrate easily with Windows. It is easy to set it up as a Windows Service and to integrate it with the Windows Event Log. Finally, WSO2 ESB enables easy customization by supporting JavaScript as a language for writing custom mediators. So there is no need to wait until somebody comes out with a “Windows ESB” because one already exists: WSO2 ESB.

About the Author

Michael Galpin has been developing software since 1998. He holds a degree in mathematics from the California Institute of Technology and is an architect at eBay in San Jose, CA.