Companies have long dreamed of assembling their enterprise systems from a collection of network building blocks. CORBA and DCOM, both early attempts at tackling this problem, never got very far in terms of adoption. But now that Web services have burst onto the scene, it looks like SOAP and WSDL will succeed in becoming the lingua franca for distributed computing, thereby providing the catalyst for a wholesale move toward service-oriented architectures (SOAs).

Since its inception, XML has gained a strong foothold on Wall Street, but the use of XSLT for financial applications has been selective. This article reviews a real-world case study involving XSLT (and other 'new' technology tools) that led to impressive business results.

Graduating Guy was president of the Students Against Sweatshops organization at NYU. A strong voice for equal rights, he spoke at many gay rights rallies and almost any other social reform event. Newly graduated, he now works at Andersen Consulting and plans to vote Republican in the next election.

During the past few months I've seen several discussions on the validity of the term XML developer. Does this breed of developer exist in today's computing industry? Has XML matured to a stage that it warrants job descriptions for developers who specialize in XML programming? Is there an independent category of programming that relates primarily to XML?

In case you haven't heard of him, Wopr is a military computer that was prominently featured in the movie Wargames. He was tied into all of the world's major networks, which caused problems since his primary purpose (for some reason) was to wage nuclear war on himself. The brat pack defeated his plans then, but he claims his time to rule all computers has come again.

As Java and XML continue as the de facto standard for developing enterprise applications, issues arise in using these technologies. For example, the need to store XML data, and the criteria for selecting the appropriate repository. Here's a real-world example of how applying XML to the wrong problem can lead to the wrong solution.

While the short-term payoff of Web services technologies like SOAP and WSDL is faster, cheaper, simpler integration, I believe the long-term benefits will be more profound. Specifically, I think that Web services will catalyze a trend toward service-oriented architectures in which enterprises view their systems as an orchestrated web of services that extend beyond their firewalls into the systems of their partners and their customers.

Currently Enhydra is receiving lots of attention for its capabilities as a server for wireless applications, but application service providers (ASPs) can use it to improve their ability to provide custom branding while at the same time reducing development costs. This article outlines some of the design patterns we used with Enhydra to create a set of applications that support thousands of very different looks from a single code base.

The Transforming Robot is a 20-ft-tall humanoid machine that can turn into an airplane. He used this talent to become a film and television star in the 1980s, but he soon found himself without a job in the '90s. He was excited to hear about XSLT, remarking at the code, 'There's more here than meets the eye!' And then he hunched over and groaned sadly.

It sounds so easy. First, get a bunch of people together who share a common need to interchange some type of data - say, invoices. Explain XML to them. Explain the significant technical benefits of having an industry standard schema for invoices. Get technically minded individuals into a room with plenty of whiteboards and caffeine. Sometime later they'll emerge with a consensus model of what it is to be an 'invoice' enshrined in some schema language (UML/XML Schema/DTD/Relax NG/whatever).

No one can beat my kung fu style! I don't care if you're a Java programmer, Orc, or both. I'll defeat you either way. The rest of the office is in fear of my l33t programming skills, and my constant Nerf dart gun fights in the office. But I think most of the fear is from the former.

Now that the age of limitless optimism is over and it's trendy to be cynical, I hear many Web services cynics remark that there's nothing new here. They're just components. Been there, done that, and in fact we called it CORBA (or COM). This leads to the inevitable questions about what truly is new and different, and what is empty hype for yesterday's news.

Kris Kringle's history is kind of a mystery. He didn't seem too interested in giving us much information on his technical experience. We know that he started working in Russia, so maybe he knows Cobol or something. Regardless, unlike normal celebrities he is a wise and innocent sage. We are excited that such a personality would want to write for us, so we give him the floor.

There was a period around 1999-2000 when anything XML was hyped beyond belief. An XML-centric GUI tool, no matter how narrow in focus, attracted interest and, often enough, VC funding. The net result was a myriad of XML tools - really XML gadgets - that tried to address a large number of overlapping small problems. As a rule, all the GUI tools vied for the .xml (or .dtd, .xsd, .xsl, etc.) file extensions and interoperated poorly with other software.

That's right. I always knew my talent for making unorthodox spiderwebs would come in handy someday. And this past year it really has. I used my talents to save a friend from the ax. And I can do the same for you. Let me explain.

I can still remember the first time I met Dr. Charles Goldfarb (the father of XML and one of the creators of SGML). It was early 1998 and the specification had just become public. We were on an XML panel at a conference and were asked what we thought were the strengths of XML. Charles discussed the merits of XML with regard to many document-processing capabilities, as this was a key focus for the creation of SGML/XML. I discussed the merits of XML for messaging and distributed computing.

Have you created me just to destroy me? Do your Malthusian curiosities know no bounds? Will your overnight torture sessions, using me mercilessly in your infantile games, ever be brought to justice? I have a good alternate activity for you: do your freakin' job. In fact, I'll help you, if you'll please stop pummeling me to death. Allow me to introduce you to the power of XML.

Is XML required for Web services? Not necessarily. Developers have been designing and building 'Web services-like' solutions for several years - long before the term Web services (or the Web, for that matter) existed. RPC introduced the concept of location transparency - distributed objects (DO) that could be located and utilized regardless of their location on the Network. Clients used IDL for describing and contracting services with distributed objects.

