Sometimes, life's little ironies are just too funny for words. Consider an e-mail sent to reporters by Chuck Humble of Waggener-Edstrom, the long-time public relations agency for Microsoft. In his missive, Chuck (in a not so humble fashion) crows about Microsoft's .NET (perhaps it should be .NOT?) strategy for delivering "Web services" over the Internet, and lobs what he's hoping are 15 tough questions for Sun to answer about our software strategy.

We think Chuck has a dilemma. You see, he thinks the race just started and is feeling good because Microsoft sees Sun in his rear view mirror. Poor Chuck. He doesn't understand that Microsoft is about to be lapped.

Well, Chuck, we really want to help you... really. So here's our response to your questions.

Microsoft Question 1: Why is Sun having a special day to discuss its software strategy when Scott McNealy believes "software is simply a feature of hardware?" Does this mean Sun is abandoning all its software development for platforms beyond its own hardware systems? Industry wags joke that the way Sun builds a $1 billion software business is to buy two $1 billion software businesses and manage the two for a year. Can Sun be a successful software provider in a hardware-centric culture?

Sun Answer: We absolutely believe that software is a feature, even if Microsoft isn't getting that point. Consider call forwarding on your telephone system. How do you get it? Do you order a piece of software, load it, configure it, update it with new features, etc.? No way. You call the phone company and order it. You let them deal with the complexity.

That said, we can understand why Microsoft might be getting a bit testy when it comes to the service-driven network. After all, they've spent billions building a brand in software, and now find that the next battlefield is for services and that software is no longer front and center. That's got to be pretty scary.

As for hardware. Yep, you've got us. We make hardware. But in our experience we haven't found a piece of software yet that doesn't require hardware. It takes both (not to mention partners and customers) to deliver the service. Of course, you're learning all about this as you're trying to ship your X box.

Microsoft Question 2: If Sun is embracing Web Services (XML-based interactions between systems), does this mean they are abandoning EJB and RMI as the glue between systems? How does Sun reconcile its participation in W3C XML Protocols with its promotion of ebXML? Does Sun actually believe in XML for messaging? If so, how come the "Java APIs for XML RPC" initiative characterizes XML Protocols as suitable only for RPC in sharp contrast to the actual charter of the XML Protocols Working Group?

Sun Answer: Chuck, your questions underscore how a little bit of knowledge can be a dangerous thing -- one that leads to mixing apples with oranges.

It's clear that you don't understand that Enterprise JavaBeans (EJB) technology comprises a programming model and RMI a method of communication between Java components. In other words, they do different things. RMI was developed for use between Java language-based programs (it works great, by the way); XML's strength is its language and platform independence, which is great when you don't know what is working with what. We support both because both are important to developers and to customers. That's the essence of openness. And that's why we aren't abandoning either.

As for reconciling our participation in both ebXML (which stands for electronic business XML) and W3C: It's easy, since they focus on different things (that apples and oranges thing again, Chuck). ebXML is about creating a horizontal framework for facilitating global trade; message exchange is but one area of work. The W3C XML Protocol working group is more broadly focused on message exchange and has taken SOAP as its starting point. We think SOAP is a significant technology for message exchange and are very interested in seeing the messaging work of both groups unified. (By the way, please tell your Microsoft friends that we miss them at the ebXML meetings. We haven't seen them since the first meeting).

Finally, you might want to read the text of JSR-067 for XML messaging and JSR-101 for XML RPC.

Microsoft Question 3: Sun's claims to having invented XML are refuted by Jon Bosak himself. In The Birth of XML: A Personal Recollection (http://java.sun.com/xml/birth_of_xml.html). Bosak states that the effort was given the green light by the W3C's Dan Connolly and though "organized, led, and underwritten by Sun," the actual work was shared among Bosak and people from outside Sun, including Tim Bray, C. M. Sperberg-McQueen, and Jean Paoli from Microsoft. And if Sun invented it, why are they so late supporting it in their products? Sun has recently shipped its first generation XML parser, while Microsoft is on its fourth generation.

Sun Answer: Uh, Chuck... forgive us for pointing out the obvious, but you partly answer the question yourself. If a) Sun organized, led, and underwrote XML development as you point out, and b) Jon Bosak of Sun was the leader of the working group, then c) doesn't that mean we should get a lot of credit? We think so.

