Prior to taking on the role of CTO at Systinet, Anne Thomas Manes was the peer-to-peer evangelist for Sun Microsystems Inc., where she championed the adoption of SOAP (Simple Object Access Protocol) alongside Java. Today she is working on creating a robust Web services architecture around SOAP. In an interview with InfoWorld Editor in Chief Michael Vizard, Thomas Manes talks about how much work still needs to be done around Web services and why Systinet has a decided edge over rivals.
Q: What exactly does Systinet do?Thomas Manes: Systinet is a Web services platform company. We build Web services infrastructure. We have a SOAP implementation with full support for WSDL [Web Services Description Language]. We have a UDDI [Universal Description, Discovery, and Integration] implementation, and we're building right now a Web services single sign-on service. I hope at some point it actually will conform to Liberty Project, if Liberty ever actually produces some specifications. We also have as part of the basic platform a set of tools to make it simple and easy for people to build Web services. The tools are designed as plug-ins into existing Java IDEs [integrated development environments], so that you don't need to start a different tool to go create your WSDL files. It's all done from directly within NetBeans or Forte or JBuilder. Our system basically plugs into your favorite Web server or app server. So you don't have to go get something new to support Web services.
Q: What differentiates you from other players in the Web services space?Thomas Manes: We're way ahead of everybody else in the market because we've been doing it longer than just about anybody, with the exception of Microsoft. The product is currently in its third release. It's an incredibly rich implementation of SOAP 1.1 and WSDL 1.1. We provide extremely good integration with everybody else. Our level of integration with .Net is unsurpassed by anyone else. We also integrate with Apache SOAP and all the other major players out there.
Q: Why is it important to plug into existing tool environments?Thomas Manes: If you are a VB [Visual Basic] developer, you're going to be using VB Studio or Visual Studio .Net, and you'll use that environment to build your SOAP clients and your SOAP servers. If you're a Java developer, then you're using a Java tool to build your SOAP clients and your SOAP servers. And a given company is going to have both. You don't just have exclusive VB developers and exclusive Java developers and exclusive C++ developers. Our approach is that you want to actually provide the Web services capability within the actual application development environment that you're using. This is why we provide our tools as plug-ins into your favorite IDE as opposed to a separate tool. We do provide three plug-ins, so we support JBuilder, NetBeans, and Eclipse. I think that that will address 80 [percent] or 90 percent of the developers out there. We do not expect that a VB programmer is going to want to use our SOAP stack in VB. We expect that they're going to want to use .Net. Therefore, our goal is to make sure that we interoperate completely seamlessly with .Net. As a VB programmer you build your SOAP implementations and your clients and/or servers using .Net, and as a Java developer you want to use a Java environment to generate SOAP. What's important is that those SOAP implementations actually do interoperate with each other. That's where we are integrating.
Q: What degree of interoperability are we talking about?Thomas Manes: Absolutely seamless interoperability. Let's say you build a Web service with Java and you use our environment to do that. Then you deploy that service into Tomcat or into WebLogic or into WebSphere or some other type of application server. And now you want to get a VB client to talk to it. All you have to do is take the WSDL file that we generate for our service and feed that directly into the Visual Studio .Net tool, and it will create a .Net client that can talk to our server. When you're building your Java Web service, you pick one of these SOAP stacks to generate all of the code that's necessary to let your Java application talk SOAP. Then you deploy that application into a Web service container, which normally runs as a server inside a servlet engine. From a VB client point of view, what you want to do is just go find a WSDL file and automatically generate the VB SOAP interfaces that would let you talk to the Java servers.
Q: What's next for Systinet?Thomas Manes: Almost all the SOAP implementation support very simple request/response-type operations, and not asynchronous stuff. Even though SOAP by itself is by nature a one-way messaging system, the way everybody's implemented it so far, it's a request/response kind of thing. We are adding an asynchronous API into our product that will be available in our next release that's currently scheduled to come out in May. That would allow you to do one-way messaging or solicit responses or notifications and other types of patterns that are of interest in the more advanced world. Most of the SOAP implementations that are out there only support a blocking API, which means you issue a request and your application just sits and waits for a response to come back. We already support the ability to send it over JMS [Java Messaging Server], over MQ Series, or Sonic MQ, or some other type of queuing service. But that still doesn't help you with the non-blocking part of the client interface. We're also adding support for a non-blocking client.
Q: Are you working with other vendors on any of this?Thomas Manes: We're working with BEA to make sure that our asynchronous APIs are compatible. We're working with BEA to make sure that we're not competing head-to-head. Cajun is a development tool for building Web services that get deployed inside the Cajun run time, which is a Web service container. But the Cajun run time is compatible with the WASP [Web Application and Services Platform] run time, so we can actually have both Cajun and WASP services deployed within a WebLogic container.
Q: Are there any significant standards efforts under way in this space?Thomas Manes: There's a new project that just got started at W3C [World Wide Web Consortium], called The Web Services Architecture Work Group. That group is going to be focusing on ways that we can address the more extended features of SOAP and to ensure some kind of interoperability. I'm also hoping that WSI, the Web Services Interoperability project that IBM and Microsoft just started, will also address some of those issues. What the W3C did was create a higher level activity, which they called Web services, and within that there are four groups. There's the XML protocol team, which is the SOAP team. There's the description team, which is a WSDL team. There is an architecture team, which is addressing higher level architecture. And then there's the coordination group, which is responsible for coordinating with other groups within W3C and potentially also with outside organizations, such as Oasis or WSI or UDDI and groups like that. I'm sitting on the architecture team, and we also have someone on both the XML protocol team and the WSDL team. We don't have anybody on the coordination team.
Q: What's your take on the emerging workflow standards?Thomas Manes: Right now there are two specs that are floating around. One's from Microsoft, called [XLANG], and one's from IBM, called WSFL [Web Services Flow Language]. As far as I know, no one else in the world has rights to use either of those specs because they're owned by their respective companies. There's certainly been no effort, in any kind of an open forum, in any case, to coordinate that activity and stuff. If you look at WSFL, you'll realize that it's not something that your average programmer is ever going to be able to comprehend and make use of. It's a very, very complicated specification. I think that's going to preclude it. XLANG is a little bit easier to comprehend. The problem I have with both of those is that they take a very workflow-oriented approach to things, and I'm not convinced that you will ever make workflow viable and simple enough and yet powerful enough to do what you need it to do. You can either make something very simple, in which case it only addresses about 20 [percent] or 30 percent of the use cases. Or you can make it very powerful, in which case it's too hard for anybody to use. And I have not seen anybody manage to simplify workflow in a way that it still is powerful.
Q: If you had one wish come true, what would it be?Thomas Manes: I want the standards process to be much faster than it is today. A year ago, IBM submitted WSDL to W3C, and they only started the W3C WSDL group now. That is horrendously bad. I mean we absolutely need to have a standardized WSDL, it's so critical to the future of the product. We also need to start addressing more interesting and challenging things, like, How do we make security work? How do we make transactions work? How do we do routing? How do we do all these other things that are necessary to make this stuff a really viable infrastructure? IBM and Microsoft have been collaborating and producing specifications, which they then submit to a standards body. I think that actually works really nicely, considering that this entire history is built on proprietary specifications defined by IBM and Microsoft and the whole world just sort of accepts these as standards, and I think that that's pretty remarkable. Neither SOAP 1.1 nor WSDL 1.1 are sanctioned by any kind of standards body in any way. They just happened to be published and accepted and have enormous acceptance. But they are not perfect specifications. There are big holes in both of those specs that makes interoperability somewhat challenging, because a lot of things are left as exercises to the implementer. When you do that, it means that each implementer does it [in] a slightly different way and then things don't quite mesh quite as easily as you want them to. That's why you have informal organizations like SOAP Builders. Every SOAP vendor in the world is a member of SOAP Builders.
Q: What is Systinet doing to promote standards?Thomas Manes: We've actually just initiated a UDDI interoperability site. We sent out a notice ... inviting all the UDDI vendors to start participating in some straightforward testing system, the same way that SOAP Builders is doing it.
Q: Who is Systinet's most high-profile customer?Thomas Manes: Deutsche Telecom has a mobile service provider in the United Kingdom called T-Motions. T-Motions is using WASP to connect the actual consumers out there on the street using phones with various content providers who can provide things like restaurant locators, gambling, stock purchases, or whatever. They're using Web services to allow the content providers to find out information about the consumers, for example where they are at a given time or what their credit history might be. They've got about 200 content providers. That's actually the real value associated with Web services, because T-Motions basically created a small set of services with a standard set of APIs.
Q: Who is driving the adoption of Web services in IT?Thomas Manes: Within any reasonable-sized organization, they have a team that is responsible for doing investigations into new technologies to see how those technologies can be used effectively within their organization. Those are folks who are currently playing with Web services today.
Q: What will it take to get the rest of the IT community on board?Thomas Manes: Business process integration and workflow and all that other gnarly stuff that is so hard to accomplish gets simplified if each of your business processes is actually represented as a Web server. Then you don't have to worry about how you actually make one application talk to the next application, it's all defined with WSDL and I know that I can make that stuff interoperate. The next thing is to figure out how to actually assemble those services in some kind of an automated process. We've got some plans under way, that I can't really talk about yet, on how one will go about doing that assembly. I think that it's actually critical that however that gets done, it's got to be simple and practically brain-dead in terms of what has to be done inside the service to make it be able to participate in an assembly. That's our focus, but certainly there's no standardization effort going on right now. I think WSFL is too complicated for the average bear. And XLANG, I think, is the wrong approach. XLANG is what's called an execution language rather than a specification language. And of course it's tied specifically to BizTalk, which is not quite SOAP standard, so there are some difficulties associated with using BizTalk.
Q: So in terms of Web service evolution, where are we?Thomas Manes: Right now we're still in the innovative stage. We're just starting to shift over into the early adopter stage. We've been selling primarily directly to the developer because most of the ... business managers aren't really ready to even think about it at this point. But we've got over 10,000 downloads of our product, and it's being used across every type of industry. I would say that the finance and telco [industries] are dominating right now. I've been promoting the concept of service-oriented computing since about 1990, and client/server sort of usurped the world at that point because it was simple and easy to use. It allowed people to effectively build solutions by themselves inside their own departments. But it was a really, really bad approach to application design, in terms of longevity and architecture and maintenance. Service-oriented computing is much better from a long-term perspective, but it's always been too hard. I think where Web services has its biggest opportunity is in making applications talk to applications. This, of course, helps us promote the use of service-oriented architecture. I don't think there are very many people who are thinking that client/server is the way to go anymore. Service-oriented architecture means that you basically build your application as a service, which can be invoked through some well-defined API. Anything that can figure out how to speak to that API can then talk to that service. Web services happen to use a specific style of protocol to implement the connection. Now the way the vast majority of the world uses Web services [is] so Web services equals SOAP. I don't think that's necessarily the way it's going to be forever, but that's the way it is today.
Q: Why has it been so difficult to get people to adopt service-oriented architectures?Thomas Manes: The impediment is the fact that it's a little bit more difficult to write service-oriented applications than it is to write client/server or GUI applications. If you think of the way people built applications with VB or Power Builder, they basically designed a user interface and then had the database exactly reflect what it is that the user was typing into the screen. The problem with that is that you couldn't really share that information with other people. It was confined to just using that GUI interface, talking to that database. It certainly doesn't work if you want to now make that available on the Web. So the problem with moving to service-oriented systems is you no longer have this nice visual approach to designing your application. You now have to break the presentation away from the actual business logic and design the business logic so that it's completely independent from the type of user interface, whether I'm coming in from a browser or through a phone or through a GUI application on the desktop. That's completely separate from the actual business logic that actually implements your code. You need to make sure that those services that you're building are highly scalable and robust and reliable and have transactions and all kinds of other hard stuff. Your average VB programmer has no clue how to do that hard stuff, and that's the biggest impediment right now to service-oriented architecture. The Web forced us to start building servlets, it's forced us to start building EJBs [Enterprise JavaBeans]. It forced us to start building ASP applications and MTS applications. All these old VB programmers who were just building GUI interfaces to talk to Oracle are forced to learn how to do better application design.
Q: How will vendors make the hard stuff easier?Thomas Manes: One of the things that we're trying to do is make it as simple as possible for you to do assembly of services and have those services automatically take advantage of security infrastructure and transaction infrastructure and state management infrastructure, without forcing the developer to actually put code into the service to manipulate and manage those things. That's actually where our long-term value-add is going to be. We're going to be creating these frameworks that make it as simple as possible for people to do this kind of assembly.