FREE ESSAY ON XML AND JAVA

XML AND JAVA

XML and Java
Abstract 
Most web developers are intimately familiar with HTML, which is a language for presenting
information on-screen so that it can be read by a human. A new markup language is rapidly
gaining attention, however. XML allows for the presentation of information which can be
read by a computer program. It is likely that the future of web development includes the
creation of increasing numbers of programs, which make intelligent use of the data on
XML-based web pages. And Java is a very good language for creating those programs. 
There has been a close relationship between Java and XML since the earliest mention of
XML. John Bosak of Sun Microsystems, Chair of the XML Working Group has said that XML
gives Java something to do (Web Techniques, pg. 43). Since there has been a decision to
provide a standard Java API for manipulating XML (WT Pg. 43), the use of Java to
manipulate XML documents is likely to continue, and increase over time. 
What is XML? 
XML stands for eXtensible Markup Language. It looks a lot like HTML. In fact, both HTML
and XML are commonly viewed as a subset of SGML (Standard Generalized Markup Language).
SGML is very complicated, a fact that has lead to it's failure to gain widespread usage.
HTML, its greatly simplified descendant, has been a resounding success, but it is
beginning to demonstrate some significant limitations. XML is in between these markup
languages in terms of complexity. It is more complex than HTML, but still significantly
less complex than SGML. (Dynamic Web Publishing Unleashed - Pg. 744-745). It is
essentially an attempt to define a common ground between HTML and SGML. 
Like SGML, XML is a metalanguage for defining markup languages. XML allows you to define
your own markup language consisting of new 'tags' which you can use to encode the
information in your web documents far more precisely than can be done with HTML. XML is
not a replacement for HTML. It is, instead, a supplement to HTML. While HTML will
continue to be used for standard web pages, XML will be useful for applications that need
more intelligent documents and more processing ability (DWP - Pg. 745). 
The main limitations of HTML are lack of extensibility, structure, and validation.
(http:// metalab.unc.edu/pub/sun-info/standards/xml/why/xmlapps.html). 
Extensibility. HTML has a fixed number of tags. While the W3C and browser developers can
(and frequently do) add tags, users cannot create their own tags to more accurately
describe their data. 
Structure. HTML does not support the creation of nested tags, which would be used to
describe and represent databases or object hierarchies. 
Validation. HTML does not support document validation. It has no means of allowing an
application to check the data for validity, or to ensure that the markup is correct and
well formed.
XML differs from HTML in all three of these major areas: 
It allows developers to define new tags and attributes as needed 
It allows document tags to be nested as deeply as needed. 
Any XML document can include or make reference to a description of its grammar and syntax
for use by applications that need to validate the structure of a document.
XML will be most widely used in applications, which cannot be accomplished within the
limitations of HTML. According to Jon Bosak of Sun Microsystems (Future of the web) 
These applications can be divided into four broad categories: 
Applications that require the Web client to mediate between two or more heterogeneous
databases 
Applications that require the Web client to present different views of the same data to
different users. 
Applications that require the Web client to present different views of the same data to
different users. 
Applications in which intelligent Web agents attempt to tailor information discovery to
the needs of the individual users.
One more quote from Mr. Bosak: XML can do for data what Java has done for programs, which
is to make the data both platform-independent and vendor-independent. 
Why Java? 
It can be argued that Java is an ideal language to use to create the applications listed
above. At the most obvious level, both have been promoted almost exclusively for use in
Web environments. But several features of the Java language make it particularly well
suited for working with XML. 
One feature is support for Unicode. Most commonly used languages still favor use of ASCII
to represent strings. This choice, however, makes it difficult to represent the character
sets of many non-English languages. Unicode, on the other hand, has some 39,000
characters, and has plenty of room for expansion. Java supports Unicode from the bottom
up (WT - Pg. 44). 
Other features of Java made it very easy to share the code needed to build XML processing
applications. The most important of these are packages, dynamic class loading, and
Javabeans (WT - Pg. 44). Packages and package naming allow for the sharing of code across
the Internet without name clashes. Dynamic class loading allows applications to ship with
a minimum configuration, and retrieve additional components as needed. And JavaBeans are
useful for expressing XML because they can have a straightforward data model, and can be
subclassed to exhibit specific behaviors. (WT Pg. 44). 
Since the early days, Java has been used to create XML parsers. One of the first such
efforts, originating in the XML-Dev mailing list used Java to create a parser which is
now known as SAX (Simple API for XML). Because the developers were from all over the
world, they needed a language, which made it easy for developers using much different
system to share their work. Java is much better for this than other languages such as C
or C++, since it is totally machine independent, and Java executables don't need to be
re-compiled to run on different platforms. (XML and Java Technologies) 
Sun has promoted the concept of portable data and portable code. Sun is adding XML
extension to the Java language to further promote its use for this type of application.
The proposed Sun extension will allow developers to use standard API functions to read,
manipulate, and generate XML text. This will make it much easier for developers to use
XML technologies in Java. It will also provide a standard, which helps ensure compatible
and consistent implementations. (XML & Java Technologies) 
Since business forms and other documents in the future are likely to use XML in order to
be more portable (machine and platform and application independent), it makes sense that
the language that will be used to process these documents will also be platform
independent. If purchase orders, insurance forms, invoices and other documents can be
sent as XML documents, then virtually any user on any platform can create them. And the
organizations, which receive and process these documents, will need platform-independent
and standards-based tools for validating and processing them. 
What kinds of applications are suited to XML and Java? 
According to JP Morgenthal, Director of Research at NC.Focus, XML and Java are
particularly well suited to the following applications. We will discuss each of these in
some detail to expand on his thoughts: 
Electronic Data Interchange and E-Commerce 
Electronic Data Interchange (EDI) 
Enterprise Application Integration (EAI) 
Publishing 
Software Development
Electronic Data Interchange and E-Commerce - The Internet has triggered a virtual
explosion of web-based business transactions. Consumers are increasingly buying products
from e-stores, and businesses are rapidly implementing purchasing and supply-chain
systems using Internet standards. Today, much of this data is moving in the form of
proprietary data files and web-based forms, which are closely tied to back-end programs
such as CGI/Perl scripts or Java Servlets. 
It has been argued that these systems would be much more flexible if they shared data
using a standard XML format. This would allow for more flexible formatting of data,
easier maintenance as requirements change, and the separation of the data from the
programs and screens which create it, and the programs which process it. When the data is
in an XML format, it describes itself. This allows programs to interpret this
description, and act accordingly. 
Without XML, each electronic transaction requires the creation of proprietary parsers for
each data format. In addition, it is necessary to implement elaborate validation routines
to insure that all required data is provided, is consistent, and meets the rules of the
transaction. This can be a significant effort, requiring custom programming to create the
data, and to process it at its destination. 
XML alleviates this problem by providing a standard way to encode data, validate it, and
parse it. This function requires the availability of a DTD (Document Type Definition).
While DTDs are not required for all XML documents, when one is present a standard parser
can refer to it and use it to determine whether or not an XML document is, in fact,
valid. If application, which creates the XML data, uses the same DTD as the receiving
application, we can be virtually guaranteed that all interested parties will be honoring
the same 'rules of the game'. And no custom programming and proprietary data formats will
be needed. This is all based on standards and widely available java-based XML parsers and
generators. 
Another benefit is that this content and format validation can be separated from the
processing application. It can even be run on a completely different machine. This
reduces the requirements for the application, which does the final processing of the XML
data, and may significantly speed such applications, since they no longer need to include
elaborate validation logic. 
While theoretically XML parsers can be created with any language, Java is well suited to
this partly because of its support of Unicode. These types of business transactions are
likely to be international in many cases, and it is well known that ASCII data doesn't
support enough characters to represent many foreign languages. Unicode is much better
suited to representing all languages. And to repeat an earlier point, Java has supported
Unicode from the start. 
It should be noted that this type of processing would work best when DTD 'vocabularies'
are developed and shared by all. If there is a common definition of an invoice, then many
companies can easily send and receive these 'e-invoices'. Unfortunately, there has not
been rapid progress to create shared 'DTD repositories' yet. According to Jeff Walsh,
published in Info World (July 19, 1999 Pg. 48): 
'While it is true that it would be nice to have an agreed-upon set of vocabularies which
everybody can adhere to, this is not the case yet and probably will not be the case in
the near future' said Norber H. Mikula, chief technology officer of both Data channel, in
Seattle, and the Organization for the Advancement of Structured Information Standards
(OASIS) industry consortium, which acts as a repository for XML schemas. 
Mikula said many of the proposals need to be put through their paces and then revised
before they are worthwhile, which does not quite match today's business models.
There has been some headway made, however. According to the same article in Info World
(pg. 48), several vendors are currently developing these specifications, including: 
CommerceNet(eCo Framework working Group): eCo is teaming with OBI Consortium, RosettaNet,
and other industry-specific groups to come up with an umbrella framework to make the
various XMNL specifications co-exist and intercorperate. 
cXML.org(commerceXML): this standard specifies HTTP-based protocols for information
exchanges and defines a DTD for various documents such as purchase orders, order
acknowledgments, and catalogs specifically targeting MRO (maintenance, repair and
operations) purchases. 
The OBI (Open Buying on the Internet) Consortium: OBI relies heavily upon existing
standards; buying and selling organizations establish an OBI trading web or extranet
using the Internet for communicating MRO purchasing transactions. 
Microsoft (BizTalk Framework): BizTalk's charter is to provide guidelines for creating
XML schemas so that developers can create DTDs and XML vocabularies in standardized and
interoperable ways. 
RosettaNet (eConcert): eConcert outlines a set of Partner Interface Process (PIP)
specifications. Central to PIP is an XML document based on specifically developed
framework DTDs that specify PIP services, transactions and messages. When used with the
standardized data dictionary, you can create catalog entries and e-commerce documents
describing products. 
XML/EDI Group (Various): This group promotes XML for electronic Data interchange
applications, creating dictionaries, frameworks, and implementation guidelines for
vertical industries.
Electronic Data Interchange (EDI) - EDI is a fairly widely used system for conducting
business electronically. It nearly always uses a VAN (Value Added Network) for
transmission, and uses either X12 or EDIFACT standards to define the encoding of data.
EDI transactions have traditionally been reserved for larger companies and large
transaction volumes because of the costs involved in setting up EDI relationships and
operating the network. EDI transactions often involve customization, especially when one
or both parties want to extend or modify the data, which is being transferred between
parties. 
It is thought that XML-based EDI can reduce the difficulty of dealing with these
customizations. It is also likely to be much less costly than traditional EDI, because it
can use the Internet, rather than an expensive VAN. Also, it should be much easier to
validate and parse XML data, since there are standards for this process, and easily
shared Java code, which implements this. And of course, this Java code runs on virtually
any platform without modification. XML and Java together provide portable data, and
portable code to process it. 
Enterprise Application Integration (EAI)- One other application that has been proposed
for XML is the passing of data between applications in a large enterprise. It has been
suggested that XML is a better solution than proprietary data formats for the movement of
this data between systems. 
In the article by JP Morgenthal, he suggested that XML could be used to send information
about sales orders from the sales to the accounting department, and information about
invoices from accounting to sales and collections. He proposed that such an XML-based
system could generate all the necessary communications for a transaction using this
standards-based data format. 
Perhaps we don't fully understand his vision, but we feel that this may not be an
appropriate use of the technology in most cases. Current shared database technology
provides for a 'two-phased commit' process which insures that all parts of a transaction
are properly recorded, or a complete rollback occurs which prevents inconsistent data. 
While the idea of XML for passing data around the enterprise sounds interesting, we don't
feel that this is going to be widely used until techniques are in place to insure that
this same capability is available. 
Conclusion 
The introduction of XML has allowed for the creation of internet-based documents, which
can be understood by software, instead of humans. XML allows the information on a web
document to be described in terms of a hierarchy of descriptive tags, making it well
suited to the sharing of data between individuals and organizations. But for this
information to be processed, programs will need to be able to handle this data in a
standard way. If these programs can be developed and run on a wide variety of computer
platforms, they will be available for use worldwide, on virtually any type of computer
system. 
This is leading to great interest in the standard, and will result in development of many
programs, which create and process XML data. For many of the reasons, which we have
discussed, Java is likely to be the language used to create many of these systems. It
will be very interesting to see which of the many ideas out there become viable business
solutions. The next 'Microsoft' is probably just getting started right now. 
Bibliography
1. Bosak, Jon (1997). XML, Java, and the future of the Web,
http://metalab.unc.edu/pub/sun-info/standards/xml/why/xmlapps.html 
2. Fuchs, Matthew, (1999). Why XML Is Meant for Java Exploring the XML/Java Connection,
Web Techniques, June 1999. 
3. Morgenthal, JP. Portable Data/Portable Code: XML & JavaTM Technologies 
http://java.sun.com:8081/xml/ncfocus.html