# ![](media/image1.png){width="2.8125in" height="0.6736111111111112in"}

# 

[[E-Government Enterprise Architecture]{.underline}]{.smallcaps}

[[A Study of Web services and ebXML]{.underline}]{.smallcaps}

[Anthony Arana]{.smallcaps}

[Choong-Mok Kwak]{.smallcaps}

[Mohandas Mavilavalappil]{.smallcaps}

[Andrius Miksenas]{.smallcaps}

###### Sridhar Varri Douglas White

[**Faculty Advisor:** Prof. Sanjay Gosain\
]{.smallcaps}

[Robert H. Smith School of Business]{.smallcaps}

[University of Maryland, College Park]{.smallcaps}

[December 2002]{.smallcaps}

# **Table of Contents**

# 

Executive Summary 3

Background 5

Methodology 6

An Introduction to Web services 6

An Introduction of ebXML 10

Evolution and Maturity of Web services 12

Evolution and Maturity of ebXML 16

Web services Advantages and Limitations 18

ebXML Advantages and Limitations 20

Web services Adoption 22

ebXML Adoption 26

Cost and benefits Analysis 27

Case studies on other Government e-service initiatives: UK 30

Case studies on other Government e-service initiatives: Australia 35

Conclusion and Recommendations 46

Appendix I -- List of Interviewees 51

Appendix II -- Additional Resources 52

**[Executive Summary]{.underline}**

Automating the flow of information between various entities in an
enterprise has always been difficult and expensive. Better and cheaper
interaction among entities can result in immediate cost savings and
create potential for innovative collaboration in the long run resulting
in superior value creation. Recent developments in the world of
distributed computing have made possible the successful integration of
diverse applications working in different environments. XML has been the
single most important factor facilitating this quantum jump in
technology.

The current climate for application integration offers two viable
platforms that deserve close scrutiny: Web services and ebXML. There
exist significant differences between the two frameworks; and there
exist complementarities as well. A policy of prudent governance should
take advantage of the immediate efficiencies offered by application
integration and interoperability, while ensuring scalability, ubiquity
of technology platform and an appropriate level of transaction security.
Considering the continuing evolution of the two frameworks, it would be
appropriate to adopt a sequential approach in implementing a solution.\
This study carried out an objective analysis of the two frameworks and
reviewed the potential\
for creating the optimal enterprise architecture for GSA's office of
e-Government. The study involved a detailed review of current literature
on the subject of enterprise architecture with a particular focus on Web
services and ebXML; and also interviews with experts in the government
and private sectors, and academic experts. The study investigates the
potential enterprise architecture for government by examining the
concepts behind Web services and ebXML, and the evolution and maturity
of the two frameworks. The study also analyzed the benefits and
limitations of each of the frameworks and profiled some of the early
adopters. This report also includes a cost-benefit frame for achieving
application integration and interoperability, case studies of current
e-Gov initiatives in other countries and considers the challenges of
interoperability across the federal, state and local spectrum of e-Gov
activities.

The final section of this report lists our recommendations regarding the
suitability of Web services and ebXML for e-Gov transactions. As part of
our core recommendations, we counsel the government to qualify and
prioritize processes that derive maximum benefit from application
integration and interoperability; to tap the synergies of Web services
and ebXML; to work with ebXML, WS-I, and other standards bodies towards
inclusion of use cases for government transactions; and to prepare
groundwork for Web service implementation. We submit these
recommendations to be used as a tool in the government's approach to
achieving application interoperability to realize a more effective
delivery of services.

**[I. BACKGROUND]{.underline}**

The Office of Electronic Government facilitates the implementation of
government-wide E-government policy. Towards fulfilling this mission, it
promotes and nurtures government-wide eGOV projects. The specific roles
played by the office are 1) identifying and conceptualizing eGOV
opportunities, 2) encouraging the involvement and participation of the
various federal agencies and 3) developing strategies for funding these
projects. As such, the Office of Electronic Government plays a crucial
role in encouraging and coordinating emerging eGOV projects across the
federal agencies.

Creating a single federal architecture -a blueprint that defines common
business practices and technologies to make government work more
efficiently- is among the top management goals of the Bush
administration[^1]. As governments are beginning to manage IT and
web-enabled systems at the enterprise level, the U.S. government is
studying the two emerging business architectures, namely ebXML and Web
services in the arena of enterprise architecture. There is a need felt
to better understand these architectures in order to fulfill the
government's role as a leader in electronic commerce.

> Specific questions raised in this context were the following:

-   What is the difference between ebXML and Web services?

-   Which business architecture is better suited to government
    transactions?

-   What is the projected maturity schedule for each of these
    architectures?

-   What products are available today or in the near future that will
    allow the government to use ebXML and/or Web services?

-   Our consulting team was asked to assist in finding answers to the
    above questions.

### II. METHODOLOGY

Our approach has been to provide in-depth research and supporting
materials that will help us uncover answers to the questions raised. We
focused our efforts primarily on researching issues such as the stage of
development of the various architectures, as well as their functionality
and limitations within the context of electronic government services.
Specifically our methodology included the following:

-   **Conduct Literature Review-** Review of the existing literature on
    ebXML, Web services and other such frameworks currently available
    for the purpose of assessing the maturity level of the technologies
    and the time when they will come into full play.

-   **Interview Experts-** Interview a wide range of experts in the
    industry that include vendors, analysts and people at the government
    who spearhead the eGOV initiatives. We also used the expertise of
    our faculty advisor Mr. Sanjay Gosain who is a leading expert in
    this area and is involved in ongoing research effort with the
    Rosetta Net consortium that is building electronic commerce
    standards for the IT industry.

-   **Benchmark-** Besides exploring the current corporate usage of
    ebXML and Web services, an assessment of the e-government
    experiences of administrations of countries such as UK, Singapore
    and Australia was carried out.

**[III. An Introduction to Web services]{.underline}**

Web services, in general, are a distributed computing architecture and
are considered to be one of the most significant advances in the area of
computer architecture in the past 30 years. The purpose of any
distributed computing architecture such as CORBA, EDI, etc, is to enable
programs in one environment to communicate and share data/content with
programs in another environment. Web services, however, feature a new
way to perform program-to-program communications that allow applications
to communicate with each other regardless of which application language
is used, and regardless of what platform and operating environment is
used.

A formal definition of Web services is as follows: Web services are a
new class of *cross-platform program-to-program communications* that
enable loosely coupled applications to easily find each other, to easily
and dynamically establish parameters that enable similar or disparate
programs to work together cooperatively, and enable them to communicate
in an automated, unattended fashion over the Internet.

# 

# **Basic Web services architecture**[^2]

+-----------------+-----------------+-----------------+-----------------+
| ##              | XML             | A common format |                 |
|                 |                 | for presenting  |                 |
| ## Format       |                 | data and        |                 |
|                 |                 | information.    |                 |
|                 |                 | This data can   |                 |
|                 |                 | be easily       |                 |
|                 |                 | manipulated to  |                 |
|                 |                 | meet the        |                 |
|                 |                 | presentation    |                 |
|                 |                 | needs of the    |                 |
|                 |                 | requestor       |                 |
|                 |                 | application     |                 |
+-----------------+-----------------+-----------------+-----------------+
|                 |                 |                 |                 |
+-----------------+-----------------+-----------------+-----------------+
| ## Services     | UDDI            | WSDL            | SOAP            |
|                 |                 |                 |                 |
|                 | (Publish)       | (Find)          | (Bind)          |
+-----------------+-----------------+-----------------+-----------------+
|                 | A directory     | A protocol that | A protocol that |
|                 | service that    | enables         | enables         |
|                 | lists           | applications to | applications to |
|                 | applications    | find a service  | agree on how    |
|                 | that can        | and to agree on | data and        |
|                 | provide         | how data and    | services are to |
|                 | services        | services are to | be communicated |
|                 |                 | be shared and   |                 |
|                 |                 | rendered        |                 |
+-----------------+-----------------+-----------------+-----------------+
| ## Network      | The Internet    |                 |                 |
+-----------------+-----------------+-----------------+-----------------+
|                 | The Internet,   |                 |                 |
|                 | using TCP/IP    |                 |                 |
|                 | and other       |                 |                 |
|                 | communicat      |                 |                 |
|                 | ions/networking |                 |                 |
|                 | protocols,      |                 |                 |
|                 | serves as the   |                 |                 |
|                 | common network  |                 |                 |
|                 | for web-enabled |                 |                 |
|                 | applications.   |                 |                 |
+-----------------+-----------------+-----------------+-----------------+

Web services, like any other program-to-program communication
architecture, pass content between applications using a common format
known as XML; Web services use a registry (UDDI), a template (WSDL), and
a programmatic interface (SOAP) to enable applications to find and
interact with each other; and they use a common network (the Internet)
to transport information and data between cooperating applications.
These Web services components are further explained below.

***XML:*** extensible Markup Language, XML, is a standard way of
representing and exchanging data. Most information is shared on the
Internet today using a language called HTML. XML tells cooperating
application programs what the data is (a name, address etc.) and thus
enables developers to control, display, share and manipulate data
(rather than presenting data graphics and static information as in
HTML). XML schemas need to be developed to present and share that data
in a useful form between cooperating programs. There are currently about
900 XML schemas developed by various consortia such as Rosetta Net and
OASIS. Most Web service-related specifications use XML for data
representation, as well as XML schemas to describe data types.

