Enterprise Integration Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2576 posts at DZone. You can read more from them at their website. View Full User Profile

MuleSoft Launches Enterprise Management Console for Mule ESB

05.12.2010
| 7194 views |
  • submit to reddit

MuleSoft's founding open source product, Mule ESB has 1.5 million downloads to date.  Today, their flagship technology is getting a management and monitoring console (inlcuded with the Mule ESB subscription) with functionality that's only found in the most high-profile, commercial ESBs.  The new Mule Management Console (MMC) provides fine-grained tooling for both operations and development teams.  DZone spoke with two representatives from MuleSoft - Mahau Ma, VP of Marketing, and Mateo Almenta Reca, the Sr. Product Manager for the MMC.  They say that the theme behind the MMC is its ability to monitor and tune not just the Mule ESB instances (service level), but also the individual resource pools (end-point level).  This recent release is a response to the trends they've seen in SOA favoring a bottom-up approach.

"A lot of ESBs come with their own built-in, general purpose monitoring capabilities. ," said Ma.  "We used to leverage the Hyperic monitoring technology for our ESB console; it was called MuleHQ."  However, Ma said that MuleSoft's customers consistently wanted something deeper and more Mule ESB-specific.  This is where the idea for MMC came from. 

Message Flow Monitoring



Ma describes MMC as a "single pane" that provides a central hub for operations and development departments.  The console provides performance and diagnostic data at both design time and runtime.  MMC also lets users tune Mule ESB resources at runtime to optimize performance. 

Memory Usage


Performance Controls
The classic performance data (threads, CPU utilization, memory, etc.) are all visible in the management console at the server and service levels.  It can drill down to a single object or thread and dynamically change the resource allocation.  You can also start, stop, and restart services and endpoints with the MMC's fine-grained resource controls.  These controls are exposed via REST API so that people outside can integrate the controls using RESTful services.  

Developers in Mule ESB have a web-based message flow debugger at their disposal, allowing them to quickly pinpoint and resolve configuration issues by auditing real-time message flows, message payloads, headers, the timing, and more.  If the service flow isn't behaving the way you would expect it to at development time, you can quickly turn on the auditor and figure out what's wrong.

Thread Pools


The Auditor (Full Console Pic)


On the Ops side, there is an intelligent alert system in Mule ESB.  You can define alerts on SLAs, resources, specific payloads, or specific service-level events.  You can also write custom scripts to take certain actions when it detects a specified event.



Endpoints Tab


Is SOA Dead Though?
Ma explains that SOA as an approach is far from dead, but with the economic downturn, organizations have become disillusioned with "big bang" top-down approaches to implementing SOA.  People don't want to spend a lot of money on an enterprise software license and spend 1-2 years rolling out an implementation before you find out if there's going to be any return on the investment, Ma says.  He believes there is also disillusionment over complex, heavyweight governance tools such as big UDDI registries or runtime SOA governance and SLA management suites.  

"Over the last few years, we've seen a huge shift in mentality towards bottom-up approaches."  In this case, Ma says you'd implement an SOA much like an agile adoption, where one department is the guinea pig.  Organizations are more successful when they roll out SOA in a specific application or department and build up their success and prove the ROI.  After that, they can gradually spread the SOA throughout the organization, where it's appropriate and effective.  There's no central group of architects that are defining a bunch of SLAs and static service interactions.  Instead, there are real-time business demands on applications and their various components that an organization needs to quickly react to, and be alerted when there are bottlenecks.  Ma said, "This release was a reaction to what our customers were asking for in that regard."