As to part two of your question regarding Microsoft's alleged fourth generation: We'll refrain from the oft-repeated barb that Microsoft doesn't get it right until Version 3.0, and cut to the chase. Contrary to your attempt at revisionist history, many of our products already support XML. In fact, we delivered our first XML parser two years ago. In a world operating at Internet speed, that doesn't qualify as recent.

We could list other XML products, too, but we think that would be almost as tedious as some of these questions, Chuck. If you really want to know, call.

Microsoft Question 4: Sun's claims that Java and XML are joined at the hip violates XML's main benefit- independence from any platform or programming language. Why is Java any better at processing XML than any other language? Exactly what is this special relationship that Sun talks about? What makes Java different in terms of XML than any other programming language?

Sun Answer: You're right, Chuck. We have said that the two are joined at the hip. We may not have been clear about our intent, so here it is:

There is a natural and wonderful affinity between Java technology and XML. The first creates portable code in an object-oriented fashion; the second defines a method of exchanging portable data and documents across the Internet. Both satisfy a tremendous demand among developers and customers for independence and choice. They want interoperability of portable data on a range of different platforms, and they're finding that on the Java platform -- not to mention the benefits of higher productivity and rapid time to market.

Now let's look at the alternative that you are suggesting. What happens, Chuck, when XML hits a computer in the Microsoft world? In the world that the Java community envisions, that program can run on any computer. That's just not so in the Microsoft world. It will only run on Microsoft .NET (presuming, of course, that it was available today).

Are you beginning to pick up a theme here, Chuck? Independence. Choice. Interoperability. Portability. People like these things. That's why they are voting with their feet (and pocketbooks) for the Java platform... and that's why to Sun (and millions of others), the Java platform is optimal for XML processing.

Microsoft Question 5: XML has never been core to Java; rather Sun has attempted to bolt it onto the side after the fact. For example, there is no way to convert an EJB Entity to an XML document or stream and there is no way to generate XML from a JDBC ResultSet. Sun's claim for supporting XML in J2EE and EJB is only for defining metadata. Sun's claim of XML support in J2EE and EJB, "you use XML to define the metadata" relegates XML to a minor role. Sun's licensees have proceeded without Sun to do their own XML support, which means there is no consistent support for XML in Java. IBM and BEA, for example, are not adhering to Sun's spec for an XML parser API. And given licensees like IBM are resisting Sun's efforts to add anything else to the core Java platform as it undermines their ability to add their own value, how does Sun plan to be a driver of XML across Java licensees?

Sun Answer: Whew! Take a breath, Chuck. It's clear the lack of oxygen is fogging your logic.

The Java platform has a rich set of APIs available to do any number of things. It's capable architecturally of supporting whatever the developer wants to do. Chuck, go look at the ground breaking work that's being done in the areas of XML processing, XML binding (i.e., translating Java to XML and vice versa in just one line), XML messaging, XML registries, and XML remote procedure calls.

And the hits keep coming, Chuck. There is strong support among the Java community (including Sun) for the continued addition of APIs into the standard, adding to the 100 great ones that are already available or are on the planning table right now.

But do you know what the really cool thing is, Chuck? The way that the Java platform and its APIs are architected lets people work on what they know best in this case, the Java language yet the platform gives them the ability to take full advantage of XML capabilities without having to be XML experts.

Of course, we wouldn't expect you to know this, Chuck, given Microsoft's position (or lack of one) in the Java community.

So the bottom line is: We don't think we need to do anything to drive XML across Java licensees. We think that the Java community will drive itself because of the natural affinity that is emerging. Maybe that's the big difference between Sun and Microsoft, Chuck. Perhaps, you think developers are dense and have to be driven (or paid beaucoup bucks) to adopt a technology; we think developers are smart and creative, and that presented with great technology they can recognize value on their own.

Microsoft Question 6: Why does Sun think Web Services are just APIs? How does Sun intend to develop applications end-to-end? Windows 2000 and .NET have XML end-to-end. Data, messaging, schemas, caching, transforming, XML views on data (hierarchical or relational), tools, data stores, etc. You also need support in your infrastructure. Where is the iPlanet support for XML? Microsoft has made XML part of the core of SQL Server, BizTalk Server, Exchange and Commerce Server.

