By eweek  |  Posted 2006-01-16 Print this article Print

Gordon Van Huizen

Whats your take on Sonic vis-à-vis the competition, not only in the ESB space, but in the whole area of competing to deliver infrastructure for SOAs?

The market continues to solidify in the way that we would have hoped a few years ago, which says that ESB is an identifiable category of technology that increasingly organizations put together RFPs [requests for proposals] for. And as organizations become more savvy about what theyre looking for, Sonic performs increasingly well in that environment. So, getting people to the point where they have bake-offs and vendors come in and compete, Sonic continues to do remarkably well.

So the dynamic that weve talked about—with IBM and BEA telegraphing this message about how ESBs fit into service-oriented architectures—creates a great environment for us competitively, since Sonic has the goods.

There are other types of technology needed to build out an SOA strategy. The Sonic approach has been to partner with the vendors we think are leaders in those areas: AmberPoint [Inc.] for Web services management [and] Systinet for registry, repository and the aspects of governance that they provide. And that set of relationships is working pretty well.

OK, but what do you think makes Sonic unique versus other players?

I think the breadth of the ESB offering. The other players tend to be missing some core component or feature of an ESB. Cape Clear [Software Inc.], for example, only recently got serious at all about messaging technology. And, generally, other small vendors tend to fall by the wayside early in the evaluation process for lack of functionality.

Also, the depth and hardening of the product is unbeatable, and things like availability and scalability come into the equation. So by the time you get to the best and final round, the smaller players have been excluded and its quite often Sonic against IBM or Sonic against BEA.

Whats your take on Microsofts strategy around ESB?

I continue to think that Microsoft is doing a great service to the industry with Indigo and the whole message-driven approach to SOA and evangelizing that.

What isnt clear at this point at all is what Microsoft intends to do from a middleware point of view around ESB. So in our view theyre allowing developers to create better service-enabled endpoints—better business-level services. But it isnt clear to us how they will offer an ESB-style product for connecting those services together.

So you see their BizTalk strategy as a stopgap?

Yes, exactly. And the usual model with Microsoft is that they dont do anything until they really, really have to. So the current BizTalk model will probably stay in place, I would imagine, for the next couple of years, until theyre pressured to do something more decentralized and more service-oriented.

Well, I guess the question then is, is it enough for their customers, or would they need to look elsewhere?

Its certainly been our experience that they do [go] to another vendor for the enterprise-grade middleware that would tie services together. And even in environments where Microsoft owns the development piece and the application deployment piece, they dont own the middleware piece that connects the systems together.

So there are certainly small-scale and certain types of SOA projects where having a centralized broker approach like BizTalk would be just fine. But for broader SOA strategies, organizations tend to think—in our experience—more broadly than this.

What is your partnership strategy? What do you look for?

We look for a technology where there is a clearly defined need and where there are multiple vendors competing in that space and there is a vendor that is demonstrating clear leadership, both in terms of the technology that they offer and market perception around the technology.

Another angle that we look for is delivery of methodology, which is why we have a partnership with BearingPoint [Inc.], in particular. They have the most evolved view of SOA.

Can you talk a little about data handling and what you guys do in that realm?

Theres a set of challenges that show up when youre building a large-scale SOA that requires the use of reference data. So, for example, if Im building a service-oriented network thats dealing with RFID [radio-frequency identification], and Im building a common infrastructure for that.

When a scan happens at a manufacturing plant, theres typically a significant amount of reference data that needs to be available to make sense of that scan and figure out what to do with it—what customer orders are impacted, etc. So theres a projection of that reference data that needs to occur. And right now the process side of SOA is dealt with in a very distinctly different way than the data management side. And over time we think these two worlds need to merge.

So what has been thought of as federated queries, the need for that is heightened quite a bit in the SOA environment.

Do you provide this?

Were incrementally building out to provide this service-oriented data layer. And the market strategy is to allow it to operate independently of the ESB, but also operate well in an ESB environment. So were looking at how to share metadata between those environments.

Check out eWEEK.coms for the latest news, reviews and analysis in Web services.


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel