Developer Product Briefs

Artix Cures Integration Headaches

Learn about the advantages of IONA's highly extensible Artix product and how it helps companies use ESBs to integrate new technology without scrapping valuable existing systems.

• By Nick Fuentes
• 10/29/2004

Companies encounter myriad pitfalls when integrating their existing large-scale enterprise architectures using Enterprise Service Bus (ESB) technologies. The key is to make these systems extensible. Ivan Casanova, an IONA senior product marketing manager, recently met with Nick Fuentes to explain the advantages IONA's highly extensible Artix product has in helping companies move forward with technology advances without scrapping valuable existing systems.

Q: Artix is a fairly new product. What are the main features that distinguish it from other ESB products as companies get a better handle on their integration activities?

Ivan Casanova: Artix is focused on service-enabling existing enterprise systems. The key differentiator for Artix is its extensibility. For a segment of the market, service-enabling existing enterprise systems means dealing with unique characteristics around things like protocols, transports, and enterprise QoS such as security and management. For these types of systems an ESB solution must be extensible. For the customers that have adopted Artix, extensibility is the reason cited for moving forward with Artix in their projects.

Q: What were the more traditional approaches to integration preceding the release of Artix?

Ivan Casanova: IONA believes that the foundation of integration is a sound architectural approach. Previous technologies forced organizations into an architectural construct that did not fit many applications. Centralized, large-scale EAI integration was forced upon customers—and they have not realized the kinds of returns on investment expected.

Using a distributed approach and moving integration capabilities toward endpoints in an SOA, services can be reused for multiple projects. Multi-channel access and client renovation—these are the use cases where we find customers adopting Artix because these are not applicable toward centralized EAI-style integration. The ESB approach is more suited for these use cases, and that's why the market is moving toward an ESB approach.

Think Long Term
Q: This isn't a one-shot deal, right? Can you implement this process now and continue to integrate things moving forward, long term?

Ivan Casanova: Yes, I think that's one of the really important concepts behind the ESB. By service-enabling existing enterprise systems customers can start to derive value early in the integration processes.

For example, we have a large-scale telecommunications vendor here in the U.S., and it service-enabled a mission-critical order-management application. Renovation of its call center drove that service enablement. But now they see that other applications can also be applied to access this service. They can extend that service to the Web, or for direct access over an IVR, for self-service to their customers, and that will provide them with value on the investment they've made today over a generation—and that's really important.

It's not an all-or-nothing proposition for integration. Customers can take an iterative approach, developing their own best practices and frameworks for best deploying these types of ESB technologies over a period of time, but still begin to deliver the value back to the organization early in the cycle of the project.

Q: You talked about centralizing the process and the longevity associated with carrying this technology beyond the initial project. What other qualities safeguard Artix from competitors in the marketplace?

Ivan Casanova: If you look at extensibility as the key differentiator for the ESB market, the features we have built into our product have created a significant barrier for companies to match our capabilities, especially at the high end of the marketplace.

For example, we have a unique plug-in architecture, which means the particular endpoint you've service-enabled has runtime plug-ins for the native transports and protocols of existing systems. If the back-end system is changed or migrated—to a lower-cost or more strategic platform—you can change the plug-ins in the endpoint to support the new target system. But dependencies created by the Web service interface for consumers of that service stay in place, and that type of abstraction is only possible when you have a plug-in architecture.

Another Artix core feature that creates this extensibility is our experience as a vendor of integration solutions for 14 years and the market leader in CORBA. For our CORBA customers we created plug-ins to support high-value enterprise qualities of service like security and enterprise systems management. Today these features are available in Artix. We support out-of-the-box Web services security standards such as WS-Security and Kerberos tokens, but we actually authenticate them against legacy security databases, or user databases. This is a unique capability.

Likewise, our support for BMC Patrol, Tivoli, and CA Unicenter enterprise systems management software is unique. Customers can manage these service endpoints using their existing enterprise systems management infrastructures, and that's a huge value.

Rely on Experience
Q: So a lot of Artix's strength is predicated on the experience IONA has in other areas to support it.

Ivan Casanova: Yes. IONA's heritage is of building distributed integration technologies for mission-critical systems in the most technically demanding applications. That's why customers have built IONA software into their network management systems, and Boeing uses IONA in its shop floor automation solution for assembling its aircraft inside its manufacturing facilities. Similarly, these high-performance, high-enterprise quality-of-service applications are where we see the uptake for Artix.

Recently we announced that Deutsche Post, Europe's largest logistics provider and the parent company of DHL and Airborne Express, has adopted Artix to build a cross-Enterprise Service Bus based on Artix. It did this because we supported enterprise features like security and management required for this type of strategic infrastructure, and we had the experience to deliver on a project that was important for the organization.

Q: You mentioned the telecom call center. Logistically speaking, what are companies looking at as they integrate these systems? What's the process they go through using Artix?

Ivan Casanova: The large-scale architectural movement where all these technologies fall under—Web services, ESBs, etc.—is SOA. The reality is that enterprise-scale SOA is still very much out in the future. What we see is customers picking off key strategic systems and service-enabling them as a good starting place. These systems will never be rewritten on some SOA platform like J2EE because they've been in production for a generation.

