Topics

Featured in Development

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved.

Featured in Architecture & Design

Will Jones talks about how Habito, the leading digital mortgage broker, benefited from using Haskell, some of the wins and trade-offs that have brought it to where it is today and where it's going next. He also talks about why functional programming is beneficial for large projects, and how it helps especially with migrating the data store.

Featured in AI, ML & Data Engineering

Katharine Jarmul discusses research related to fair-and-private ML algorithms and privacy-preserving models, showing that caring about privacy can help ensure a better model overall and support ethics.

Featured in Culture & Methods

This personal experience report shows that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. Whenever we become aware of the blame game, we should address it! DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital.

Featured in DevOps

Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.

Apache Synapse Graduates from Incubator, Releases 0.91

The Apache Synapse project has been promoted from the Apache Incubator to a full member of the Apache Web Services project. Apache Synapse is a mediation framework for Web Services that allows messages flowing through, into, or out of an organization to be mediated. The Synapse team has just released 0.91 of the project, which can be downloaded from the Apache web site.

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!