Iona, a SOA infrastructure solutions provider, has announced the latest release of its Artix Enterprise Service Bus (ESB). Artix is an extensible ESB that is intended to reduce operating costs for organizations with complex and heterogeneous IT systems by managing and securing a SOA without a centralized hub. Artix uses distributed computing technology to leverage and modernize existing middleware investments. New features and enhancements include:

• Expanded standards, platform and transport support: The new release includes support for SOAP 1.2. Artix features persistent WS-RM, allowing applications to operate without concern for failure at the software component, system or network level. Remote Method Invocation (RMI) support adds additional platform and protocol interoperability.
• Enhanced orchestration: Greater support for the enterprise QoS required for SOA deployments. Security Identity Propagation enables the passing of secure credentials between services that are part of established BPEL processes.
• Management capabilities: The release includes availability of a JMX management console

As IONA's partnership with AmberPoint expands, this latest release also includes interoperability with the provider of SOA visibility, management and security solutions. This feature enables reporting on SOA performance metrics and supporting the configuration of policy changes and alarms and triggers. What do you think of this latest release of Artix?

I think the mentioned Release is 4.1. Here is the description with some additional details : http://www.iona.com/products/artix/new_in_4.1.htm The question is, which of this fine new features will be also available for the ESB Open Source Alternative: Celtix ? Roland SOA Kompetenznetzwerk Information & Collaboration Portal Portal-Relaunch with new Look & Feel and new Features upcoming ...

The question is, which of this fine new features will be also available for the ESB Open Source Alternative:

Take a look at the XFire site (www.xfire.org). It announces a merger between XFire and Celtix and it says that Celtix isn't really an ESB itself. It positions Celtix and something you would want to add to your SOA infrastructure in addition to an ESB. I wonder when that merger will be complete?

The question is, which of this fine new features will be also available for the ESB Open Source Alternative:

Take a look at the XFire site (www.xfire.org). It announces a merger between XFire and Celtix and it says that Celtix isn't really an ESB itself. It positions Celtix and something you would want to add to your SOA infrastructure in addition to an ESB.

I wonder when that merger will be complete?

We're hard at work on the merge right now. We're hoping to do an M1 very soon, but its a bit hard to give an exact date because its open source :-). So a few notes for the confused on artix/celtix/xfire in general: - Celtix provides a lot of ESB like features , but IMO isn't an ESB as it doesn't provide things like clustering or transformatiosn out of the box. It is a full JAX-WS implementation though. - Artix 4 isn't based on Celtix AFAIK, it is a different code base. - XFire and Celtix are merging to become Apache CXF. It will not be an ESB, but a services framework where services framework = web services (SOAPy and REST) + legacy integration (think CORBA things) Also, the xfire site is http://xfire.codehaus.org not xfire.org :-)

... We're hard at work on the merge right now. We're hoping to do an M1 very soon, but its a bit hard to give an exact date because its open source :-).

So a few notes for the confused on artix/celtix/xfire in general:
- Celtix provides a lot of ESB like features , but IMO isn't an ESB as it doesn't provide things like clustering or transformatiosn out of the box. It is a full JAX-WS implementation though.
- Artix 4 isn't based on Celtix AFAIK, it is a different code base.
- XFire and Celtix are merging to become Apache CXF. It will not be an ESB, but a services framework where services framework = web services (SOAPy and REST) + legacy integration (think CORBA things)

Also, the xfire site is http://xfire.codehaus.org not xfire.org :-)

Here is also an interested description of Celtix: http://www.iona.com/opensource/celtix/ Existing many excellent ESB-Solutions by the Open Source World. Generally I think, working together and sharing important Base-Technologies or Extensions with other solutions, builds always extented Synergies, which will help to produce the best solutions in straightforward term-categories. Roland

Artix is always described by IONA as the extensible ESB - referring to the fact that it is modular. That is, functionality comes in the shape of plug-ins that can be purchased at the node that needs it. Do people think this is a good thing, or a bad thing? Does it make more mature implementations a lot more expensive? Or does the low entry cost and ability to buy what you want where and when you want it outweigh this? My own opinion, as expressed in more detail in the LiteBytes blog featured at http://www.illuminatusresearch.com is that companies may find the need to continually buy additional plug-ins difficult to manage from a purchasing process point of view. Steve

Artix is always described by IONA as the extensible ESB - referring to the fact that it is modular. That is, functionality comes in the shape of plug-ins that can be purchased at the node that needs it.

Do people think this is a good thing, or a bad thing? Does it make more mature implementations a lot more expensive? Or does the low entry cost and ability to buy what you want where and when you want it outweigh this?

