Sonic helps organizations share information

WITH ITS SONICXQ architecture, Sonic Software provides a backbone that helps organizations share information across the enterprise and across the Net. Sonic’s vice president and chief technology evangelist, David Chappell, met with InfoWorld Test Center Director Steve Gillmor, News Editor Mark Jones, and Lead Analyst Jon Udell to discuss the importance of asynchronous Web services and the standards process surrounding the next generation of communications.

InfoWorld: How critical are WSCI [Web Services Choreography Interface] and BPEL4WS [Business Process Execution Language for Web Services] to your future value proposition? I’m assuming that you’ve relied to some degree on proprietary capabilities prior to these standards?

InfoWorld: To what extent are you involved in the conflict between BPEL4WS and WSCI and the reluctance on IBM’s part to involve Sun in those discussions? Is that impacting how you’re architecting this new Web framework?

Chappell: There are a number of conflicting standards. There’s WSCI, which BEA happens to be involved in, but then there’s BPEL for Web services — they’re kind of overlapping. It is political and we’re looking to see how that pans out. But in the meantime, what we provide is an infrastructure, and part of what that infrastructure provides is the ability to orchestrate the interactions between applications and services using this notion of an “itinerary.” That’s what we call it. An itinerary is something that gets carried around [over] the message as it goes from place to place, instructing each stop on the way what needs to be done. It actually fits very well into what, for instance, WS-Coordination and WS-Transaction and BPEL4WS are doing. In fact, one of our professional services people recently wrote a mapping utility between XLANG and our internal formats. It’s a half a step [toward BPEL4WS].

InfoWorld: Hasn’t Microsoft kept WS-Routing, for example, to itself and is baking that into their architecture, regardless of what anybody else does with it?

Chappell: That’s what I’ve heard. They’re going to put a lot of emphasis on that. It maps very nicely [to our software], and we’re in tune with what [Microsoft is] doing. We’ll be keeping an eye on that. We’re also involved in things like the Web Services Interoperability [WS-I] organization, and we’re chairing the technical committee that’s coming up with the scenarios for that.

InfoWorld: Can we really describe the business process in any computationally meaningful sense? At the end of the day, aren’t scripting languages still going to be important?

Chappell: We take a very pragmatic approach to all that. We’re living through these evolving standards, too, and we have a certain value proposition of technologies that exist today that are requirements for this type of choreographed orchestration of communications, regardless of how all these nascent proposals sort themselves out. Things like asynchronous communications, the ability to somehow string them together and then carry things around. It’s not just about how you get things from place to place, it’s about what happens when things go wrong and where are the buckets that you put these things [into]? And what’s the management framework around that to make it all happen?

InfoWorld: Is it fair to say that SonicXQ is a hybrid of a distributed strategy with some points of centralized control?

Chappell: Yes, that’s a great way to say it. One of the key components of our architecture is this notion of a lightweight distributed services container that allows you to pick and choose where you put services when and where you need them. That’s why I use the word “lightweight.” Lightweight doesn’t necessarily mean that it’s lame or anything, but it’s lightweight as compared to a J2EE container. Whereas a J2EE app server vendor will say, “Sure, we do connectors, we do translation, we do this, we do that. Just install an app server over there and have at it.”

When you think of it from an architectural point of view, to install an entire BEA stack simply to act as a conduit to one of their adapters to talk to an R3 system — it’s absurd, right? The app server paradigm was created to take in Web requests and serve up pages. What we have is a notion of: Just put a container over there, and if you want it to be a specialized translation service, fine. Put it out there next to the R3 system that needs to get the data translated. Or if you want it to be a routing and a translation service, fine. You can put as many things in there as you want and it’s all controlled through a monitoring and management system that’s based on JMX.

InfoWorld: What’s the tradeoff with that? What do you lose in terms of going back to a simpler yet more targeted time?

Chappell: It’s hard to envision the down sides. One could imagine that [it’s] got to be a nightmare to administer all that. But through having the notion of centralized management and being able to remotely deploy things and remotely redeploy service containers and sort of [re-kick] them, as we call it, as services change and such — that’s really the best of both worlds. A centralized monolithic has the advantages of centrally managing things.

InfoWorld: As these standards evolve, and we can grab business processes more intelligently with loosely coupled software as a service-style stack, how does that intersect with innovations from the likes of IBM around grid computing?

Chappell: Grid computing is an interesting concept. Conceptually, having this global enterprise grid is kind of like the utility that everybody plugs into. [But] I think [it’s] kind of out there at this point. I think what we provide is more of a pragmatic approach. What we’re really seeing in [wide] deployments is that there’s the notion of Web services that can talk to anybody across all kinds of Internet boundaries. Then there’s the notion of: What’s under your control within the four walls of your organization? What’s really happening is that there is a notion of a common infrastructure from one or maybe two vendors that can span globally across your enterprise for all the places that are under your control. And then there’s this notion of the edge of the network, [of] having that infrastructure being capable of reaching beyond that edge where you have control and [are] still able to be productive and communicate in that kind of a conversation. What you need is an architecture that’s capable of adapting to those kinds of topology changes. The boundaries between businesses and these dividing lines that are split apart by firewalls are constantly changing. So how do you adapt to that as your business arrangements change?

