MuleCon2007 Mule and Spring

Ross Mason provides details about Mule, Spring and when to use what, starting off with ESB and Inversion of Control (IoC).

IoC and ESB Similarities include loose coupling, separation of concerns, wherein the business logic is separate from the infrastructure, reusable components and deployment flexibility. With all the use cases, one repeating theme is that the endpoint starts small.

Spring is an application framework that supports many network functions, such as JMS Messaging, eMail and Web Services, among others. Mule builds atop the Spring container and common services.

Use Mule with Spring when a POJO becomes a service that is shared among applications, with a heavy load, handling concurrent requests. Another reason to use Mule with Spring is the transports. Mule provides powerful routing and distributed data transformations.

Spring 2.0 Rocking the Mule

Good looking Mule on Ross' slides. B)

Mule incorporates some features from Spring such as namespace handlers and AOP support. Ross showed examples of handling namespaces in Mule 1.x vs. Mule 2.0.

Questions for Captain Mule

Mostly, folk want copies of "Captain Mule". You had to be there... you should have been here.

In many ways, Service Component Architecture (SCA) makes more sense for Mule than JBI, and the Mule folk have been talking with the Tuscany [see the linkblog in the sidebar] folk about the SCA spec.

We're blogging from MuleCon2007 throughout today and tomorrow.

MuleCon2007 Mule Roadmap

Ross finally has some slides done. :p

What's it like to go from an open source project to a product

Roadmap for 1.4, 2.0 and 3.0

The old roadmap was much like Lombard Street in San Francisco, as Ross' attention was caught by new curves. A more structured roadmap is being developed. Mule 2.0 is targeted for May, with maintenance release for 1.4 continuing into the fall.

Mule 1.4

  1. BPM Support
  2. Nested Routers
  3. Streaming
  4. Over 100 bugs fixed
  5. Support for Multiple Models

Through multiple models, one can change the way in which services execute, and these can be mixed and matched.

Mule 2.0

  1. New configuration model - schema based - Spring 2.0
  2. Spring 2.0 under the covers
  3. No more Mulemanager
  4. Service registry
  5. Between 1.4 and 2.0
    • WS-Security
    • SFTP
    • CSV Transformation

Mule 3.0

  1. OSGi Support
    • Hot Deployment
    • component versioning
  2. Failover Support
    • Group membership
    • Custom Recovery Strategies
  3. MuleH! Patch Management
  4. New Examples based on actual use cases

MuleForge

The MuleForge is meant to be a community resource for hosting Mule extensions. It will also be a place to host sample applications, use cases and a knowledge base.

As stated earlier, 58.3% of Mule users build Mule extensions. The Mule community is very involved. There are a variety of reasons to contribute one's code, including getting the community to help debug it.

The MuleForge will be using Codehaus, with Jira, Confulence, Maven 2, Bamboo, Subversion and Fisheye - all with a single sign-on.

Code Jump

Ross is jumping into some code examples to show what one can do with 1.4. The first case is the Amulzon bookstore. The AmulzonService is a POJO that implements a BookstoreService interface. Domain objects are the messages. Ross then went over configuring the Amulzon bookstore. Once configured, one then exposes the Amulzon Bookstore as a web service with a SOAP service name, telling Mule to use XFire, all through the simple configuration XML files. One could also add a configuration file to allow both .NET and Java processing. Next is allowing the Amulzon Bookstore to call out to other services, e.g. to a validation service. This is where the new with 1.4 Nested Router Bindings come into play. The Amulzon Implementation for calling out to the validation service is then shown in Java, with binding back to the interface with a defined endpoint. These changes enhance unit testing, removes dependence on the Mule API, and allows a visualizer to map through the process. While the example has a hardcoded URI for the endpoint, best practice is to use logical endpoints, and keep the targets separate.

Mule Streaming

Mule Streaming allows services to consume very large events in an efficient way. Simple routing rules based upon event metadata are still possible. Streaming and non-streaming endpoints can be combined, as separate models are used. A variety of streaming transports are supported.