Another one of our customers has taken on a network provisioning application and shared that as a service based on SOA principles. It has a standards-based WSDL interface, and this WSDL-defined endpoint can easily be incorporated into new application development projects. And the new application projects are much more tightly aligned with the new business initiatives.

One telecom customer is launching into a new consumer market, and it wanted to leverage its existing order-management, billing, and provisioning systems because they'd been in production for a generation, and the systems were robust and supported the kind of scale the company wanted. It used Artix to tie together the components needed to support the new market and integrate with a Web-based customer service application. That's the model we see—service-enabling those types of systems in support of a new business initiative.

Extensibility is the Key
Q: IONA has coined 'Extensible Service Bus' vs. 'Enterprise Services Bus,' which is the generally accepted industry term. Can you speak as to why it's taken awhile for the marketplace to catch onto the extensibility part of the equation?

Ivan Casanova: We have fully embraced the Enterprise Service Bus product category. So our product literature and how we talk to the market focuses on the extensible Enterprise Service Bus, or extensible ESB. Certain times you'll find that term gets concatenated to Extensible Service Bus.

The real driver for this is education of the customer around SOA and Web services, which is now beginning to ramp up significantly. 12 to 18 months ago, it was all theory. But now they have some of these technologies in place and have begun to work with it.

Another driver has been from the tool vendors. Microsoft and BEA roll out development tools and runtime platforms like .NET or J2EE that support SOA and SOA development. Engineering groups within our customers' organizations start to build service-oriented applications. But what they've found is that a gap exists between the newer platform technologies based on Web services and their core existing enterprise applications that aren't service-enabled.

We refer to this as the 'extensibility gap.' The question is what tool are you going to use for service enablement if you have a core system for order management that's written in C++ and is a stateful server, is based on legacy protocol, doesn't speak XML natively, supports transactions, has its own homegrown security model, and has to be managed by BMC Patrol for enterprise systems management?

Well, the gap from a technology perspective between that system and a portal you built using Java and J2EE is significant. The larger that gap, the more extensibility is important for service-enabling the application. Artix customers are attempting to service-enable systems where the extensibility gap is significant.

That is driving the adoption of Artix for IONA, and this is where we're focusing our resources. We are driving our sales organization, our partner organization, and all of our marketing toward customers service-enabling those systems that are mission-critical and have a significant extensibility gap. Systems that can be easily service-enabled are a commodity problem. For example, service-enabling a J2EE application will be part of a company's J2EE platform if it isn't already, or it can be service-enabled using some commodity or open source type of tool.

For us, it's those existing enterprise systems with non-Web services protocols, non-Web services message formats—so they don't speak SOAP; they don't speak HTTP. Also, they have their own security model, must be load-balanced, need to be highly available, and must perform to scale to thousands of users and millions of transactions a day.

Q: With a growing company, no less.

Ivan Casanova: Exactly. That's where we believe other vendors are simply falling short. They're focusing on the commodity problems, and they're offering commodity technologies. IONA is really focused on solving the service-enablement challenge for a class of applications that has not been addressed yet in the marketplace. That's why we're seeing significant uptake in our business.

Getting Technical
Q: Can you speak briefly about the technical aspects of the product? How it's built, what language it's written in, and so forth.

Ivan Casanova: The product is based on IONA's patented runtime platform called the Adaptive Runtime Technology, or ART. ART is a cross-platform infrastructure that runs on more than 30 platforms. It runs on everything from a Windows box to a Linux box to the mainframe, and that's a unique capability—we can actually extend the Enterprise Service Bus to the mainframe.

We support both Java and C++—again, if you're going to have an extensible solution for customers, you've got to give them the flexibility to connect to either Java or C++ applications. We offer plug-ins for most of the major transport technologies and middleware platforms—things like CORBA, IMS and CICS on the mainframe, MQSeries, and JMS types of messaging systems. We have a plug-in for Tuxedo applications as well because that's a core runtime platform that customers want to service-enable.

We provide a set of development tools that are simple in nature and make it easy to configure your runtime and plug-ins. At the end of the day, all of these things resolve themselves into a highly portable, vendor-independent WSDL service contract, which is the interface for service consumers who want to consume that service after you've developed your endpoint.

Who Uses Artix?
Q: How many clients currently use Artix for these integration solutions?

Ivan Casanova: Artix has 14 customers, and a significant portion of them are in production today. Also we are beginning to understand the significant value these customers are deriving from Artix. The customers are based in the core verticals, where IONA has always been successful. As you might guess, these verticals have highly distributed, high-performance, mission-critical systems that run the business.

Telecommunications companies like Bell South and Sprint are customers and have these types of performance and enterprise quality-of-service requirements. Zurich Financial in Europe is a longtime IONA customer and is now an Artix customer. We've also begun to see significant penetration into the global logistics market, because companies in that market have a similar pattern to their infrastructure and enterprise requirements. We've also been successful with previously mentioned Deutsche Post.

Q: What's the future plan for Artix at this time?

Ivan Casanova: We're really focused on extending our leadership position in providing enterprise qualities of service. We'll provide some tools integration that will plug into some of the popular available development tools. We're looking forward to getting out there in the world and telling the marketplace what they can expect from IONA and Artix.