MULE ESB (II): 500,000 Downloads and counting...

According to this news at ebizQ.com, the open source ESB, MULE, has already more than 500,000 downloads.(image from MuleSource.com)

By the way, see below the environments where MULE can operate:

- Operating System: Red Hat / Fedora Linux, Windows Server, Solaris SPARC / x86, Suse Linux, Ubuntu / Debian Linux, FreeBSD, Mac OS X

- Java: 1.4, Java 5, 6 and 7

- Transport: JMS, MQ Series, Tibco, Oracle AQ, Web Services/SOAP, FTP, HTTP/HTTPS, SSL/TLS, Multicast, IMAP, In-Memory, JBI, JDBC, Multicast, SMTP/POP3, RMI, and more...

- Integration: Spring, JBI, EJB, GigaSpaces, HiveMind, JavaSpaces, JCA, JNDI, JOTM, JTA, PicoContainer, Plexus

- Web Services: Apache Axis, XFire, REST, SOAP, WebMethods Glue

- Application Servers: WebLogic, WebSphere, JBoss, Apache Tomcat, Geronimo, Jetty, JRun, Oracle, Resin

Good enough :-)?

MULE ESB: A Case Study

Eugene Ciurana (from Walmart.com) wrote this article that you can find at TheServerSide.com. The subject is ESB, more specifically MULE ESB. Version 1.3.3 is "fresh from the oven" with 27 issues/functionalities implemented since 1.3.2.

Eugene's text starts with a simple question: "Why are ESB needed?". After this there is an interesting comparation between the ESBs from TIBCO (Matrix BusinessWork), SUN (openESB), Progress Software (Sonic ESB), IBM (WebSphere ESB) and, of course, Mule ESB (open-source, MuleSource Inc.).

He points out some advantages of Mule ESB:

* Active open-source community and commercial support available
* State of the art implementation and ability to run under Java 5/6
* Number of relevant features out of the box
* Response time from vendors within 48 hours (average time for the winners was 2 hours)
* Ease of installation and deployment
* Ease of configuration and expansion
* “Codeless” integration with legacy, third-party, and commercial products
* Ability to drop in/pull out without incurring in lock-in or ancillary product dependencies
* Low total cost of ownership

And how Mule ESB enables two or more applications to communicate? Mule implements elegant protocols and standards based on well-defined patterns. Applications communicate with one another by implementing these patterns with a set of predefined components (see figure below):

Eugene continues:
"... - Applications interface with Mule over a transport.
- A transport carries service objects between components (some of the current documentation refers to service objects as “UMOs” or universal message objects; that term is deprecated now).
- The transport is any mechanism for exchanging data between two points
- Mule doesn’t implement or mandate use of particular transports. It offers instead a number of transport providers and the integration engineers or developers get to choose the appropriate one for a given application.
- A transport provider implements a message receiver or dispatcher, a connector that implements a protocol like JMS, TCP, etc., and an optional transformer.
- The transformer may be use to convert service objects from one format to another (XML to native Java, for example).
- Mule routes inbound and outbound data between transports through the service object component, which is responsible for managing component events to and from the component, and for managing pooled resources. ..."

Good reading!

RIA and SOA

I am investigating the advantages of RIA (Rich Internet Application) over the traditional Client/Web interfaces. In this article, Duane Nickul, Senior Technical Evangelist at Adobe, puts some light in this discussion.

Lest start with a traditional SOA stack:

Since a human being lives in the world above the service consumer,
the service itself will not necessarily care or be aware that a human is there. However, it is highly likely that humans are part of a service call and exist as either the trigger of some event that results in a service call and/or are the ultimate
consumers of the service result themselves. While contradictory to the title
of this article, one could state that humans are not directly part of SOA any
more than business processes are. However, both business processes and
humans utilize the SOA infrastructure.
To architect such interactions, architects should take great care to abstract any details of the service itself away from the human. The human should view the
"V" (view) component of MVC and not care about the "C" or "M" components. Accordingly, architects need a mechanism to present consistent views to the human that are abstract of any dependency upon the service.

Client-server Approaches:

1. Traditional Approach

2. AJAX, Flex mode for RIAs (new approach)

3. Final Considerations