Travis Carlson Jumps-in with OSGi and Mule

OSGi is a dynamic module system for Java, allowing plug & play interfaces such that one can change pieces of an application without restarting the application, as well as increasing security. OSGi is gaining wide industry support, including plug-in for Eclipse and being embraced by the Spring Framework.

OSGi brings several benefits to Mule

  • hot deploy
  • change management
  • high availability - update and restart one part of a running Mule instance without impact on the entirety
  • better dependency management
  • enabling technology for patch management in MuleHQ

Mule will operate within an OSGi framework, which manages Bundles [static libraries] and Services [dynamic components]. Each Mule module/transport is an OSGi "bundel" containing a special manifest file, declaring packages and services. Both packages and services have versioning. The OSGi framework lifecycle provides for failover and audit trail. Bundles can be grouped into "run levels" allowing them to be brought up/down in a layered approach, much like *nix services.

This makes a Service Registry possible.

The big 3 open source OSGi frameworks are

  1. Equinox from Eclipse - seems to Travis to be more suited to desktop apps
  2. Knopflerfish from Gatespace Technologies - best fit for Mule
  3. Felix from Apache - least mature

OSGi will be the foundation for future versions of Mule.

From Q&A

There should be no performance impact from using the framework.

Patch management didn't exist in previous versions of Mule - so this is good news.

The roadmap, cleaning up the lifecycle, is to have Spring in Mule 2.0, and OSGi in 3.0.

Moving from current versions of Mule, to these later versions, shouldn't impact the current configuration files at all. That is, there will be backwards compatibility.

In Mule 1.x, using Spring was an option, Mule 2.0 forward will incorporate Spring. Spring OSGi hides the details of registering and consuming OSGi services.

The idea is that one can use this to take one's own components online and offline independently.

Spring is independent of the frameworks [such as the big 3 mentioned above] being used.

We're blogging from MuleCon2007 throughout today and tomorrow.

MuleCon2007 FIMAT

John Mahoney & Chad Vawter from FIMAT, one of the largest institutional brokers, executes trades on different exchanges, and is a Clearing Member of Global Exchanges. FIMAT is one of the top 5 globally, in terms of volume. They have a massive amount of mission critical, real-time data. As a Clearing Member, risk management is an extremely important part of the business. The technology topology is very complex, with each client having a customized process for interaction, and there are a multitude of systems that are very tightly coupled.

FIMAT chose Mule as it was quick to launch using existing transports/transformers, while being very easy to customize, and build upon. The fact that it was open source was a big factor. Support has been excellent from the Mule team.

An existing project, Scheduler, is very important. The next version requirements demanded many integration points with a flexible workflow, allowing interaction between .NET and Java applications through web services. One main goal is to have operational visibility, which is accomplished through MuleHQ.

The audience initiated a discussion on the complexities of integrating .NET and Java. Start with the WDSL, and then build the schema, and then going to the individual applications' definitions. But the complexity of the interchange is what really determines the effort.

Enterprise Integration Patterns through the many message routes that are in place, was a selling point for Mule with its ease of router configurations. The variety of the data types being used by their clients, and the ease of customizing transformers, was another selling point for Mule.

We're blogging from MuleCon2007 throughout today and tomorrow.

MuleCon2007 Virtual Tax Services

Dan Cahoon and Christopher Ginn from H&R Block are presenting their experiences with Mule.

[As an aside, Dave mentioned that Ross is over in the corner working on his slides for later. Ross yelled out that "they're coming". And on another note, later tonight, there will be 9 ball, 8 ball and darts competition with the room against Dan, Christopher, Ross and Dave - winner gets a Mule jacket.]

The goals of virtual tax services is to move the tools to where the preparers do the work. H&R Block have over 13,000 locations in the USA, more than those burger joints. They spin up for four months around their own mini-Y2K... tax season. The concept is to move this out with a massive virtual service bus as a real-time, asynchronous communications platform for all of those offices.

One major goal was to demonstrate the open source technologies as a viable alternative to commercial solutions. Given the conservative nature of the company, this is an amazing vote of confidence that open source solutions are ready for the enterprise.