***UDDI:*** Universal Description, Discovery, and Integration is a
registry standard, i.e. a place where an application program can
register characteristics about itself so that it can be located by
companies that need the specific application. For example, Company A
might expose an invoicing Web service that the company's suppliers use
to send electronic invoices. Similarly, a Vendor V might expose a Web
service for placing orders electronically. UDDI, an industry effort
started by Ariba, IBM, Microsoft, and 33 other companies, currently has
over 200 community members.

***WSDL:*** The Web services Description Language is an XML-based
language to define Web services and how to access them. Thus, once a
source application makes a request to UDDI for a particular kind of
application service, WSDL helps find the service. Once the source and
the secondary applications know about each other, they need to agree on
how they will communicate and exchange data. WSDL protocols help
establish those parameters. Thus, in essence, WSDL protocols locate Web
services applications and determine if those applications can work with
the source application.

***SOAP:*** The Simple Object Access Protocol is a simple XML based
protocol that lets applications exchange information. Thus, once the
source application finds the application it is looking for and the
parameters of how they want to communicate have been established, SOAP
helps to cement the relationship between the two applications and helps
them communicate to each other so that the service is rendered.

To put it all together, the following sums up the basic Web services
architecture.

![](media/image3.png){width="3.902083333333333in" height="2.30625in"}

The Service Broker provides lists and information about Web services
applications (in UDDI). The Service Requester is the one who requests a
Web services application (hence, the source application) and Service
Provider is the Web services application. Web services are applications
that make use of registry and communications standards to work together
in a dynamic manner where one application provides transactional,
messaging, or computational services for another. These applications
make use of an agreed-to format (XML or some other variant of XML) for
presenting information and data; and they use Web services standards for
finding service applications (UDDI), negotiating how to communicate
information (WSDL), binding communication sessions (SOAP), and then
transferring that information over the Internet (HTTP).

##### [IV. Introduction to ebXML]{.underline}[^3][^4]

Business entities communicate with each other utilizing various methods.
Often the communication is performed by sending information by mail or
phone. Carrying out these communications online reduces the redundancy
and simplifies the process by saving considerable time and also physical
and labor resources. The methodology to perform business online in such
a way has been realized previously by many large companies in the
industry through Electronic Data Interchange (EDI).

However, there were several problems to expand the EDI initiative. Due
to the fact that EDI was developed initially for the big companies, it
required vast initial investment and complicated skills that were
unfeasible for small and medium size companies. To offset such
shortcomings of EDI, the utilization of XML has risen as an alternative
factor. XML is not just easier to use, but also has many functions
rather than simply exchanging data between business partners. It is
designed as a platform-neutral language so that anyone can easily create
applications from anywhere. Nevertheless, XML does not address all
shortcomings of EDI and identification of this gap brought about the
early discussions that evolved into the ebXML initiative.

ebXML is an XML-based open framework for e-business transactions. ebXML
not only defines architecture, but also views business with a new idea.
It is a set of specifications to reach specific business objectives and
covers Business Processes, documentation of a company\'s capabilities
and transfer of documents among new and existing trading partners. These
specifications of ebXML are briefly explained below:

**Message Services:**

Messages are sent using standard formats and protocols. ebXML enables
the exchange of business documents among trading partners using SOAP
(Simple Object Access Protocol) with Attachment, enabled by MIME
(Multipurpose Internet Mail Extensions) protocol. MIME is a packaging
protocol that offers a way to carry different kinds of digitized file
formats. It not offers to transport not only multiple formats, but also
encrypted content. The MSH (Message Service Header) controls the
messages using SOAP with Attachments specification so that information
about the message is included in a SOAP message, and the documents are
contained in payload attachments.

**Business Process & Core Components:**

The Business Process standardizes diverse business transactions.
Companies document their business processes and business document
structures using the BPSS (Business Process Specifications Schema).
Hence, the methodology of performing business utilizing a specific
vocabulary in BPSS is definable. Core components standardize items of
exchanging messages. Based on the core components, predefined documents
such as form of purchase orders, administrative information or the goods
themselves are created.

**Registry/Repository:**

The registry and the repository can be thought of as a database. ebXML
registries contain important information on potential trading partners.
They store information about items that actually reside in a repository.
Items in the repository are created, updated, or deleted through
requests made to the registry. Registries and repositories help
companies find the information and structures they need rather than
reinvent them.

**Trading Partner Profiles:**

Companies document capabilities by utilizing a CPP (Collaboration
Protocol Profile) and make business agreements with partners using CPA
(Collaboration Protocol Agreement). CPP is an outline of the
capabilities of the trading partner in an XML document. Registries
include information on potential trading partners in the form of a CPP.
CPA matches the business processes and allows an agreement on the
processes and messages. Once the companies have agreed upon the CPA, the
partners are on the same page thus eliminating confusion with respect to
transactions.

# **V. Evolution of Web services**

Web services has its roots in component architecture of the 1980s.
Components were originally developed in the context of Graphical User
Interfaces (GUIs) and allowed the re-use of existing application code.
Within this architecture, code is compiled into several independent
units instead of into a single entity. As use evolved, component
architecture grew from managing communication between components on the
same computer to communicating with component infrastructures on other
computers across a network. These newer, distributed component
architectures drove the rapid development of more complex, distributed
applications. This trend eventually led to the specification of CORBA
(Common Object Request Broker Architecture) in 1991 and Microsoft DCOM
component architecture, as well as Sun J2EE distributed architecture.
Distributed component architectures have one serious limitation:
generally they can only be used across a tightly managed network, such
as a corporate intranet. They don't play well in an open, fragile
environment, such as the public Internet.[^5] Web services evolved to
fill this void, using the Internet's protocols to provide a component
infrastructure for the development of distributed components that
function on this open network. In the early1990s, HP Labs began to
investigate reducing the technical and cost problems of distributed
systems. The resulting design principles which led to HP\'s e-Speak,
which emerged as probably the first Web services technology, and
certainly the first commercially marketed Web services technology.[^6]
The concept of using HTTP and XML technologies to develop open and
license-free implementations drove results with some high levels of
interoperability and low cost. At the same time, the EDI community
viewed XML and Internet protocols as a vehicle for potential savings by
moving their data exchanges away from the costly set up and transaction
fees of Value-Added Networks (VANs). Groups such as CEN/ISSS were formed
in Europe and XML/EDI in the U.S. which began working on ways to encode
EDI transactions. These trends led to early forms of Web services for
business-to-business transactions. These XML/EDI systems were also
designed to take advantage of the established EDI mechanisms for
orchestration, prioritization, security and other issues that Web
services did not adequately address at the time. The effort to turn this
into a formal standard became e-business XML (ebXML). ebXML is a joint
project of OASIS and the United Nations Centre for Trade Facilitation
and Electronic Business (UN/CEFACT). OASIS is a not-for-profit, global
consortium that produces worldwide standards for security, Web services,
XML conformance, business transactions, and interoperability within and
between marketplaces.[^7] UN/CEFACT is a non-profit group that focuses
on the worldwide facilitation of international transactions, through the
simplification and harmonization of procedures and information
flows.[^8] In February 2002, IBM, Microsoft, Intel and other firms
formed the Web services Interoperability Organization, WS-I, a
non-profit organization whose goal is to promote Web services standards.
WS-I was created not only to investigate and qualify standards, but also
to validate the standards from W3C and OASIS. The idea behind WS-1 was
not to create new standards, but rather to assemble "profiles" of
standards against which conformance tests and certifications can be
established.[^9]

![](media/image4.png){width="4.166666666666667in" height="2.5in"}

*source: "The Past, Present and Future of Web services, Part 1" Uche
Ogbuji,*

## 

## Maturity of Web services

SOAP and WSDL are already mature with several successful applications
already in use. There is another group of specs to provide more complex
functionalities still evolving in\
WS-Security, WS-Coordination. Public UDDI is still evolving, but it can
be said that the roadmap and directions for the future of Web services
already exist

. Currently, vendors are focused on selling their component tools and
component frameworks that are central to building services. It is
expected that vendors will want to sell their software products as Web
services if a viable market develops. Potential revenue models will be
studied closely by vendors in evaluating the question of whether or not
to enter the market with their software products. In 2002, the majority
of potential customers still view Web services with cautious curiosity.
While recognizing the potential for gaining efficiencies in automating
certain application functions, buyers remain somewhat wary of investment
in a new, unproven technology, given the current economic situation.
Indeed, those companies adopting Web services in 2002 are largely
employing only those services where the impact on the bottom line is
immediate and obvious. Mainstream acceptance will be attained only after
the appearance of a Web Service poster child; a tested model for how to
use Web services, including a pricing model as well as tools to
facilitate the process. Smaller, independent software vendors are
expected to lead the way in adopting Web services and we can observe
today that a number of small vendors package parts of their application
functionality in B2B Web services.

This trend is expected to continue through 2003, concurrent with a
proliferation of private registries to support an increasing number of
private, web-based exchanges. Increased government usage of the Internet
for delivery of services will continue to grow and this will serve to
drive the need for more Web services, especially in the G2C sector.

