Warning: A non-numeric value encountered in /home/ricston2/public_html/blogarchive/wp-content/themes/Divi/functions.php on line 5766

From time to time, I see a rather unusual question popping up on the user lists (or in class) which causes me to step back and question my own beliefs. While I do tend to think of some things as being “obvious” (or which should be “common sense”), “obvious” is always relative to your standpoint. In integration work and Mule applications, this depends on your level of expertise – but it may also depend on your language skills (see disclaimer below).

I’m referring to this recent post on the Mule user lists where a Mule developer asked the community to help out with his application which does not seem to work. His intention is to read specific files off an FTP server and place them into a directory but his configuration is setup back-to-front: he’s reading items from the directory and uploading them to the FTP site.

It is not always obvious what a service is supposed to be (or do) in Mule, especially if you come from a completely different background, so here are a few ground rules for people new to Mule:

  1. A service is meant to contain a specific task. If you’re following SOA (service oriented architecture) principles, a service would contain business logic and be part of a business process. If you’re working on a smaller integration project, SOA may not be for you. In such a case, a service may be nothing more than a “placeholder”. In the example posted on the user list, the service is merely acting as a bridge between two different transports.
  2. Anything that the service reads or requires as input should be made available on inbound endpoints. An inbound endpoint pulls data into the service. If your service does something, this is the data it will operate upon. If your service is a bridge, the source data will come from the inbound endpoints.
  3. Anything that the service produces or writes will be sent to the outbound endpoints. An outbound endpoint pushes data to the destination – whether it is by TCP, e-mail, web service call or on to a VM queue. If your service produces a result, this result will be passed along. If your service is a bridge, the original data will be sent along.

Of course, I’m not mentioning transformers, routers and all the other Mule elements to keep this example simple.

PS: By the time you read this blog post, the original poster may have replied pointing out that the config he posted originally was wrong or perhaps there was some other explanation for his post. I have encountered this query a few times before, so this explanation will be useful for a few people.

PPS: My reference to “language skills” is not meant to make fun of anyone. As someone who works in 3 different languages, I know that certain things cannot be easily explained in English – and that some others, when translated literally, can end up meaning the opposite.