Discussions

News: ServiceMix 2.0, ESB container, released

  1. ServiceMix 2.0, ESB container, released (16 messages)

    Codehaus has announced that ServiceMix 2.0, their open source ESB container, has been released with better JBI support, more examples, and improved routing capabilities along with bug fixes and other code improvements.

    From the release notes:
    • Improved JBI support including both interface based routing as well as service based routing together with improved WSDL parsing
    • Support for Publish Subscribe Routing
    • Improved JAX WS support
    • Migration to XBean as the XML configuration mechanism which works with any Spring release and allows us to mix and match ServiceMix configuration with other XML configuration mechanisms like ActiveMQ and Jencks
    • Migration to backport.util.concurrent to make it easier to move direct to a pure Java 5 solution.
    • a new Loan Broker example from the EIP Patterns Book
    • a new simpler POJO based deployment model
    • build reorganised to make ServiceMix more modular
    • a new ChainedComponent which implements simple pipelines of components easily
    You can get Servicemix from the download page.

    Are you using a JBI container or other enterprise service bus currently? What features do you look for in an ESB container, or what would make you use a specific one?

    Threaded Messages (16)

  2. Excellent[ Go to top ]

    Congratulations on the new release

    We have been playing with 1.x for a while and are
    have been very satified with the quality, architecture
    and feature set - We plan to integrate (no pun intended)
    it into our solution offerings in coming months

    Keep it coming, guys..

    Arun Rao
    arun.rao@resilientcorp.com
  3. congrats!

    -geir
  4. Why can't ServiceMix have documentation similar to that of Mule. Mule has decnt documentation.
  5. Documentation in the lines of Mule[ Go to top ]

    Why can't ServiceMix have documentation similar to that of Mule. Mule has decnt documentation.

    We're working hard on that, the documentation should get much better over the next month or two.

    James
    LogicBlaze
  6. ServiceMix versus Mule[ Go to top ]

    Are there anyone who has tried both ServiceMix and Mule? It seems that they have lot of overlap in their functionality. I've been using Mule a bit and like it a lot. Any comments?

    EIP Patterns Book Seems to be getting mentioned with ServiceMix and used as a design base for Mule. It's a great book on messaging patterns, really can recommend it!
  7. ServiceMix versus Mule[ Go to top ]

    I've used Mule in the last projects always with success. I'm interested to try ServiceMix, but I cannot find TCP/IP transport I need. This is the reason since I never tried it before...

    bye,
    Luca Garulli
    Pro-Netics.com (member of Orixo.com, the XML business alliance)
    OrienTechnologies.com (All in one JDO solution)
  8. ServiceMix versus Mule[ Go to top ]

    I've used Mule in the last projects always with success. I'm interested to try ServiceMix, but I cannot find TCP/IP transport I need.

    We use ActiveMQ to provide the TCP, UDP, multicast, SSL transports. Then it allows us to

    * use auto-reconnection and failover across networks
    * use discovery to find nodes to talk to
    * add compression onto messages
    * reliability, transactions and XA
    * pesistence if required
    * store/forward
    * publish/subscribe instead of just point to point.

    Is there any reason why you need just a trivial TCP transport?

    James
    LogicBlaze
  9. ServiceMix versus Mule[ Go to top ]

    I've used Mule in the last projects always with success. I'm interested to try ServiceMix, but I cannot find TCP/IP transport I need.
    We use ActiveMQ to provide the TCP, UDP, multicast, SSL transports. Then it allows us to* use auto-reconnection and failover across networks* use discovery to find nodes to talk to* add compression onto messages* reliability, transactions and XA* pesistence if required* store/forward* publish/subscribe instead of just point to point.Is there any reason why you need just a trivial TCP transport?JamesLogicBlaze

    Wouldnt this mean that a TCP client would need to also handle the JMS protocol?
  10. ServiceMix versus Mule[ Go to top ]

    I've used Mule in the last projects always with success. I'm interested to try ServiceMix, but I cannot find TCP/IP transport I need.
    We use ActiveMQ to provide the TCP, UDP, multicast, SSL transports. Then it allows us to* use auto-reconnection and failover across networks* use discovery to find nodes to talk to* add compression onto messages* reliability, transactions and XA* pesistence if required* store/forward* publish/subscribe instead of just point to point.Is there any reason why you need just a trivial TCP transport?JamesLogicBlaze
    Wouldnt this mean that a TCP client would need to also handle the JMS protocol?

    JMS is an API not a protocol; ActiveMQ does all the TCP stuff for you so its all invisible.

    Or is it that you need to talk to some external system which talks its own custom protocol over TCP?

    James
    LogicBlaze
  11. ServiceMix versus Mule[ Go to top ]

    I've used Mule in the last projects always with success. I'm interested to try ServiceMix, but I cannot find TCP/IP transport I need.
    We use ActiveMQ to provide the TCP, UDP, multicast, SSL transports. Then it allows us to* use auto-reconnection and failover across networks* use discovery to find nodes to talk to* add compression onto messages* reliability, transactions and XA* pesistence if required* store/forward* publish/subscribe instead of just point to point.Is there any reason why you need just a trivial TCP transport?JamesLogicBlaze
    Wouldnt this mean that a TCP client would need to also handle the JMS protocol?
    JMS is an API not a protocol; ActiveMQ does all the TCP stuff for you so its all invisible.Or is it that you need to talk to some external system which talks its own custom protocol over TCP?JamesLogicBlaze

    isn't JMS and API and also a protocol, because at the end of the day, you have 2 sockets and use the "JMS protocol" to send java strings backwards and forwards. So theoreticaly, if i knew the JMS protocol, i would be able to have a JMS client in, say PHP.

    (Googleing, i found this: http://sourceforge.net/projects/phpmq/)

    So my initial point was that a TCP client/server funtionality would be nessary in a ESB. For example to talk to a Mainframe via Tn3270(E). To answer your last question, yes we do some across cases where its easiest to use TCP.
  12. ServiceMix versus Mule[ Go to top ]

    I've used Mule in the last projects always with success. I'm interested to try ServiceMix, but I cannot find TCP/IP transport I need.
    We use ActiveMQ to provide the TCP, UDP, multicast, SSL transports. Then it allows us to* use auto-reconnection and failover across networks* use discovery to find nodes to talk to* add compression onto messages* reliability, transactions and XA* pesistence if required* store/forward* publish/subscribe instead of just point to point.Is there any reason why you need just a trivial TCP transport?JamesLogicBlaze
    Wouldnt this mean that a TCP client would need to also handle the JMS protocol?
    JMS is an API not a protocol; ActiveMQ does all the TCP stuff for you so its all invisible.Or is it that you need to talk to some external system which talks its own custom protocol over TCP?JamesLogicBlaze
    isn't JMS and API and also a protocol, because at the end of the day, you have 2 sockets and use the "JMS protocol" to send java strings backwards and forwards. So theoreticaly, if i knew the JMS protocol, i would be able to have a JMS client in, say PHP.(Googleing, i found this: http://sourceforge.net/projects/phpmq/)

    The JMS specification doesn't define a wire level protocol; thats an implementation detail.

    Incidentally here's a great open wire level protocol we support in ActiveMQ...

    http://stomp.codehaus.org/

    which has native clients for C, C#, Ruby, Perl, Python, Pike etc.

    So my initial point was that a TCP client/server funtionality would be nessary in a ESB. For example to talk to a Mainframe via Tn3270(E). To answer your last question, yes we do some across cases where its easiest to use TCP.

    When you're talking TCP is this some custom TCP protocol thats in house or something? Or is it a Tn3270(E) transport you want?

    James
    LogicBlaze
  13. ServiceMix versus Mule[ Go to top ]

    The JMS specification doesn't
        define a wire level protocol; thats an implementation detail.Incidentally here's a great open
        wire level protocol we support in ActiveMQ...http://stomp.codehaus.org/which has native clients for C, C#, Ruby,
        Perl, Python, Pike etc.

    In that case, my bad. I was assuming (my weakness!) it was a Protocol.
    When
        you're talking TCP is this some custom TCP protocol thats in house or something? Or is it a
        Tn3270(E) transport you want?JamesLogicBlaze

    Both actually. We do quite a bit of Mainframe integration work, hence the Tn3270. There arent any (good) open souce Tn3270 implementations, so we recently "rolled our own" than we plan to Open Source soon. Also a lot of the places where we run our software are not java-houses at all, so they have other systems running: PHP, Perl, VB, C++ etx and we need to talk to them. A simple TCP socket can do quite a bit ;)
  14. ServiceMix versus Mule[ Go to top ]

    When    you're talking TCP is this some custom TCP protocol thats in house or something? Or is it a    Tn3270(E) transport you want?JamesLogicBlaze
    Both actually. We do quite a bit of Mainframe integration work, hence the Tn3270. There arent any (good) open souce Tn3270 implementations, so we recently "rolled our own" than we plan to Open Source soon. Also a lot of the places where we run our software are not java-houses at all, so they have other systems running: PHP, Perl, VB, C++ etx and we need to talk to them. A simple TCP socket can do quite a bit ;)

    An open source Tn3270 Binding Component for JBI would rock! :)

    If you need to talk to non-Java systems then either try using a REST or Web Service stack - or you can use Stomp. All are supported nicely from ServiceMix today.

    James
    LogicBlaze
  15. Support non-XML message[ Go to top ]

    Does ServiceMix support non-XML messages in v2.0? Say integrate a FTP endpoint to collect non-XML messages from proprietary systems.
  16. Support non-XML message[ Go to top ]

    Does ServiceMix support non-XML messages in v2.0? Say integrate a FTP endpoint to collect non-XML messages from proprietary systems.

    Absolutely. The idea behind JBI is that a Binding Component can use any kind of data format / transport / protocol it wishes for input or output, it just exposes it as a NormalizedMessage (a bag of properties and a blob of XML) so that Service Engines can work with any Binding Component and add features like multi-protocol connectivity, content based routing, rules, transformations, orchestration etc.

    e.g. in ServiceMix many of our file/FTP/WebDAV based JBI components we tend to use a FileMarshaler plugin strategy to allow any transformation from a file to a NormalizedMessage and back again.

    James
    LogicBlaze
  17. Celtix and ServiceMix[ Go to top ]

    I have been working with Mule for a few weeks, and I can say I am truly impressed. Really takes the bite out of the IBM WebSphere Biz Integration, MQSeries, MessageBroker, Process Server "freighten your CIO into buying an overly complex solution" hype-machine. Hoping that ServiceMix has a similar feel as I plan to test run it next.

    Also noticed this regarding strategic alignment of IONA Celtix and ServiceMix:

    http://www.idevnews.com/TipsTricks.asp?ID=156

    Jeffrey Bonevich
    http://jroller.com/page/bonevich