Sun Answer: Let's cut to the chase, Chuck. The short answer is -- together with partners -- we're delivering the technologies today that are making Web services happen right now. By contrast, anyone who wants to adopt your model will have to wait until 2003, the year Microsoft projects it will be shipping the bulk of the .NET goodies that you raise in your question.

There's an even more important point to reconcile, Chuck, when it comes to talking about an end-to-end architecture. That is, the world will remain forever heterogeneous with new technologies that will need to interoperate with existing technologies. Customers will always choose technologies that enable them to preserve their investments in databases, ERP back-ends, mainframes, and the like. Java technology and XML provide this.

Just as an aside, Chuck, we're curious about your comment that "Windows 2000 and .NET have XML end-to-end." Are you suggesting they are joined at the hip?

Bottom line: No company can afford to rip out what they have and start over every time technology advances. And no technology company can force its customers to do so, unless of course they have a monopoly on technology.

FYI: As to your question about iPlanet solutions, you'll just have to tune in on Monday afternoon to hear our presentation.

Microsoft Question 7: ebXML (pronounced 'ee-BIX-i-mell') appears to be a key part of Sun's strategy and seems to be its preferred standards body. Why ebXML as opposed to W3C? Is ebXML even suitable for anything outside of EDI-like B2B messaging? W3C has very successfully developed XML and a host of other standards that run the Web and is working on key Web Services technologies like SOAP (Simple Object Access Protocol), as well as other standards that run the Web. ebXML has a narrow focus around migrating EDI solutions. While this is an important task, why should anyone consider ebXML instead of the work going on in the W3C? What has ebXML delivered and seen adopted by the marketplace? Will ebXML even be around in four months? Its charter expires in May and there is talk amongst participants of not renewing it.

Sun Answer: Chuck, such divisiveness! It would almost appear to a curious outsider that you are trying to drive a wedge between the two groups.

The truth is, Chuck, that the work being done by ebXML and W3C are very complementary.

We think ebXML is great because it helps anyone anywhere do business with anyone else over the Internet. The focus is on the creation of simple technologies that can be used by small, medium, and large businesses. In fact, it's the only soup-to-nuts framework for e-business that is fully open and available to participants today.

Just look at what's been accomplished so far, Chuck. The ebXML team has published specs ahead of schedule (how often does that happen in our industry?), and it has delivered proof-of-concept demos before a live public audience in which more than 15 vendors participated -- proving that the open stack works!

The work being done by the W3C XML Protocol working group is important, too. That's why we joined. But it's different. Is there some overlap between the two? In the area of messaging, yes. Interestingly, though, that overlap was only created when Microsoft took SOAP to the W3C XML Protocol Activity Working Group after expanding it from RPC to messaging.

As to the second part of your question: Will the ebXML charter be renewed? We think so. It's backed by 2,000-plus participants on five continents, and has drawn the interest of a half-million potential users. Moreover, though the ebXML group is young, it has the backing of the United Nations, which was chartered in 1945, and the OASIS standards group, which is eight years old.

But we're really curious about two things, Chuck: How would you and Microsoft know what talk there was among participants on the future of ebXML? Microsoft hasn't attended a meeting since the very first one.

Oh, and one last thing, Chuck -- it's pronounced E-B-X-M-L.

Microsoft Question 8: What is Sun's story for supporting multiple programming languages? Web Services are inherently multi-language. While Sun obviously prefers Java, what is its strategy for supporting multiple languages (e.g., PERL, Python, Eiffel, SmallTalk, C++) given over 90% of the world's programmers doesn't know Java. What is Sun's strategy for supporting new languages that emerge? Does Sun believe Java is the right language for every task? If so, when will Solaris be written in Java? If not, please explain what customers should use when and why they should have to rewrite all their existing applications in Java.

Sun Answer: The important part about Web services isn't that they are multilanguage. Of course they are. What's more important is that Web services are language-independent. The question is, can you take advantage of all the services regardless of what language is used to write it or what platform is used to access it? Our answer is yes. What's yours?

You see, Chuck, openness is less about checking in to a technology; it's more about whether you can check out when and if you want. Let's see how that works in a real-world scenario. You can check in from LDAP to Active Directory, but once there you can't check out (move from Active Directory to LDAP).

