MuleCon2007 Selection

Scripps [TV] Networks [one of their properties is the Food Network] on SOA and ESB Selection. Starting with a design, going from a top-down approach, they began their selection. The next step was to run a few pilot projects to test a bottoms-up approach using three use cases.

  1. Asset Ingest, assets being videos, closed caption files, and the like
  2. Enterprise Asset Notification System, using a publish and subscribe model
  3. Asset Retrieval

Asset Retrieval use case was detailed, and forms the basis of the design challenge. The design challenge to the audience is to go to the whiteboards and work it out. A true exercise of an open source community. :p

  1. Performance is the primary criteria for success.
  2. Assets are registered with a Handler.
  3. Handlers are Spring configuration beans.
  4. Dynamic Handler Data plus Static URL's equals Asset Retrieval ReSTful URI.

Ross, Andrew, Eugene and Travis will lead the teams.

We're blogging from MuleCon2007 throughout today and tomorrow.

MuleCon2007 MuleHQ

Doug MacEachern of Hyperic and Andrew P??? of MuleSource. Hyperic is management product providing auto-inventory, deep & clean monitoring, control of servers and services, tracking of configuration changes and log events, alerting, a web-based mulit-user portal, and a scriptable CLI.

The product goals are ease of installation, maintenance, and adapting to specific needs.

Specific actions, such as vacuuming the database, can be brought into MuleHQ through its plug-in architecture.

Doug then went through a illustration depicting the Hyperic/MuleHQ inventory model, and the architectural diagram for the MuleHQ server. MuleHQ uses role-based access control. It ships with PostgreSQL, but one can use any RDBMS. Next came the architectural diagram of the MuleHQ Agent, basically a dæmon.

There are ~50 platforms supported by MuleHQ, including operating systems, web servers, virtualization servers, application servers, etc.

MuleHQ actively monitors the transport endpoints protocols.

The adaptability of MuleHQ is exemplified by the plugin development kit:

  1. JMX
  2. SNMP
  3. Windows Performance Counters
  4. SQL/JDBC
  5. SIGAR
  6. Scripting/Nagios
  7. Java

All the plug-ins use a common API, written in Java, so that the plug-in developer need not worry about which platforms will be used in their environment. There's a plug-in development resource on http://support.hyperic.com/

Doug gave a demo, showing the AJAX web-based MuleHQ UI and features. The inventory model was shown with the platform view, listing everything on the ESB, such as various OSs and databases, and the Service, which for Mule itself, showed routers, transports and endpoints.

MuleHQ is only available with a subscription.

We're blogging from MuleCon2007 throughout today and tomorrow.

MuleCon2007 Mule and Healthcare

Art Gramlich talking about a healthy Mule.

The challenges they were facing include EMI [X12, HL7, XML, Flat Files], Coding [ICD9, CPT, SNOMED] and Transports & Protocols [WS-*, HTTP, FTP, Raw Sockets] that included legacy, current and emerging standards.

The research showed that Mule was a better fit than most technologies. JBI led them to Mule, as JBI was close but not exact. Mule is lightweight and fast, easy to integrate, expand & customize, encourages reuse, and is highly testable.

Yet another but different architectural diagram. The variety that these Mule users have shown here today, very much emphasizes the flexibility of Mule, and open source solutions.

Art went through the configuration and conventions being used, represented as an hierarchical tree.

What they like is that they can maintain data source neutrality, richer clients [AJAX or Flash], and CSP & futures concurrency models. One data source may not now, or later, provide all the information required. One query, such as a patient looking at a diagnosis, might pull from multiple databases, and the times were untenable. The concurrency models and Mule allows for multi-threading, speeding up the process.

We're blogging from MuleCon2007 throughout today and tomorrow.

MuleCon2007 MLB

Ross Paul of MLB talks about how the Mule saves baseball, or maybe it's baseball has been very, very good for the Mule.