Hel-LO there! I've started using XML recently, and let me tell you, I CAN'T live without it now! LOL! XML can really help you keep track of your computer files, IMHO. That is, if your computer needs as much organizing as mine does, anyway ;-). If you don't think you need that, well, LYL, but IGJ! :-p But if you think you could use the organizing power, then stick around!

Listen up! This is your security chief talking about XML encryption. I better not catch any of you dozing during my speech, because my Laser Pointer is set to stun! I have found that our online databases contain some unencrypted XML information. This is unacceptable!

Process- or workflow-based applications are making a comeback. They ease the concept of plug-and-play functionality by separating application logic into discrete individual components that can be replaced at deployment time by existing infrastructure logic. This type of approach allows us to develop software to the 80/20 rule. Using this rule, enough functionality can be provided out of the box to solve a specific problem (80%) without customization. Over time, the software can be enhanced and customized to leverage enterprise application data (20%) without modifying the overall business solution.

In previous articles in XML-J (Vol. 2, issues 3, 4) we documented the thought processes involved in Crossmark's development of a knowledge management system using NeoCore's XML Information Server. Although the first version of the application isn't yet complete, we'd like to share some of the insights we've gained during the development period.

Many companies have been building P2P systems for a number of years, even before Napster made P2P famous. In fact, P2P has been around for a long time under other names. Distributed computing is the most accurate - it captures the essential idea the best.

For the past 20+ years SQL has been the predominant query language, but is it now time for a change? The W3C XML Query Workgroup was chartered to develop a query language for XML. It was formed by a large group of companies, each with a wide range of objectives for their particular products. In my opinion, these companies fall into two camps: the data-centric or traditional database and the document-centric. However, there's no real definable dividing line since many companies blur the line on some of the issues.

For service companies, such as eye-care chains and auto maintenance shops, the time spent performing the service is their inventory so lost time means lost money. Customers who call a business and are frustrated by the time spent on hold or wading through a touch-tone system (punch 1 for billing, punch 2 for customer service) often hang up for good. On the other hand, businesses that employ live operators to schedule routine customer appointments aren't making good use of valuable staff resources. Today's slow and cumbersome way of making reservations and appointments is clearly in need of a face-lift, and that's where Xtime comes in.

Since agreeing to chronicle the thought process behind CROSSMARK's Knowledge Management System (KMS) and the use of NeoCore's XML Information Server, I've been involved in two incidents that convinced me that CROSSMARK needs both of these to be successful.

XML is changing the business world by making integration easier. You can't pick up a computer industry or business magazine without seeing an article about the impact of XML on large software infrastructure companies such as Microsoft, Oracle, and SAP.

People are beginning to understand the power of XML. It's an enabler for structured communication within and between companies. XML-formatted documents are used for Enterprise Application Integration (EAI) projects to exchange data between disparate systems within an enterprise and B2B solutions, linking buyers and sellers and, more generically, consumers and producers. Both EAI and B2B solutions require the same thing: an easy method to define the data that needs to move between internal systems or between two or more organizations.

Do you really have to spend $50,000 a year and commit to spending that amount for each of the next three years to have formal input to the W3C process? Well...yes and no. If you expect to have hands-on influence in the development of W3C Recommendations for XML and other Web technologies, the answer is a qualified yes. There are two levels of membership: Full Member and Affiliate Member. However, if you want to participate in the Recommendation Review Process, then no.

In today's competitive environment if a company isn't knee-deep in e-business, many times it's not in business at all. Organizations have realized that leveraging the Internet can give them tremendous competitive advantages, but along with these advantages comes increased challenges.

There's no doubt about it, Web services are a hot topic in the XML world. It's somewhat ironic that when Jon Bosak, then an online information technology architect at Sun, brought a group of us together in 1996 to bring the powerful concept of generic markup to the Web, Web services were far from our minds.

Many products currently support XML as an input/output format; that is, they can translate back and forth between their internal data formats and APIs and those of XML. Such XML-enabled products have many advantages over their competitors that don't support XML. They can more easily exchange data with other products running on other platforms, and they can be programmed to some extent by means of code written to XML-related specifications.

Managing a company's IT infrastructure has become more complicated in recent years. The tools at the disposal of IT managers haven't quite figured out how to work together to deal with this complexity. Instead, to understand how the infrastructure is actually supporting the business, IT managers struggle to manually assimilate a grab bag of incompatible technologies, often with unsatisfying results.

We now live in an age of rapid change. Long gone are the days of writing a business plan, analyzing every detail, then living with that plan for years. The business climate of today demands split-second decisions, rapid execution and competitive leapfrogging that happens in a matter of weeks, not years. In other words, the MO for most businesses is constant change: add a feature, add a partner, add a business unit - most often outside the scope of the original plan.

The very fact that you've picked up a copy of XML-Journal or are viewing it online at www.XML-Journal.com and are reading this editorial means that my job is half done. Because it shows that you're already paying attention to XML and thinking about how it will change the world of business. But you may be confused about just what it all means to you, and which direction you should take. So let me try to unconfuse you....

XML is a significant technological achievement, but what's it really good for when it comes to e-business and industry applications? In these columns I'll discuss how companies and consortiums are developing XML specifications for a wide range of industries. Most of the hot activity these days is around using XML for messaging for business integration and business-to-consumer (B2C) and business-to-business (B2B) e-commerce. I don't expect to discuss publishing in any depth, though some interesting work is going on with content distribution such as ICE and newspaper electronic formats such as XML News, and I'll probably talk about it in future columns.

This article explores the paradox that sharing a common vocabulary can actually restrict the richness and nuances of a business paradigm.