The service framework in Mule has always existed for building integration solutions. The design is simple and highly scalable: 1) messages flow in on a channel to an inbound endpoint, 2) transformations and filters are applied (if necessary), 3) the service component processes the messages and, finally, 4) the outbound router sends them on their way to the desired outbound endpoint (again, applying any transformations or filters as necessary). Using this basic concept, many integration patterns can be solved, and since it is based on a SEDA architecture, when processing is asynchronous, Mule ensures high performance and scalability.
In the first part of this post we show how to start an Activiti process from Mule ESB using the new Mule’s activiti module. In this part we are going to show how to call a Web Service from Activiti that is going to be contained in Mule. Notice that you can expose anything as a Web service in Mule such as: beans, queues, etc.
First of all we need to create our proces. It will receive a request containing the username that has requested the image and the image name. The process will work as follows: check if the image needs copyright; if it needs copyright then allow the owner to approve or disapprove the request. If the request is approved, then charge the requester otherwise cancel it. In case that the image doesn’t need approval, just charge the requester with the cost.
How much time do you invest in estimating your backlog? Do you really get any value from it? When was the last time you thought about the value it provides you? I can see estimation as a source of problems in many ways.
We are pleased to announce Mule 3 Activiti support. We’re very happy to be working with the Activiti team and see a lot of value for our community using Mule and Activiti together. I already discussed why BPM and ESB need to work together and two different uses of ESBs with BPM. Today I am going to present a real world example.
My example application uses Mule ESB and Activiti allowing users to view low-resolution images and request a high-resolution version that needs to be approved by a human participant (similar to Stock.XCHNG). Mule will handle the creation of the Activiti process and will take care of exposing it as a service. Activiti will take care of orchestrating the process that requires a user task (approval).
Mule 3 has been out since mid-September. Our developers have been working furiously to refine the new features in successive point releases. Testing and refactoring almost never stop here.
In the middle of all this activity, the ESB team has undertaken major improvements to our documentation. Last week, you might have noticed the appearance of a few topics based on a new template for module and transport reference docs.
We’ve added a huge amount of information to each topic, with the goal of providing a complete source of reference on a single page for each of the objects that constitutes the essential features of the Mule ESB.
For example, consider the following two files:
- Take a look at the previous version of the Previous SMTP Transport.
- Now check out the newly updated SMTP Transport Reference.
I’m not a wagering man, but anyone who says these new topics aren’t more useful than the old is welcome to my long out-of-print Lives of Famous Reference Librarians.
More on the Way
There is no denying it, the cloud is having a massive impact on all our lives. In the enterprise many of the applications that we to host in our own data centers now live in the cloud. We are a fairly typical company in terms of our IT, we don’t host any business software in house. We use Google Apps, Salesforce, Intaact, Marketo, and more. We do it because it is convenient, quickly and usually painless. This instant app-gratification that SaaS and cloud provides is inviting us to make the same mistakes again; we’re putting our data in silos.
One of the enterprise integration patterns that Mule hasn’t explicitly supported up until now is the “Content Enricher”. Enrichment has of course been possible but it hasn’t been as easy as it should have been. That’s changing for Mule 3.1 as we introduce support for message enrichment. Read on to learn what you can do with the new enricher and see some examples..
On my previous post about Kanban, I presented the challenges we had in our Engineering team. They were:
1. Uncontrolled growth of Work In Progress.
2. Not Enough visibility.
3. Reduced quality.
4. Inability to properly estimate all tasks upfront.
5. Planned features and improvements are hard to manage and implement.
During the implementation of Kanban we focused on solving those problems.
Being able to publish and subscribe to event streams is a powerful enabler for business activities. As business rules change and systems evolve, the low coupling that is inherent to this integration pattern allows an IT landscape to evolve gracefully.
Imagine, for example, that you need to perform several independent actions whenever a user signs-up to your site (like: create an account, register to a marketing mailing list, warm-up caches…). A good design would be to have these different actions performed by different systems acting upon receiving their marching order from a central place where “new user sign-up” events would be published to.
Messaging systems used to be found only in big enterprises or in the financial sector. Who else needed the reliability and scalability offered by such systems? But times have changed: public web sites have grown to sizes that dwarf some of the most advanced corporate systems. And as these web sites have grown, the need for timely decoupling their subsystems in order to scale has increased to.
This lead an entirely different breed of developers to want messaging systems too. They wanted something simple, fast and proven. And it needed to work with their languages of choice too: PHP, Ruby, Python, anything but the usual suspects of the enterprise world.