Home

News: Mule 2.0 Released: Tech Brief

  1. Mule 2.0 Released: Tech Brief (10 messages)

    Mule 2.0 Community Edition platform is now available for download. Its new architecture allows new flexibility for building new applications. One of the main features of Mule 2 is the consistency of the APIs and configuration services. Now transports, containers, transformers, and other features have a consistent look and feel. Mule 2 also features the schema-based Spring XML configuration to ease integration with traditional web applications. Expression evaluation is built into the message handlers directly into the run-time so that headers, Xquery, or other tests can be done without having to define a new POJO or transformer for these activities. A new REST pack was released with Mule 2.0 based entirely on MuleForge contributions from the open-source community. Current users of Mule 1.5 have an easy migration path to Mule 2.0. The biggest changes came in the syntax of the configuration file and the re-definition of some internal plumbing. Mule 2.0 allows to swap the configuration to SCA, if required. (Click here if you can't see the video.) Time: 7'24" Ross Mason is Co-founder and CTO of MuleSource, Inc., the creators of the open source Mule integration platform. Ross founded the Mule project in 2003 and strived to make it the leading Java-based ESB and integration platform. Previously, Ross was Lead Architect for RaboBank and played a key role in developing one of the first large-scale ESB implementations in 2002.

    Threaded Messages (10)

  2. Re: Mule 2.0 Released: Tech Brief[ Go to top ]

    Just to clarify, we don't currently have support SCA, but we now have an architecture where we could offer support for SCA configuration if there is a demand for it. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  3. SCA[ Go to top ]

    Ross, I could be wrong but I seem to remember having read one of your blog posts in the past where you did not express a very favorable opinion of both SCA and JBI. If that's right what made you change your mind about SCA? My apologies if I got it completely wrong.
  4. Re: SCA[ Go to top ]

    Hi Satadru, I have indeed expressed my opinions about JBI here. I mention SCA in that posting too. I think SCA is fundamentally a better approach to JBI since it concentrates on the configuration of services, which means we could start building cross-vendor/ cross-platform tooling. But SCA hasn't gained the adoption yet to make it really compelling and the specification still feels a bit web-service-y. I think it is a step in the right direction though. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  5. Re: SCA[ Go to top ]

    Ross, not sure what exactly you mean that SCA is still bit web-service-y? As I understand from specification with SCA you can use Web services, JMS, JCA and EJBs with the same code for incoming and outgoing requests.
  6. RE: SCA[ Go to top ]

    As far as I know, you can only interconnect services between different domains using web services. Greetings Mario
  7. Re: SCA[ Go to top ]

    Mario, Just to clarify... A domain is generally a single-vendor (or open source) environment and is loosely defined as a realm of control. Within a domain, service assembly is done via “wiring” or explicitly binding to an endpoint. The actual protocol used for remote wires can be left to the domain to choose (perhaps based on criteria such as “reliability” or security requirements) or be configured explicitly. For binding to an endpoint, SCA specifies Web Services and JMS. However, the goal of the spec authors was to allow SCA implementations to add their own binding extensions. For example, the open source Fabric3 (www.fabric3.org) runtime supports additional wiring protocols and bindings such as Hessian, Burlap, RMI, and OracleAQ. There has also been interest in AMQP. Communications between domains or to other external services is done using bindings. Since two domains may be run by different vendor implementations, the binding used will need to be one supported by both. The most likely bindings in this case would be JMS or Web Services, since they are specified by SCA and not extensions. It’s important to note that in SCA remote communications are not restricted to web services. In fact, in many situations, I would expect remote inter-domain communications to not use WS-*, particularly when messaging infrastructure is available. For example, one user of Fabric3 I know makes heavy use of OracleAQ. Between domains, communications are likely to be web services since WS-* is a way to achieve interoperability, but communications could be over JMS or some other mechanism. In terms of SCA feeling a bit too “web servicey” that may be because a lot of time has been spent defining how SCA can make use of WS-*. However, we tried to take care that the actual Java-based SCA programming model is not burdened by the complexity of those technologies. Instead, we wanted to create a model that provides for strong-typing based on services, composition (the ability to construct services based on smaller “components”), loosely coupled interactions (e.g. asynchronous communications, callbacks, conversations), and simplicity (POJO-based). In most SCA applications, the use of Web Services can be limited (or avoided) and shouldn’t interfere with the programming model. Jim
  8. Disclaimer before I start :) I have been quite closely involved with the SCA specifications and two of the OSS SCA implementations for the past two years. Anyway, my comments are mainly as an end user on using SCA as a technology for building composite applications implemented using disparate technologies. For the past three to four years we have built a successful payments architecture that is part of the UK critical national infrastructure using Spring and Mule, we are now expanding our presence in Europe with SEPA (Single European Payments Area) and beyond. Mule and Spring, both have been of tremendous value to us. They were inline with our philosophy of light weight development model moving away from heavy weight container based technologies. However, now SCA presents a standards based alternative. Even more, IMHO, SCA addresses some of the intricate issues of compositional application development better. To define SCA in four bullet points, 1. It provides a recursive assembly model for building compositional applications from components implemented using disparate technologies. 2. It provides a transport abstraction that decouples transport level interaction concerns from your application components. 3. It provides a standards based mechanism for enforcing policies and constraints on your enterprise infrastructure. 4. SCA domains provide a unified view of your enterprise's service network both from a logical and operational perspective. I agree with Ross that SCA hasn't had enough traction. However, I would say first time in the industry, now we have a set of prescriptive specifications that definitively describe how to build SOA applications. It is not about what SOA is, rather how you build a SOA. SCA addresses all aspects of building service oriented compositional applications. It not just addresses concerns of building and provisioning stateless services over WS-* protocols. It also addresses the intricacies of how you build these services, by defining the semantics on conversations, callbacks, policies, composition, transport abstractions etc. Within your enterprises service network not all services are implemented as coarse-grained stateless services, they are built from fine grained tightly coupled components which are stateful, which require conversations, which perform callbacks. SCA addresses these micro issues at the same time doesn't ignore macro aspects like provisioning, policy enforcement, transport abstractions, domain management etc. I would really like to see vendors putting more effort into evangelising SCA. I can understand the industry being wary of vendor driven technologies, having their fingers burnt by heavyweight container-based technologies in the past. However, lightweight OSS SCA implementations like Fabric3 are a testament for building enterprise applications using a lightweight programminng model, yet not compromising on standards compliance. From first hand experience, I wouldn't say SCA is too "web servicey". Of all the SCA specifications listed below, only one is directly related to web services, SCA Assembly Model SCA Policy Framework SCA Java Client & Implementation SCA BPEL Client & Implementation SCA Spring Client & Implementation SCA C++ Client & Implementation SCA Web Services Binding SCA JMS Binding There is no denial that Spring and Mule have been fantastic for us and they are great technologies. However, we have now made an informed decision on replacing Spring and Mule on all our new architectures using SCA. And it is a testament to Spring and Mule that we are able to wire most of our existing software assets built on top of Spring and Mule, now using SCA. Meeraj Kunnumpurath Lead Technologist www.vocalink.com
  9. Dominant OS ESB ?[ Go to top ]

    Hi, Is Mule now the dominant OS ESB ? What other OS offerings are comparable ? Thanks,
  10. Dominant OSS ESBs[ Go to top ]

    I think the main ones I see being used are: * Mule * Apache ServiceMix / Iona Fuse * Apache Synapse / WSO2 ESB Warning I am biased (PMC chair of Synapse and CTO of WSO2). However, I haven't seen a lot of/any Sun OpenESB out there. I would say that while Mule has the mindshare, both Synapse and ServiceMix have plenty of interesting customers and usage and strong communities.
  11. Paul, You might want to look at JBoss ESB: http://www.jboss.org/jbossesb/ We recently launched our SOA Platform, which includes JBoss ESB - http://www.jboss.com/products/platforms/soa - http://customers.press.redhat.com/category/solutions/jboss/jboss-enterprise-soa-platform/ The SOA Platform can run standalone, side-by-side with our Enterprise Application Platform (based on JBoss AS) or in the same JVM. JBoss ESB is based on the same micro-kernel architecture that participated to the success of JBoss AS (à la carte services, ease of deployment, etc.) Cheers, Sacha JBoss, a division of Red Hat