Category Archives: ESB

Artix 4

The software engineers in IONA product development have been working nights and weekends lately. The usual build up to a product release. If it isn’t one of Murphy’s Laws it should be – projects closer to deadline take more of your time than projects farther from deadline.
Artix 4.0 shipped today. It’s a major upgrade in features, functionality, and stability. This will go a long way toward establishing Artix’s leadership position in distributed service oriented infrastructure technology.
Artix 4 includes:

  • Orchestration – deployable at the endpoint or intermediary – includes Artix multi protocol support
  • WS-RM – reliable messaging for HTTP
  • Data services – creating services from data sources
  • WS-Addressing support along with WS-Coordination and WS-AtomicTransactions

Because Artix already supports WS-Security, Artix has just become the first commercial product to support secure, reliable, transacted Web services.
Integration at the endpoints means placing a bit of software at the physical point at which applications share data with each other. This can exist completely in addition to existing hub and spoke architectures. Why not use this flexibility where possible and save money and time?
Artix 4 also is priced differently than previous versions of Artix. There’s one price for the core, and ala carte prices for plug-ins and protocols, so you can avoid a big up front investment in software.

The ESB Question

I think the issues with ESBs that Joe McKendrick highlights in some of his recent posts have to do with the way in which some vendors have implemented the concept rather than with the concept itself.
Enterprises need infrastructure for SOA deployment. In the debate about ESBs everyone can at least agree on the fact that the ESB is designed to meet requirements for SOA infrastructure.
However as Joe and others correctly point out, most vendors interpret this requirement as an excuse to reuse, repurpose, or reface their existing message bus technology with Web services and a bunch of fancy add ons.
The dilemma for us was whether or not to align ourselves with the ESB product category since we have a completely different approach, one that meets SOA requirements far better. Unfortunately, there isn’t another product category that’s a better fit for us. So I guess we just have to try to gain consensus that ours is the right approach ;-).
In the debate the need for a distributed infrastructure is recognized, like the one used in the Web. That’s exactly what we have done. We live at the application endpoints, service enabling them (you don’t need a Web server or an app server) and connecting the services however you want – peer to peer, point to point, or even hub and spoke (although we would recommend against this pattern for SOA).
Our architecture is definitely the right way to go, though. It’s microkernel based with plug ins, endpoint oriented, multi-communications protocol, multi-data format, with high performance, language neutrality, and enterprise quality of service – all based on WSDL and WS-*. This is what our customers told us they needed and wanted – and among our customers are some of the largest deployed SOAs in the world.
I believe this is also the reason Anne Thomas-Manes doesn’t like to include IONA in the ESB category. I hate it when we get lumped in with the other guys that just don’t get it, and we end up getting criticized along with the JMS centric crowd. An ESB is not JMS + Web Services +++ Not if it’s really going to meet customer requirements for SOA infrastructure.