Page Comparison

...

ESB provides its fundamental services via an event-driven and standards-based messaging engine (the bus). Thanks to ESB, integration architects can exploit the value of messaging without writing code. Developers typically implement an ESB using technologies found in a category of middleware infrastructure products, usually based on recognized standards.

ESBs are ESB is a relatively new concept. The term has only been in common use for the last several years. 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.

The WSO2 ESB is a fast, light-weight and versatile Enterprise Service Bus product released under the Apache License v2.0. Using WSO2 ESB you can filter, transform, route and manipulate SOAP, binary, plain XML, and text messages that pass through your business systems by HTTP, HTTPS, JMS, mail, etc.

Distributed Computing Evolution

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 scales 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.

Image Removed

ESB in Context of SOA

Here is a list of facilities in an ESB runtime that encourage SOA:

• Message routing and distribution. The applications should not have hard-coded destinations for messages or services. The ESB can help in two ways:
  • by supporting virtualization (mapping logical destinations to real destinations) and
  • by supporting event architectures, where the publisher does not need to know about the subscribers.
• Management - The ESB should provide a common set of management capabilities which give a common view of all services and endpoints. This includes:
  • alerting,
  • statistics,
  • audit and
  • logging.
• Excellent support for the Web architecture - ESBs should encourage good use of HTTP and the Web architecture. Support for HTTP proxying and caching.
• XML performance - If an ESB is going to help manage and route XML messages then it has to do it with minimum overhead. It certainly has to be much more scalable and per formant than the applications it talks to. Fundamentally this promotes two key technical requirements:
  • non-blocking IO (meaning that the ESB must not block while waiting for applications to respond) and
  • Streaming XML (meaning that the ESB can send XML through without having to create a large in-memory buffer and fully parse every message).

• Security Control - Managing distributed security is one of the hardest problems in SOA and augmenting application security with a set of central security controls is often an essential component in an enterprise infrastructure.

WSO2 ESB

WSO2 ESB is a fast, light-weight and versatile Enterprise Service Bus product released under the Apache License v2.0. Using WSO2 ESB you can filter, transform, route and manipulate SOAP, binary, plain XML, and text messages that pass through your business systems by HTTP, HTTPS, JMS, mail, etc.

Image Removed

Image Added

What is new in this Release

The WSO2 ESB version 4.0.5 is the successor of version 4.0.3 and has several new features, enhancements and defect fixes included in it as follows:

New Features:

• Mediation library support
• EJB mediator
• MSMQ support
• Cloud connectors - Twitter, LinkedIn, SFDC (experimental)
• XPath 2.0 support (experimental)

• SNMP support

• API versioning support

• Endpoint unification

Enhancements:

• Improved endpoint UI
• REST API UI support for inline sequences
• New deployment synchronizer UI with SVN support
• Improved message stores and processors UI
• Enhanced JSON support

Bug Fixes:

The bug fixes included in this release are both in the base framework as well as the ESB specific components. For more information on the defect fixes, refer to the following pages in WSO2 Oxygen Tank:

• WSO2 ESB 4.5.0 - Fixed ESB-specific Issues
• WSO2 ESB 4.5.0 - Fixed Base Framework Issues

Known Issues

For a list of known issues in the WSO2 ESB 4.0.5, please refer to the following links in WSO2 Oxygen Tank:

• WSO2 ESB 4.0.5 - Known Issues in Components
• WSO2 ESB 4.0.5 - Known Issues in Base Framework

Community Resources

WSO2 is willing to provide you guidance for any technical issues or questions regarding the ESB product. You can communicate with the WSO2 ESB development team directly using the relevant mailing lists mentioned here: http://wso2.org/mail.

WSO2 encourages you to report issues and enhancement requests for WSO2 ESB using the publicJIRA available at https://wso2.org/jira/browse/ESBJAVA. You can also track their resolutions and comment on the progress.

Questions regarding the ESB can also be raised through http://stackoverflow.com. Ensure that you tag the question with appropriate keywords such as WSO2 and ESB so that our team can easily find your questions and provide answers.

For tutorials, articles, Webinars and similar resources, visit the WSO2 Oxygen Tank and search under the Resources menu.

The Application Programing Interface of Apache Synapse is used underneath WSO2 ESB: http://synapse.apache.org/apidocs/index.html. This API is useful when you write advanced custom mediators.

Support Options

WSO2 also offers a variety of development and production support programs, ranging from Web-based support during normal business hours, to premium 24x7 phone support. WSO2 is committed to ensuring that your enterprise middleware deployment is completely supported from evaluation to production. Our unique approach ensures that support leverages the open development methodology and is provided by the very same engineers who build the products. For additional support information please refer to http://wso2.com/support.

Get Involved

WSO2 invites you to contribute by checking out the source from SVN using the following commands. This project uses Subversion to manage its source code. Instructions on Subversion can be found at http://svnbook.red-bean.com.

The WSO2 ESB release 4.5.0 is based on Carbon 4.0.0.

Anonymous Checkout 

The complete source including the Carbon platform can be checked out anonymously from SVN with this command:

$ svn checkout http://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.0.0 wso2carbon

Developer Access 

Everyone can access the Subversion repository via HTTPS, but Committers must checkout via HTTPS. The Carbon framework related source code can be checked out using the following commands.

$ svn checkout https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.0.0 wso2carbon

$ mvn clean install -Dproduct=esb

$ svn commit --username your-username -m "A message"

Access through a Firewall

If you are behind a corporate firewall which is blocking http access to the Subversion repository, you can try the developer connection:

$ svn checkout https://svn.wso2.org/repos/wso2/trunk/carbon carbon

Access through a Proxy

The Subversion client can be configured to access through a proxy.

 1) Specify the proxy to use in the "servers" configuration file in:

• "~/.subversion" directory for Linux/Unix
• "%APPDATA%\Subversion" hidden directory for Windows. (Try "echo %APPDATA%")

2) There are comments in the file explaining what to do. If you don't have this file, get the latest Subversion client and run any command. It will create the configuration directory and template files.

Example : Edit the 'servers' file and add something similar to:

[global]
http-proxy-host = your.proxy.name
http-proxy-port = 3128