I’ve been writing a high-level ‘architectural vision’ document for my current clients. I thought it might be nice to republish bits of it here. This is the section that makes a justification of service oriented architecture based on messaging. Here are some of the resources and conclusions I found when studying SOA...
We will be using Mediation Router to help write a simple integration between a REST endpoint and a resource files on a file system. I’ll be using camel-cxfrs component to expose the REST endpoint and will be using the camel-file component to read a directory on the file system.
Here is a quick guide to setting up a development environment for working on Apache Servicemix projects... You can update some of these versions mentioned in the rundown.
So, how does an API Gateway cater for HATEOAS? A key requirement is not to break it. As in medicine, "first do no harm". Consider what an API Gateway does: It provides external-facing APIs to the public, then translates them to back-end (usually on-premise) API calls. Check out the following JSON returned by a server to the client.
It's pretty straight forward to take a message, use an SI header enricher construct and place the message in the header using a SpEL expression - in fact one for the header key name and one for the payload extraction. The following SI flow demonstrates an example of how to do just that.
Here are some notes on adding Camel exception handling to a JavaDSL route. There are various approaches/options available. These notes cover the important distinctions between approaches...
SoapUI is de-facto number 1 tool for testing SOA services. This article shows how to run SoapUI tests from Ant/Ivy script. It's useful for automated testing of your services.
Although I know that RabbitMQ has the shovel plugin which can bridge between Rabbit instances I've yet not found a good plugin for JMS <-> AMQP forwarding.
The first thing that came to my mind was to utilize a Spring Integration mediation as SI has excellent support for both JMS and Rabbit.
When we try to think about service consumers, the obvious candidates are, of course, other services. Nevertheless there are other software components that interact with services e.g. legacy systems, Non-SOA external systems or reporting databases. The Composite Frontend pattern deals with yet another type of service consumer – the User interface.
When creating webservices a lot of people have objections against using JAXB for binding XML to objects. This may be because of performance reasons, allergy to generated code or simply a philosophical belief that you should not mix document centric services with an object oriented model.
In my current project I'm using Apache Camel for the integration, and I bumped into a significant oops moment while using the camel-servlet component. I found that while I had multiple applications (WAR's) deployed I often started the wrong routes, even though I was hitting the correct endpoint url
As an integration consultant I've worked with registries ranging from overly complex offerings (IBM Websphere Registry and Repository) to time-consuming simple wikis, but I have to say that his solution is arguably the most elegant yet.
In this article we'll look at how you can connect from Scala to RabbitMQ so you can support the AMQP protocol from your applications.
Take a look at the Spring Integration example for creating a project in STS tooling. And then compare to the equivalent Camel example below.
One of Lukasz Budnik's goals was to replace internal JMS queues with AMQP. In this article you'll see how he did it and why he was forced to change from RabbitMQ to Apache Qpid...
WOA does not mean a web in terms of the web-site or a Web Service (let alone the term 'Web Service' is too overloaded). According to Renat Zubairov, WOA is a application architecture for next generation of applications. Applications that are running in new runtime environment (Desktop or Mobile browser).
Oh what's this… an Enterprise Integration Zone?! Now we have a focused place for information on integrating applications and services! Check out what's in store.
Message groups in JMS provide a way to identify a set of related messages. The messages could be related by anything - a customer order number, for example. This article has examples of using message groups with ActiveMQ within Apache Camel.
REST based APIs are generally easier to use and get started with the SOAP based services and usually don't require all kinds of code generation to create the messages and the envelopes. However, one thing that is often missing or overlooked, when creating REST based APIs or services is the documentation part. Let's look at some examples.
If I believe that the ESB is being misused or shouldn't be used, I'd rather lose the support revenue and gain the customer's trust by telling him or her straight.
While trying to figure out how to use a push vs. polling model for timed notifications I discovered a clever hack using temporary queues, x-message-ttl and dead letter exchanges.
The main idea behind this is utilizing a new feature available in 2.8.0, dead-letter exchanges.
For example: OAuth handshakes are geared towards a client application driven by a user, which requires API-enabled authorization missing from many EI applications.
Security and governance are only two of the concerns that come with movement to a Saas-style public cloud. This post discusses another: integration.
JMS providers like ActiveMQ are based on the concept of passing one-directional messages between nodes and brokers asynchronously. A thorough knowledge of the type of messages that can be sent through a JMS middleware can simplify a lot your work in mapping the communication patterns to real code.
You may have found a CLI tool for working with STOMP queues called stompcat, but nothing similar for AMQP brokers. Well, Joe Miller has the solution: AMQPcat. In two easy steps he'll show you how to use it.