In the private sector, Web services will be most likely used through
2004 for integration between trusted partners and for integrating
applications within an enterprise.[^10] While a recent PwC study cited
that the greatest technical challenge facing most large organizations in
the use of IT is application integration, it also concluded that "the
realization of Web services vision will be unlikely during the
three-year forecast period...because the concept assumes that companies
will be willing to do business with new and unfamiliar trading
partners."[^11]

Gartner predicts that by the end of 2005, new licenses for software that
use Web services will represent a \$21 billion market. However, the key
to Web services gaining broad acceptance will center on standards. Few
vendors in 2002 agree on standards, but generally vendors concur that
standards are an important governance issue and that the question of
standards has to be reckoned with once the domain of Web services
reaches a critical mass. Web services are very suitable for ad hoc
application integration solutions, as well as more complex, automated
solutions that incorporate some level of interoperability. However, as
the population of users increases, new and additional scenarios develop
which require laws, or standards to address the changing nature of the
domain. In 2002, few laws are required as so many Web services are
focused within a company's firewall. As the domain and scope of Web
services users expand outside the firewall to the set of all transaction
partners and then beyond, to the global community of the Internet, it
becomes more difficult to create rules on an ongoing basis. In this
scenario, there is a clear requirement for standards.

# 

# **VI. Evolution of ebXML**

ebXML was commissioned in September 1999 and all specs were released in
May, 2001.

As indicated above, the roots of this initiative go back to the EDI
movement. EDI (Electronic Data Exchange) has its roots in the 1970s and
represents the first generation B2B collaboration; a loosely-coupled,
document-centered collaboration between business units and between
business trading partners. EDI was not widely adopted in the business
community as a whole due to the high investment required. EDI has a
strong user base among large companies, such as automobile manufacturers
and computer hardware manufacturers, yet globally just 2% of businesses
use EDIs today. ebXML is designed with a larger user base in mind: it
can help up to 25 million businesses worldwide to automate their
inter-enterprise collaboration.[^12] Given its broad target, the success
of ebXML will depend on the adoption of ebXML by a large number of
companies from all points of the size spectrum. Inherent in that
dependency is the notion that the ebXML initiative must be able to
successfully communicate the value of ebXML to small business.

ebXML is currently in the innovator adoption phase. As of late 2002,
interest in ebXML is limited mainly to the messaging component. Many of
the products currently available implement the ebXML Message Service
specification. Large vendors such as IBM, Microsoft, and Oracle are not
zealous proponents of ebXML and that is to be expected; industry players
tend to wait and see and jump on board once the platform has been
established. These vendors have generally been required by the market to
provide support for RosettaNet, and this requirement can be seen as an
indicator that vendors will be willing to support ebXML once the demand
is deemed sufficient. This can mean that procurement requirements will
influence vendors when ebXML support is included in RFPs as a
requirement for submission of bid or for final vendor selection.
Moreover, in the current economic climate, software vendors, especially
the giants, will push products to market strictly on a demand-driven
basis. They are far less willing to experiment with new, unproven
products in the current economy. Industry groups and possibly user
groups will influence the speed at which vendors pursue open-source
applications. The economic climate and the dot-com meltdown has also
forced the industry to refocus on building tools and infrastructure that
create value for businesses and further enable e-business activity.

ebXML messaging has generated some interest with the applications based
on ebXML standards. Discovery and automated trading partner agreements
have not been met with great enthusiasm, largely because businesses are
generally reluctant to collaborate with unknown trading partners. The
vendors may not be interested in providing applications that are less
expensive and therefore undermine current revenue models. Current user
groups lack the focus and the power to demand compliance of vendors.
Widespread, visible support from industry groups will be required to
drive adoption of ebXML, as well as government initiatives. The public
sector, in pursuing the goals of reducing single-vendor dependencies and
the promotion of vertical and horizontal collaboration between agencies,
will continue to press for a platform based on vendor-neutral standards.

### VII. Web services- Advantages and Limitations

*Advantages*

-   **Interoperability**. Any Web service can interact with any other
    Web service. Thanks to SOAP, the new standard protocol supported by
    all of the major vendors (and most minor vendors), the difficulties
    of converting between CORBA, DCOM and other protocols should be
    over.

-   **Ubiquity.** Web services communicate using HTTP and XML.
    Therefore, any device which supports these technologies can both
    host and access Web services.

-   **Components**. Web services can break applications down to
    specialized components. Rather than all functions within a service
    residing on one server, services act as collections of components
    spread across the Internet. A common component, like an
    authentication gateway, can be shared by many applications.

-   **Industry Support.** All of the major vendors are supporting SOAP
    and the surrounding Web services technology. For example, the
    Microsoft .NET platform is based on Web services, thereby making it
    very easy for components written in Visual Basic to be deployed as
    Web services, and consumed by Web services written using IBM
    VisualAge, and vice-versa.

-   **Direction.** The foundation for Web services application design
    and deployment is already in place and a clear road map exists.

#### Limitations

Although hundreds of Web services applications have been written and
UDDI, WSDL and SOAP do work as advertised, numerous improvements need to
be made to UDDI registry service and related Web services protocols to
make them more robust for use in message-rich, transaction-heavy,
enterprise-class computing environments. Bloor-Research North America
has identified mainly six shortcomings with Web services as they stand
today[^13].

-   **Security/Privacy.** Authentication and validation of content needs
    to be ensured and authorization rights need to be restricted to
    prevent unauthorized use of the content.

-   **Routing/messaging, Reliability.** Protocols need to be developed
    to track messages through multiple intermediaries. Standards must be
    established to ensure messaging reliability.

-   **Transaction handling.** All prior distributed computing
    architectures provided ways to monitor and track transactions. Web
    services do not have any such transaction monitors in place, and
    since W3C is not in the process of developing such a standard, the
    task is that of the vendors.

-   **Manageability.** An overall plan for managing Web services
    environments (from a system, network, and application level) does
    not exist.

-   **Interoperability.** Though the formation of WS-I goes a long way
    toward addressing how interoperability will be achieved across
    multiple disparate platforms and differing application program
    language environments, the newness of WS-I plus its initial
    political positioning (leaving Sun off) make the group's initiatives
    somewhat suspect.

-   **Performance/tuning.** There is a distinct lack of performance
    tuning information and/or tools for optimizing Web services
    computing environments. Although the W3C does internal quality
    assurance, enough is not yet being done to assure that Web services
    applications can be optimized to compete from a performance
    perspective with tightly coupled distributed computing
    architectures.

Though faced with limitations at present, the W3C, the vendor community,
open-source software providers and consortia are taking many initiatives
to address these shortcomings.

###### [VIII. ebXML Advantages and Limitations]{.underline}

###### *Advantages*

-   **Business Processes**[^14]**.** Enterprise integration requires
    standard business processes. ebXML defines business processes for
    the business or organization. The business process models define how
    business processes are described. The specification for business
    process definition enables an organization to express its business
    processes so that they are understandable by other organizations.
    This enables the integration of business processes within a company,
    or between companies.

-   **Registry/Repository**[^15]**.** The Registry and Repository of
    ebXML have robust and comprehensive functionality. They allow for
    dynamic build of schemas. ebXML registry provides space for a
    business or organization to store its components and authenticate
    trading partners. ebXML provides ways to define and register trading
    partners and their capabilities in concise profiles that are
    maintained in registries. This permits users or systems to discover
    registered capabilities, and facilitates the process of completing
    agreements among trading partners.

-   **Security**[^16][^17]**.** Government has stringent security
    requirements. Messaging specs of ebXML are far superior to those of
    SOAP for secure documents The ebXML Messaging Service specification
    defines the set of services and protocols that enables electronic
    business applications to exchange data. The specification allows any
    application-level protocol to be used. These can include multiple
    protocols such as SMTP, HTTP, and FTP. Well-established
    cryptographic techniques can be used to implement well-built
    security. For instance, secure protocols such as HTTPS can be used
    to guarantee secrecy. In addition, digital signatures can be applied
    to individual messages or a group of related messages to guarantee
    authenticity.

#### Limitations

-   **Payload**[^18]**.** The success of payload (Universal Business
    Language) is critical for ebXML. By utilizing XML, businesses will
    be able to trade with anyone, any time, without the need for the
    expensive integration work that has been required in the earlier
    period. XML can be used to build electronic catalogs, purchase
    orders, invoices, shipping notices, and other documents needed to
    perform business. But XML doesn\'t guarantee that these documents
    can be understood by any business other than the one that creates
    them. XML is only the groundwork on which additional standards can
    be defined to achieve the goal of true interoperability. The
    Universal Business Language (UBL) initiative is the next phase in
    achieving this goal. The development of UBL within OASIS also helps
    ensure a fit with other essential ebXML specifications. ebXML may be
    adopted only in parts until the payload (UBL) is introduced. The
    first version of UBL is expected to be released sometime in
    2003.[^19]

-   **Slow Pace of Implementation and Use**[^20]**:** ebXML is not yet
    ready and its adoption curve depends on further development of other
    components. Many in the industry believe that ebXML is not quite
    ready for prime time. Some components are fully developed and ready
    for deployment, while others are still under construction. For
    example, the messaging and transport components are well developed,
    but the core components need more work before it can be implemented.
    Many businesses are using portions of the ebXML specification, but
    not the entire standards package.

