Iona

Tutorials on Distributed OSGi RI

Mon, 09 Feb 2009 13:10:30 -0800

This is a pointer to a new entry on my new blog about the new tutorials David Bosschaert has posted on his blog about the reference implementation of Distributed OSGi/RFC 119.

New Blog

Fri, 23 Jan 2009 11:15:50 -0800

After nearly 5 years of blogging at iona.com, it looks like the domain will finally be taken down, and the blog moved.

I've started a new blog called Modular IT on Blogger and will be creating at least the OSGi-related posts there from now on.

Depending on how and when this blog goes away, I'll keep posting other items here until it's clear what is going to happen.

I'd like to thank everyone who read and commented on this blog over the years, and am glad if I have been able to contribute to the "discussion" and to the emergence of this great new medium.

Eric

Update Jan 25: See the new blog for a writeup of the recent OSGi EEG meeting

Sun and OSGi: Cooperation through competition

Mon, 22 Dec 2008 18:05:47 -0800

Last week I attended my last OSGi Board meeting, which was hosted by SAP near Heidelberg. Although I'll remain EEG co-chair, Gordon is replacing me on the board.

As you might imagine, one of the hot discussion items was Sun's recent announcement of Project Jigsaw, their latest modularity initiative. Hal, Mirko, Peter, and Neil have already recorded their thoughts in their blogs, and I don't want to repeat what they've already said.

One way I like to sum it up is that it wasn't the breakthrough we were hoping for. After Sun rejoined the OSGi Alliance last year, and announced they were using OSGi in Glassfish, OpenESB, and ProjectFuji - not to mention hiring the Apache Felix project lead - many of us started thinking Sun might finally bury the hatchet. But no, Sun has apparently decided to cooperate with us by competing with us.

We knew, of course, that Sun is kind of schizo about OSGi. I did my best to encourage them to participate in the EEG, and after Sun hired Richard, I guess you could say that sort of happened. But he still is primarily focused on Felix, which is understandable. We have not seen or heard anything from Mark Reinhold and his colleagues, however.

And now we have to worry about the confusion Sun's announcement creates. I can't see the customer or the industry benefit in having to choose between two modularity systems. Do we really expect all the vendors that are currently shipping hundreds of products on the OSGi Framework, to invest in supporting an additional modularity framework for their products, just because Sun proposes it? Yet it is certain to raise questions and generate debate, just as the end is in sight for the OSGi enterprise release.

