XML-J: What's the focus of Progress Software?
Gordon: Our primary focus is connectivity and standards - connectivity from the SonicMQ messaging infrastructure into other messaging infrastructures and support of nonmessaging Internet protocols. We're also very focused on standards initiatives that relate to XML messaging.

XML-J: Do you work with messaging buses like TIBCO?
Gordon: Yes, we've developed a best-of-breed messaging implementation based on the JMS standard. People are basing more and more of their new applications on the open standards of JMS, and selecting product values based on features, performance, and scalability. They still need to connect to existing infrastructures. For example, they have legacy applications built on IBM's MQSeries or they're required to use MQSeries to connect to their business partners' repositories. We've developed a series of bridges that extend the JMS messaging infrastructure of SonicMQ out to these different environments.

XML-J: Sonic MQ provides a JMS implementation?
Gordon: You can look at it two ways: we either have a JMS implementation or a highly capable messaging infrastructure that happens to support JMS.

XML-J: How does XML relate to the JMS forum?
Gordon: XML is particularly interesting to us for a variety of reasons. JMS is a highly capable way of transporting and routing XML-based content, particularly in terms of business transactions, and that's a real sweet spot for us. One of the application areas where we're gaining a lot of traction is supporting B2B relationships across the Internet. In this case we're delivering XML payloads on behalf of buyers and sellers in an exchange situation or as part of other business relationships.

XML-J: How do you store those relationships? Is that a message format?
Gordon: Right now that's problematic as it would be with any messaging system on the market. It's one of the reasons we're interested in emerging XML standards and protocols related to e-business messaging. We're highly active in ebXML, for example. We're also active in XML protocol, the W3C's more generic XML transport.

XML-J: What about SOAP?
Gordon: SOAP is definitely interesting, and occasionally we consider a SOAP implementation in our product. We believe the XML protocol will probably be more interesting than what's happening there, though it's pretty early in the specification process. The working group was formed recently and we, along with others, are layering requirements that aren't necessarily part of SOAP, such as reliability and security, that we believe are necessary for XML messaging in a B2B context. You can always layer them in. We believe it's important to have support for that in the wire protocol.

XML-J: Is security something you actually look at different app server vendors for?
Gordon: No. In terms of security we have our own infrastructure, not that we can't integrate with and leverage an existing security infrastructure that might be present in an app server environment. However, we don't require an app server environment.

The reliability is in the JMS spec, and we have a high-performing, reliable infrastructure in place now.

XML-J: What does your security infrastructure provide?
Gordon: Basically we can connect to certificate authorities. We have server-side support certificates, the option of encrypted payloads, and we can use SSL so a variety of security schemes can be applied.

XML-J: The main focus of your group is messaging?
Gordon: The main focus of the SonicMQ business unit is e-business messaging. And the main focus of my particular group is connectivity and standards, XML-related standards. We've developed a bridge infrastructure, and we're releasing a specific set of bridges with the 3.0 release of SonicMQ.

XML-J: Who can we talk to with that bridge?
Gordon: We talk to MQSeries. We can effectively message through JMS to FTP, for example, so we can obtain documents via FTP and place them in topic MQs. We can also do the same for SMTP. Both are obviously interesting in the B2B context.

XML-J: Do you see workflow engines playing a role in this?
Gordon: We do see that as a very interesting piece moving forward, particularly as standards emerge that can represent business processes in a uniform manner with some amount of rules, business processing, or workflow, depending on how you look at it. That currently consists of layers built on top of the messaging infrastructure. Our focus is best-of-breed transport and routing, and other folks handle the layers above that. Certainly the relationship between workflow and business rules and the messaging infrastructure will become more important over the next 18 months.

XML-J: Do you have any plans for playing in that area or integrating with some of the players?
Gordon: We're entertaining a variety of notions that are still in development.

XML-J: Are you involved in any standards definitions?
Gordon: Yes, we are. We're involved in ebXML and the W3C XML protocol. We're an advisor in UDDI; we're on the expert group for the Java XML messaging API through JavaSoft. So yes, we're involved.

XML-J: You mentioned UDDI. How do you see that shaping up?
Gordon: UDDI is really interesting. I think for a lot of the people in the industry it came from out of nowhere. For example, folks at the ebXML initiative have been focusing on a complete framework and UDDI did an end run on the directory and repository. In many ways that's a useful thing to do. They have a usable implementation, as far as it goes. It'll be interesting to see whether UDDI ends up being the dominant directory repository format. Regardless, it's done a lot of good spearheading that kind of effort.

XML-J: How do you see the XML market shaping up?
Gordon: Having participated and watched the XML market for as long as it's existed, I was originally focused on the content side and multiple representations of existing data. At Sonic we're focused on the transactional side; it's been interesting to witness the development and marriage of those two concepts.

XML-J: How real is this right now?
Gordon: I think it's becoming very real. I think the fundamental standards are sound. XML schema is certainly a step in the right direction. I think a few other well-chosen protocols and standards and other functional areas are extremely vital. And the whole framework notion...we'll have to see how that plays out - whether there are best-of-breed components or standards that get plugged together or whether there's one umbrella framework. The RosettaNet implementation is certainly an interesting reference point; they successfully looked at a particular vertical with specific needs and developed XML schema and message collaboration formats and all that good stuff. What we're attempting to do now is open that up in a more generic way. Of course that will take quite a bit of time, but there are some wonderful incremental steps that have value.

XML-J: In terms of XML security, there are also initiatives to have XML-DSig - where do you think that's going?
Gordon: I'm not that close to XML-DSig. I hear good things from the experts that I know and trust there, and there's a lot of the same thinking being layered into ebXML, for example, so I trust something useful will happen.

XML-J: Do you have any message for our readers?
Gordon: I think the message is that XML is quickly becoming a real way to conduct business transactions. There are things you can do to implement B2B transactions in a variety of different business models. I encourage people to start doing that, start using the existing pieces that work today, and help us build toward the future.

XML-J: Does your product have an evaluation copy?
Gordon: Yes. Our Web site has tons of content, in addition to an evaluation copy that can be downloaded. Our philosophy has always been to make the developer edition free. The documentation for the product, which is a great tutorial on JMS, is available for download from the Web site, so I encourage people to check out www.sonicmq.com for the content.