## 

## [IX. Web services adoption]{.underline}[^21]

Web services is still very early in the adoption cycle; the chasm to
broad penetration across vertical markets will probably be crossed only
over the next two years. At the same time, the adoption of Web services
is deep in select verticals for some specific applications. It is now
clear that the early adopters are larger enterprises in search of more
cost-effective demand chain solutions, in verticals such as banking,
insurance, travel, and manufacturing. Usually, early adopters are
innovative market leaders who want to gain experience with a more
loosely coupled architecture that has the promise of quickly delivering
measurable cost reductions. These companies are in relatively data
intensive industries and they need to integrate multiple partners or
customers who are on heterogeneous technology platforms.

-   There are four major application areas of Web services:

-   Demand Chain Applications

-   Supply Chain Applications

-   Private Marketplaces

-   Applications or Web Service Provider Integrations

# 

# **Demand/Supply Chain Applications**

Companies are using Web services to grow profits by distributing their
applications or data to partners and/or customers. Such Web services are
used by insurance, travel and financial services verticals. Fidelity is
using Web services to eliminate a complex web of protocols and
transformations required to give customers an integrated view of their
accounts across different products. Galileo travel reservation system,
connecting 42000 travel agencies, 511 airlines, 37 car rental companies,
350 tour operators and 47000 hotels, is experimenting with Web services
to offer travel services and to integrate with their travel suppliers.
Both supply and demand chain applications are used by companies
integrate components of their demand/supply chain itself with
distributors, resellers and customers. These types of Web services are
used by financial services and manufacturing verticals. Smaller
suppliers had resisted EDI integration because of the fear of being
squeezed by their buyers, but Web services enable them to integrate
without being locked into their customers' systems.

# **Private Marketplaces/Collaboration Hubs**

Companies are using Web services in the area of private marketplaces or
collaboration hubs mostly in the insurance and manufacturing sectors. A
collaboration hub brings together partners to execute business
processes. For example, one insurance service provider has collaboration
hub that aggregates all parties involved to execute an insurance claim.
Web services are used to bring together the assessor, bank, repair shop
or health care provider.

# **ASP/WSP Integrations**

Companies try to reduce costs by transporting select data from or
between application service providers (ASP) or web service providers
(WSP). This information can be used to trigger events or to trigger
other information feeds based on information in a specific field or
fields. Putnam Lovell is an investment bank that is using Web services
to integrate Salesforce (CRM) and Blue Matrix (research report
distribution) with their customers. Putnam keeps customer profiles in
Salesforce.com, and transports the data on the ticker symbols of
companies the customer wishes to track. Using Web services, this data is
delivered to Blue Matrix, which automatically sends the relevant
research reports on the companies of interest directly to customer. To
customer it appears that everything is done by Putnam.

Dell is one of the first companies to see a dramatic improvement in its
supply chain

efficiency as a result of implementing a Web service to automate the
flow of information between the firm and its suppliers. In 2000, the
company began sending components specifications to its suppliers in a
Web services format so that the suppliers\' inventory-management systems
could read the data automatically. That move helped Dell reduce the
inventories of components at its many geographically distributed
assembly plants by more than 80 percent. Dell also used Web services to
optimize demand management across all of its assembly plants. The
firm\'s suppliers serve many plants, and the company decided that if it
could aggregate information across them, it could match production
capacity to demand and manage supply shipments accordingly. However, due
to the company\'s rapid growth and geographic expansion, each Dell
assembly plant had implemented its own manufacturing applications and
database-management systems, with no effort at coordination. Information
was thus shared manually. Rather than replace systems to achieve
uniformity across plants, Dell used Web services to do the job, vastly
improving utilization and cutting logistics costs throughout the
production network.[^22]

**Web services products**

Though there are many approaches to obtaining Web services products and
services, the products available today can be classified into three
categories, in general.

*Category1:* Most of the early, real-world competition in the Web
services space has come from the providers of turnkey application server
environments (turnkey systems that include software for application
development, application deployment, and extensions that make it
possible to easily build and deploy component applications). These Web
services platform providers can further be classified into two main
groups.

1.  Vendors that build and sell completely integrated systems software,
    application development environments, hardware, and services. E.g.
    IBM (with WebSphere), Sun (with Sun ONE) and HP (with NetAction)

2.  Vendors that build application development environments that can be
    sold on multiple different systems platforms. E.g.: Microsoft (.Net)
    and BEA.

*Category2:* Building one's own a la carte, point product Web services
applications. Examples include point product tools and utilities and
open-source Appache server. Companies like google and amazon, who expose
their applications as Web services could also be included in this
category.

*Category3:* Professional services firms that can help build and
maintain Web services applications, such as GE GXS, Nextlinx

## 

## [X. ebXML adoption]{.underline}

In our research, we came up with one substantial practical
implementation of ebXML. ERCOT (Electric Reliability Council of Texas)
is an independent, not-for-profit organization responsible for
overseeing the reliable and safe transmission of electricity over
Texas\' main electricity power grid.

-   1 of 10 NERC reliability regions

-   Single, integrated control area

-   37,000 miles of transmission

-   \~70,000 MW of generation capacity

-   \>57,000 MW peak demand

    -   6.25 million customers (2nd U.S.)

    -   9% of U.S. electricity demand

    ```{=html}
    <!-- -->
    ```
    -   Covers 75% of land area of Texas

    -   Implements full deregulation in Texas: January 2002

    -   Processes over 15 million transactions per month[^23]

The system, developed by Systrends, an energy systems vendor, supports
two types of activities: services and actions. The messages exchanged in
the system contain largely EDI data, but use the ebXML messaging format
as the transport medium.

ERCOT's system supports upload and download services, each with request
and response actions. It also supports a directory service that provides
an index of folders. The stringent ebXML reliable messaging functions
require persistent storage of messages in case recovery of messages is
needed. The stable document identifier enables persistent storage of
messages, thus making possible ebXML's reliable messaging. ERCOT also
takes advantage of ebXML's security features. The ERCOT application
includes public key and SSL certificates.[^24]

ERCOT uses ebXML "Push-Pull" with Open-PGP Encryption and HTTP with
SSL.[^25] The system is used both for the transactions between retailers
and ERCOT, ERCOT and customers. Currently, the above mentioned standards
are used when the customer wants to switch the current electricity
provider for another. It is both used for B2B and B2C transactions.
ebXML was probably chosen because EDI standards were used before, and
ebXML added the ability to exchange the documents safely, instead of
using FTP standards.

**ebXML products**[^26]

Below are a few products that have ebXML messaging component:

-   ebXML Connector 1.0 - btrade, Inc.

-   Cyclone Activator 4.2, Cyclone Interchange 4.2 - Cyclone Commerce

-   Sterling Integrator(TM) 1.2.0 - Sterling Commerce Inc.

-   Web services Integrator (WSI) 2.5 - Sybase, Inc.

**[XI. Cost and Benefits of Web services]{.underline}**[^27]

Total Cost of Ownership (TCO) is a concept by which all costs associated
with a capital investment are accounted for. It can also be considered
the cost of owning and operating an existing asset over a given period
of time. As such, TCO can also be a useful means in determining the best
value between several alternatives. There are broadly two different
types of assets: Firstly, the development and execution environment,
which is a collection of software products required to develop and
execute Web services, and secondly the Web Service itself.\
A TCO calculation can be applied to both asset types.

> The total cost of ownership of Web services includes:

-   Capital: Software license and software maintenance cost;

-   Operation: Cost incurred during the lifecycle of a software product,
    such as installation and configuration, administration, and
    performance management;

-   Development: Cost related to the lifecycle of a Web Service, which
    is developed using the software product suites development tools;

-   IT staff training and consulting by vendor: Cost incurred with
    enabling IT staff to make optimal use of the software product.

Obviously, cost calculations begin with initial license prices and
associated maintenance fees. However, this is only a small part of the
picture. Any valid calculation must focus on an all-inclusive view,
taking into account direct and indirect costs. While direct costs are
relatively easy to obtain, it is much harder to determine indirect
costs. For example, it is all but easy to track how much time developers
spend getting around problems in the development environment. To get a
better perspective at TCO, it is helpful to view the problem space from
two different angles: the execution oriented view and the development
oriented view. This perspective does justice to the very different
characteristics of businesses. While some businesses will find a
substantial portfolio of ready-for-use Web services, other businesses
will have to carry the burden of in-house development.

Several software vendors have already launched software products that
support the Web services layer. There are two camps: firstly, vendors
that focus on the Web services layer and integrate their products with
existing application servers from leading vendors, such as BEA and IBM;
secondly, there are the application server vendors, who strive to extend
their application infrastructure base by adding the Web services layer.

In the medium and long range, it is expected that full-fledged software
infrastructure platforms will emerge, which, of course, include the Web
services layer. In this scenario, no additional license cost is incurred
for the Web services layer software. Software updates deal with the
infrastructure platform as a whole, which means that system
administrators need not worry about additional software update cycles.
Likewise, software management encompasses the entire platform.

# **Web services Benefits**

Medium and long term business benefits to enterprise:

-   Faster time to market with new and improved services

-   Expanded service deployment at lower cost

-   Vastly improved business agility

-   Increased process efficiencies due to business-to-business
    collaboration

-   Reduced human error due to business process automation.

In short term, Enterprise Application Integration (EAI) projects will
benefit from \"wrapping\" existing business services and thus extending
their lifecycle. From the technical standpoint, when the Web services
mature, the benefits will include:

-   Lower integration costs, mainly attributable to a broad base of
    public standards

-   Increased speed of deployment as a software services industry gains
    momentum

-   Less coding requirements at large, owing to the ability to license
    more services from third party vendors

-   Less internal human resources required.

McKinsey's view on the costs of implementing Web services is as follows:
the actual cost depends on the scale of the project. It costs about
\$30, 000 to create modest connection between 2 applications, but the
cost might be as high as \$800, 000 for the customized version of the
software. The code rooted in a feature of an application makes for rigid
connection: if the underlying application is changed, the customized
connection must also be changed or even rewritten.

The impact of Web services on systems integration depends on category of
systems. The largest impact in savings can be achieved by integrating
systems interfacing, with 20% savings currently and up to 50% when Web
services mature.[^28]

To conclude, we should consider the above discussed costs and benefits
while making the decisions on implementing the Web services.

Note: Since ebXML is still under development, we are not able to make
specific assessment of the costs involved in implementing it. However,
some of the cost components discussed above obviously apply to ebXML as
well.

**[XII. Case studies on other Government e-service initiatives: United
Kingdom]{.underline}**

**Office of e-Envoy: e-Government Interoperability Framework**

Better public services tailored to the needs of the citizen and
businesses require the seamless flow of information across the
government. The e-Government Interoperability Framework (e-GIF) sets out
the government's technical policies and specifications for achieving
interoperability and information systems coherence across the public
sector. The e-GIF defines the essential pre-requisites for joined-up and
web enabled government. It is a fundamental framework policy for the
e-Government strategy.[^29]

The e-GIF defines the minimum set of technical policies and
specifications governing information flows across the government and the
public sector. They cover interconnectivity, data integration,
information access and content management. Adherence to these
specifications and policies is mandatory. As these specifications set
the underlying infrastructure, the public sector organizations can
concentrate on serving the customer through building value added
information and services. It will be for the organizations themselves to
consider how the business processes can be changed to be more effective
by taking advantage of the opportunities provided by increased
interoperability. Gartner estimates the e-GIF targets to bear fruition
by 2005.

The key policy decisions that have shaped the e-GIF are: [^30]

-   Alignment with the Internet: Universal adoption of common
    specifications used on the Internet and World Wide Web for all
    public sector information systems.

-   Adoption of XML as the primary standard for data integration and
    presentation.

-   Adoption of browser as the key interface.

-   Addition of metadata to government information resources.

-   The development and adoption of the e-Government Metadata Standard
    (e-GMS) based on the international Dublin Core model.

-   Adherence to e-GIF is mandated throughout the public sector.

The factors underlying the e-GIF specifications are[^31]:

-   Interoperability: only specifications that are relevant to systems
    interconnectivity, data integration, information access and content
    management are specified.

-   Market support: The specifications enjoy wide market support and
    thus reduce the cost and risk of government information systems.

-   Scalability: These specifications have the capacity to be scaled to
    satisfy changed demands made on the system, such as changes in data
    volumes, number of transactions or number of users.

-   Openness: The specifications are documented and available to the
    public at large.

**Scope:**

The e-GIF covers the exchange of information between government systems
and the interactions between:

-   UK Government and Citizens.

-   UK Government and businesses. (World wide)

-   UK Government organizations.

-   UK Government and other Governments (UK/EC, UK/US etc).

The UK Government includes central government departments and their
agencies, local government, the devolved administrations as voluntary
partners, and the wider public sector. The e-GIF does not standardize
the appearance of information on the human interface, which can be
provided by various user channels e.g. Internet, public kiosks, Digital
TV, etc. The e-GIF does standardize the interchange requirements for the
delivery of data to such interfaces and tools for the management of the
presentation of such data. The technical policies for interoperability
across the public sector cover interconnectivity, data integration,
information access and content management.

**Implementation:**

The OeE (office of e-Envoy) will give priority to schemas that serve the
requirements of services or processes that are generic across many
public sector organizations. The "Interoperability working group" will
promote the development of schemas. Open submission of schemas to the
GovTalk website is also welcome. This group will track international XML
specifications development through links with standard organizations
such as W3C and OASIS.