My own opinion, as expressed in more detail in the LiteBytes blog featured at http://www.illuminatusresearch.com is that companies may find the need to continually buy additional plug-ins difficult to manage from a purchasing process point of view.

Steve

In theory at least it is a good thing because you can buy and implement only what you need as you need it. Unfortunately, some vendors are selling a bunch of marginally related, incompletely integrated "modules" under a common product name. The "modules" are either products they acquired by purchasing this or that company, or are OEM'ing or something they found amongst their older products that was "close enough". Some vendors do a good job pulling this off but some end up selling "ESB construction kits". This variability and inconsistency gives the approach a bad reputation so many would be loathe to try such a product. I've not tried IONA's ESB, so I can't comment on how well they've executed this approach.

There also includes many new features of Artix Desginer in this 4.1 release: - support RMI binding, then you can create a web service using RMI protocol to talk to EJB in any J2EE container and vice versa, all these need you just click mouse - support one station security, all you need is select the security mechanism that you want, then Designer will do everything for you - support WS-RM, just create a new Eclipse launching configuration, then WS-RM will enable - support DB2 web service on z/OS, similiar like DB web service in Artix 4.0, now you can deploy a DB2 web service to z/OS directory in Designer - improved WSDL editor - improved z/OS support - improved Artix code generation - improved management console

Returning to the properly meaning of this article: Any experiences with Artix ESB 4.1 and the specified, new or extended features (WS-RM,...) ? Roland

I've spent quite a bit of time working with Artix recently, it's a very interesting technology. Distributed SOA is how I'd decribe it, a service enabling technology not an SOA as such but the ideal technology for enabling existing and new services into an SOA. The most interesting feature seems to be the lack of lock-in in the technology. You can describe interfaces and payloads through standard WSDL and Schema but using Artix you're not restricted to the "classic" and IMOHO crap Web Services technologies like SOAP over HTTP. In fact you're not even restricted to XML. Of course you can expose services as SOAP over HTTP or MQ/JMS if that's what you need but it opens the options up a little. You can take an existing ESB or EAI solution and essentially open up the integration points and topology. They use endpoint integration, i.e. they bind the payload, transport and transformation etc. into the endpoints. It works on C, C++, Java and .NET on Linux, UNIX, .NET and zOS (mainframe) meaning you can expose any application runing in any of the above languages on any of the above OSs as a service on any transport (JMS, AMQP, File/FTP, IIOP, MQ, RV etc.) I've seen a message from a C++ app talking to a Java app over MQ be changed to the same C++ app over HTTP to .NET. One of their engineers did this ona customer site in minutes, pretty cool stuff. -John- CTO C24

Hello John, very interested description of the work with Artix from a professional point of view. Maybe, some of the mentioned technologies should be also provided - more or less - by some other professional ESBs from the Open Source or Business Areas. Whould be very nice, to hear some more details of interested facilities from Artix, which are experienced in the real professional praxis. Maybe interested themes are e.g.: - the Performance-Criterions (what are the real facilities to use C++ instead of Java today ...). I think, Performance is a very important point e.g. in banking areas - Is the implementation of Realiable Messaging with Standard-Functionalities (WS-RM,...), in the praxis really recommendable and funcionally ... - what advanced, specialized Adapters or Protocols existing specially for Artix, which has greater extensions or are generally not supported by other known solutions .... Sorry for my simple English - every new day its a new learning day ... Roland

I was thinking of writing a little paper on some of the work I've done on Artix, I'll see if the TSS guys are interested in posting it. It's very rare for anyone to write anything from scratch in C++ these dayas and the performance argument died a few years ago. Java now runs consistently faster than most C++ applications, of course there are exceptions but every application I've seen in both C++ and Java, the latter has always out-performed the former. AMQP is a good example (AMQP is the new wire-level messaging protocol running a global trading application at JPMC), the Java version ran faster (but less consistently) than the C++ implementation, they were both written from scratch. Most C++ is legacy, it is most commonly found in calculation engines, these are awkward to change and re-write because so many applications and businesses depend on them. Given that the majority of internal services are writing in Java, Artix is a great way to bridge from Java to C++ without losing the performance. Of course you could have done the same with CORBA but Artix is providing a more "standard" way of defining the end-points using WSDL etc. The same pattern can be reused throughout the ESB or SOA. As for the Reliable Messaging etc. I afraid I can't comment I work on reliable transports so WS-RM has never interested me. I'm using Artix in a number of interesting enterprise scale scenarios for large Financial Service companies and it seems to do what it says on the tin very nicely. -John-

Thanks for this interested impressions from the practice. I think, many people would to hear more and so are very interested to see one these days the mentioned paper here on TSS ... Roland