InfoWorld: Unanticipated consequences of XML and business colliding?

Chappell: Right.

InfoWorld: I can cross enterprise boundaries if it’s side to side, but how do you go Sonic to not-Sonic? What are the connectors out to the edge then?

Chappell: This would be a concrete example of what I was just talking about. Conceptually, you get to that edge of the network [and] what do you do? Part of the service-oriented architecture that you plug into … would be a service that represents a call out to some external Web services. An example we like to use is a credit authorization. You plug in all these things — some of these things are Sonic messaging — all connected together under the covers. They’re all tunneling across the world through your warehouses. And sometimes it’s just SOAP over HTTP that needs to go out to a Sun Web service, and we handle a seamless mapping. Or [over] FTP. We have a bridging capability where we abstract those deployment details away from the person who’s trying to construct all this. So you can actually send a message to a JMS destination from one node on the system and have it pop out as a SOAP over HTTP transmission on another side. And vice versa.

InfoWorld: How does that differ from Microsoft’s BizTalk server architecture? Do you convert everything into XML in the middle?

Chappell: Yes, for the places at the edge, we convert. Everything is pure XML SOAP over HTTP. For the internal stuff, from Sonic to Sonic, it’s our own HTTP tunneling.

InfoWorld: If I’m designing an enterprise application that spans many departments, when I reach out to a Web service or JavaBean or use one of the connectors on the bus to trigger a non-SonicXQ event, do I lose track of it from the point of view of the Sonic management console?

Chappell: Yes.

InfoWorld: Does it block until it returns or it can be asynchronous as well?

Chappell: It can work either way. It all depends on how the service is defined. That’s the part about what’s under your control and what’s not under your control, on that edge. If it’s beyond that, then there’s not a lot we can do except [if at] that boundary you create a message that conforms to somebody else’s orchestration language.

InfoWorld: What’s your perspective on the evolution of the directory? What needs to be filled in for these service-oriented architectures to rely on some kind of intelligent directory?

Chappell: I think there’s a long way to go in terms of directories. I don’t know if directories are ever going to have the full semantic capabilities that people want them to have. Trying to add too much intelligence to a directory gets too complicated. Nobody’s going to use it. Even UDDI is already way too complicated, but it’s still not enough for anybody to really use it in a fashion that people can actually dynamically discover each other and start [trading].

InfoWorld: In SonicXQ 1.5, you solve the problem of inadequate directory standards by rolling your own. How is the directory handled once I cross over an enterprise boundary? All my business rules, my content-based routing information is stored in that directory, so presumably all of these external services must have access to the directory if they’re Sonic-based services?

Chappell: Right.

InfoWorld: If I’m General Motors deploying SonicXQ and I tell my tire supplier, “Go buy a copy of SonicXQ and we’ll make you part of our itinerary,” what happens when it crosses over in terms of directory?

Chappell: That’s a big focus on what we’re working on right now. The ability to support globally distributed deployments — that’s sort of the next generation of management. To have a certain configuration and be able to beam that out to different places, still from a centralized management console. Right now it’s all based on a directory service that service containers access when they start up.

InfoWorld: How do you push that over? JMS?

Chappell: We have JMX built on top of JMS.

InfoWorld: You’ve got SOAP over MQ too, right?

Chappell: Yes, that’s right. We’ve also recently gotten involved in the Apache Axis project, where we’ve become active committers. Committers means you’re part of the governing body. It’s timely because we’ve recently added, as a first step, a simple JMS transport so that people can actually write to Axis APIs, but under the covers we’ll be using JMS. Going forward, the other committers [and] IBM and Macromedia, who are the other people on the team there, are going to work with us to build asynchronous invocation support into the Axis core engine. [Macromedia is] welcoming us with open arms and that’s pretty exciting. It’s all up there in the Axis Development Public List.

InfoWorld: Will Axis 1.0 be a naïve messaging transport that’s available to everybody for basic use and research and development, and more robust ones can be plugged in on a commercial basis?

Chappell: Yeah, that’s part of the initial implementation. Sonic is becoming more and more ubiquitous. We worked with Tony Hong of XMethods to Sonic-enable all the services that are on XMethods. We started with the one called XSpace and then we created a lightweight JMS client that’s freely downloadable to be able to use this, so it’s actually the predecessor to the Axis core. The Axis core is really just a wrapper around that. You’re going to start seeing just Sonic becoming ubiquitous.

[We are] throwing our hat in the ring to help the whole [Apache Axis] community, because we’re experts in messaging and asynchronous communications, and long-time advocates of that. [We are] helping the de facto standards, which is the Apache community, to move into this next generation of communication, which is asynchronous communications.

Source: www.infoworld.com