We have released an updated draft (warning: this is a pdf link) of the current design documents. Several of these have been submitted to expert group vote so that the final phase can begin - writing the specifications. (BTW it's not too late for comments and feedback on the updated drafts.)

You may know that the OSGi Alliance is unique (at least among standards consortia I've worked with) in hiring someone to write all the specifications (Peter Kriens, of course). I think this is one of the reasons the OSGi specifications are so good - and because Peter has been with OSGi since the beginning, he can ensure continuity and consistency.

With any luck, we will be more or less done by March, 2009. I am not exactly sure what the bits and pieces of designs we have add up to yet - I think one of the major work items (in significance if not effort) is to check the current designs against the original requirements, and against several scenarios people are likely to want to use OSGi technology for in the enterprise - such as building web applications, distributing an application's processing work, or managing persistent data.

I want to be sure the release adds up to something, and that it will have the best chance at being adopted. This was, of course, another important discussion item during last week's Board meeting: getting the enterprise release out and ensuring its success.

For me one of the big factors has always been, and still is, whether or not enterprise developers will adopt the OSGi programming model. I am optimistic.

It's Progress, After All

Wed, 25 Jun 2008 12:05:07 -0700

It definitely seems like a long time since the process started, but this is about as good an outcome as we could have hoped for.

The number of employees who have both IONA and Progress on their LinkedIn page is probably a couple dozen or even more. We have been neighbors in the Boston area for a long time and there has been a lot of cross-pollination.

Although we have been competing in the ESB and SOA space, we have had a common vision and very similar positioning in the market. It's a bit like two former rivals of the basketball court, each with different strengths and skills, finally getting put on the same team. And it's actually this aspect that's the most interesting - putting together two strong teams with complementary expertise.

I started thinking about this because one of the questions we keep getting on the analyst briefings is how we plan to combing the Artix suite and the Sonic ESB family.

First, it's interesting to note that both companies have been moving away from a "pure" ESB positioning toward a "suite" or "family" of products for SOA. So the question is actually a bit broader: how can we sensibly combine multiple product components and create the best independent and comprehensive "anti-stack" SOA offering?

Some of the specific details are yet to be worked out, but we have always known that even while we were promoting Artix as a unique, configurable microkernel aimed at endpoint integration requirements, the Sonic family's approach, based on leading JMS technology, is something that meets a lot of different and equally important SOA requirements. The Artix suite's focus on distributed service enablement actually adds a lot to the Sonic family, and even as we positioned ourselves competitively in the past I think we each always knew this somehow.

One of the more interesting aspects is the future of the FUSE product line and the view of the combined company toward the open source projects with which we've been involved. We have already seen this commment on the Server Side. As one of the folks who champoined getting involved in open source I am glad to say the Progress folks I've spoken with are very interested and enthusiastic supporters, and see a lot of value in the announced acquisition in helping to get more involved in open source.

We have also worked together as partners. A few years ago we were resellers of the Progress Sonic MQ product, and Artix still offers native integration with Sonic MQ, as does the recently released WCF Connect product. And more recently we had begun integrating the Actional SOA Management product line with the Artix suite and selling them jointly.

A couple of years ago I had the unusual situation of being asked to share a half-day SOA tutorial with someone from Progress. For the first couple of hours we took turns saying exactly the same things about SOA, application architecture, and the unnecessary complexity of Java EE application servers. Then we each took a turn describing how our respective products met the same requirements, and served exactly the same segment of the industry (i.e. SOA infrastructure) with different approaches. Instead of arguing over that, we can now agree 100% and are part of the same team.

News: VOCALINK SELECTS IONA ARTIX DATA SERVICES TO SUPPORT EURO PAYMENT SERVICES

Tue, 29 Apr 2008 03:30:00 -0700

DUBLIN, Ireland and WALTHAM, Mass. - April 29, 2008 - IONA(R) Technologies (NASDAQ: IONA), a world leader in distributed service-oriented architecture (SOA) infrastructure solutions for performance-demanding IT environments, today announced that VocaLink, the transactions specialist, has selected IONA Artix(TM) Data Services as a component of Vocalink's Euro Payment Service for its pan-European and global customers. VocaLink provides its customers with the facility to translate legacy format payments into a SEPA compliant format, using Artix Data Services, minimizing the impact of SEPA compliance for customers.

News: MILESTONE GROUP SELECTS IONA ARTIX FOR REAL-TIME FINANCIAL MESSAGING INTEGRATION

Mon, 03 Mar 2008 21:30:00 -0800

DUBLIN, Ireland and WALTHAM, Mass. - March 04, 2008 - IONA(R) Technologies (NASDAQ: IONA), a world leader in distributed service-oriented architecture (SOA) infrastructure solutions for performance-demanding IT environments, today announced that Milestone Group, a specialist supplier of next generation fund processing and investment analytic software to investment managers, banks, life companies, custodians and hedge fund administrators, has selected IONA's Artix(TM) Data Integration solution to extend the messaging and integration capabilities of their pControl funds processing platform.

みんなで渡れば怖くない…

Wed, 20 Feb 2008 18:41:06 -0800

JUASというITのユーザ団体があって、よくセミナーのお知らせをいただくのですが、結構、費用がかかるので、参加したことはなったです。今回、3,000円と手頃だったので、OSS（オープンソース）の適用の阻害要因についてのお話を聞いてきました。モチベーションとしては、我々もクローズソースのESBとオープンソースのESBの両方を影響するハイブリッドな戦略をとっているからですが、日本の事情はUSとも違うという考えを持っていたからです。ITの環境で日本とUSの違いはオープンソースに限ったことではないですが、昔からUSから18ヶ月遅れて日本は新技術が適用されるなどという通説もあります。でも、話はそれほど単純ではないと思います。このセミナーに結論があるとしたら日本のITユーザには「みんなオープンソースを使っていますよ」と言って促すことだということです。日本のITユーザは「みんなで渡れば怖くない」という前提があるように思います。プロダクトアウトを前提にしている我々からするととても大きな壁です。最初の話から日本ので事例を聞きたがりますから。 USでも同じような傾向がありますが、日本ほど画一的ではないように思います。平成19年情報通信に関する現状報告　特集「ユビキタスエコノミーの進展とグローバル展開」の6ページや30ページに日本とUSの成長や投資の違いが表されています。やはり、なんらか先行するべきという気持ちがこの違いに現れているように思うの私だけではないと思います。なんだか批判めいたことになってしまいましたが、我々ベンダーとしての責任はもちろんありますし、実際のビジネスとして生き残るためには、避けることはできない問題です。

News: IONA ANNOUNCES PRELIMINARY Q4 2007 RESULTS

Wed, 09 Jan 2008 02:00:00 -0800

DUBLIN, Ireland and WALTHAM, Mass. - January 9, 2008 - IONA(R) Technologies (NASDAQ: IONA), a world leader in distributed service-oriented architecture (SOA) infrastructure solutions for performance-demanding IT environments, today announced preliminary results for the fourth quarter ended December 31, 2007.

News: IONA LEADS SOA INNOVATION WITH LATEST ARTIX RELEASE

Mon, 10 Dec 2007 02:00:00 -0800

DUBLIN, Ireland and WALTHAM, Mass. - December 10, 2007 - IONA(R) Technologies (NASDAQ: IONA), a world leader in distributed service-oriented architecture (SOA) infrastructure solutions for performance demanding IT environments, today announced updates to IONA Artix(TM), the company's advanced SOA infrastructure suite. With Artix, IONA offers Global 2000 customers an alternative to centralized and proprietary middleware stacks shortening implementation times, reducing costs and generating greater ROI from their existing IT assets.

News: DZ BANK SELECTS IONA ARTIX FOR SOA GOVERNANCE

Mon, 05 Nov 2007 00:30:00 -0800

DUBLIN, Ireland and WALTHAM, Mass. - November 5, 2007 -- IONA(R) Technologies (NASDAQ: IONA), a world leader in distributed service-oriented architecture (SOA) infrastructure solutions for performance-demanding IT environments, today announced that DZ BANK, a leading international bank with European headquarters in Frankfurt, Germany, has selected Artix(TM) Registry/Repository to actively govern the use of services across the company's distributed SOA.

News: IONA RECOGNIZED AS "A UNIQUE PLAYER WITHIN THE SOA MARKET" BY CURRENT ANALYSIS

Wed, 24 Oct 2007 01:30:00 -0700

DUBLIN, Ireland and WALTHAM, Mass. - October 24, 2007 -- IONA(R) Technologies (NASDAQ: IONA), a world leader in distributed service-oriented architecture (SOA) infrastructure solutions for performance-demanding IT environments was recognized by leading competitive analysis firm Current Analysis as a 'unique player within the SOA market.' In a recent competitive intelligence report covering IONA's FUSE(TM) family of open source products, Current Analysis highlights that the current FUSE release builds upon 'both brand and technology acquired from LogicBlaze' and 'dramatically helps IONA differentiate its open source SOA products.'

Climate Servers Computing

Sun, 30 Sep 2007 22:10:46 -0700

GoogleとIntelがデスクトップコンピュータの消費電力の浪費から生じる温暖化問題に対応する非営利団体を立ち上げています。デスクトップのコンピュータの30％から40％の電力が浪費されているそうです。コンピュータの電力消費の調整機能は90％が無効にしていると言われています。 CPUのクロックも頭打ちであり、IT技術は新たな課題を背負わなければならなくなっていると思います。温暖化問題など地球上のあらゆる物事を正しく維持するための方法を考えることをSustainable Developmentといいます。非常に大きな課題であり、解決に近づけるためにはITの力が不可欠です。そのIT自身もその技術の限界を試されていると思いますが、いかがでしょうか。

ServiceMixがApacheのトップ・レベル・プロジェクトへ

Thu, 20 Sep 2007 19:52:57 -0700

アイオナのオープンソース製品の中核になるFUSE ESBのプロジェクトであるApache Software FoundationのServiceMixがインキュベータからトップ・レベルのプロジェクトに昇格しました。アイオナのオープンソース戦略はヨーロッパのコミュニティのObjectWebのCeltixプロジェクトから始まりました。その後、CeltixはApache Software Foundationへ移行するとともにXfireプロジェクトと統合し、Apache Software FoundationのCXFプロジェクトとなっています。さらに、2007年4月にServiceMixやActiveMQを提供していたLogicBlazeを買収し、新たなFUSE製品群を発表することでオープンソース戦略をアップデートしています。 ServiceMixのトップ・レベル・プロジェクトへの昇格についてはアイオナのプリンシパル・エンジニアのGuillaume Nodet のブログをご参照ください。

オーバーレイ・ネットワーク

Mon, 10 Sep 2007 21:30:35 -0700

TMFのTokyo Symposium 2007が東大の工学部の講義室で行われたので資料としてのカタログ詰めとともに参加してきました。学部の講堂としては立派なものですが、資料を袋に詰めるのは人海戦術で各社のカタログを一枚ずつ束ねていく作業をやっていました。200名弱くらいは参加されたのでしょうか。TMFというテレコムのOSS開発に特化した内容ですので中身は濃いものとなります。展示も数社あったのですが、狭いところ活発なコミュニケーションができていたようです。その中で、ソフトバンクテレコム株式会社の研究所の米田　進様の講演でオーバーレイ・ネットワークという話題がありました。Web2.0の発想を元にして、XMLのメッセージのネットワークのプラットフォームを構築しようというもので、実験を行っておられるようです。インターネット上を検索してみると、NGN+S 2007での講演やソフトバンクテレコムの広報サイトでも同様のお話しをされています。アプローチの仕方が違うので、同じものであるとは言えないのですが、以前のエントリのインターネット上のESBの考え方と位置は同じです。米田様はRFIDに代表されるようなID管理をこのプラットフォーム上で実現することを想定されていますが、同様にこのプラットフォームを利用して実現するアプリケーションを考えていくことはなかなかおもしろうそうではないでしょうか。そこにはアーキテクチャの重要性が含まれていると思います。

Last Week SOCA. This Week Catalyst

Wed, 27 Jun 2007 17:27:19 -0700

Last week I was in L.A. talking about SOA on an expert panel at SOCA 2007. It was an honor to be on the panel. I really enjoyed Prof. Wei-Tek Tsai's discussion about how the process for developing SOA has not yet being completely figured out yet. He claims there was a big shift in methodologies and processes when we went to OO and that a similar shift is needed in SOA. I mentioned some of my experience in this shift in a previous blog called Trusted Services Network. I hope to catch up with Prof. Tsai regarding this in the future.

Today I've just finished my presentation on OSGi at Burton Group's Catalyst conference in San Francisco. My presentation was well received. I'll blog on OSGi soon. I will say that it was amazing how complimentary the presentations in my session were. It was almost as if we had rehearsed the message but we had not.

One of the cool presentations was Jeff Barr's from Amazon regarding their web services. His discussion on Amazon's approach to web-Scale Computing really was an eye opener. I'm embarrassed I didn't know about this before. I knew that Amazon was providing Web service APIs for developers but I had no idea that they had a complete infrastructure for organizations to utilize. Hardware and infrastructure as a service. This is not unlike what some of the large telecommunications companies are trying to do - i.e. provide their infrastructure for people to deploy their services. Amazon is providing that and more - the ability to host your entire IT on their "network".

No need for Wedges

Mon, 25 Jun 2007 12:49:28 -0700

I really enjoy reading Joe McKendrick’s blog over at ZDNet. In fact, most of the bloggers over at ZDNet offer a lot of good insight on a lot of different topics. The site is well worth a regular visit or an RSS subscription. It’s Joe’s entry from June 22, “Time to drive a wedge between SOA and Web services?” that really caught my eye. Interestingly, the general idea of what he’s saying, along with several of the folks he quotes, is what IONA has been saying since we started talking about SOA. Granted, the headline is a little sensational – not too over the top – but a little bit, and I guess it worked because it got me to read the entry. The philosophy that SOA and Web services need not be intrinsically joined at the hip is one that we fully support. But do we really need to drive a wedge between the two? I’m amused when people casually throw around terms such as “always.” You hear that word often in relation to SOA deployment, especially from the vendor community and especially if a vendor’s product grew up out of a specific industry segment. How often have we heard that SOA is always about integration…or reuse…or interoperability? Or heard arguments about Web services always being the best way to implement your SOA…or in some schools of thought never? I find it hard to believe that so many people believe the world of SOA is so black and white. The real power of SOA is found ultimately in the flexibility of this computing methodology. And when choosing the underlying technology, it can't be an all or nothing argument. An ideal SOA environment should be able to evolve easily as the technology landscape changes. Remember, SOA isn’t new. The acronym may be, but the approach is well established. IONA customers were deploying SOA 10 years ago on CORBA, and many of those systems are still up and running and delivering value. Today, they’re taking those existing systems and making them a part of new systems that incorporate the latest Web services standards, and who knows what they’ll be doing tomorrow. To that end, IONA just added a bunch of new capabilities in the latest version of Artix that allows developers to take advantage of scripting languages and build REST-based services. Our technology is evolving at the same time as the needs of our audience. The beauty of SOA is that there’s no need to choose sides or employ wedges. SOA isn’t a specific technology – or rely on a specific technology – and you should be wary of anybody that says or implies otherwise.

SOA - its not just for Christmas

Thu, 17 May 2007 10:35:41 -0700

Just back from some great days in Stockholm, at a SOA conference there. Great event, great people - at the end of the event the organisers asked me to prepare an executive summary, which I'm attaching inline below. In a nutshell: SOA is maturing nicely, but EDA and REST have a big part to play in SOA solutions.

The "SOA for the Services Industry" conference took place this year in Stockholm, bringing together battle-hardened SOA practitioners, industry visionaries and solution providers, under the banner theme "Beyond the Introduction: Managing SOA for a Decade". The event lived up to its promise of bringing to bear the idealism and purity of the SOA architectural vision with on-the-ground experience and real-life use-cases. IONA Technologies was delighted to sponsor and chair this event. A recurring theme that emerged throughout the presentations, panel discussion and conversations throughout the event was that "SOA is just part of the solution". Many of the case studies, drawn from the airline, financial services and telecom industries, showed that while a SOA-based architecture formed the backbone of their thinking, Event Driven Architecture (EDA) also formed a key role. One delegate captured this succinctly, saying "our business is event-driven ". Gartner's proposal for a "SOA 2.0", which emerged mid-last year amidst much debate and mixed acceptance, declares EDA to be a key differentiator from its predecessor; however, some delegates felt that EDA is already a de facto part of existing SOA solutions. Case studies showed also that the principals behind REST architecture, as defined in Roy Fielding's thesis, are also immensely important in designing distributed scalable systems. Delegates found some agreement on the idea that SOA does not always have to be an enterprise endeavor - the principals and technologies behind SOA can be applied at an application or project level to good benefit. In fact, one delegate was keen to point out that the feudal nature of his organization meant that any attempt to impose an enterprise-wide methodology was simply doomed to fail for political reasons alone. By applying SOA principals in the small there was a greater change of building a groundswell and ultimate acceptance. Applying all elements of SOA architecture, from services creation and deployment right through to orchestration and choreography, just "for the sake of it", is clearly misguided; one delegate went as far as to say "It's almost better to have no SOA at all, than a badly done SOA". The use of SOA as a business facilitator, supporting and easing mergers, acquisitions and outsourcing programmes was demonstrated in a number of presentations in the telecoms and airline sectors. The importance of governance and organizational training in achieving SOA success was also stressed. All were agreed that SOA is perhaps now far more a people problem than a technical problem: aligning an organization to understand and capitalize on SOA, or rather, aligning a SOA to facilitate and support an organization’s DNA, may be the greatest challenge. And, in the long term, remember that a SOA is "not just for Christmas": SOA practitioners must consider the cost of ongoing deployment, evolution and maintenance of SOA systems. Planning for success requires strategic thinking around version control, ownership and scaling is crucial for success in the long term. The event was organized by Inoventa; for more information on the event, and to download conference materials, go to http://www.inoventa.com/

Getting the message right

Mon, 23 Apr 2007 08:20:24 -0700

As a vendor, independent validation of your messages and positioning is always nice to see. That validation is even sweeter when it comes not from an analyst that you’ve briefed, or even your own customer, but rather from someone you’ve never met. I know that may sound a bit strange, but hear me out. For sometime now, IONA has been talking about how the term SOA may be new, but the underlying principles have been around for quite sometime. In fact, we can look back 10 years to customers that were building SOA on Orbix, our CORBA technology. We’ve also been strong proponents of a SOA strategy that calls for incremental adoption, from both a cost and technology perspective. We like to say that when implementing SOA, customers should be able to “Think big, start small and scale fast.” I came across a very interesting opinion piece written by Galen Gruman, identified as a US CIO. The article, The Real Challenge of SOA: Four Steps to Making Your Business Transform, sounds like a page from the IONA playbook. Many of the examples called out show that organizations have been "doing SOA" since before the term was made popular and highlights that many organizations are not falling for the "Big Bang" hype. The first challenge called out advises, “deploy in pieces but create a long-term plan.” I feel like I’ve heard that somewhere before. The second piece of advice is to take governance seriously. We recently launced Artix Registry/Repository to address that exact issue, and to do so in a much more “active” way then is currently available. The third piece of advice, about rethinking the talent pool, makes a lot of sense, but doesn’t have a direct correlation to IONA. However, the fourth item, about applying SOA principles to data, is a big part of our recent acquisition of C24. Read the article and let me know what you think.

IONA Advances SOA

Fri, 30 Mar 2007 11:24:19 -0700

It's been an exciting month at IONA. First IONA acquired C24 and therefore strengthened both its technology in terms of data services including transformation, but also it's penetration in the financial services industry. Then this week IONA announced availability of a new product Artix™ Registry/Repository which I believe will have a major impact on how companies will view SOA governance.

QCon London, Celtix Enterprise and AMQP

Tue, 20 Mar 2007 13:35:17 -0700

I got to go to QCon in London this year, and decided to put together something challenging for my presentation. I'd been playing with Unified Business Language (UBL 2.0), and posed the question: how easy would it be to build a Celtix Enterpise server that can accept a UBL invoice in a variety of formats (XML, SOAP, JSON) over a number of transports (AMQP, JMS and HTTP)? Finding the answer turned out to be a lot of fun: Using Eclipse, WTP and Celtix Enterprise I quickly got a WSDL contract together for the service, along with bindings for XML and SOAP payloads. After that, implementation was straightforward JAX-WS - all the details are provided in my slideware, which I'm attaching to this blog. Using JSON was a little tricky, but thanks to some help from Dan Diephouse (Thanks Dan!) I used the Jettison STAX implementation with an XML binding to produce both Badgerfish and mapped JSON. It's a pragmatic approach, but I'd prefer it if there was a bona-fide JSON binding for WSDL that handles these detail, taking JSON support out of the code and into the contract. Maybe that's something we should get into the Apache CXF roadmap? While it's always great to put a lovely demo together and have it work on the day, its doubly rewarding to see how relevant this stuff is: AMQP is a hot topic right now and the ability to simply configure AMQP in to a pure-Java JAX-WS client or service is really nice. Also, as Sailesh Panchal of Travelex was keen to point out in his presentation, the ability to support XML and SOAP payloads over multiple transports is hugely important in terms of producing really reusable services, supporting both REST and SOA architectures. Next up? I'd like to push my demo a little further to get some performance stats over different payload and protocol combinations: I've heard talk that JSON parsing can be up to 100x faster than XML parsing: let's see if that really holds true. Also, I'm keen to test the fundamental premise of AMQP: on-the-wire interoperability between different messaging middlewares. Right now my client, service and broker are all Apache QPID, the AMQP implementation that comes bundled in Celtix enterprise. I'd like to see what happens if when I swap the qpid broker with open-amqp or RabbitMQ... watch this space for more... Download Ade's slideset

Artix & Microsoft Update

Mon, 05 Mar 2007 15:42:23 -0800

For the last two weeks I had the pleasure of working with Conor from our Dublin office on some of our Microsoft initiatives. We decided that, for a change, we'd have Dublin engineering come to Colorado instead of me heading over to Dublin. This meant Conor traveled over to work out of the Colorado Springs office - my home office now. He didn't have many complaints.

Conor and I had lots to do. We mainly worked on the CSF sandbox activity which IONA has recently signed up to participate in (see CSF Network Mashups). We haven't published anything up there yet but we're working on a service that will allow ISVs to expose their CORBA based services in the CSF sandbox. It should be there in a week or so.

As well as building what is essentally a routing appliance that routes from SOAP/HTTP to CORBA IIOP, Conor and I also took a look at IONA's next generation integration with Microsoft's platform based on WCF. It's going to be pretty cool. WCF is not unlike Artix in that it is based on interceptor chains that abstract away much of the complexity of the middleware. By linking together various interceptor implementions different flavors of "middleware" can be achieved. Artix provides connectivity out of the box to legacy applications built on various middleware including CORBA, Tuxedo, MQ Series, Tibco RV and many more - including proprietary and custom technologies. And Artix runs on non-Windows platforms as well as Windows. So we can help extend the reach of WCF.

Anyway, it was a pretty geeky week as you can see. Conor and I received our geek shirts at the Microsoft Vista launch in Seattle and decided to take a picture in the Colorado snow before he headed back to Dublin to his team. (We may never live down this picture. My wife is proud and my Mac friends are threatening to disown me ;-) And no, the caption to the picture is not "I'm a Mac ... I'm a PC".

Now we need to get down to the real hard work of finishing out the sandbox project and pushing ahead on our other Microsoft related work! Fun stuff ... even for a Mac guy.

Rapid SOA service test and simulation with Artix

Wed, 07 Feb 2007 23:37:00 -0800

In any production distributed system, testing is crucial: services don't make it into the production environment unless they've passed rigorous tests in unit, system, and user-acceptance environments. Running services in non-production environments is typically easy if you have all the deployment artifacts close to hand, and a bed of appropriate sample data to fuel testing - generally, in any solid development environment, this is going to be the case. Many services, however, do not live in isolation: the implementation of their business logic may require other services further down-stream. So, in order to test your service, you've got to deploy the down-stream services as well. Sometimes, however, you don't have access to the back-end service deployment artifacts, so you can't deploy an instance of this service in your test environment. I worked recently with a customer who had exactly this problem: their system depended on a third-party service for which no test environment was readily available. As a result, they could not test their own service in a timely fashion; instead, they had to negotiate a "testing window" with the third-party, and run all their tests within this testing window. The delays in making these test windows available were seriously impacting this customers ability to roll-out new releases of their product, holding up their design, test and development process. So - how does Artix solve this problem? Using Artix it's possible to rapidly build and deploy a service simulator (or "stub") that can be deployed in a test environment, allowing you to continue with the testing of your core systems. Using Artix allows you to pursue a number of different "Service Simulation" strategies:

Randomized Service Simulator.Using Artix's code generation tooling, a service implementation can be generated, compiled and deployed in minutes that generates randomized responses to incoming requests. This is a great way to ensure that connectivity between your software and the stub is being exercised, and can assist in performance and stability testing. One draw back of this approach is that, if your own system performs data validation, then the random values returned may be inappropriate.
Black-box Service Simulator.Using the Artix "Universal Test Harness" framework, you can define a set of pre-canned responses, providing rules on when each response should be used. For example, if a valdateCreditCardNo() operation arrives with a well-known test string such as "1234-1234-1234-1234", then return a response that indicates a successful validation. Black-box stubs can be built in a matter of hours, and are suitable for stateless services where all the information required to return a valid response is present in the incoming message. The approach is called "black-box" because it treates the service as a black box and does not attempt to simulate internal business logic of the service.
White-box Service Simulator. There are times when black-box approaches (outlined above) are not rich enough to simulate the required behaviour. For example, consider an interaction where a test client invokes getCustomerDetails(String id), updateCustomerDetails(String id, Details d) and then getCustomerDetails(String id). A typical client-side test would expect that the second call to getCustomerDetails() would return a different response from the original call, where the customer's details have been updated accordingly. Recall that the black-box approach is good for simulation of stateless services; here, the service is stateful: it must rememember the customer's details across different invocations. This use-case requires white-box simulation, where code is implementated that simulates some of the service's internal business logic. Artix provide a set of productivity tools, through its tight integration with Eclipse, that allow such services to be rapidly constructed within a day or two.

IONA and Microsoft

Mon, 05 Feb 2007 09:11:55 -0800

Recently I've been working on IONA's partnership with Microsoft. That has been keeping me very busy. Trips to Redmond, Nashville and Copenhagen for various events, and lots of other activities.

Prosspero - ソフトウェアソリューションの有効化

Thu, 01 Feb 2007 19:31:27 -0800

TMF（TeleManagement Forum）の今年の活動の目玉にProssperoがあります。Prossperoの名前の由来はNTTコムウェアの野本様のブログにあるようにシュークスピアの戯曲に出てくる人物で、混沌とした社会の秩序を取り戻した功績があるそうです。TMFはフォーラムの活動の結果として標準化に順ずるOSS/BSSの仕組みの共通化を行ってきましたが、実際のアウトプットをマーケットで有効な存在とするための効果が上がっていませんでした。いわば、OSS/BSSに関する先進の技術のキャズム（新しい技術が先進的な利用者の閉じた利用からマーケットへ出ていくことをいいます。）を超えることができていなかったということです。Prossperoは、このキャズムを超えるためにいろいろな場面で製造されたソフトウェアのアプトプットをパッケージ化することで利用を促進することを狙っているようです。これは、Celtix Enpterpriseで複数のオープンソースを統合して製品化したのに似ています。個々の技術をインテグレーションして使えるものにしていくことが重要性に着目してみてはいかがでしょうか。技術を開発して世の中に出していくのは時間と労力がかかります。しかも、時間をかけて開発した技術がマーケットに受け入れられなければ消えていく運命となるのです。このような、いわば無駄を回避するのがインテグレーションです。 SOAのひとつの側面にアッセンブル（組み合わせ）の考え方があります。サービスを組み上げてコンポジットなサービスを作ることです。Web2.0ではマッシュアップです。そんな中でProssperoという考え方が出てきたのは、ITの世の中の流れを示しているのではないでしょうか。江川

Porting JAX-WS applications across web services toolkits

Thu, 01 Feb 2007 05:54:53 -0800

One of the proposed benefits of a specification like JAX-WS or JAX-RPC is that you can easily move your application code from an existing web-services toolkit to another - the specification-compliant APIs used in one toolkit should be compatible with those of another toolkit. I recently put this idea to the test when I migrated a load of ObjectWeb Celtix application code to CXF. For those that don't know, Celtix, the open source ESB that originally resided at ObjectWeb, moved to Apache last year, merging with the XFire project to become CXF. CXF has an substantially different runtime to ObjectWeb Celtix, and can be considered an entirely different toolkit. By the way, IONA's "Celtix Enterprise" product contains CXF as its JAX-WS core runtime. Just for clarity, I use the terms "Objectweb Celtix" and "Celtix Enterprise" instead of "Celtix" on its own, to distinguish between the original ObjectWeb project and the IONA offering based on CXF. So - how did I get on? The porting turned out to be much easier than I thought: JAX-WS does have its advantages. As you'd expect, however, my porting effort was not uneventful. Here are some areas to look out for if you're attempting something similar. Packaging, building and environment The development environment changed (slightly) from ObjectWeb Celtix to CXF; for example, instead of a CELTIX_HOME environment variable you should set CXF_HOME. Also, an obvious difference is that the classpath has changed significantly: you need to modify your Ant files so that the new JARs are picked up. Some other not-so-obvious issues arise: I went looking for some XML Schema definitions for configuration beans in CXF and couldn't find them under the CXF installation directory; it turns out that these schema are all held in a JAR file in the CXF distribution. Toolkit specific APIs While the JAX-WS specification covers the bulk of the APIs for implementing your service and creating an endpoint, every toolkit typically supplies its own APIs to do additional things such as configuration, registration of handlers, etc. ObjectWeb Celtix had the concept of a Bus, implemented by the class org.objectweb.Celtix.Bus. CXF also has a Bus concept; however, the CXF Bus is is located in a different class (org.apache.cxf.Bus) and has a different API for instance creation. If your application relies heavily on toolkit-specific APIs then you will have to take this into account when you being a porting or migration activity Implementation glitches I was surprised to find some implementation differences on the interpretation of the specification. Thankfully, these were small and easily fixed; however, the experience has pointed out that there's no substitute for testing. For example, if you call the JAX-WS getPort() API on a client side service object then, in CXF, you must specify the target namespace of the WSDL contract as the namespace of the port name, like this:

HelloWorld helloWorld = helloWorldService.getPort( new QName("http://www.my/wsdl/target/namespace", "SOAPOverHTTPEndpoint"), HelloWorld.class );

In Celtix you could leave the namespace of the port name as an empty string "". If you do this in CXF then the call to getPort() will fail. It turns out that this latter behaviour (in CXF) is more in keeping with the JAX-WS specification (see Section 4.2.3 of the JAX-WS Specification). Based on my experience, I put some notes on the "Celtix Migration Page" in the CXF user guide. If I come up with any other migration issues then I'll submit them there to keep them in the one place.

Mainframes and SOA

Wed, 17 Jan 2007 09:46:50 -0800

I know that it's a couple weeks late, but Happy New Year to anybody that's reading this. Conventional wisdom always seems to say that the period around the holidays is a little less hectic from a work perspective...but I'm just not seeing it. It seems that something is always cropping up, and that could partly explain why I only end up writing here about once a month. But, one of my goals for 2007 is to try and make it here a little more often. I'm not promising anything, but it's a goal I'm working toward. I tend to draw inspiration for my blog entries from things that are going on at the company or the bits of information that cross my desk on a daily basis. These items aren't always a direct hit to what we're doing in the realm of SOA or open source, but they often help create a spark that hopefully leads to some mildly interesting on these pages. I came across one such item at the end of last week. Sharon Gaudin of InformationWeek wrote a piece "Analyst: Long Live The Mainframe" that highlighted a recent Butler Group report about current and future mainframe use. A brief mention of advances in SOA prompted me to think about how IONA is helping its customers utilize their mainframe assets as part of a comprehensive SOA strategy. Since its introduction, Artix has been able to run natively in mainframe environments, ensuring that these valuable assets, and the mission-critical applications that run on them, were readily available for use as the enterprise adopted SOA. You can read more about that here and also in this press release issued last year about how we're prepared to add value to BEA deployments in this particular area. Mainframes aren't going away anytime soon and to paraphrase Mark Twain, the report of their death is an exaggeration. The trick will be finding the right technology to ensure they can participate as equal citizens in SOA.

Celtix Enterprise: so far, so good

Tue, 05 Dec 2006 15:15:40 -0800

Stefan Tilkov has written a nice article describing our new Celtix Enterprise release. The response to our announcement so far has been pretty good, with a few hundred downloads over the past 24 hours. My own little contributions here are in the CXF dynamic language support, which I originally designed and wrote for the Celtix open source project but which has now moved to CXF, and in Qpid, the Apache Incubator implementation of AMQP, where I'm a committer. Don't let the "ESB" label scare you, BTW. I know many of you dislike ESBs and for good reason: most vendors' ESBs are either just glorified JMS implementations or are big, scary, centralized, and expensive EAI-like monstrosities. With Celtix Enterprise, IONA has again used its extensive pedigree in distributed computing to put together an adaptive and truly distributed SOA offering. While in theory all SOA is distributed, in practice, many ESB solutions force you to use centralized hubs no matter what. With Celtix Enterprise, knowing there's no such thing as a one-size-fits-all enterprise solution, we give you the full range of options, from centralized messaging brokers with Qpid, for example, to smart multi-protocol multi-format SOA endpoints with CXF. Speaking only for myself, I actually wish IONA wouldn't define Artix or Celtix Enterprise as ESBs, but given that I'm not in marketing, what do I know. Well, I guess I do know that given the features and functions we offer, ESB is, for better or worse, the closest fit for us from a market category perspective. Whatever you want to call it, Celtix Enterprise is about as far away from the "business as usual" ESBs as you can get. But don't take my word for it, check it out for yourself. These are cool times to be at IONA, I must say. In about three weeks I will have been employed here for 10 years (!), and the release of Celtix Enterprise is in all honesty the most exciting product release I've seen in my time here. It represents a new way of doing things, technically and business-wise, both for our customers and for ourselves. And it's only going to continue to get cooler going forward.

SOA Facts

Wed, 22 Nov 2006 08:40:11 -0800

My colleague Aidan pointed me to these SOA Facts. It's about time someone properly explained the big picture. :-)

SOA and midrange systems

Wed, 01 Nov 2006 10:03:03 -0800

I like coincidences. I came in this morning to an article in the November issue of Midrange Computing that had come in through one of my daily news searches. The article, FAQ on SOA is authored by Alex Nubla and covers a ton of stuff on SOA in midrange environments and a ton of stuff about SOA in general. It’s a good read if you’re at all interested in SOA. I almost wish one of my regular authors had written it, but I guess you can’t win them all. If nothing else, it’s nice to see IONA get a quick shout out when Alex talks about the work being done on the Service Component Architecture or SCA specification. I’d also like to point out that when Alex says,

An ESB must eliminate the consumer's need to deal with upgrades and load balancing between instances of specific services (e.g., the consumer invokes a service, not realizing that there may be many instances). It is uncertain that today's ESB delivers all these capabilities.

– I can say with confidence that IONA’s Artix is at least one ESB that can. But I digress, and have gotten away from the whole coincidence thing that begins the post. To get back on track, and to explain that whole coincidence thing, this morning we issued a press release talking about how we’re partnering with LANSA to help companies the are running mission-critical applications in midrange environments take advantage of SOA in multi-technology IT environments. SOA, done right, is a great way to achieve greater ROI on existing IT assets. Our work with LANSA helps customers achieve that goal for System i environments.

Advanced Message Queing Protocol

Tue, 31 Oct 2006 21:27:04 -0800

My Nov/Dec 2006 Internet Computing "Toward Integration" column just came out. This one is entitled "Advanced Message Queuing Protocol" (PDF), aka AMQP, and as its name implies it provides an overview of AMQP. Over in the Apache Incubator, the Qpid project, an open-source implementation of AMQP, is up and running. As I mention in the column, you can find working Java and C++ AMQP brokers there, as well as client capabilities in Java, C++, Python, and Ruby. Qpid is where I spend almost all of my development cycles these days. It's about time the industry had a standard, interoperable enterprise messaging protocol, and I think AMQP is on track to meet that need. If you're interested, get involved in Qpid.

just starting with CXF (celtixfire)

Thu, 19 Oct 2006 12:27:53 -0700

The Apache CeltiXFire project has just recently been renamed to CXF. Which is much more userfriendly for the mouth at any rate, (Celtixfire is a bit of tongue twister). I am only a newbie and only getting started on it now. I successfully imported the project into Eclipse thanks to Dan Kulp's explanation. The only problem Ive come across so far was when building the project (out in the command line) using Maven 2.0.4 my /trunk/distribution/target directory was not being created. "mvn install" needs to be run in the trunk and distribution directory, however I found running "mvn -e install" more useful for error output. Maven runs fine from the distribution directory ( /trunk/distribution) directory but from the trunk directory ( /trunk) it generated a build error. java.lang.NoClassDefFoundError: org/apache/cxf/configuration/CommandlineConfiguration at java.lang.Class.getDeclaredMethods0(Native Method) It seemed this was caused by out-of-date binaries. To make sure you update these, use "mvn clean install" instead of just "mvn install". If clean fails (which it did for me!), delete the */target directories manually. Clean out the local repository, i.e. remove the org.apache.cxf directory in c:\Documents and Settings\ \.m2\repository. Then run "mvn -e install". After this my build worked and the /trunk/distribution/target directory was created. The project is now complete with distribution jars and demos \distribution\src\main\release\samples and up and running in Eclipse.

Latest Version of Artix Available

Tue, 10 Oct 2006 14:54:52 -0700

On October 10, we announced availability of the latest version of Artix. As with any new release (or at least as it should be with a new release), there are some pretty cool new features added to the mix. We’ve expanded its standards support, added new management capabilities and included some new enhancements to Artix Orchestration – all designed to meet the needs of Global 2000 companies that are deploying SOA in multi-technology, mission-critical IT environments. We’ve had a pretty good response to the latest version of Artix from folks such as Paul Krill of InfoWorld and Rich Seeley of SearchWebServices. It’s also nice to see that analysts including Anne Thomas Manes of Burton Group and Tom Rhinelander of New Rowley had good things to say about Artix when asked. What may be even more interesting about Artix is that from its inception (the first release of Artix was almost three years ago), the product has been designed for incremental adoption. There’s been a lot of noise lately about how customers don’t want to be tied down by a monolithic stack and how some vendors are responding with plans to componentize their SOA infrastructure offerings. We agree that customers want something different – and they don’t necessarily want to wait. From day one Artix has been component based, relying on a distributed architecture that truly enables customers to deploy only the service endpoints they need, when they need them and to easily modify those endpoints as business and technology requirements evolve.

JAOO SOA Track

Tue, 03 Oct 2006 05:18:22 -0700

On the first day of the JAOO conference (with over 1000 attendees this year!), after Werner's excellent keynote about the Amazon.com technology platform (which, BTW, is service-oriented), Gregor Hohpe hosted the SOA Track. He opened the track with a quick yet deep overview of SOA -- probably the most useful introduction to SOA I've ever heard. Following Gregor's introduction, I gave my talk on dynamic languages and SOA. For better or worse, SOA is often associated with large and sometimes expensive "enterprise" software systems, where your choice of programming language tends to be limited to Java or C++. I encouraged the attendees to avoid being "enterprisey," which is defined as coming up with vastly overblown architectures or designs for the problem at hand. There are many functions within a SOA that can be handled by just a few lines of Ruby, Python, or JavaScript, rather than hundreds of lines of Java or C++. I also gave some examples of scripting JAX-WS with ECMAScript for XML (E4X) in CeltiXfire, scripting Artix with Ruby, and scripting clients for Qpid with Ruby and Python. After lunch, Ivo Totev of Software AG talked about SOA governance. This is one of the newest aspects of SOA, and it's particularly important because it raises the issues above the pure technology level to how SOA systems are deployed, managed, and extended over time, understanding how changes to parts of a system are going to affect the overall system, and how SOA systems can be made to properly reflect the appropriate business operating procedures. Governance is often a term that's thrown about without much definition or depth behind it, but Ivo gave it a very thorough and informative treatment. Next up was Beat Schwegler from Microsoft, who talked about how to architect applications for SOA. Beat hammered home the point that there's a huge difference between technology and business, that SOA ultimately is about reducing the cost of doing business, and that technology is subservient to that need. He pointed out that technology flexibility is a benefit of SOA that allows the business to control its cost of IT. Beat gave the example of moving services off of a mainframe to reduce costs without breaking users of those services: this is much more feasible with a service focus rather than a technology focus. He talked about the folly of trying to build reusable services right off the bat, explaining that you first have to have "use" before you can move on to "reuse." Beat then covered service contracts, architectural refactoring, and application partitioning, all required to create adequate boundaries within a SOA so as to ensure that it's properly abstracted and give it the required business flexibility. Following the break, Gregor again took the stage, this time to talk about loosely coupled conversations. Coupling is extremely important in SOA systems because if subsystems are coupled too tightly, the business agility you seek by adopting SOA ends up eluding you. Conversations between subsystems obviously impact the degree of coupling present in the system. Gregor explained various message exchange patterns, choreography, and approaches for verifying message exchange rules. He then gave an overview of several service conversation description standards, including BPEL, CDL, and SSDL, each of which takes a different approach to defining and prescribing conversations. He explained that the outputs of tools based on these standards are meant for machine, not human, consumption, and so then moved on to explain a number of conversation patterns, which are far more human-friendly. We capped off the SOA Track with a panel consisting of all the track speakers as well as Frank Buschmann of Siemens AG, whom Gregor invited as a devil's advocate of sorts. The panel stressed the fact that SOA isn't magic, and that doing it right required all the non-technical business factors to be addressed by the organization's leadership. Even Werner, who normally asks really hard questions at such panels, said that he thought the panelists were on the right track. What was most impressive to me about the SOA Track is that none of the speakers communicated about their talks or exchanged slides before the conference, yet the messages of all the track's speakers meshed very well. Furthermore, despite the heavy technical leanings of the audience, they too understood that SOA is ultimately not about technology but about creating business value. I believe this is all good testament not only to the expertise of my fellow SOA Track speakers, but to JAOO's amazing ability to always attract highly knowledgeable speakers and attendees who possess formidable hands-on experience. And finally, what JAOO would be complete without a great conference party! The Monday evening event was outstanding, as usual, complete with Chili John's excellent "Route 66" buffet, a great performance by the Absolute Girls, and some really nice locally-brewed beer.

Eclipse COSMOS

Tue, 19 Sep 2006 10:15:01 -0700

In a previous entry I mentioned SML and the fact that I got a chance to speak with one of the authors at EclipseWorld. During the conversation we were joined by Mark Weitzel and Joel Hawkins and we started talking about something called the COSMOS project - a joint effort between IBM, Cisco, HP, Compuware, IBM, Intel and others. This project was about unifying a lot of the capabilities of SOA Systems Management and agreeing on resource modeling approaches using the aforementioned SML. Just today, I read an entry on Chris Aniszczyk's blog stating that COSMOS had been proposed as an Eclipse project. This looks like a good idea to me, and from the point of view of the SOA Tools Platform Project it could make it more straightforward for us to incorporate management of SOA resources. By the way, Mark and Joel put together a really interesting talk and demo at EclipseWorld in which they managed to mashup SCA, Tuscany, OSGi, and TPTP. I was totally impressed!

Eclipse 2006 - Meetin' and Greetin'

Tue, 12 Sep 2006 01:26:20 -0700

Working in OSS projects means that much of the time the only chance you get to meet co-developers and other community members is when conferences like EclipseWorld happen. Usually, you get to meet brand-new people and have interesting conversations with them. At the Wednesday night Tailgate Party at EclipseWorld I was introduced to Chris Aniszczyk and - I don't know how we got into it - we had a little conversation about the PDE. My major gripe relating to the PDE is the headless facilities for automating build, test and coverage - after I compared it to something like chewing ground glass, Chris informed me with a grin that he worked on the PDE UI. The PDE UI you will agree is in good shape. You just have to take a look at the new and noteworthy for 3.3 M1 to see that the team haven't been sitting on their keisters since Callisto. It's great to use, but from my perspective it's only part of the equation of shipping software on the Eclipse platform. Back to the PDE headless build. The PDE build works - right now every Eclipse project uses it as far as I know. But it's got a steep learning curve, and it's brittle. I know this from experience :-) So let's fast forward to now: in STP we got the PDE build to work well under the expert guidance of Naci Dai, who is the JST lead and buildmeister extraordinaire. Adrian carries on the torch and maintains the STP build for us. I've probably timed this badly, but we would like some more people to help us with build mastery. Send email to the usual address - stp-dev@eclipse.org :-) Update: looks like Felix is heading out of incubation! Update: a sudden conversation on Bug 154251 - Maven2 Integration shows some relevant work in progress.