The OeE in consultation with local and central governments developed the
e-Government Metadata Standard that defines the structure and rules
governing metadata used by public sector. This standardization ensures
the true interoperability of the data. The e-GMS is based on the
internationally recognized Dublin Core standard, but has additional
elements and refinements to meet the specialist needs of the public
sector.\
The UK Gov Talk website [www.govtalk.gov.uk](http://www.govtalk.gov.uk/)
forms a fundamental part of the e-GIF implementation strategy. It will
be used to provide help and guidance for XML schema developers. It is
also being used for wide consultation on a number of other e-Government
frameworks and documents.

**Management Processes:**

The Office of e-Envoy in the Cabinet Office (signifies the importance
attached to the mission) is the lead authority for implementing and
maintaining the e-GIF framework. The office provides central direction
where required while much of the action will take place in individual
public sector organizations. The Industry, which is an important partner
in this endeavor, is expected to comment on the appropriateness of
policies and specifications for interoperability and provide innovative
solutions. The citizen is encouraged to provide comments, suggestions
and innovations to help improve information access and service delivery.
The approach involved creation of several working groups to tackle with
various parts of the effort. Technology Advisory Group, Interoperability
Working Group, Government processes Group, Government Schemas Group, and
Metadata Working Group are some such groups.

**Technical Policies:**

The technical specifications formulated for e-GIF covers the areas of
interconnectivity, data integration, content management and information
access via multiple channels. The technical policies for systems data
integration and transformation are:

-   XML and XML schemas for data integration

-   UML, RDF and XML for data modeling and description language

-   XSL for data transformation

XML products will be written so as to comply with the recommendations of
the World Wide Web Consortium (W3C). The attempt is to stick to open
standardization within the W3C framework.

The UK initiative is actively considering the specifications being
generated by various standards bodies, business communities and other
groups working on XML based and other specifications for the exchange of
specific content related information. Ad-hoc working groups are being
set up to study maturing business specific specifications with the view
to making recommendations as to their applicability and inclusion into
future versions of the e-GIF. For e.g. the e-procurement
Interoperability Working Group is examining the ebXML standards for
e-commerce purchasing logistics.

The UK initiative is a comprehensive and robust attempt at achieving
genuine electronic governance. The Government looks at it as a long-term
initiative supported by robust processes.

# 

# **XII. Case studies on other Government e-service initiatives: Australia**

It is a longstanding government objective to enable people to interact
online with the government without needing to understand how government
is structured. The 1997 government statement for growth had improvements
in the quality, user friendliness and consistency of government services
as an objective.

The Australian government formed the executive agency National Office
for Information Economy (NOIE) in 2000 to strengthen the country's
participation in the information economy, for the benefit of Australian
citizens. The key objectives have been identified as:

-   To provide leadership and better coordination within government on
    information economy issues; and

-   To focus debate within the wider community on priority issues.

The diagram below further illustrates the role of NOIE[^32].

![](media/image5.png){width="5.997916666666667in"
height="3.0972222222222223in"}

*Source: National Office for the Information Economy*

Released in April 2000, the Government Online strategy outlines a
framework to accelerate progress towards this objective. The following
diagram gives the details of this framework. The framework sets in place
a consultative process to assist agencies in further developing
processes, policies and standards to promote interoperability.

![](media/image6.png){width="5.99375in" height="4.000694444444444in"}

The key areas identified are:

-   Policy & Business framework

-   Service Infrastructure

-   Interoperability standards

**Current State**[^33]

The main entry point for the Commonwealth Government,
**http://www.fed.gov.au**, is an essential part of the Commonwealth's
strategy for providing transparent and comprehensive access to
government agencies and information. There are opportunities to enhance
these facilities and make them simpler and more powerful through the use
of metadata and by the creation of customer-oriented portals. To greatly
improve ease of access, the government has endorsed a
whole-of-government online portals framework to provide a
customer-focused, coordinated approach to the Commonwealth's online
presence. This framework consists of: a set of portals based on customer
groups; a set of portals based on topics or subjects; the key point of
access at the Commonwealth Government Entry Point; a staged development
approach, where applicable; agency consortia to develop and manage the
portals to facilitate close coordination and cooperation among resource
providers across agencies to provide customer oriented services;
responsibility for the development and delivery of online services
remaining with primary agencies; an agreed set of cross-portal
standards, such as AGLS (Australian Government Locator Service)
metadata; and governance arrangements. The portals will all be available
through their own Internet address and through the Commonwealth
Government Entry Point. These portals will not replace the existing set
of agency-based and subject-oriented websites, which will remain
fundamental to the objective of placing all appropriate services online.
The portals will complement these sites, and place them in a
customer-oriented framework. The development of the portals will be
staged and variable. This approach will see new portals initially
developed to an agreed minimum requirement and over time grow through to
fully mature portals offering more sophisticated capabilities. This
approach recognizes the rapid pace associated with the development of
the Internet and a process of continuous improvement based around user
requirements. It also leverages existing significant initiatives, such
as the Business Entry Point (BEP) and National Business Information
Service (NBIS), Education Network Australia (EDNA), the Source (DETYA
youth website), Healthinsite, the Environment Resources Information
Network (ERIN) and Infoterra (Environment Australia).

**Future Plan:**[^34]

It is anticipated that an early priority will be the development of a
distributed interactive online repository to support the Framework. It
will be the vehicle for the web publication of the Interoperability
Framework, the key communication channel for agencies developing the
Framework further, and the mechanism for sharing XML schema.
Opportunities exist for this repository or registry to be scoped,
developed, populated and used by the public and the private sector.

Other potential priority areas for development, identified through
consultations to date, include:

-   Identify which business processes need schema;

-   Set the specifications for, and coordinate the production of XML
    schemas for use across government; and

-   Develop standards and XML schema in consultation with agencies.

Other issues that might be considered are:

-   Embedding interoperability concepts in other technical frameworks,
    such as authentication frameworks, procurement frameworks,
    frameworks for specific sectors and frameworks for specific
    communities of interest;

-   Directory system interoperability;

-   Network interoperability issues;

-   Web service security;

-   Non text data such as voice, graphics, sound, video images;

-   Redesign of business processes so that they can benefit from online
    delivery:

-   how business rules are applied to integrated services;

-   how trust and risk are handled across organizational boundaries; and

-   Integration in the context of outsourced environments

**Approach to integration across federal, state and local government**

One of the issues governments face while offering the various services
is the integration that is required across the different departments at
all levels of the government. The Australian government addresses this
issue with the creation of Portals that serve as junctures (see figure
below).

![](media/image7.png){width="5.990277777777778in"
height="3.2055555555555557in"}

*Source: National Office for the Information Economy*[^35]

These portals offer a single point access to the services offered by the
different levels of the government (federal, state, local government)
organized by type of service rather than by provider. The US government
has addressed this issue by creating the
[http://firstgov.gov](http://firstgov.gov/) portal.

The various players within a government portal do not usually strike
agreements with each other on an exclusive basis. In the same way that a
government agency would not give a certain chain of sports stores the
exclusive right to sell fishing licenses online, government should allow
multiple service providers and public portals to offer public services.
Public portals need to be affiliated with as many service providers as
possible in order to connect to a variety of government agencies.
Service providers require affiliations with various public portals and
Web merchants in order to reach as many users as possible. To have the
integration that is required to ensure that relationships are
non-exclusive, each player relies on open and standardized technical
requirements and published business rules for providing a service.

Also, the relationship with the customer must be managed end-to-end. For
example, a government employee might have some questions and will need
to contact a citizen who has filed his/her tax declaration through a
public portal. But, since that citizen is not a direct customer of tax
office, the government has to be prepared to use the relationship with
the service provider and public portal to send queries and reply to
him/her. Further, the service provider and public portal must provide
the government the ability to reply and ensure that when an email is
sent, for example, that it is actually delivered. In order to manage the
customer relationship end-to-end, government, service provider and
public portals must all use common or interoperable tools.

Collaboration through organizations, such as the Congressional Internet
Caucus, the Council for Excellence in Government and Office of
E-Government, that provide forums for the interaction of all levels of
government with the e-business industry is key. These
organizations/forums provide:

-   Forums for learning the best practices from every level of
    government (Local, State, and Federal) as well as many international
    governments

-   Incentives for award winning solutions that engage multiple levels
    of government and industry

-   Safe pilot/prototype environments to test new e-government solutions

-   Collective market dynamics to hone and increase the effectiveness of
    solutions

It is through these efforts that E-Government will be successfully
implemented across Local, State, Federal and International
governments.[^36]

**Approach to** **interoperability across federal, state and local
government using Web services**

One key technical challenge of E-Government is fundamental in any
complex system composed of other systems: how can the many separate
parts work together to achieve common objectives? This
\"interoperability\" challenge involves not only the large scale of
government systems, but the complex ways that technology interacts with
public policy and social issues. The policy goal of obviating the
\"digital divide\", for example, sets a requirement that
interoperability efforts encompass the wide range of ways that
governments interact with the people they serve, from high-tech systems
down to print products and personal contact. In technology terms,
interoperability is needed within and among technologies such as
telephone, television, automated kiosks, off-line media, and wireless
devices, as well as public and dedicated electronic networks (see
diagram below).

![](media/image8.png){width="5.989583333333333in"
height="4.134027777777778in"}

*Source: National Office for the Information EconomyError: Reference
source not found*

![](media/image9.png){width="8.333333333333333e-3in"
height="9.236111111111112e-2in"}Given such technology complexity and the
wide variety of government services, it is apparent that E-Government
interoperability must be approached in an incremental fashion.

The ongoing need to enhance government-wide \"information and services
discovery\" is a perfect opportunity to deploy interoperability
solutions, as has often been cited by advisors to government in the
technology arena. In this narrow slice of E-Government, issues of
technology complexity rooted in public policy concerns are relatively
well-understood from experiences stretching back to the earliest public
libraries. It is safe to say that initiatives in this area are likely to
garner strong interest among the public and opinion leaders. From the
perspective of incremental progress, the discovery challenge is also a
good choice in that virtually all other government services have some
dependence on discovery mechanisms. Work on discovery mechanisms would
help expose some of the most profound E-Government technical challenges,
such as data integration challenges in cross-agency service delivery.

E-Government interoperability in the area of information discovery
already has a robust law and policy base within the U.S., and a mature
set of international standards on which to build. Projects such as the
National Spatial Data Infrastructure and the Global Information Locator
Service (GILS) have demonstrated that inter-governmental collaboration
works very well in this area and that current technology is effective
even with the very large scales needed for government-wide deployment.

Recently, hundreds of information technology companies have begun to
collaborate on a common infrastructure for such an information and
service discovery mechanism focused on business-to-business
interoperability challenges. This mechanism, known as Universal
Description Discovery and Integration (UDDI) is already being extended
to include government organizations and services. Oxford University has
even built an automated gateway connecting UDDI with all of the
directories, catalogs, and inventories available through the GILS
information discovery mechanism.

One objective of an initiative focused on information and services
discovery using UDDI and GILS could be to establish and maintain an
online, authoritative directory of the current U.S. Federal Government
organizations and their services. This directory would re-use existing
sources in several agencies, but these various information sources would
gain a common and coherent interface through UDDI. Establishment and
maintenance of such a resource could be decentralized as needed and
other levels of government could participate at will.

Web services offered by each organization would be accessible online in
the directory, although the text content could also be printed for
distribution to any citizen or company that wants it. One could locate
organizations by classified type of service, as well as by location,
organizational hierarchy, or any other characteristics particular to
that organization. Government \"portals\" such as AOL Government Guide,
FirstGov and GPO Access could add value to this directory with
additional facilities to help people find organizations, services, and
sources of information across government.[^37]

By exploiting industry's building block Web services, government
integrated services can move online -- agency, service provider and
public portal can interact with each other using Web services. A service
provider wanting to issue fishing licenses, for example, can submit an
online query to UDDI which will respond with the Web site of the
government department responsible. Another query will tell if a
government Web service is available for issuing fishing licenses and, if
so, what the service provider has to do to interact with the government
back-end system and what business protocols are required to provide the
service. The service provider will have to, for example, establish the
identity of the citizen applying for a fishing license, which can be
accomplished using a web service. A government web service such as
filing a tax declaration will require a stronger identification service,
but the mechanisms will be the same. A business or citizen might file a
return through their accounting firm, which will use Passport together
with a digital signature and an authentication code obtained from
government.

The fastest moving e-government application is probably e-procurement.
Using the Web services, contractors do not have to visit the Web site of
every municipality, regional authority, and central government
department to see what each has put out tender. Instead, vendors can go
to the Web and see requests related to their expertise from all
organizations and all levels of government. XML indexing, through UDDI,
enables the ability to search and find services and information
automatically, without the need for a middleman to pull everything
together. The technology matches the services and people who are
interested in each other.

The public sector is a service by definition, so it is in one of the
best positions to leverage the web service approach. Organizations can
start today to build their e-government solutions, first by using
XML-based Servers to secure and extend their government infrastructure.
Pushing an existing corporate LAN or WAN out to provide citizens with
Internet access, email and services available through multiple channels
over a range of devices will help government bridge the digital divide
and manage their customer relationship.[^38]

**[XIII. Conclusion and Recommendations]{.underline}**

An analysis of the two architectures, ebXML and Web services, brings out
essential similarities underlying the two frameworks. At this point in
time, the two architectures are in a way competing with one another. The
vendors led by Microsoft, IBM, Oracle, Intel, etc. are actively backing
Web services while

various industry associations (Covisint, Open Travel Alliance),
especially those with EDI background, are active supporters of ebXML.

Web services have a ready to use product, though with basic integration
functionalities. ebXML, by contrast, offers standards based on which
these services/software can be provided by a software vendor (for e.g.
ebXML Connector 1.0 - btrade, Inc.) Increasingly, companies are viewing
with curiosity the development of these frameworks before making a
decision on investment. There is immense potential for companies to
start integration with services at the edge, such as the existing
outsourced functions, before looking at adopting one of these frameworks
for the organization\'s core activities.

Considering the existing state of integration and interoperability
functions in various companies, the probability of most of the projects
based on these frameworks to be intra-company rather than
inter-companies is real. This is all the more likely considering the
security issues involved in moving beyond the firewalls of the company.
Also with regard to realizing the optimal potential of Web services
there are trust issues involved in companies doing business (for
example, consuming applications) with other companies simply based on
contacts made on the UDDI. Moreover, the process of achieving a
comprehensive UDDI and deciding on the entity to govern it, has some
time to go before companies would start warming up to the concept. Thus
we look at Web services serving the integration/ interoperability
functionalities primarily within the organization for the next three
years. Interoperability between different organizations is also possible
only when the business processes are defined for the industry and the
Document type Definitions or the Schemas are standardized. It would not
be possible for an individual vendor to do this industry-wide unless he
is given such project by an industry association. The most likely
situation for the next two years is each vendor defining business
processes for the client depending on the requirements of the
integration project.

ebXML has an advantage in this regard as the standards boards are
already working on the business processes and creation of schemas for
various industry-wide transactions. This makes it easier for a company
to adopt an integration/ interoperability solution based on these
defined standards. Thus the demand from clients would push the existing
vendors who aren't actively associated with ebXML to use ebXML standards
and come up with cost effective solutions. However, at this point in
time, with the exception of some software packages for messaging based
on ebXML standards, there is no existing comprehensive ebXML product.

In the light of this background, we offer the following recommendations:

-   Web services are here to stay; using either the standards being put
    forward by W3C, WSI, etc. (in the Web services camp) or the ebXML
    standards. Web services currently offer lower level functionalities.
    However, for the interoperability/ integration to be achieved, the
    business processes and the business schemas need to be developed. As
    the complexity of the business processes increase, so does the time
    and cost involved in defining the dynamic schemas, especially for
    governmental transactions. Considering the magnitude of government
    business, the whole process of defining the business processes and
    creating the schemas would be a long,\
    drawn-out affair.

> Government should qualify and prioritize the processes that derive the
> maximum benefit from application integration and interoperability. For
> example, in the realm of Government-Citizen interaction, there exists
> Web based (HTTP standards) interaction at this point of time with
> respect to a variety of services. If these service areas are
> identified as priority, the existing understanding of the business
> processes can be used with advantage. Similarly identifying those
> areas for which a certain level of integration (customized
> applications) currently exists would facilitate easier implementation
> of application integration/ interoperability at higher levels. The
> probability of success increases due to existing appreciation for
> technology in these service areas.

-   Complementarity between ebXML and Web services: We see the two
    frameworks / standards as complementary and not in conflict with
    each other; they are parts of the complete solution. Despite the
    fact that at this point of time, there seems to be two different
    camps in Web services and ebXML, the strengths of the two frameworks
    are in different areas. On account of its immediate utility and
    revenue generation possibilities, the existing Web services
    technology is appropriate for deployment within the firewall
    operation. As integration/interoperable applications are developed
    (or consumed via the Web) for non-core business activities, and the
    companies see the potential for integrating company wide and
    inter-company transactions, the need for industry wide standards for
    business processes and schemas gain importance. Considering the head
    start that ebXML and its various standard setting bodies had in the
    arena of business processes and repository/ registry, it would be
    advantageous for vendors to make use of the progress in these
    standards and come out with cost effective solutions. The government
    may find it advantageous to consider these complementarities as it
    decides on the enterprise architecture.

-   Government should work with ebXML standard bodies, other industry
    and private standards bodies towards including use cases for
    government transactions. Considering the magnitude of government
    business, it may be prudent to start working towards defining
    schemas and business processes as soon as possible. It may be
    advisable for the government to come up with an e-Gov standards body
    on the lines of the Office of e-Envoy in UK entrusted with the work
    relating to business processes specification schemas. This body
    should be proactive in interacting with the various standards bodies
    and deciding on the appropriateness of their work for government
    transactions. This e-Gov standards body should, in league with
    industry and citizen, formulate technical specifications for
    interoperability based on open standards. Ad hoc working groups can
    be formed to focus on individual areas such as a technology advisory
    group, a government processes group, and a government schemas group.
    This approach has the advantage of bringing the government up to
    speed with developments in these technologies, besides having the
    advantage of ensuring that the final standards are open and
    acceptable to industry and citizen.

-   Government backend systems should be ready to be exposed to external
    applications using service-based frameworks. With the concept of Web
    services gaining increased visibility as an optimum way of
    integrating applications, 2003 may be a threshold year in terms of
    acceptance by businesses. It may be advisable for government to
    prepare the groundwork for implementation of Web services. This
    requires updating the servers to XML capabilities, mapping out the
    existing integration capabilities, and charting out a map for
    achieving interoperability at the agency/department level; and
    ultimately for the entire government viz. federal, state and local.

Appendix I: Interviews

1\. Chris Kurt, Microsoft. October 16, 2002.\
\
2. Mike Jacobs, USN. October 16, 2002\
\
3. Mark Crawford, LMI. October 16, 2002\
\
4. Alan Kotok, DESA. October 25, 2002\
\
5. Arthur Ryman, Phd IBM, November 1, 2002

6\. Hao Jiang, University of Maryland Netcentric Lab, November 6, 2002.\
\
7. Brand Niemann, EPA. December 2, 2002\
\
8. Velan Thillaiyaraja, Enterprise Application Integration Technologies
Inc., December 5, 2002

Appendix II: Additional Resources

1\. Holmes. Douglas. eGov. eBusiness Strategies for Government. Nicholas
Brealey Publishing.\
London. 2001

2\. Datz, Todd. \"Integrating America\". December 1, 2002 Issue of CIO
Magazine.

\<http://www.cio.com/archive/120102/america.html \>

3\. O\'Looney, John. Wiring Governments: Challenges and Possibilities
for Public Managers.\
Quorum Books. London. 2002

4\. Lenk, Klaus and Traunmüller,Roland. \"Broadening the Concept of
Electronic Government.\"\
J.E.J. Prins (ed.) Designing E-Government. Kluwer Law International.
2001. Netherlands.

5\. \"Electronic Government\'s Role in Implementing the President\'s
Management Agenda.\"\
July, 2002. \<http://www.egov.gov/it_policy.cfm#role \>

6\. eGov 24 initiatives. \<http://www.egov.gov/egovreport-3.cfm\>

7\. \"EGovernment and the Secure Channel Vision.\" Copyright 2000
icorp.ca.\
\<http://www.icorp.ca/eGovernment_and_the_Secure_Channel_Vision.pdf \>

8\. Draft Executive Summary & Recommendations. 2nd National Workshop on
\"IT Applications in e-Governance\". 20-21 September 2002.
\<http://www.ascihyd.org/exsum.htm\>

9\. Zweers, Koen and Planqué, Kees. \"Electronic Government from and
Organization Based Perspective Towards a Client Oriented Approach.\"
Designing E-Government. J.E.J. Prins (ed.), 2001. Kluwer Law
Intenational

10\. \"Supporting the Homeland Security information infrastructure with
Web-based integration, collaboration, data management and security
solutions.\" IBM Software Group. 2002.

11\. McIver and Elmagarmid. \"Policy and Portals: A doorway to an
electronic government.\" (ed.) Advances in Digital Government.
Technology, Human Factors, and Policy. 2002. Kluwer Academic Publishers.

12\. Strover, McIver and Elmagarmid. \"Citizens\' Perspectives on
E-Government.\" (ed.) Advances in Digital Government. Technoly, Human
Factors, and Policy. 2002. Kluwer Academic Publishers.

13\. Reynolds, Margery M. \"Challenges - Interoperability. Microsoft
E-Government Initiatives. Advisory Committee.\" Congressional Internet
Caucus. \<http://www.netcaucus.org/books/egov2001/pdf/EGovInte.pdf \>

14\. Dignan, Larry. \"Will the government ever go paperless?.\" Anchor
Desk. December 23, 2001. \<http://zdnet.com.com/2100-1107-504156.html\>

15\. Herman, Jim. \"E-enabling your enterprise\", *Business
Communications Review*. BCR\
Enterprises. April 2002.\
16. April, Carolyn A., \"OASIS serves up messaging standard; ebXML
Messaging service spec to\
enable secure business transactions.\" Inforworld.com. September 5, 2002

17\. \"Demystifying Web Services\" webMethods, Inc., 2002

18\. \"Auto exchange to promote two XML standards\" *Modern Materials
Handling*. Cahners Business Information. March 2002

19\. \"E-government Interoperability framework.\" Version 3. Crown
copyright 2001

20\. Kiely, Don. \"E-business language of choice?\" *Informationweek*.
May 7, 2001

21\. Kotok, Alan. \"The e-business continuum: Web services, ebXML and
EDI.\" published on webservices.org 26/06/2002.
\<http://webservices.org/article/articleprint/479/-1/22\>

22\. Kotok, Alan. \"Taking ebXML and Web services to the cleaners.\"\
\<http://webservices.org/article/articleprint/499/-1/62\>

23\. Baljko Shah, Jennifer. \"Beyond Babble\" *EBN.* Manhasset. October
1, 2001.

24\. Meehan, Michael. \"EDI, ebXML groups agree to cooperate.\"
*Computerworld.*\
Framingham. July 2,2001.

25\. \"Toward a Common Language.\" *EBN.* Manhasset. July 2, 2001.

26\. Montalbano, Elizabeth. \"ebXML: What\'s ahesd?\" *CRN.* Jericho.
March 12,2001.\
27. Hickman, Sam and De Smedt, Philippe. \"ebXML Is Emerging Asa
Reliable Standard \--\
Proof of Concept Demonstrates its Viability As EDI Alternative.\"
*Electronic Buyers News*.\
October 9, 2000.

28\. Webster, John. \"An Alphabet Soup of B2B Standards \--SOAP, ebXML,
UDDI and others\
will slowly gain momentum.\" *InternetWeek.* Dec. 18, 2000.

29\. Web Services Primer
\<http://www.xml.com/pub/a/2001/04/04/webservices/\>

30\. W3C SOAP Version 1.2 Primer
\<http://www.w3.org/TR/2001/WD-soap12-part0-20011217/

UDDI -- http://UDDI.org, UDDI to GILS http://www.gils.net/uddi.html\>

31\. WSDL (W3C) \<http://www.w3.org/TR/wsdl\>

32\. Web Services Architectural Requirements (W3C)
\<http://www.w3c.org/TR/2002/WD-wsa-reqs-20020429\>

33\. Web Services Activity Statement (W3C)
\<http://www.w3.org/2002/ws/Activity\>

34\. Niemann, Brand L., EPA "Peer-to-Peer XML Content Networks of Web
Services,"

\<http://www.gsa.gov/attachments/GSA_PUBLICATIONS/extpub/11-BLNiemann-EPA_7.htm\>

35\. U.S. Federal E-Government Strategy
\<http://www.cio.gov/Documents/EgovStrategy%2Ehtml\>

36\. NASCIO Enterprise Architecture
\<https://www.nascio.org/hotIssues/EA/\>

37\. XML Applications in Government Newsletter -- Office of
Intergovernmental Solutions
\<http://www.gsa.gov/Portal/content/pubs_content.jsp?contentOID=120147&contentType=1008&PMGZ=1\>

38\. GAO: Electronic Government: Challenges to Effective Adoption of the
Extensible Markup \<Language http://www.gao.gov/new.items/d02327.pdf\>

39\. Di Maio, Andrea. "Government Insights: What Do Web Services Mean?"
Gartner Research. August 22 2002

40\. Kreizman, Gregg. "Predictions: Web Services in E-Government
Architecture." Gartner Research. December 20, 2001

41\. Smith, David. "Explaining Web services Apparent Contradictions."
Gartner Research.\
June 4, 2002.

42\. Daryl Plummer, Mark Driver, Yefim Natis, Larry Perlstein, David
Smith. "Requirements for Web Services: Terms and Technology." Gartner
Research. May 2, 2001\
43. Daryl Plummer, David Smith, Whit Andrews "What Web Services Will and
Won\'t Do."\
February 19, 2002\
44. Smith, David. "Web Services: 2002 and Beyond." Gartner Research.
December 14, 2001

[^1]: Chabrow, Eric. One Nation, Under I.T. Nov. 11, 2002 "The feds say
    they need more unified architecture to tackle problems such as
    homeland security" Information Week.
    \<http://www.informationweek.com/story/IWK20021107S0010\>

[^2]: Clabby, Joe Web services Explained - Solutions and Applications
    for the Real World. Upper Saddle River, New Jersey. Prentice Hall
    PTR. 2002.

[^3]: Kotok, Alan & Webber, David R.R. ebXML-The New Global Standard,
    Indianapolis. New Riders. 2002

[^4]: \<http://www.ibm.com/developerWorks\>

[^5]: "Evolution of Integration Functionality" Technology White Paper.
    Sybase Web services, 2002

[^6]: Ogbuji, Uche "The Past, Present and Future of Web services, Part
    1", Published 28.9.2002 Web services.org

    \<http://www.webservices.org\>

[^7]: \<http://www.oasis-open.org/who\>

[^8]: \<http://www. unece.org/cefact/\>

[^9]: Ogbuji, Uche "The Past, Present and Future of Web services, Part
    1", Published 28.9.2002 on Web services.org

    \<http:// www.webservices.org\>

[^10]: DM Review, "PwC Technology Forecast Explores Trends" Published in
    DM Review Online April, 2002 \<http://www.dmreview.com\>

[^11]: DM Review, "PwC Technology Forecast Explores Trends" Published in
    DM Review Online April, 2002

[^12]: Jenz., Dieter E. "ebXML is Getting Closer" Published 21.10.2002
    on Web services.org
    \<http://www.webservices.org/index.php/article/articleprint/713/-1/24\>

[^13]: Web services Shortcomings - Bloor Research-North America, May
    2002 \<http://www.bloor-research.com/\>

[^14]:
    ####  Enabling Electronic Business with ebXML, December 2000

    #### \<http://www.ebXML.org/white_papers/whitepaper.htm\>

[^15]: Medbiquitous
    \<http://www.medbiq.org/technology/tech_architecture/\>

[^16]: ebXML \<http://www.ebXML.org/white_papers/whitepaper.htm\>

[^17]: ebXML Overview Report given 27 March, 2002. Hong Kong University
    Center for e-commerce Infrastructure
    Development\<http://www.cecid.hku.hk/Resources/ebXMLOverview.pdf\>

[^18]: Crawford, Mark \"The Universal Business Language Initiative\"

    \<http://www.xmlconference.org/xmlusa/2002/plenaries_crawford.asp\>

[^19]: Crawford, Mark, XML Lead, Logistics Management Institute (LMI),
    Personal Interview Oct.17, 2002

[^20]: Scmeltzer, Rolnald (analyst) \"The Open Applications Group:
    Business Object Documents Fill a Critical B2B Role\"
    \<http://www.openapplications.org/news/OAGI-092001-(ZTBN-0131).pdf\>

[^21]: Scott Durchslag "Beyond the Hype... the Reality of Early Web
    services Adoption". March 2002. SYS-CON Media
    \<http://www.wsj2.com\>

[^22]: Hagel, John \"Edging into Web services\" The McKinsey Quarterly,
    November 2002

[^23]: Darnell, Dave

    "Utilities Industry XML -- Business Case Example", Uniform Code
    Council U Connect Conference, May 22-24, 2002, Salt Lake City

[^24]: Kotok, Alan "Utility Deregulation Requires Effective E-Business
    Standards", June 2002, p.23

[^25]: Darnell, Dave

    "Utilities Industry XML -- Business Case Example", Uniform Code
    Council U Connect Conference, May 22-24, 2002, Salt Lake City

[^26]: The Drummond Group. Products list.
    \<http://www.drummondgroup.com/html-v2/products-ebXML.html\>

[^27]:
    #  [Jenz](http://www.webservices.org/index.php/article/author/view/21), Dieter E. "A view at Total Cost of Ownership and Return on Investment - parts 1-4", Published 21.10.2002 on Web services.org \<http://www.webservices.org/index.php/article/articleview/197/1/24, 03/18/2002\>

[^28]: Hagel, John "The strategic value of Web services", The McKinsey
    Quarterly, November 2002

[^29]: e-Government Interoperability Framework. Part One: Framework,
    Version 4.0

[^30]: e-Government Interoperability Framework. Part One: Framework,
    Version 4.0

[^31]: e-Government Interoperability Framework. Part One: Framework,
    Version 4.0

[^32]: Local GovOnline: Interoperability and Standards. Peter Hallams,
    Manager Integrated Services, National Office for the Information
    Economy. GEAC Users Conference 5 Nov 2001
    \<http://www.gmc.geac.com/media/5111PHStandard.pdf \>

[^33]: DigitalPlays.com Charting the rise of the Digital Age\...
    E-Government. March 23, 2002.
    \<http://www.digitalplays.com/Links/e-government.htm\>

[^34]: Interoperability Framework for the Commonwealth Government
    http://www.noie.gov.au/projects/egovernment/Better_Practice/Interoperability.htm

[^35]: Hallams, Peter. Manager Integrated Services, National Office for
    the Information Economy. Local GovOnline: Interoperability and
    Standards.Proceedings of GEAC Users Conference 5 Nov 2001.

[^36]: Reynolds, Margery M. \"Challenges and Opportunities -
    Intergovernalism- eGovernment is pervasive\" Microsoft eGovernment
    initiatives
    \<http://www.netcaucus.org/books/egov2001/pdf/EGovChal.pdf\>

[^37]: An Immediate Opportunity in E-Government Interoperability.
    Submitting Organization: GILS Maintenance Agency, U.S. Geological
    Survey, Department of the Interior. Contact: Eliot Christian.
    Congressional Internet Caucus
    \<http://www.netcaucus.org/books/egov2001/pdf/caucus_b.pdf\>

[^38]: Challenges contact: Interoperability. Margery M. Reynolds.
    Microsoft eGovernment initiatives.
    \<http://www.netcaucus.org/books/egov2001/pdf/EGovInte.pdf\>