Risk mitigation is often more important than functions or cost. One consideration was that for all of these nodes [remote, temporary offices], connectivity is all over the map. Trying to accomplish the goals with a annual licensing from a large vendor just wouldn't make sense.

Christopher went over the VTS Architecture, showing Mule at the office level, and how it interacts with the main Mule VTS Service Bus. Many of the applications using the bus are open source, such as Alfresco for ECM including scanned documents from the offices. A great endorsement "Mule is, hands down, the best decision we ever made."

From the Q&A...

Development started in November 2006, and was rolled-out to sixty offices before the end of January, 2007.

SOAP and Rest are being used, with an emphasis on Rest. SOAP is mostly sticking around because of third-party support. [Legacy issues already. /sigh]

They don't use any business logic within Mule. It's infrastructure, it does what it's supposed to do very well, and they want to keep it simple.

We're blogging from MuleCon2007 throughout today and tomorrow.

MuleCon2007 Mashup

Eugene Ciurana, Director of Systems Infrastructure at Leapfrog, is presenting on Enterprise Application Mashups with Mule ESB.

Once upon a time, Eugene did industrial robots - we'll have to make sure that he and Clarise get to talk, as she still talks about her Singapore days, doing robots for Motorola.

Case Study 1: eCommerce Site

The objective for a large, international retailer, was to make an Architecture that would last for 5 years, through a 10 months skunkworks, that wouldn't force system upgrades on business units. The prime directive was to acquire not build, and to go with "best of breed". This prime directive was in recognition that no ONE vendor is best in every area. There was also a clear separation of concerns between platform infrastructure and applications, such as ERP, eCommerce, CMS, etc. [BI, where's BI in this plan?]. &#59;)

The result was a mixed environment of over 10 vendors, 3 hardware platforms and geographically distributed. How to integrate all of this? The answer is an ESB, and they looked at commercial and open source alternatives. From the commercial, one vendor looked good, but with an insane price; their JMS component was included in the final solution. On the open source, they looked at:

  • Jboss
  • OpenESB
  • Tuscany
  • ServiceMix
  • Mule

Jboss and OpenESB requires you to eat their whole enchilada [my words], and it wasn't digestible. ServiceMix and Tuscany are built to meet JBI, not solve real world problems. Eugene wanted to keep flexible, and not commit to Java as the solution for every problem. Mule was the solution. The resulting architecture has eCommerce Suite, Order Capture, Order Management, Web Service, Single Sing-on, CRM, CMS, Product Information, B2B/EDI and BPEL hanging off of the Mule Services Backbone, bringing about a successful reference implementation. This is being used to support a customer facing web structure that has 50 MILLION hits per day. The team only had 21 days to build the environment and integrate all vendors' products. Working with the Mule team, the first Mule-enabled components were the eCommerce Suite and CRM, which only took 7 days. Integrating the other 8 vendors took 20 minutes. More about this can be found from Eugene's site.

Case Study 2: Download Store

The objective was to create a download store, with a geographically dispersed team in 60 days. The work is still ongoing, but Eugene went into some of the details and showed the architectural diagram.

We're blogging from MuleCon2007 throughout today and tomorrow.

December 2019
Mon Tue Wed Thu Fri Sat Sun
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
 << <   > >>
The TeleInterActive Press is a collection of blogs by Clarise Z. Doval Santos and Joseph A. di Paolantonio, covering the Internet of Things, Data Management and Analytics, and other topics for business and pleasure. 37.540686772871 -122.516149406889

Search

Categories

The TeleInterActive Lifestyle

Yackity Blog Blog

The Cynosural Blog

Open Source Solutions

DataArchon

The TeleInterActive Press

  XML Feeds

Mindmaps

Our current thinking on sensor analytics ecosystems (SAE) bringing together critical solution spaces best addressed by Internet of Things (IoT) and advances in Data Management and Analytics (DMA) is updated frequently. The following links to a static, scaleable vector graphic of the mindmap.

Recent Posts

powered by b2evolution