Integration in the retail industry

Fri, 18 Aug 2006 09:23:31 -0700

Recently Margo and I have visited an ISV who produces software solutions for the retail industry. In one of the meetings I learned that retail is a business of low margins and extreme competition. This is specifically true for countries like Germany. As if I asked for an example of this claim I heard in the news that a very large US superstore chain would retreat from the german retail market in order to concentrate forces into markets where they can grow faster. So when margins are low, prices cannot be raised, costs must be kept down. The software that these folks write is to harmonize the demand and supply in a way that customers would never stand in front of empty shelves while at the same time, the store's stock is never full. In the past, this optimisation was part of the staff's responsibility and based on vast experience, however with the variety of products these days and the dynamicity of the labour market it is impossible to build the keen sense for quick and slow selling items. Also, more and more stores are branches of a chain where smart logistics is to be applied. Smart software is required here to forecast demand. One of the most complex parts of managing a supply chain is the integration of the various parties in this chain: stores, warehouses, manufacturers, shipping companies. To complicate things, goods and the corresponding data does not flow into one direction only. Flows are back and forth, e.g. if goods are returned due to quality problems. For instance, one integration use case is when orders are sent from the store to the warehouse. Orders from all stores will be consolidated to create another order to the manufacturer. In some cases, the manufacturer's shipping company sends the goods directly to the store, in some cases these products are sent to the warehouse for redistribution. Sounds like a big integration task! Another example is the creation of orders. Orders are based on forecasts. Forecasts are based on existing sales data. The sales data needs to be transferred from the stores to a central location for calculating the forecast and the orders. The current solution that transfers sales data to the central server is based on a simple yet proprietary protocol. It works no problem. However their customers need to operate and support this proprietary protocol and have no real alternative. The ISV considers using an Enterprise Service Bus to open up the architecture of their product to use any protocol. Now what does this have to do with Open Source? The ISV has OEM licensed its product to a large SCM software company. The inclusion of commercial third-party products into their product "could" mean that existing contracts need to be renegotiated. Hence, this ISV envisages open source software as a strategy for creating value for customers, Partners and themselves without having to change business processes. Another note I wanted to add is that, the described use case with the transfer of sales data is a challenging one for us and the Celtix product. The integration we're seeing here is not an integration of functionality, i.e. classical application integration. We're looking at integration of data sources and sinks. To my mind, there are many such integration problems out there. We've just seen a tiny bit of it.

