<jdj>: SilverStream has been on the cusp of J2EE and Enterprise Java in Internet environment development. This has helped SilverStream grow from an application server company to a J2EE frameworks company and, now, a consolidation of all these efforts, a Web Services company. So, what's going on at SilverStream this year?

<litwack>: Web Services is an important technology. However, the really important thing that's happening is that the industry is going through a once-in-a-decade transformation to a new application paradigm - a new way of building applications.

I'd like to draw a comparison with client/server. Client/server wasn't a specific technology. It was the culmination of a set of technologies - graphic user interfaces, relational databases, networks, and personal computers - that resulted in a new way of building applications. And that way of building applications was very important because it was a clean separation of information from the user interface. It transformed the way we use computers in businesses from what had been predominantly an administrative or clerical function, to having the corporate repository of information available to everybody that had a computer on their desktop. That was the revolution.

What's happening today is we have a set of very important technologies - Java, J2EE, XML, SOAP, WSDL, UDDI, HTTP, the Internet - that have reached a level of maturity where we can think about building the applications in a completely different way. The GartnerGroup calls this a services-oriented architecture, and Web Services is certainly a key piece of that. The important thing about a services-oriented architecture is a clean separation of the transaction, information, or service from the audience to which it's supposed to be delivered. Put another way, it turns the traditional design paradigm backward, the traditional being: Architecting to who the application's audience will be.

In a services-oriented architecture you shouldn't know or have any design criteria that involves knowledge of who the audience is. That is so important today because, through the Internet, we can deliver applications to people we've never met or to devices that haven't been invented yet. We can deliver applications inside or outside a firewall. So a services-oriented application meets the needs of e-businesses in the Internet age because it allows us to build applications that can be flexibly deployed to unknown future audiences.

<jdj>: Can you describe SilverStream's progression in leadership roles through the advent of the application server and Enterprise Java, the frameworks that you've pioneered, and now the culmination of all these technologies with your framework and application servers under the Web servers' realm?

<litwack>: Let's look at the services-oriented architecture. The history of SilverStream is the history of the pieces of a services-oriented architecture. SilverStream was one of the first, if not the first, pure Java-based application servers in the market. Five years ago we were building one of the largest Java applications in the world. Then when J2EE came along we quickly hopped on the bandwagon and again were one of the first Java applications services to be fully J2EE certified and compliant with our 3.7 release, which has been shipping for several months now.

For the past two years we've been building a set of engines or class libraries generically on top of J2EE, which involves a lot of the pieces that are necessary in a Web Services environment. These include on XML mapping and a transformation engine that provides connectivity and integration to a broad variety of back ends such as mainframes, Relational databases, EDI, AS/400s, Web sites, or MQ series. This is important as most won't be invented from scratch. Most Web Services will be based on existing applications that becomes Web Services 1_enenabled. By creating an environment in which we can connect to back ends, we can provide an XML request response metaphor. We're already doing the essence of Web Services today and, of course, by being fully J2EE, we also have the environment for building new Java-based applications as well.

When I think of Web Services there are two unanswered problems that the standard doesn't answer. One is, "Where does the XML come from?" And the other is, "What do you do with the XML once you have it?" With our XML transformation and integration, and with our Java-based J2EE capability, we answer the question, "Where does the XML come from?" That's the service producer's side.

The service consumer side has the responsibility for delivering up the XML in a variety of ways. The key thing is to take the information delivered up from Web Services and apply the notion of relevance to the particular circumstance.

Web Services are great but we don't want to deliver them in the same way to everybody. We want to tailor them depending on who the users are-what their jobs are, whether they're high net worth individuals or retirees, whether they're business partners, corporate customers or your own salespeople, whether they're inside or outside the firewall. We may increasingly tailor Web Services to whether it's the weekend or the week, or based on what device they have connected from. Someday, with GPS embedded in wireless devices, we may want to tailor the service depending on where they are, because with GPS devices we'll know their location within 10 meters. These are all parts of the services-oriented puzzle.

At JavaOne we announced the release of the cap piece of all of this, the lock piece of the puzzle. It's our Web Services engine that we've built using a combination of our existing Java-based Web technology with things such as WSDL compilers to generate very high-performance Web Services out of any Java class. Not only is this high performance, the Web service effectively gets generated as a servlet that can then be flexibly deployed in any J2EE server?

On the client side it can be accessed either from a SOAP client with a SOAP stub that gets generated, or through an RMI stub so the Web service can be accessed as a straight remote Java object. I think this will appeal to Java developers because they can create a Java class, turn it into a Web Service by generating a skeleton and remove Java client, and the entire Web service looks like a straight Java object.

I also want to mention our plans to generate a Visual Basic and C# client, because when you create that Web service, part of being a Web service is accessibility from any kind of client, and Web Services is an agnostic technology.

<jdj>: What's in store for SilverStream, and Web Services in general?

<litwack>: Over the next few months we'll be delivering a full product line called SilverStream eXtend. It includes the engines I've just described - Web Services, XML integration, workflow, business rules transcoding for mobile devices, and content management - all running on the major J2EE servers.

We'll also be shipping our Web Services producer product, which is the creation of Web Services and our consumer product, which provides a relevant view of Web Services.

Web Services can be produced from new Java applications or existing back-end systems. The Web Services consumer product includes personalization, user customization, and customization to a variety of wireless devices. We also provide an integrating workbench that's oriented around the notion of services-oriented applications. In addition, we're beginning to provide vertical application-level frameworks, the first of which is shipping SilverStream eXtend for insurance, with actual application framework code that demonstrates to different industries the way they can take advantage of Web Services, to have the various constituencies in a business communicate electronically in an e-business