As new services and demands come up, and increasing loads on legacy applications, and performance all around is a concern, Mule for I/O is the solution. The MLB does about 70,000 games per year. Going live we see that our SF Giants are losing to Milwaukee, 2 to 5; stats are scrolling on the top of the MLB web site, there's a scoreboard on the leftSideBar and near-real time animations are showing the game... Powered by Mule. All the live data from the Game Day Engine is routed as messages through Mule to a wide variety of destinations, in a wide variety of formats.

Once they realized how powerful and easy Mule was, they started to look for other problems that the Mule could solve, and database polling came up. Numerous stand alone polling applications were combined, using a cocoon transport, database transport, cocoonBeans, and a chaining router. By not having to constantly load in the cocoon JARs, performance has increased dramatically. One thing this allowed was to pass some of the MLB services to mobile devices via WAP.

Some other things involving Mule and Baseball:

  • web scraping for RSS aggregation
  • email sender listening to JMS
  • no more cron jobs
  • distributed search of Lucene indices
  • client of PA sports ticker
  • tasking Accucast via RMI
  • JMX statistics aggregation and control

For a lot of fun, watch all the live changes on the MLB site, and remember that Mule is driving it.

We're blogging from MuleCon2007 throughout today and tomorrow.

MuleCon2007 GeoMail

Rune Peter Bjørnstad from Bouvet AS, in Norway [They're coming from all over the world to sing the praises of Mule.]

Once upon a time, Rune checked out the logs on his DSL router, and saw that there were geotags available, which led him to create a use case to check out Mule and to create a custom Ajax connector for Mule, AjaxMQ.

If one is funning a community and you wish to understand from whence your community hails, this will work for you. Components include Google Maps, Mule and Spring and provide AJAXian live updates.

Rune created a Maven archetype for the Mule community. The next slide showed the architecture. As an aside, Mule had a problem with POP3 headers, that, being open source, Rune was able to fix. As Rune walked through the architecture, he exemplified many of the features within Mule that were shown in yesterday's training.

The AjaxMQ connector is very simple, using the Jetty service to run Ajax Servlets, triggering JSON events.

The project is available on MuleForge as is a demo, and Rune gave a quick, local demo which was very impressive, seeing the emails pop up on a Google map. Now, think about the possibilities of this with customer support workflow management, any type of geotagging, and mobile location based services.

We're blogging from MuleCon2007 throughout today and tomorrow.

MuleCon2007 Mule BPM BPEL

Business Process Management (BPM) is "programming in the large", bridging the gap between business analysts and programmers. It allows for Business Activity Monitoring (BAM), and can make business processes more agile and include human input [workflow] as part of the process.

Mule brings integration to BPM such that the process engines don't exist as silos, providing operational managers a unified view of the business. BPM allows for easier modeling and management of long running integration processes, using complex decision logic and human intervention.

BPEL tries to combine BPM and integration in a standard way but it only talks to web services and XML while Mule will integrate anything with anything. One can use a BPEL engine with Mule, through the SOAP endpoints, but a BPM engine with a JAVA API is a much better complement to Mule. By having a BPM connector for Mule, one defines a simple, standard interface to plug in any BPM engine. The Mule BPM Connector allows a running process generate synchronous or asynchronous Mule events. The examples given are in 1.4. At this point, the Mule BPM connector integrates with JBoss jBPM, but the future looks towards being able to plug in other BPM.

Feedback, Quesitons, Thoughts

Perhaps of more interest would be to be able to use BPEL in a Mule configuration file, with the capability of dropping in the business processes into the XML.

Take a look at IT|Redux if you're interested in BPM.

We're blogging from MuleCon2007 throughout today and tomorrow.

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.

May 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    
 << <   > >>

At the beginning, The Open Source Solutions Blog was a companion to the Open Source Solutions for Business Intelligence Research Project, and book. But back in 2005, we couldn't find a publisher. As Apache Hadoop and its family of open source projects proliferated, and in many ways, took over the OSS data management and analytics world, our interests became more focused on streaming data management and analytics for IoT, the architecture for people, processes and technology required to bring value from the IoT through Sensor Analytics Ecosystems, and the maturity model organizations will need to follow to achieve SAEIoT success. OSS is very important in this world too, for DMA, API and community development.

37.652951177164 -122.490877706959

Search

  XML Feeds