News: IONA AND AEPONA REDUCE COSTS FOR TELECOMS SEEKING TO INTRODUCE NEW INTELLIGENT NETWORK SERVICES

DUBLIN, Ireland and WALTHAM, Mass. - August 12, 2008 - IONA(R) Technologies (NASDAQ: IONA), a world leader in distributed service-oriented architecture (SOA) infrastructure solutions for performance-demanding IT environments, today announced a collaboration with Aepona, the leading supplier of telecom service layer products and solutions to telecoms globally, to extend Aepona’s Universal Service Platform (USP) to enable customers to integrate their intelligent networks with their business and operational support systems (BSS/OSS).

News: IONA REDUCES COMPLIANCE COMPLEXITY FOR FINANCIAL MESSAGING DATA SERVICES

DUBLIN, Ireland and WALTHAM, Mass. - June 18, 2008 - IONA(R) Technologies (NASDAQ: IONA), a world leader in distributed service-oriented architecture (SOA) infrastructure solutions for performance-demanding IT environments, today announced a broad set of enhancements to Artix(TM) Data Services, designed to offer customers the broadest and richest financial messaging data services development and deployment platform. The latest release includes the most comprehensive implementation of SWIFTNet(TM) MT Standards Release 2008 (SR2008) and the launch of a new free online validation service. IONA is also announcing new solution offerings for OTC (over-the-counter) derivatives processing and payments straight-through processing (STP) designed to reduce risk exposure and operational costs for financial firms.