New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Apache Synapse Graduates from Incubator, Releases 0.91
Posted by Stefan Tilkov on Jan 08, 2007
Apache Synapse is intended to be the basis of a highly manageable XML-oriented Enterprise Service Bus (ESB) and supports logging, routing, and transforming all kinds of XML messages including XML/HTTP, SOAP, JMS. Also supported are a number of open standards including XSLT, XPath, WS-ReliableMessaging, WS-Security, WS-Policy and WS-Addressing.
According to a blog entry by WSO2 CTO Paul Fremantle, highlights of the release include:
- Content-based routing using XPath 1.0
- Configurable Message logging based on Apache Commons Logging
- Support for XML and SOAP over JMS, tested with Apache ActiveMQ
- Initiation and termination of WS-Reliable Messaging 1.0
- Authentication and Authorization using WS-Security 1.1
- Support for remote configuration via HTTP-based registries
- Extensible using Java and scripting languages, including support for JavaScript, E4X, JRuby, and other scripting languages
InfoQ sat down with Paul Fremantle to ask a few questions about Synapse. As Paul's company, WSO2, is the driving force behind the Open Source Axis2 stack, the first question concerned Synapse's coupling to Axis2:
Synapse is pretty tightly coupled to Axis2. We have tried to keep the dependencies reasonably clean. For example we introduced a concept called the SynapseEnvironment that "stubs" out Axis2. However, we did this mainly to isolate the programmer from having to understand too much about Axis2. Because Axis2 is the only implementation of this interface, it would be hard to estimate how hard it would be to create an alternate implementation. A lot of the function (e.g. WSRM, WSSec, XML/HTTP support) is inherited from Axis2 and other projects like Sandesha and Rampart.
The next question concerned the topologies supported by Synapse.
Obviously the simplest installation is a single process, but there are a number of options to scale into a cloud.
Synapse supports some different ways of intercepting messages. For example, Synapse can be configured as an HTTP proxy, whereby all requests are routed via a Synapse instance. In this model its possible to specify a set of rules that operate on all messages. In effect this is a policy definition (not WS-Policy, just "policy" :-)). In this model there could be any number of Synapse engines interspersed around dealing with messages. This was the driver for our HTTP Registry support - so that a number of engines could be bootstrapped from a remote registry. In this model, Synapse will pick up changes from the registry at a fixed interval and then new messages will automatically use the updated configuration and rules.
In addition we have designed Synapse to be mostly stateless (it has state between a request and reply, but no state beyond a single interaction). The result is that it is very easy to cluster or replicate Synapse across a network.
Intrigued by the mentioning of an "HTTP-based registry", InfoQ asked whether it is a full-blown registry, and whether or not UDDI was supported:
As for registry support, we simply need the capability to "look up" some XML. It might be a synapse configuration directive, a WSDL, an XSLT transform, etc. So we abstracted the concept of a "registry". At the moment the only implementation we have of this is to grab the XML from a URL (you might think of this as a REST Registry). We have an extensible interface for this, so we could support UDDI fairly simply. But at the moment no-one has asked us for that!
Find out more about Apache on the website at http://ws.apache.org/synapse.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
No comments
Watch Thread Reply