There is an interesting post by Anne Thomas Maines from Burton Group exclaiming that SOA has gone the way of the Dodo:
Once thought to be the savior of IT, SOA instead turned into a great failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever.
Of course the part we all want dead is the vague, hand-wavy, SOA hype. Those that bought into proprietary-SOA and its heavy-handed, “big bang” approach lost out and everyone else got sick of fuzzy SOA promises. But behind any hype in the enterprise space you can find good ideas. The fact is that the ideas behind SOA are as important to us (the distributed masses) as Object Orientation was to the development of complex applications. The difference is that OO required that a single developer to think differently, SOA requires a whole organization of people to think differently-
With so many integration points and applications of Mule, troubleshooting issues can be a daunting task for those just starting out with Mule. This post will provide a few tips on how to get to the root of issues you may encounter.
In this episode, MuleSource CTO and co-founder Ross Mason speaks with David Dossot, creator of the JCR transport for Mule. The JCR transport reads from, writes to, and observes JCR 1.0 containers. Mule users can find a user guide and examples for using the JCR transport with Mule 1.4.x on the MuleForge – the user guide and examples for Mule 2.1.x are in the works now.
I was able to squash some bugs on the IDE since the last snapshot release.
The first bug was related to creating new projects with a non-default Mule distribution. If you have more than one Mule distribution registered in our Mule IDE preferences, you can choose the runtime to use when creating a new project and the project will refer to the proper jars.
Hot on the heals of the Mule 2.1.2 release, we’ve pushed out a new release of Galaxy as well. This release contains many improvements:
- A new custom policy example
- A new AtomPub API usage example
- Fixed LDAP Integration
- Many bug fixes!
Last week I posted about Writing Mule Transformers, this week I’m going to continue with some more advanced features users can take advantage of.
All objects in Mule have lifecycle associated with them. Lifecycle calls can be added as necessary. For transformers, there are two lifecycle methods that are most useful.
By default the AbstractEventAwareTransfromer and AbstractTransformer both implement the org.mule.api.lifecycle.Initialisable interface. This means that once all bean properties are set on the transformer (if any) the doInitialise() method will be called. This is useful for transformers to do any initialization or validation work. For example, the transformer may need to load an external file resource in order to be able to perform its function, this should be done in the doInitialise() method.
Additionally, transformers may want to clear up resources when the transformer is no longer needed. To do this a transformer just needs to implement org.mule.api.lifecycle.Disposable and implement the dispose() method.
One of the great things about working on Mule is hearing the amazing tales of what people are doing with it. I’ve heard Mule referred to as a “Swiss army knife of integration” because of its flexibility and number of supported service topologies and technologies. While some case studies are available online from large implementations, I am very interested in hearing about the smaller successes people have had using Mule. Regardless of the size of your project if you have a story you’d like to share about how you used Mule to solve a problem, please do so by commenting on this post. You may just enlighten another Mule user to try the same, encourage a Mule developer to add a new feature or even spur a new MuleForge project.
I will be presenting a webinar tomorrow Dec. 9th at 9 AM PT/ Noon ET covering integration between Mule and webapps. It will be a technical walk-through of an example application consisting of two webapps consuming Mule services, one with Mule running inside it. The audience is assumed to have some prior experience developing with webapps and/or Mule.
It’s a holiday season, and we’re happy to give you Mule 2.1.2! This little Santa helper features over 50 bugfixes and enhancements. Even better, it’s hot in our documentation department, with a dozen issues resolved there and major work put into schema annotations for seamless configuration reference info lookup. Some other highlights include:
A bit of history
We created Mule IDE to ease the work when developing with Mule. Along with the work on Mule 2.0 we started work on an updated version of the IDE that would allow you to graphically design Mule configurations. This turned out to be by far more work than initially expected so we decided to rescope the work. Right now we focus on the little helpers that make developing with Mule easy and cut out the graphical editor for now.