Friday, October 31, 2008
Monday, October 27, 2008
As some of you know we released Mule 2.1 Community and Enterprise last week. Tomorrow (Tuesday) I will be hosting a webinar for folks interested in getting started with Mule 2.1.
The session will cover:
- Introduction to new features
- Creating your first Mule project
- Mule IDE
- Example case study
You can register here. Hope to see you tomorrow at 9am PST, 4pm GMT.
Thursday, October 23, 2008
I cannot believe it but my Mac Book Pro has just died again. I am using an older one because my other one died about a month ago thanks to a faulty graphics chip. For those counting, that is three major outages for me this year (the first happening in June).
While I have been a diehard fan of the PowerBook and MacBook Pro over the years, I think its time to find a new platform. My main concerns with the switch right now are:
- Calendar and calendar sync to my iPhone - I guess this may mean a change in phone
- Swtiching email - I just don't like the GMail interface
- MS Office support - I use them every day
- Backup - Timemachine is the best I have used
- I don't think I can bring my self to go back to Windows
It seems like my only viable option is a Thinkpad and Ubuntu. Anyone else have another idea?
Tuesday, October 21, 2008
After a lot of sweat and beers Mule 2.1 Community and Enterprise editions have been released. Improvements on the Community version include-
- Component Interceptors have been re-introduced. We thought folks could get by on Spring AOP alone but it wasn't the case. Interceptors allows developers to intercept events before and/or after a component
- Expression Support. Expressions allow developers to evaluate expressions on the current message to perform transformations, content-based routing, and filters. There is now better support expressions in routers and transformers. The expression syntax has also changed in this release to play well with Spring Property Placeholders. See the migration guide for more information
- Reconnection Strategies have been replaced with the new Retry Policy framework. the old reconnection method only worked some of the time, the new Policy framework gives us much better control over how retries are attempted
- Routers now support returning collections of messages using the new MuleMessageCollection interface. This is useful if you want to invoke multiple endpoints, say using the Multicasting router and return more than one result
- Endpoint configuration has been tightened up to make it easier for people to configure event flows. It's now required that all endpoints are configured with the synchronous attribute, otherwise the default for the Mule instance is used. For more information about configuring event flows, see the Messaging Styles page
- The Message Splitter router has been simplified to make it easier build custom splitter routers
- There have been many schema updates to make it easier or more logical to configure Mule. These are detailed in the migration guide
- The documentation is in orders of magnitude better than in previous releases. We still have work to do, but you can find information on almost all areas of Mule at the community site
- The Mule codebase has been made OSGi-ready. This means that Mule now ships as OSGi bundles, but we have not made the move to actually having the server run inside an OSGi container. We want to do alot more around our support for OSGi, this was the first step
- As always there is a huge number of fixed in this release. Thanks to the Mule community and customers for reporting them
We also released Mule 2.1 Enterprise this week. This is the commercial Mule offering providing all the benefits of the Community edition plus some extra tools and features.
- Premium JDBC Connector - support for advanced JDBC functions, such as batch and cursor mechanisms, resulting in over two orders of magnitude (150x) performance improvements for certain use cases
- WebSphere MQ Connector - bi-directional request-response messaging between WebSphere MQ and Mule JMS using native MQ point-to-point, as well as synchronous and asynchronous request-response communications
- Mule RESTpack - now supported as part of the core Mule 2.1 Enterprise product, allows developers to create REST-style services, which form the basis for web oriented architecture (WOA), using popular frameworks such as RESTlet and Jersey
- Mule 1.x Migration tool helps existing Mule users migrate from Mule 1.4-1.6 to Mule 2.1
- MuleHQ is a 360-view management and monitoring tool for managing all deployed assets such as the OS, JVM , database and of course Mule.
Out-of-the-box retry policies - allows creation of self-healing connections, instructing Mule to attempt reconnection based on pre-defined policies, without the need for custom code
You cab grab the Enterprise Edition here (inclides a 30-day evaluation license) or get the Community Edition here.
Wednesday, October 15, 2008
Recently, Zack Urlocker posted an entry on his Infoworld blog, High volume is key for open source. He put open source users into two categories -
My view is that when open source products are most successful (and most disruptive), they serve two distinct markets: a nonpaying community and a paying enterprise market.
I think these groups are more like different ends of a user spectrum. I believe there is also a middle ground that defines the gray area between those that do pay for open source and those that might.
At one end of the user spectrum there is a large user group for any successful open source project who will never pay for the software. Within this group there is a small sub-set of people who will give back to the project in some other way such as submitting patches, feedback or answering questions on forums. Lets call these users the "passive community" and "active community" respectively. The best way to get value from this group is to grow your active community by making it as easy as possible for users to understand how to contribute and foster those contributions.
At the other end of the spectrum there are those that will always pay for open source software that has risk associated with it. By risk I mean that they rely on it to run parts of their day-to-day business. To these customers, the safety net of having a support agreement with the vendor is vital, typically they will also care about indemnity and warranty of the code they are deploying into their well-guarded production environments. If something breaks they want it fixed right away, so going with the vendor is the safest and most reliable option.
Then there are the people in between. These users will use the software in production even for mission critical applications. Generally, they will consider purchasing from the vendor but this consideration has a lot of variables that stem from the needs of the customer and the offering from the vendor. Customer considerations often include -
- Is the application mission critical? People don't pay to support applications that have little or no impact on their daily operations.
- Can we absorb the cost? I would guess that 100% of IT start-ups use open source software to build their applications ad infrastructure. There is no way they are paying for anything unless they are making money.
- Can we support ourselves? Often, customers think they can support themselves without the vendor. This is obviously fine and one of the upsides of open source software. However, in my own experience I've seen that often customers take a "bad path" when designing their SOA/integration solution, just because they didn't understand what could be done with Mule. Talking to MuleSource early would have saved a lot of pain later on.
- Do we have the right team to self-support? If customers build their solution in-house, they will answer yes to this question. However, I've seen users say they can support themselves then realise that their mission critical system is supported by 6 contractors. Given the current climate, those guys may not be around for too long. Often there will be a champion of the product in the organisation that introduces it. What happens when that person leaves?
- Do we know we are running Mule? As Matt Asay points out, it's fairly common that an SI will introduce open source products into a customer environment without the customer knowing it. What if something goes wrong and the SI cannot fix it?
From the vendor perspective appealing to this middle group should be approached with an emphasis on value. Always ask "what problems do we solve for the customer with our commercial solutions?" rather than "here is what I can sell you".
The meaning of value will vary greatly from market to market and customer to customer. You can define value in different ways such as additional product features, tools, premium content such as knowledge bases, indemnity, services, training, support and of course pricing.
Ultimately, You need an acute understanding of your users and customers to ensure you strike the right balance between your open source offering and commercial offering. It boils down to making decisions that embrace your user community and provide value to your customers. You will find yourself make distinct decisions for users and customer, but must always consider both carefully before arriving to a conclusion.
We're proud to announce the recent release of Mule Galaxy 1.5 Community and Enterprise Editions. It is a huge leap forward from our 1.0 release (hence the version jump). Some of the great new features include-
Enterprise Edition Features
- Remote Workspaces: Support for attaching workspaces from remote Galaxy instances. This provides simple federation since you can deploy multiple Galaxy instances in different regions/departments/projects and also share some artifacts and policies across the whole deployment.
- Workspace Replication: Replication takes advantage of the administration shell and the remote workspaces capabilities to allow you to easily copy workspaces from one Galaxy instance to another. This is very useful if you wish to periodically push production worth artifacts/entries from a development instance of Galaxy to a production instance. By writing a simple script and scheduling it, you're able to control how and when replication occurs.
Community Edition Features
- Scripting Shell: This is a groovy-based scripting shell that allows you to create executable scripts to run against Galaxy from the Web UI. This is a powerful feature that allows you do thins like create event listeners and trigger other processes, fire notification, perform back ups and more. There is also a cron-based scheduler to execute scripts periodically.
- Entries: In addition to being able to store artifacts, Galaxy can also store entries inside the registry. Entries can represent a wide variety of services as they do not require a service description like WSDL, they just store pure meta-data. For instance, a RESTful service can be listed in the registry by creating an entry and storing information such as it's URL, links to documentation, etc.
- Event API: All events inside Galaxy now trigger an internal event that can be listened to (Observer pattern). These are accessible from the Scripting Shell or Java extensions to Galaxy.
- Feeds for search results: Now every workspace and every search has a link to a feed for that search. This allows you to easily subscribe to changes occurring inside Galaxy and monitor them via a newsreader.
- There have also been a load of improvements to the Atom pub API, Query engine, and property type handling. The UI has changed a lot, we spent a lot of time addressing usability.
- Finally, Galaxy supports an auto-upgrade feature. If you were using Galaxy 1.0, you just need to install Galaxy 1.5 and run it!
Go and give it a spin and let us know what you think!