Interview with Grand Central CEO Craig Donato Part 1

Craig: Grand Central is a web services network that enables business systems to reliably and securely interoperate between organizational boundaries. A good metaphor for Grand Central is the public switched telephone network (PSTN): Instead of enabling any two people to communicate, Grand Central enables any two applications to interact.

Craig: A large stack of agreements needs to be in place in order to have a true B2B conversation. Web services standards really only address a small subset of these issues—the bottom part of this "B2B stack"—relating to data formats (XML) and communication protocol (SOAP). Everything beyond these standards needs to be put in place to ensure appropriate levels of security, reliability, and transactional integrity (correlation, compensation). Addressing these issues within a B2B context is especially difficult because you must coordinate a solution with your partners, who are likely to operating different B2B stacks.

There are two general ways to address this issue. The traditional B2B integration approach is to get everyone to use one stack: yours. If you use a certain schema, they have to use that same schema. If you decide to authenticate identity using VeriSign technology and a certain certificate authority, they have to use it as well.

Grand Central offers a new approach that embraces heterogeneity—allowing partners to use their own B2B stacks, with Grand Central mediating the differences between implementations. For example, you may decide to use a certificate authority to authenticate yourself, but your partners may have a different method of doing so. Rather than forcing your partners to do it your way, you just set up a business rule in Grand Central that says, "I'll accept the following methods of authentication." After Grand Central authenticates their identity, it's validated against your authentication business rule.

We also do things like protocol and data format mediation. Just because you decide to deploy web services, doesn't mean that all of your partners do so. So we enable SOAP to interact with a web site speaking HTTP, or an FTP server. We also can translate ASCII into XML and vice versa.

Craig: When we talk about security, we mean four things: encryption, authentication, access control, and firewall vulnerability. Grand Central's web services network not only provides support for each of these layers of security, but more importantly provides the mediation necessary to ensure interoperability between disparate security models.

As we discussed previously, Grand Central enables companies to establish business rules that allow partners to interact in a decentralized and heterogeneous environment. Authentication and authorization are two areas that can be deployed and managed through Grand Central. We support a variety of authentication mechanisms, including username and password as well as VeriSign certificates.

Grand Central also provides rule-based access control. This allows you to decide which users have access to a service, which version they should map to, as well as functionality for things like availability windows. We also support the flip side of authorization, which is provisioning or granting new access to a service.

There is clearly a lot of activity in this area and we're working closely with the major web services toolkits to ensure interoperability with their security models.

Craig: Policies are created via web-based forms in Grand Central. In the long run, we also expect to integrate with tools that author and manage policies within an enterprise.

Craig: Grand Central provides both the sender and recipient with a common tracking slip. This allows either party to have a full visibility into what's happened with the message.

Craig: Exactly. We provide an independent audit trail, similar to [the FedEx audit trail], that indicates when the message was sent and when it was received. This is a significant improvement over traditional integration technologies that require participants to do a lot of manual work resolving audit logs on both sides of the transaction.

Craig: We don't see web services completely replacing these solutions. We actually see them providing a key role within an evolved web services architecture—that of the service broker.

Craig: To extend the phone system analogy that I used earlier, it's our belief that products like TIBCO and Vitria will act like PBXs: monitoring and managing internal service interactions, weaving them together into business processes. Just as PBXs connect into a public phone network, we believe that these platforms will plug into something like Grand Central's web services network.

In addition to being a platform for services, application servers such as WebLogic are being used as service brokers. With traditional EAI vendors and application servers both attacking the service broker segment, we see this as the biggest area of contention in the web services world.

Craig: We firmly believe that in order for web services to be adopted in mass scale beyond the firewall, you need to have two things:

• A shared infrastructure that will support a many-to-many world. FedEx, the public switched telephone network, and VISA are all modern-day examples of shared infrastructures that enable a many-to-many collaborative world.

• Web services standards that allow business systems to interoperate with unprecedented flexibility and affordability.

Alone, these two variables are not sufficient for most business-to-business interactions. Grand Central's web services network, which is built on top of the Internet, enables businesses to harness the power of web services with the levels of security and reliability required for enterprise-class integration.

When you implement web services between firewalls, you have a higher bar when addressing the issues around security and reliability. For example, username and password may be an acceptable internal authentication scheme, but would not be suitable outside the firewall. That said, I think you'll see a lot of B2B web service deployments in conjunction with web service networks like Grand Central that address these deployment issues.

Moreover, I think B2B integration more naturally lends itself to a standards-based approach, since it's inherently involved in deployments where you don't control what's on the other end. So you can't force your partners to always do it your way. With standards like SOAP and XML, you get around the problems with proprietary protocols and data formats. But there are still a host of other issues that require you to use a web services network like Grand Central.

Craig: Right. And I think you'll see clients first deploy a web service internally. Once they get comfortable with the internal deployment, they can share it with selected partners. At this point, they need to deal with the issues of security, authentication, provisioning, version control, etc. And if they use Grand Central, they can easily address these issues.

Craig: A firm that wants to exchange data with their partners—whether informational content or transactional content—typically in a server-to-server fashion. For example, they want to integrate their forecasting system with their partner's inventory system, or their CRM system with their partner's purchasing system.

Craig: Absolutely. When we work with customers, we are about 1/20th of the cost of a traditional software implementation.

Craig: In addition to being more affordable, ease of deployment and manageability are two other major advantages of using Grand Central's web services network for B2B integration. Traditionally B2B integration technologies tend to be very expensive, time-intensive, and complex to manage, so only the biggest companies typically deploy, with their top 4 or 5 partners, for a limited range of interactions. With Grand Central, you have something that can be effectively deployed by [a company of any size], with all of their partners, for a very broad range of interactions.

At the end of the day, we can demonstrate that there is no need for an organization to implement and manage its own B2B integration network. We provide higher levels of service than they would implement on their own, and because it's shared infrastructure, we can do so at a fraction of the cost.

Craig: It's very simple and it's transparent. If your application can speak SOAP, you don't need to install any software or hardware, or even open any holes in your firewall. All you do is go to Grand Central's site and create a proxy for that service in our network. You then redirect users through that proxy. One metaphor that I use for people who are a little bit more technically minded is Akamai. If I were Yahoo!, I could have implemented my own caching network. I could have purchased software from Akamai, installed caching servers out on the Internet, and had every one of my customers download some sort of caching software into their browser. But that would have been very expensive and inefficient. Instead, sites like Yahoo! create a virtual proxy for their web site in Akamai and redirect users through it. And these users don't necessarily need to know that they're using Akamai. It just gets inserted into the conversation.

This is a very good metaphor for Grand Central. You create a virtual proxy in Grand Central and you redirect users through it. But instead of making web pages faster, we enable B2B conversations to be more secure and reliable.

Craig: Customers wrap the proxy with business rules that enable them to effectively manage that interface. For example, rules can be used to support change management. All users access one logical proxy in Grand Central. Rules within the proxy then redirect those users to the appropriate version of the web service. To upgrade a user, you simply change the user's designation in your access control list. This process also supports provisioning. When you add a new user to your access control list, that user sees a listing for that service automatically pop up in his or her Grand Central directory.

Craig: We built our directory to be UDDI-compliant. We've built functionality on top of it, however, to enable it to support issues surrounding access control and visibility. Most of our customers are looking to deploy web services to specific partners, not make them generally available. As such, they want more control over who can access the web service and even who can see it.

End of Part 1. Part 2 of this interview will appear at InformIT next week.