Microsoft Question 9: Sun talks a lot about open standards, yet it has a proprietary processor, proprietary systems and a proprietary operating system. Claims that Java is an open standard seem to ignore the fact that Sun withdrew standardization efforts from both ISO and ECMA. You can't have a standard just by unilaterally declaring something to be a standard. Or is the definition of standard now something that has published specifications? How is that any different than say Windows?

Sun Answer: We hate to be the first ones to tell you this, but the concept of open applies to architecture, not to implementations. And architectures and implementations are two different and independent notions.

In fact, our strong belief in open-standards architectures is what enables us to compete so effectively.

Even beyond these points, however, you're just plain wrong about our processor and operating system, Chuck: The SPARC processor is an IEEE standard; in fact, it's owned by a company called SPARC International. The Solaris Operating Environment complies with Spec 1170, which defines the UNIX® standard. Its source code is openly available, too, allowing developers and customers to innovate.

But it gets even better, Chuck. Look what we've done with the Java language, the Solaris Operating Environment, and StarOffice software. In each case, the source code is open to view and innovate for developers and customers. Can you say the same about Microsoft Windows or Office? We were intrigued by your recent announcement that you are giving large companies some limited access to Microsoft Windows, but were disappointed that you didn't go further, i.e., they can look at it, but they can't change it. It makes us think that perhaps this is an end-of-life version of Microsoft Windows that you've placed into escrow for companies that are dependent on it.

Here's one other point you might want to consider, Chuck. When governments want competitive quotes on UNIX, they can get multiple ones because there is a published standard. That's not true of NT -- there is no competitor in that space because it's the only thing in its category.

Microsoft Question 10: How is this announcement not a belated and vaporous response to Microsoft .NET? How can Sun's existing product line suddenly be just the right thing for doing Web Services? Suddenly what's old is new again? If Sun insists on a term other than Web Services (e.g. Smart Services), why is it not willing to use the term the rest of the industry is using?

Sun Answer: Chuck, we are enormously flattered by Microsoft's .NET. After all, it's recognition of a vision that we've had since Scott first uttered the phrases, "The Network Is The Computer" in the late 1980s; and "the service-driven network" in 1996.

Now that the world has recognized this vision, though, it's time to talk about what actions we are taking to get there. That's what Monday is all about.

Since you're the last one to the table, we'd be happy to share some of our insights so you can start developing applications today.

Oh, about your confusion on definitions let us spell it out for you. Smart services are smart Web services. Again, tune in Monday.

Microsoft Question 11: How does Sun explain its progressing from ignoring SOAP to saying it is a bad idea to saying that it is not exactly opposed to it to saying it is an OK technology for limited use? SOAP has not changed. What has? Does Sun support SOAP or not? If Sun does now, is the support unqualified or does it come with a bunch of caveats, such as positioning SOAP as a simple, RPC-only mechanism? Has Sun read the SOAP v1.1 spec? If SOAP is inappropriate for some tasks, what is it inappropriate for and what is Sun proposing as an alternative? The "Java APIs for XML RPC" initiative avoids any mention of SOAP. Why is this? Will Sun allow its customers to interoperate with SOAP--using Web Services? Will Sun support WSDL (Web Services Definition Language)?

Sun Answer: That's downright disingenuous, Chuck. SOAP has changed a lot. It started to become interesting to us when IBM made additions to the mediocre specification that Microsoft initially championed (you're right, we thought that specification was a bad idea).

Still, you're probably wondering what we think of SOAP. So there is no confusion: We think it's great! We support it on the UDDI, on W3C XML Protocol Activity working group, in the Java language, and in other products.

That said, we're cautious because we have concerns about what Microsoft is doing with SOAP. For example, Microsoft is pushing hooks that would allow it to create extensions to the SOAP framework that would require Microsoft technologies to access Web services. The only way those services can then be accessed in their richest form is via the Internet Explorer browser connected to a Microsoft Windows server. That's called lock-in. That means no choice. We think that's wrong.

Our experience is that Microsoft uses standards as second-class connections. They make them available where they must to communicate outward, but they lure customers into a proprietary lock-in.

Then again, your actions on the standards front don't surprise us. You give yourself away in your own questions. For example, "allow" our customers to interoperate? Everyone knows that no vendor can dictate terms to its customers.