XML-J: Tell us what Talva does.
Martin: We do XML servers. What we do is something that's at the end of the pipeline. It sits on top of XML stores, because XML stores are also called XML servers.

We're partnering with IXIASOFT. Our product will include the IXIASOFT datastore and other XML stores. It actually includes basic folders - file system folders. The end product will most likely include the XMLExtreme datastore. We also included the Tamino datastore. Our customers can pick the best one. "Okay, I like this XML store so I may take either IXIASOFT, Tamino, or XMLExtreme."

XML-J: What do you feed into the pipe? You pull XML formatted data from the store and then...
Martin: We're just behind the Web server. We receive the GET or the POST request. The first stage is that we recognize these agents and then search the user agent capabilities in our database. We have a database that contains the information of about 900 different devices. We can recognize if the device is a VoiceXML, i-mode, or an HTML device, then we build a device profile. The device profile is used later on for the transformation stage. When the browser requests an XML document, whatever browser it is, we build this device profile, get the XML document or the document's fragment from the store, and finally transform the document into a rendering format. But not only that. We can do some aggregation with XInclude or XSLT, and more particularly with the document function.

XML-J: What's the difference between the competition and your product?
Martin: The answer is that we've created an XInclude engine, which is based on the XInclude recommendations. We created the XPart element, which inherits from the XInclude behavior and provides, among other things, conditional inclusion. For instance, based on the device profile, it will or will not include a particular document or a document fragment. You can also override the HTTP caching parameters and cache the included document to speed the future requests on the same document.

If you aggregate contents from a partner who forgets to set a Time to Live (TTL) for the document and you know that this content is renewed only once a week, you can overload that default behavior and cache the content locally. To do so, set a TTL for this document in the XPart element. We manage a two-stage caching mechanism. The first stage is caching the document on the disk. The second stage is caching the XML document in the virtual memory. However, when you build a DOM or a structure in memory, after a certain time your content is spread everywhere on different virtual memory pages. We worked hard to get a document's info set in the same page continuum. It's like a cluster. That way you don't have a lot of page fault. This is the second level of caching. We're also caching the XSLT stylesheets, which is similar to what the other engines are doing. As a work in progress we're working on an infoset virtual machine. This means it will be a virtual machine that processes infosets. You'll have operators to manipulate the infosets, operators like a processor's op code. The good thing about it is you'll be able to compile your stylesheet into code that will be interpreted by this VM.

XML-J: This VM is one that you've developed?
Martin: Yes. Last June at the GCA Conference in Paris someone made a presentation about using a VM engine to process XML documents with XSLT. We started to discuss it and then realized, "Gee, this is a good idea!" Especially since not everyone wants their XSLT code exposed. Because it's compiled as op codes, they can produce their stylesheets in binary code and protect their assets, otherwise the source is available as open. It's a choice. You can use the source code, so in that case we do a just-in-time compiling and keep the compiled version. Otherwise you publish the compiled version and there's no parsing, no translation, just code execution. It's minor things like that that improve the performance.

In addition, the server has been set from the beginning to work on a single processor machine, or a multiple processor machine with a cluster of up to 256 processors each having several processors each. In other words, a supercomputer. What we discovered from processing XSLT stylesheets on a quad processor machine is that if you don't have a well-managed heap, you end up with a situation in which you don't increase the performance even if you add new processors. Since they all share the same heap, the system swaps a lot. We manage to have each processor with its own heap. Many minor things like that increase the performance of the server and also its scalability factor.

XML-J: Typically, in an enterprise application, the next level that would sit on top of your server would be something similar to a content presentation layer?
Martin: This is where we deal with TalvaStudio.com. Since a lot of people say, "Here's the server. You say it works, but do you have anything to run on top of that? How can we manage this XML site?" we concluded that developers need a place where they can create their own XML environment to build XML applications. This is why we are creating TalvaStudio.com, which will be a free space where all the XML developers can test their XML applications.

XML-J: And that's running out of your site?
Martin: Yes, on the server side. Also, we have partners providing other development environments, such as the Tellme Studio. Included in TalvaStudio we have all the studios that are Web-based XML environments. TalvaStudio itself is an XML application. It's a wall-to-wall XML application using XSLT, XML, XInclude, and XLink.

We tend to stick to what's in the W3C recommendations and we're happy with the results so far. Surprisingly, we can do a lot more with the XML technologies than we expected at first. For instance, take what we call the NetFolder. It's a complete document-management system. At the beginning of the process used to create the NetFolder is a Java Servlet that contains all the procedural code. The Java Servlet is producing an XML document. The XML document could be syndicated or transformed and have a different look and feel.

For instance, an XSLT stylesheet can transform it into VoiceXML. From a theoretical point of view, it makes sense to produce an XML document that's produced by a Web service. For rendering devices it can be adapted to their rendering capabilities. To produce XML documents with procedural code, we've included a J2EE environment in TalvaStudio.com. This J2EE environment is used to produce XML documents, then these XML documents may be transformed. When we started this development, we weren't confident that it would work and that it would scale. Let's say you have a couple hundred connections or a couple thousand simultaneous connections, it may crash somewhere or it may take an eternity to return a rendering document or to fulfill a service request. But we learned how to balance things, such as putting the transformation process on a separate machine and the XML document creation on another one.

We came up with a new scheme, a new way to create a Web farm. Today the actual practice is to create a Web farm from a collection of HTTP servers, all with equal capabilities. We discovered that this scheme doesn't work. You have to create several specialized server farms - a server farm for transformation engines, for XML stores or XML creation engines, and for aggregation engines. As you can imagine, it's not so easy to set up. Now we're in the process of creating the tools to make that setup easier to do. We learned by trial and error, but things are getting better and we're happy with the results.

XML-J: Can people go to www.talva.com and check it out?
Martin: Yes. TalvaStudio includes the "My Community" service, again all based on XML technologies. You'll see all the people connected to TalvaStudio and be able to share and exchange with them - useful in case you're in trouble and need help or you simply want to exchange some info with your peers.
ajit @ Sys-con.com