It has been a while since I last blogged about the new XMPP transport for Mule ESB. I’ve been making slow progress since then, but I’ve finally arrived at a point where the transport is starting to be useable. I’d like to show that by building a simple jabber client using the XMPP and stdio transports.
The Lean Startups movement has produced several important and successful techniques that can yield benefits to all types of organizations. One of these is continuous deployment — a process in which all code written for an application is immediately deployed into production. The result is a dramatic reduction in the development cycle time and the freeing of individual initiative. You can read about it here as described by Eric Ries.
In a recent post by Loraine Lawson on ITBusinessEdge, an informal survey was cited that referenced a majority of mid-market CIOs who “said they had no current business need for SOA.” I was a little surprised by the headline since MuleSoft continues to see tremendous adoption of our open source Mule ESB and subscriptions of our enterprise version among companies I would describe as mid-market. So, I decided to read further and try to learn more.
Mule community member, author, and consultant Eugene Ciurana recently discussed a technique for extending or modifying the run-time code in Mule without stopping the server, greatly reducing development time for Mule apps.
In our continuous quest to understand developer trends and preferences, we are conducting a short survey. The survey should take around 5 minutes to complete and will help us gain insight into developer trends. We may contact you for a follow-up discussion to get detailed input from you. We will also enter your name into a random drawing for $100 if you provide contact information.
Please retweet/blog or email the survey to your friends and colleagues.
Are you frustrated with how hard it is to build and manage your web applications? Are you looking for a way to automate your webapp release and deployment processes? And for a way to easily manage upgrades and rollbacks to groups of Tomcat servers?
Recently, while working with Canonical, the commercial sponsor of Ubuntu, an opportunity came up for us at MuleSoft to take on open-source community work to improve the Ubuntu Tomcat 6 package. Having spent several years administering the most popular Tomcat Internet Relay Chat channel, I’ve gathered lots of feedback from Tomcat users about what they had difficulty with, and the changes I had to offer turned into implementation work.
A part of the work we are doing on Mule 3 is to clean up and simplify the existing design. One thing I recently started working on is untangling the relationship between MuleMessage and MessageAdapter and review the use of message adapters throughout the code base.
The current design around these two is somewhat awkward: MuleMessage extends MessageAdapter. I consider this to be the exposure of an implementation detail rather than a good design choice.
Your application infrastructure should never get in the way of delivering the web applications. Cloud computing has been gaining rapid adoption with developers and IT organizations alike, as it is often the easiest way to provision infrastructure for delivering applications.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.