Synapse is a simple XML and Web services management and integration broker that can form the basis of an SOA and Enterprise Service Bus (ESB). Synapse, which recently graduated from the Apache incubator, is now a full-fledged Apache initiative as part of the Web Services project and is an offshoot of the highly successful Apache Axis2 project. It offers the ability to mediate, manage, and transform XML messages among a variety of different applications.
The Apache Synapse project recently released version 1.0. You can read more about this important release on the Apache Synapse Web site (see Resources for the link).
Turn your existing systems into an SOA platform
Most companies are keen on transforming their existing middleware to an SOA platform, often at great expense. Apache Synapse, a simple, high-quality open source alternative, provides an approach to SOA that can expose existing applications without rewriting any code. The ability to reuse, integrate, manage, and control interactions with your existing applications without changing them makes Synapse an attractive choice and a key approach to an SOA strategy.
The ESB concept is, unfortunately, poorly defined. However, we have a simple, pragmatic definition: Connect, transform, manage.
The ESB model promotes SOA-based integration with service contracts and metadata associated with the service contracts, such as Web Services Description Language (WSDL), schema, or policy. The ESB model (see Figure 1) ensures that every message that goes into the bus ends up in the right place.
Figure 1. Enterprise Service Bus
Take a look at the principles on which Synapse is built.
Synapse is built around XML and Web services standards. Fundamentally, Synapse is based around the idea of messages moving around a network. The messages can be any format, but Synapse molds them into a logical infoset (see Resources for more information) modeled on the SOAP idea of an envelope containing header and body. By using Web services standards, such as WS-ReliableMessaging and WS-Security, you can use Synapse to enable secure, reliable connections between applications. Synapse can offload these types of quality-of-service (QoS) capabilities without modifying existing applications. For example, by placing a Synapse instance directly in front of an existing XML/HTTP service, you can add support for WS-Security. This can add support for digital signatures, which can be important in a B2B environment.
Universal interaction model: HTTP and SOAP
With the advent of the Web, HTTP has become the universal transport of choice. Most enterprises have exposed their services over HTTP due to firewall friendliness, wide availability, acceptance, and the support that HTTP enjoys around the globe. HTTP can be seen in two ways — as a real interaction protocol and as a transport protocol. Those who see HTTP as an interaction protocol follow the REST (see Resources for more information) model and tend to be strict about the semantics of the HTTP verbs (GET, PUT, POST, DELE). HTTP can also be used as a firewall-friendly transport, in which case the usual model is to post XML documents and get XML documents back in response.
SOAP is a universal, transport-independent messaging format. Because of its platform-, transport-, and language-neutral nature, it's being used for many applications ranging from helping eBay PowerSellers manage their shops to sending print jobs across a network. It's also the basis for many higher-level specifications. Used together or separately, the fact is that SOAP and HTTP form a universal interaction model and can connect heterogeneous systems across and within enterprise boundaries.
Although Synapse supports many different transports, including Java™ Message Service (JMS), Mail, XML/HTTP, and SOAP, at the core it uses the SOAP model. What does this mean? Fundamentally it means that there's an internal data structure that mirrors the SOAP envelope. For example, the to and replyTo addresses are modeled on the WS-Addressing spec. As the message flows through the Synapse engine, the message can be transformed to and from various formats, including REST, SOAP, JavaScript Object Notation (JSON), and JMS, with standard mediators. In addition, it can be extended by writing a custom mediator.
XML, without doubt, has been the universal data format in the recent past with wide acceptance and support in virtually every programming language that exists today. This enables heterogeneous applications to pass data using a common data model that's readily understood by any language. In Synapse, our world is all about XML, and the idea is to push XML as far as possible in the network, thereby turning your entire network into a bus. One way of thinking about this is that all the XML interactions across your network form the ESB, and Synapse can be interposed to manage that bus (see Figure 2).
Figure 2. The Apache Synapse ESB model
Synapse can be deployed in a few different ways. The simplest way to deploy Synapse is using the concept of a proxy.
In the proxy model (shown in Figure 3), you explicitly define a new endpoint (proxy) that Synapse listens on. Effectively, this is just like a new service, except that the service logic is implemented by a remote service. In the simplest instantiation of this model, you directly wire the proxy listener to a remote endpoint. However, even in this simple case you can do some useful things. For example, you can switch between XML/HTTP and SOAP and JMS. You can turn on or off protocols, such as WS-Addressing, WS-ReliableMessaging, and WS-Security. And in the 1.0 release of Synapse you can define a set of identical services and load-balance across them.
Figure 3.The proxy model
In this approach, you configure your clients to send all messages to Synapse. For example, Synapse can act as an HTTP proxy. This is handy, because almost every Web client has the ability to configure an HTTP proxy without changing application code. So it's usually trivial to redirect the messages through Synapse. Synapse has a default sequence of actions that applies to any messages that arrive in this way. Techniques like content-based filters (XPath or Regex) can then be used to selectively apply policies to particular messages.
Apache Synapse implements a generic mediation framework. As mentioned earlier, you can specify a sequence of mediations that operates on a message — either based on which endpoint it arrived through or on some filter. The aim of Synapse is to support a useful common set of mediations out of the box. Such built-in mediations include:
- Logging to log4j.
- Modifying headers, including WS-Addressing headers.
- Running scripts, including JavaScript, Groovy, Ruby, and others supported by Bean Scripting Framework (BSF). E4X support allows JavaScript to directly manipulate XML messages without needing to use APIs like DOM. Similar support exists in Ruby as well.
- Enabling and terminating WS-Security and WS-ReliableMessaging.
- Switching between SOAP versions and XML/HTTP.
- XML Schema validation.
- Faulting messages or dropping them.
Figure 4. Mediation engine
Connect, manage, and transform your enterprise services
As illustrated in the previous sections, Synapse can connect, manage, and mediate your services.
As well as operating within the intranet, Synapse can act as a gateway to your enterprise and manage the exposure of services to partners more effectively. The gateway model can include applying authentication and authorization to incoming messages using the Apache Rampart framework to support WS-Security and WS-SecureConversation. By mapping virtual URLs to real URLs inside your network, Synapse enables your enterprise to maintain an uniform addressing scheme to the outside world while hiding the internal infrastructure details. You can use the same model inside your organization to provide a clean, manageable set of bus-level services independent of the actual implementations. A centralized connectivity model also promotes better management of QoS aspects
For example, Synapse can be used to map simple GET HTTP requests into XML/JMS connections to a back end. In this way, legacy resources can be exposed to a much wider range of clients, including Asynchronous JavaScript + XML (Ajax) applications and mobile devices.
Synapse provides a consistent model to administer policy and other aspects of services. By interposing Synapse as an intermediary, you can control aspects like authentication, auditing, logging, or QoS aspects like failover and load balancing. This lets your organization manage resources more efficiently and effectively. All these features can be enabled by configuring a simple XML file without writing any code.
Here are some examples:
- http://stockquote.com?symbol=RHAT can be mapped to a service, deployed as a cluster based on a load balancing strategy, such as round robin. If it's a primary and backup scenario, the failover mediator can map it to the backup server in case the primary server goes down.
- All requests to http://abcbank.com/personal can be authenticated, logged, and randomly logged and marked for auditing.
- Mediators can be applied to http://abcbooks.com/suppliers?category=XXXX to add different policies based on the suppliers category. For example, if category=silver, then the supplier credit limit is 5000; if category=gold, the credit limit can be 10000.
Synapse can transform your legacy applications into state-of-the-art Web services. Synapse can act as a proxy and virtualize the service and application by doing one or more of the following:
- Performing an XSL Transformation (XSLT) to the SOAP message (headers or body)
- Having JavaScript/E4X transformers map XML directly into JavaScript
- Using a plain old Java object (POJO), where you can write Java logic to manipulate the message
- Mapping JSON to XML, where a JSON/HTTP stream can be sent out as a SOAP message, or vice versa
- Performing attachment mediation, where conversions like SOAP with Attachments to Message Transmission Optimization Mechanism (MTOM), Base64 to MTOM, and vice versa are supported.
- Performing your own custom transformation
This provides an opportunity to reuse your existing applications and integrate them to offer improved services with minimum investment. With Synapse at the edges, you can transform your entire network into an ESB, which provides a centralized and consistent way of managing your service offerings.
A case study using Apache Synapse
The following case study illustrates how you could integrate and reuse existing applications using an SOA approach to handle the middleware operations of a credit card payment system.
ABC bank has decided to provide an Internet-based payment gateway. The application needs to accept credit card payment requests online, check for fraud, and then verify the requests with Visa or MasterCard systems. The bank has existing applications that detect fraudulent transactions, an audit system, Short Message Service (SMS) applications, and Visa and MasterCard applications for credit card processing.
You can use Synapse to integrate, manage, control, and transform these existing applications as services using an SOA approach. Some of the simple logic — like initial screening for fraud, content-based routing, and fraud score handling — can be done using script-based mediators that allows reusing the existing applications without the need to rewrite code. If these scripts are pulled from a dynamic registry, then it provides the flexibility of modifying the logic without even restarting Synapse and disrupting the traffic.
As illustrated in the diagram in Figure 5, the request is first screened for the possibility of being a fraudulent transaction using a script mediator. If it's clean, it's sent to either the Visa or MasterCard service, depending on the card type, using a switch mediator. If the fraud screening process determines that it needs to send the transaction through a fraud scoring system. then it's forwarded to the fraud scoring service. The fraud scoring service assigns a fraud score to the transaction. The fraud alert service then determines the course of action using a switch mediator to define deferent logical paths based on the fraud score.
Figure 5. Architecture diagram
As mentioned previously, configuring the logic is as simple as writing an XML file. However, describing the code samples in detail is beyond the scope of this article. I have attached the code samples (see Resources for the synapse.xml link) to illustrate the ease of use, and most of the code is self explanatory if you follow along with the diagram in Figure 5. You can download the complete synapse.xml file using the link provided in the Resources section.
Synapse provides a simple, easy-to-use open-source alternative to rebrand your existing middleware as an SOA platform with minimum cost and effort. Synapse maximizes reuse by mediating or transforming existing services without coding, and it provides a good model to integrate your services into an ESB model.
Learn
- Get a wealth of information about
Apache Synapse, including mailing
lists and extensive documentation.
- Learn more about
infoset.
- Learn more about
REST.
- Read the
Apache Synapse User
Guide.
- Check out the
Synapse presentation at Apache Con Asia 06
and at Apache Con EU 06.
- You can download
synapse.xml
for the use case provided in this article.
- The
SOA and Web services
zone on IBM® developerWorks hosts hundreds of informative articles and
introductory, intermediate, and advanced tutorials on how to develop Web services
applications.
- The
IBM SOA Web site
offers an overview of SOA and how IBM can help you get there.
- Stay current with
developerWorks technical events and webcasts.
- Browse for books on these and other technical
topics at the
Safari bookstore.
- Check out a quick
Web services on demand demo.
Get products and technologies
- Innovate your next
development project with
IBM trial software,
available for download or on DVD.
Discuss
- Participate in the discussion forum.
- Get involved in the developerWorks community
by participating in
developerWorks blogs.

Rajith is a senior software engineer from Red Hat's Emerging Technology team, an open source enthusiast, an active committer on several Apache projects, including Axis2, Qpid, Tuscany, and a contributor on Synapse. He has published several articles and has spoken at several industry conferences and user groups, including ApacheCon, Colorado Software Summit, and Toronto JUG. Rajith is currently focused on building scalable messaging middleware and is a member of the Advanced Message Queuing Protocol (AMQP) working group. Rajith enjoys painting and playing cricket during his free time.

Paul is a cofounder and VP of Technical Sales at WSO2, an open source SOA company. Paul is a member of the Apache Software Foundation and a committer and release manager on the Synapse project. Paul also co-chairs the WS-RX Technical Committee at OASIS, which has completed the WSReliableMessaging 1.1 standard. Before founding WSO2, Paul was a Senior Technical Staff Member at IBM where he created the IBM Web Services Gateway, the Web Services Invocation Framework (WSIF), and WSDL4J. Outside of work, Paul enjoys kayaking, cooking, and playing the tin whistle.
Comments (Undergoing maintenance)





