|
What is XML?
The following points explain the purpose of XML:
- XML stands for eXtensible Markup
Language.
- XML is a markup language much like HTML.
- XML was designed to describe data.
- XML tags are not predefined. You must define
your own tags.
- XML uses a DTD (Document Type Definition) to
describe the data.
- XML with a DTD is designed to be self-describing.
It is important to understand that XML is not a
replacement for HTML. The main purpose of HTML is the Format the Data
that is presented through Browser. For Displaying data on Handheld Devices
WML is used. The purpose of XML is not to Format the Data to be displayed.
It's mostly used to store and transfer data and to describe the data.
It is device or Language independent and can be used for Transmitting
Data to any device. The Parser (Or the Program which is capable of understanding
the Tags and returning the Text in a Valid Format) on the corresponding
Device will help in displaying the data in required format.
You can define your own tags in XML file. The way these tags will be interpreted
will depend on the program, which is going to get this XML file. The data
embedded within these tags will be used according to logic implemented
in the secondary program, which is going to get this XML as Feed.
In many ways, the Java language has become the programming language of
choice for XML. There are now complete tool chains for creating, manipulating,
transforming, and parsing XML documents.
But while many Java developers use XML daily, Sun has lagged behind the
industry in incorporating XML into the Java platform. Because the Java
2 platform went gold before XML had made its mark as a key technology
for everything from business-to-business integration to Web site content
streamlining, Sun has been using the JSR process to grandfather in existing
XML APIs that have gained wide acceptability.
The most significant addition to date has been the inclusion of JAXP,
the Java API for XML Parsing, which includes three packages:
- org.w3c.dom, the Java implementation
of the W3C's recommendation for a standard programmatic Document Object
Model for XML.
- org.xml.sax, the event-driven Simple
API for XML parsing.
- javax.xml.parsers, a factory implementation
that allows application developers to configure and obtain a particular
parser implementation.
Though the inclusion of these packages is a good
thing for Java developers, it merely represents a formal nod to existing
API standards, and not a giant leap forward in providing elegant Java-XML
interoperability. What the core Java platform has lacked is an intuitive
interface for manipulating XML documents as Java objects.
Enter JDOM. The brainchild of two well-known Java developers and authors,
Brett McLaughlin and Jason Hunter, JDOM was inaugurated as an open-source
project under an Apache-like license in early 2000. It has grown to include
contributions and incorporate feedback and bug fixes from a wide base
of Java developers, and aims to build a complete Java platform-based solution
for accessing, manipulating, and outputting XML data from Java code.
It's the API, dummy: Where JDOM Fits
JDOM can be used as an alternative to the org.w3c.dom package for programmatically
manipulating XML documents. It's not a drop-in replacement, and, in fact,
JDOM and DOM can happily coexist. In addition, JDOM is not concerned with
parsing XML from text input, although it provides wrapper classes that
take much of the work out of configuring and running a parser implementation.
JDOM builds on the strengths of existing APIs to build, as the project
home page states, "a better mousetrap."
To understand why there is a need for an alternative API, consider the
design constraints. Language independent. The DOM wasn't designed with
the Java language in mind. While this approach keeps a very similar API
between different languages, it also makes the API more cumbersome for
programmers who are used to the Java language's idioms. For example, while
the Java language has a String class built into the language, the DOM
specification defines its own Text class.
Strict hierarchies. The DOM's API follows directly from the XML specification
itself. In XML, everything's a node, so you find a Node-based interface
in the DOM that almost everything extends and a host of methods that return
Node. It's elegant from a polymorphism point of view, but as explained
above, it's difficult and cumbersome to work with in the Java language,
where explicit downcasts from Node to the leaf types lead to long-winded
and less understandable code.
Interface driven. The public DOM API consists of interfaces only (the
one exception, appropriately enough, is an Exception class). The W3C isn't
interested in providing implementations, just in defining interfaces,
which makes sense. But it also means that using the API as a Java programmer
imposes a degree of separation when creating XML objects, as the W3C standards
make heavy use of generic factory classes and similar flexible but less
direct patterns. For certain uses where XML documents are built only by
a parser, and never by application-level code, this is irrelevant. But
as XML use becomes more widespread, not all problems continue to look
so parser-driven, and application developers need a convenient way to
construct XML objects programmatically.
To the programmer, these constraints mean a heavy (both in terms of memory
use and interface size) and unwieldy API that can be hard to learn and
frustrating to use. In contrast, JDOM was formulated as a lightweight
API that, first and foremost, is Java-centric. It does away with the above
awkwardness by turning the DOM's principles on their head:
JDOM is Java platform specific. The API uses the Java language's built-in
String support wherever possible, so that text values are always available
as Strings. It also makes use of the Java 2 platform collection classes,
like List and Iterate, providing a rich environment for programmers familiar
with the Java language.
No hierarchies. In JDOM, an XML element is an instance of Element, an
XML attribute is an instance of Attribute, and an XML document itself
is an instance of Document. Because all of these represent different concepts
in XML, they are always referenced as their own types, never as an amorphous
"node."
Class driven. Because JDOM objects are direct instances of classes like
Document, Element, and Attribute, creating one is as easy as using the
new operator in the Java language. It also means that there are no factory
interfaces to configure -- JDOM is ready to use straight out of the jar.
JDOM makes use of standard Java coding patterns. Where possible, it uses
the Java new operator instead of complex factory patterns, making object
manipulation easy, even for the novice user.
IVR, XML Vision: Hype or Reality?
The answer is a little of both. MediaVue launched money-saving, self-service
customer applications based on standards such as XML and Voice XML that
reduce the load on your agents. You've integrated your CRM software with
computer telephone integration (CTI) so that back-end database information
on customers is available to agents in the form of screen pops.
Customers reach your contact center any way they wish -- voice call, e-mail,
chat and real-time collaboration over the Web. The customer experience
is consistent across all media, and each interaction is immediately reported
so updated information is available right away. The contact center blends
resources, and manages and reports on all contacts via a common application
suite.
This contact center is possible with today's technologies, but full-blown
implementations are still few and far between. However, experts are confident
that Vo IP-based, multi channel contact centers are the future of customer
relations, so it's important to start planning.
The next-generation contact center requires two fundamental architectural
shifts. In the network infrastructure you need to shift from the TDM PBX
world to VoIP. And in the applications infrastructure you need to migrate
call routing and reporting, traditionally handled by automatic call distributors
(ACD), from closed switching systems to open, industry-standard servers.
Open Architecture
Open architecture offers the promise of infrastructure-agnostic applications.
Routing, reporting and management functions can run on a server that talks
to the switching infrastructure. Open applications can seamlessly route
voice calls, e-mail and Web-based contacts, and they can connect online
customers with contact center agents via chat, escorted browsing or collaborative
form completion. Switch vendors offering open architecture contact-center
products include Cisco and Nortel.
The idea is that once contact-center applications are freed from single-vendor
proprietary systems, customers would be able to select best-of-breed products.
This open architecture would attract a larger pool of application developers,
leading to new capabilities, lower costs and improved integration.
For example, a Swedish financial services company servicing 3 million
customers and handling 44 million calls per year (85% of them automated),
has deployed a framework to transform its contact-center operation, improve
the customer experience, and save more than $1.5 million per year.
By migrating from the ACD applications on its Nortel switch to a server-based
software to manage not only phone calls, but also other media. The IP
Contact Center routes contacts and integrates with information systems
and databases. And rolling the system out to additional sites would be
a relatively quick once the initial infrastructure was in place.
Customers have the choice of which channel they want to use to reach the
company and the software funnels customers to the best available and qualified
of 1,000 agents in 14 centers, considering language, product/service and
customer type.
Limitations, Opportunities
With an open architecture, users theoretically can mix and match products
from various vendors. But that point has not been reached yet. For example,
switch infrastructure vendors offer specialized applications that are
tuned to their own products or they promote the pre integrated capabilities
of their server applications tying together ACD, interactive voice response
(IVR) and CTI functionality. So the world is not as "open" as it might
seem.
On the plus side, customers can use standard interfaces to make integration
easier. For example, APIs, such as TAPI and JTAPI, link switches to servers.
CRM and CTI solutions integrate with pre built adapters, such as the MediaVue
CRM. These allow for integration with a top-tier CRM package, in hours
or days, rather than weeks or months. Similar connectors integrate IVR
systems and reporting tools.
Other tools further the goals of openness for ease of integration, interoperability
and portability. Standardized yet flexible data schemas and data access
provided through SQL, Open Database Connectivity (ODBC) and XML are examples.
The architecture frameworks of Java 2 Platform Enterprise Edition, .NET
and Common Object Request Broker Architecture also are becoming prevalent
in contact-center applications today.
Vendors have been responsive to customers' need for easy integration by
offering an increasing number of connectors. Many leverage standard tools,
such as ODBC; XML; and extraction, transformation and loading (ETL) applications.
Faster and easier integration of the diverse elements in a center is critical
to enabling efficient and effective resource management.
Most vendors seeking to integrate with CRM solutions have, or will have,
connectors to the top four products. For these vendors, there likely is
a full-blown product. For others, it is an open hook -- a software development
kit (SDK) or API that can be written to more readily. CRM and CTI integration
now is tackling the thin client architecture, which most CRM packages
also are migrating to.
The cable companies wanted to route contacts on open issues to the last
agent who handled it, if possible, and pop the trouble ticket on the screen.
MediaVue integrated 60 agent desktops in one weekend, avoiding a large
systems-integration effort.
Voice Self-Service
Open architecture also applies to interactive voice response, where one
server runs the speech processing for a natural-language user interface,
and another runs the standard Voice XML code of the core application.
Both are communicating with standard voice-processing cards.
IVR vendors are supporting the VXML standard; most are or will soon be
Version 2.0-compliant. This architectural change has huge potential to
open the previously small pool of developers and enable portability of
applications, while leveraging the Web infrastructure and common data.
However, Version 2.0 of the VXML standard needs significant extensions
to support customer contact applications. CTI-based call control, screen
pops and integrated reporting are examples of functions that require capabilities
beyond the standard. So a standards-compliant application might not be
portable across platforms.
Many vendors generate VXML code from their proprietary graphical user
interface as an option, easing the migration for those with in-house programming
expertise on their current platform (but this code is not portable to
a different platform if it includes any extensions). They will work to
promote the development of the VXML as well as Call Control XML standards.
They also will comply with and support Speech Application Language Tags.
Ready, Set, Implement?
So what's holding users back from implementing open application architectures?
Some products aren't mature; VXML, for example, is just being used by
early adopters. Some interfaces aren't truly open. Not enough "canned"
interfaces exist, partly because they are vendor-specific, not standards-based.
It can be hard to integrate solution elements, potentially resulting in
significant system integration costs. The products don't plug and play
the way they're marketed. Not many have done it before them.
Maintenance and ongoing management costs can be high; for example, an
upgrade or new release in one element can have a ripple effect to other
elements for upgrades and testing. As a customer, you must evaluate potential
costs and trade-offs in integration, problem resolution, upgrades and
the like. Your strategic approach to vendor and product selection needs
to consider the tradeoffs of integrating best-of-breed products vs. buying
a suite of products from one vendor.
Click here to learn about
XML vs. Corba.
|
|
