- Updating the core Carbon platform
- Tightening up the significant additions that went into ESB 2.0
The first major enhancement I want to talk about is the transaction support that we built into ESB 2.0. Transactions are a very interesting subject, especially in the context of an SOA. I think there is a huge misunderstanding of the benefits and disadvantages of transactions in many people (obviously I don't mean you (: ). One of the disadvantages is that ACID transactionality doesn't work well in widely distributed request-response systems. However, there is a specific pattern of transactions that is very valuable in an ESB. You have to think of this as a message-based system, so even if there is a request-response interaction going on, you consider each interaction as asynchronous and separate. In this model, the message can come into the ESB over a transactional queue, and possibly leave over another transactional queue. And all the operations the ESB performs locally can be part of that transaction. For example, you might update several database and then continue. This model still doesn't imply any end-to-end transaction. But it does mean that the message is only forwarded if everything in the ESB space has continued correctly. This is the model that we added to Synapse and the WSO2 ESB in the last release. One of the design decisions that we took with Synapse was to not encumber the core processing model with transactions, but to allow it to be layered on. This means that the core engine is screamingly fast, but still allows full transactions to be enabled.
The second major enhancement I want to talk about is the event-based architecture support we added into the ESB. In the 2.1 release we have done significant performance and hardening of this. It is based loosely on WS-Eventing, but in fact, like everything in the ESB, it is completely multi-format and multi-transport. Effectively this allows the ESB to be a pub-sub broker where the subscribers can use a variety of transports and formats.
The third major enhancement that came in 2.0 was the significant improvement to the UI and the range of things that can be configured via it. This included full control of transports, role and group based authentication and authorization configuration, and much better sequence and proxy editors.
In addition we have now started supporting the Drools/Rules mediator, which means that it is very easy to add rule-based mediation into your ESB flows. We plan a lot more Rule-based integration into Carbon over the next few months.
There are a host of other improvements and additions but I think its a good time to talk about the Carbon improvements now.
What does Carbon really bring to the ESB? It brings the ability to plug in other components like BPEL (Business Process Server), Registry/Governance, Service Hosting (WSAS), and more. But how do you install those? In the last Carbon release, these were simply ZIP files you had to download and dump into the right place. But the big Carbon change we have done is to add support for p2 provisioning. p2 is the Eclipse Update manager, recast as a core part of the Equinox OSGi stack. This means that we now have a well defined set of features, with a feature repository, and the command-line p2 tools to install and uninstall them into any Carbon-based product.
Congratulations to the whole Carbon team on this release and kudos to the ESB team for the great product they've built. Download it now - and let us know how we can make it even better!
No comments:
Post a Comment