In the Flex example shown, web services are used to communicate interactively
with the services at the bottom. Note that the cardinality is not limited in any
way to 1:1. A Flex or AJAX application may communicate directly with multiple
services, then abstract all the complexity of SOA and present the view and some
control components to the human being above the client side.
Several recent examples of the model for RIAs to interact between humans and services can be seen all over the Internet. Some applications like Apple iTunes have viewer panes which are generated locally on the client machine—such as the user's music library (see Figure 4). When they switch panes to view the iTunes Music Store, they connect directly to the Apple iTunes Music Store service, retrieve a result set, and then present it to the human being (see Figure 5). To the human being, the end result is a seamless experience joining both service calls and local
processing into one application

Implications of SOA on Business Strategy

This is an article that you can find in SOA Magazine, 3rd edition (Jan/2007). Thomas Erl is the site editor of this excellent source of information about Service-oriented Architecture.

Below some excepts from the article "Implications of SOA on Business Strategy and Organization Design", written by William Murray.

1. From Business Tasks to Business Services
In 1994 Hammer & Champy's “Manifesto for Business Revolution” argued that technology could be applied at the process-level to significantly improve organizational efficiencies through streamlining organizational processes, structures and governance, thereby bringing to the mainstream the discipline of business process reengineering, and the concept that business processes are the fundamental building blocks of the corporation. This is the beginning.

2. The IT Utility Curve
From this manifesto, we see that, regarding technology adoption in a company, there are three phases, mode and planning posture to this adoption:

Phases: Enabling, Disruptive, Enabling
Modes: Experimentation, Innovation, Commoditization
Planning Posture: Tactical, Strategic, Tactical

The graphic that shows the investment along these phases or modes is a "S" curve:

SOA Meta Model

This is what David Linthicum proposed as SOA Meta Model.

Ten Things to Think When Building SOA

David Linthicum wrote another excellent article. The tips (listed below), in fact, tell us what to do and what NOT to do regarding SOA implementation. Let's see the " rules" with my notes:

1. Focus holistically, act locally: SOA is NOT a project. SOA is a path that not ends, like quality (in an broad sense). SOA is the sum of many parts and you should take them in count when implement you architecture.
   
2. Define the value: Strategy is important, better, a business case. If you defined that SOA is the new architecture approach for you company, how it can happens if there is no guideline that will make this happen?
   
3. Don't neglect service design: What we have behind composite application and composite process?... ...Services! So, they deserve special attention. Web Services must be design to be reused, to provide behavior and information (not to be app specific), must be aware of hardware and O.S. (no calls to native interfaces).
   
4. Leveraging a legacy is unavoidable: What keeps our business running? Legacy systems! Service-oriented architecture came to allow you to take the best from these legacy systems, not to rewrite them.
   
5. Remember the semantics: When dealing with data think about the real meaning of them, the context of this information, the semantic... ...ask yourself which relevant information you can extract from this data?
   
6. The proper place for orchestration: SOA implementation does not necessarily need orchestration to run. However, consider it for some application.
   
7. Security soaks in as you execute; it's not an afterthought: You might firstly developer Web Services for internal use, but in a near future they can be used for other companies (partners). Think about Identity Management from the beginning.
   
8. Classify the patterns of use: Three rules when implementing Web Services: patterns, patterns and patterns.
   
9. Persistence is important: "... You need to think about persistence for a few reasons, including federation of services around the SOA. When building an SOA you may end up with composites or processes created out of services that may exist over a dozen or more different systems, and as such, persistence becomes more complex if done at the points...".
10. Don't skimp on testing: Keep in mind that most of the data and system that Web Services will deal with are business-critic. Thus a test plan is very important and this must be written from the beginning.
    

100+ in TI Innovation

In last December 2006 Transit received an important prize: it is one of 100+ in TI innovation (category: Telecom and Technology). The project submitted is related to "CDR convergence and mapping using SOA".

See all categories and the winners. I received, on behalf of IT team, this prize.

See below other picture.

SOA Book in my Wish List

This is the #1 SOA book in my wish list. Please feel free to donate one :-).

Happy 2007! (now with blackberry)

This Blackberry (BB) you are seeing is (was) one of the most desired gadgets in my "wish list". It was a suprise on my birthday (Dec, 27th). Now I can post directly from my BB, read and write my e-mails, browse the Internet, send SMS... ...and, believe or not, I can you use it as a mobile! Simply wonderful. I've asked myself how I could, so far, live without one of them?

Thanks Debby!