Archive for the ‘Enterprise Service Bus (ESB)’ Category

Super Simple Data Integration with RESTx: An Example

Sunday, October 2nd, 2011

Super Simple Data Integration with RESTx: An Example

From the webpage:

Most people who ever worked in real-world data integration projects agree that at some point custom code becomes necessary. Pre-fabricated connectors, filter and pipeline logic can only go so far. And to top it off, using those pre-fabricated integration logic components often becomes cumbersome for anything but the most trivial data integration and processing tasks.

With RESTx – a platform for the rapid creation of RESTful web services – we recognize that custom code will always remain part of serious data integration tasks. As developers, we already know about a concise, standardized and very well defined way to express what we want: The programming languages we use every day! Why should we have to deal with complex, unfamiliar configuration files or UI tools that still restrict us in what we can do, if it is often so much more concise and simple to just write down in code what you want to have done?

Therefore, RESTx embraces custom code: Writing it and expressing your data integration logic with it is made as simple as possible.

Let me illustrate how straight forward it is to integrate data resources using just a few lines of clear, easy to read code.

In my experience “custom code” means “undocumented code.” But leaving that mis-giving to one side.

RESTx gets us part way to the TMDM by its use of URIs.

We just have to use them as appropriate to create TMDM output for further integration with existing resources. That is we have to decide which of these URIs are subjectIdentifiers and which function as subjectLocators as part of our integration activity.

I have just started to wander around the Mule site. Feel free to suggest examples or places I need to look at sooner than others. Examples of RESTx output as topic maps would be nice! Hint, hint.

PS: I’m got a small data set I need to clean up for a post next week but I am also planning a post on URIs, simple or complex identification?

Mule ESB

Sunday, October 2nd, 2011

Mule ESB

The Mule ESB has an amusing stat line that reads: “103,000+ developers use Mule 3,200 Companies in Production 0 Headaches”

I don’t know if I believe the headache stat but if the other two are even approximately correct, this sounds like a place to be pushing topic maps.

To get the flavor of the community:

From “What is Mule ESB?

What is Mule ESB?

Mule ESB is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily, enabling them to exchange data. Mule ESB enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMS, Web Services, JDBC, HTTP, and more.

The key advantage of an ESB is that it allows different applications to communicate with each other by acting as a transit system for carrying data between applications within your enterprise or across the Internet. Mule ESB includes powerful capabilities that include:

  • Service creation and hosting — expose and host reusable services, using Mule ESB as a lightweight service container
  • Service mediation — shield services from message formats and protocols, separate business logic from messaging, and enable location-independent service calls
  • Message routing — route, filter, aggregate, and re-sequence messages based on content and rules
  • Data transformation — exchange data across varying formats and transport protocols

(graphic omitted)

Do I need an ESB?

Mule and other ESBs offer real value in scenarios where there are at least a few integration points or at least 3 applications to integrate. They are also well suited to scenarios where loose coupling, scalability and robustness are required.

Below is a quick ESB selection checklist. To read a much more comprehensive take on when to select an ESB, read this article written by MuleSoft founder and CTO Ross Mason: To ESB or not to ESB.

  1. Are you integrating 3 or more applications/services?
  2. Will you need to plug in more applications in the future?
  3. Do you need to use more than one type of communication protocol?
  4. Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing?
  5. Do you need to publish services for consumption by other applications?

I am exploring the Mule site and entries for data integration in particular for those that may be of interest to topic mappers. More anon.