XML Component Management and Repository Tool Recommendation to Pursue a Vendor Pilot

XML Component Management and
Repository Tool


R
ecommendation

to Pursue a
Vendor Pilot



April 8, 2009










Prepared by

the


PESC Technical Advisory Board
















© Postsecondary Electronic Standards Council (PESC) 200
9
. All Rights Reserved.


This document may be copied and furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, pr
ovided that the above copyright
notice and this paragraph are included on all such copies and derivative works. This document
itself, however, may not be modified in any way except when expressly approved by PESC for
the purpose of developing standards an
d specifications.


Notice:

The material contained herein is not a license, either express or implied, to any intellectual
property owned or controlled by any of the authors or developers of this material or PESC. The
material contained herein is provided

on an “AS IS” basis and to the maximum extent permitted
by applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors
and developers of this material and PESC hereby disclaim all other warranties and conditions,
either express, i
mplied or statutory.


IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERILA OR PESC BE
LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUSTITUTES
GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY
INCIDENTAL, CONSEQUENTIAL, DIRECT,
INDIRECT, OR SPECIAL DAMAGES
WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN
ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS
MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE
POSSIBILITY OF SUCH DAMAGES.



Overview

................................
................................
................................
................................
.........

1

Recommendation

................................
................................
................................
........................

1

Expected Benefits to PESC

................................
................................
................................
.........

2

Pilot Project Technical Assessment

................................
................................
............................

4

Criteria Used for Evaluation

................................
................................
................................
.......

6


Appendix
–

Licensi
ng and Deploying igniteXML for PESC

................................
.........................

8

Licensing

................................
................................
................................
................................
.....

8

igniteXML 5.0
................................
................................
................................
.........................

8

ICS 2.0

................................
................................
................................
................................
....

9

Deploying igniteXML for PESC

................................
................................
................................

9

Location of Servers

................................
................................
................................
.................

9

Connectivity

................................
................................
................................
............................

9

Deployment Diagram

................................
................................
................................
............

10


PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
1

Overview


In 2002 PESC chose to use a

tiered architecture of up to three schemas
for component definition
and schema deve
lopment. This architecture has provided a means to create and maintain like
-
named elements and components whose underlying definitions differ due to the varying
requirements of PESC members, as well as provide a schema
-
based method of knowing which
defini
tion was used in a particular schema via the use of namespaces

to differentiate like
-
named
elements and components.


When this architecture was chosen, the operation and behavior of toolsets used for handling
XML in various application development environm
ents was not known. However, it has become
evident that t
his tiered architecture is a hindrance to performance in these software environments.
There is a need to move away from
some of the tenets of
this tiered architecture
and
to
ward

a
system of assembl
ing schemas from components.


After considering “manual” options for component
and schema
management,
t
he PESC
Technical Advisory Board

(TAB)
undert
oo
k a
feasibility study,
search
ing
for an XML
Component Management and Repository Tool.

Since PESC does not

have
staff dedicated to
schema maintenance,
a tool providing automation of the component development and
maintenance processes, as well as the schema creation
process,

may be a large part of a viable
alternative to our current
practices for managing the
t
iered architecture.


In support of that
feasibility study

the Technical Advisory Board

created a list of requirements
and capabilities that are desired in such a tool.
The Board

categorized

these items

as “Must
Haves” and “Should Haves”

and use
d
them
as t
he basis for
our
tool analysis.

These items are
listed on

subsequent

pages of this document.


One tool, igniteXML from digitalML, was trialed by SunGard and was brought to the attention
of the Technical Advisory Board. Members of the TAB searched for oth
er tools offering any of
the features and capabilities that were sought. No other tools were found that offered enough of
the desired functionality as to make them a viable candidate.


Recommendation


The hands
-
on experience by a TAB member at
SunGard
sho
w
ed

that
igniteXML

meets

many of
the
criteria the TAB ha
s

established
.

Demonstrations for the TAB as well as the Sta
ndards
Forum Steering Committee showed the powerful capabilities of the tool as well as
some of
the
benefits PESC
may

realize with its use.


T
he Technical Advisory Board recommends that PESC
initiate
discussions with digitalML
. The
goal of these discussions
should

be a pilot project starting in 2 to 3 months
and
with a suggested
duration of
30 to 60 days. At the end of that period a recomme
ndation will be made to move
forward with the product or not.


PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
2

Expected
Benefits to PESC





Eliminate the use of the CoreMain and Sector schemas
.


igniteXML will
allow
existing versions of CoreMain and Sector schemas
to be imported
into the product. This sh
ould greatly ease the task of
break
ing
out the components
contained within each

of these schemas
. In addition, components broken out from each
version of a CoreMain and Sector schema can be maintained
in a separate group for each
version of the “parent” s
chema.

This
could aid

backward compatibility
with

existing
PESC schemas. Schemas from other standards organizations can be imported and used in
this same manner.





Provide a repository for individual schema components, both simple and complex


igniteXML’
s repository can group, store, and maintain components according to
user
-
chosen criteria. Within these groups, components can be maintained and versioned as
required.
Components can be moved to new groups.
Non
-
XML
-
based items such as
documentation can b
e associated with a component and versioned as well. Components
and documentation can be exported
in various formats.
T
his
should
make it possible to
import them into
another facility, such as FSA’s XML Registry and Repository for the
Education Community
, or for delivery to end users.





A
n interface that allows a schema to be created or changed using components stored in
igniteXML’s repository


New schemas can be created and generated by choosing only those components that are
needed. When working with c
omplex components, the user interface illustrates the
hierarchy of its sub
-
components.

Properties of components can be changed if necessary.





T
he ability to perform an impact analysis and create a corresponding report before any
change is applied


Allowi
ng t
he impact of a potential change
to

be identified
in an automated manner should
greatly reduce the risk of performing the impact analysis manually.





T
he ability to identify components in a schema or other structure that are not being
used


There are
co
mponents and structures in CoreMain that are
believed to be
not
in
use, but
igniteXML can confirm what those are.



PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
3




W
eb access to some of
igniteXML’s schema design tools in order that schemas may be
created and modified
by a workgroup as their design
is

re
fined


Workgroups can be provided
access to a “workarea” within igniteXML that is created
specifically for their use. The workarea can be pre
-
populated with
e
xisting components
the workgroup may need.





M
ultiple levels of
access control


The tool utilizes

an
“administrators”
function
for critical processes such as checking
designs into and out of the repository
, assigning versions, etc
.
However, c
omponent and
schema creation and modification do not require the level of access of the administrator.

This s
hould reduce the risk of compromising the integrity of the repository.



PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
4

Pilot Project
Technical Assessment

In addition to evaluating igniteXML’s XML Schema management capabilities, the pilot project
must
include a technical feasibility assessment to deter
mine
the
appropriate
deployment and
licensing scenario.
A summary recommendation is provided below, while a more detailed
recommendation is provided in the appendix. The pilot project must include a decision on
whether these recommendations are tenable or
whether an alternative approach must be sought.


The Technical Advisory Board recommends the deployment of a centralized igniteXML server
providing Web client access along with a limited number of thick clients. This configuration
should be supported by l
icensing an igniteXML Communication Server (ICS) license pack, if it
is still available from digitalML. A license pack would provide the ICS, which provides Web
access to the igniteXML database, as well as a specific number of thick client licenses for use

by
organizers of XML common components. This configuration is depicted in the following
diagram.




The TAB believes that a 5 client license pack will be adequate as an initial deployment to
support the limited number of individuals that regularly compo
se PESC schemas. Web client
access can be used by work groups to evaluate existing components as well as by the community
at large to browse and understand PESC message schemas, sector libraries, and core
components.



PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
5

The more challenging aspect of the de
ployment is not the software, per se, but rather the
acquisition, location, connectivity and maintenance of the hardware for the ICS and the
igniteXML database server. The following key requirements must be addressed

and
met in order
for the pilot to comme
nce




The ICS server must reside in a secure location and provide secure connectivity via
supported browsers.



The igniteXML database server must also reside in a secure location that provides for
periodic backup. Additionally, this server must provide secu
re access for thick clients.


One of the factors that must be evaluated is the latency between igniteXML clients and the
database server. Given the decentralized and geographically
-
dispersed nature of the PESC
organization, the co
-
location of client appli
cations and the database server is unlikely.
Consequently, an assessment of distributed access must be made.


PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
6

Criteria Used for Evaluation


The Repository Tool
Must:


1)

Be sufficiently robust as to support the creation and maintenance of PESC
schemas based
on components contained in the Repository.


2)

Have the ability to import existing schemas, both PESC schemas and schemas
from other sources.


3)

Be able to create schemas from Repository
-
based components that are backward
-
compatible with existing schema definit
ions.


4)

Be able to store schemas in separate namespaces to accommodate existing PESC
schema definitions, which provide like
-
named elements and types that exist in
separate namespaces.


5)

Be able to create a new schema file and namespace from Repository
-
based
components.


6)

Provide the ability to move a component to a new namespace/classification
scheme.


7)

Provide the ability to create new components from subcomponents whose
definitions exist in different namespaces.


8)

Be able to conduct an Impact Analysis of a cha
nge to a definition contained in the
repository and its affect on:




Schemas



Components



Elements


9)

Provide the ability to see parent/child associations and relationship history across:




Schemas



Components



Elements


10)

Be able to support multiple versions of the

same definition (concurrent versions as
well as those in various development stages) for:




Elements



Components



Schemas


PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
7


11)

Have the ability to publish/deploy definitions within the repository in multiple
formats such as plain text and Comma Separated Values
(CSV) for:




Elements



Components



Schemas



The Repository Tool
Should
:


1)

Provide a means to publish contents of the repository to a Component Registry
such as Federal Student Aid’s XML Registry and Repository for Higher
Education, the ebXML Registry and Repo
sitory, etc.


2)

Provide the ability to create/publish one or more subsets of a larger schema.


3)

Have the ability to identify elements and components that are not used within
another component or schema definition.


4)

Be able to create Core Components that have
been modeled in other tools (such as
a tool that is UML
-
based).


5)

Provide a means to track changes made to components and other artifacts (such as
a sample instance document) stored in the repository.


6)

Provide a means to store supporting information (sample

instance documents,
change history, documentation, etc) and tie it back to the corresponding
component.


7)

Provide the ability to generate a report that details the results of an Impact
Analysis. This report will serve as evidence of due diligence by a PES
C
workgroup that is adding or changing an element, component, or schema.


8)

Provide the ability to enforce policy on components residing in the repository,
such as requiring the presence of documentation, sample instance documents, etc)
before the component
is available for publishing.


9)

Be able to generate instance documents based on a schema definition residing in
the repository.


10)

Be able to generate a report of the metadata utilized as part of the definition of a:




Element



Component



Schema


PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
8

Appendix
–

Licens
ing and Deploying igniteXML for PESC

Licensing

The Technical Advisory Board recommends the deployment of a central igniteXML server
providing Web client access along with a limited number of thick clients.

This deployment supports the
two user profiles

de
fined by digitalML: t
he
XML Schema
“organizer”

and the
XML Schema “
consumer
”
. Organisers use igniteXML 5.0 to organi
z
e,
extend and maintain the library

of core component
definitions. Consumers use
a browser to
connect to the
ICS (igniteXML Consumer Serve
r)
for
Web
-
based search, navigat
ion
, and reuse
of
definitions when designing, building and updating SOA based applications.

This configuration should be supported by licensing an igniteXML Consumer Server (ICS)
license pack, if it is still available from
digitalML. A license pack would include the ICS
software for establishing Web
-
access to the igniteXML database and a specific number of thick
client licenses for use by organizers of common components. This configuration is depicted in
the following diagra
m. Additional details about the igniteXML software components follow the
diagram. The TAB believes that a 5 client license pack will be adequate as an initial deployment.

igniteXML 5.0

Allows
organizers

to import and navigate existing
XML
definitions and
organize them in a single
hierarchy which represents the entire model from logical to physical constructs. Every construct
is a core
-
component and as such can be easily extended, versioned and tagged with relevant
metadata. New components can be simply ad
ded to the existing model. igniteXML is a
collaborative system which allows for access control, update management, impact analysis and
approval workflows.



PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
9

The igniteXML 5.0 client may operate stand
-
alone, or, more typically, connected to a central
databas
e server. This latter configuration is preferred for PESC since it realizes the requirement
of a central repository of PESC core components.

ICS 2.0

Once the
core components d
efinitions
l
ibrary has been approved for reuse it is essential that
every one in
volved in planning, building and maintaining
XML
-
based applications can easily
access and reuse the
d
efinitions.
The
ICS server facilitates this aim

by providing Web
-
based
access to the repository
. It uses familiar web metaphors such as Google
-
style sear
ching and
shopping cart component selection. The
c
heckout metaphor allows the user to automatically
produce a subset XSD that is runtime optimized and ready for use in WSDLs and message
payloads.

Deploying igniteXML for PESC

The more challenging aspect of
rolling out igniteXML for PESC is not the software, per se, but
rather the acquisition, location, connectivity and maintenance of the hardware for the ICS and the
igniteXML database server.

Acquisition and maintenance are currently outside the scope of th
is document. However, the
requirements for location of the igniteXML database server and ICS and connectivity to them are
not. Specifically, the following key requirements must be addressed:



The ICS server must reside in a secure location and provide secur
e connectivity via
supported browsers.



The igniteXML database server must reside in a secure location that provides for periodic
backup. Additionally, this server must provide secure access for thick clients.

Location of Servers

The TAB recommends the co
llocation of the igniteXML database server and ICS in order to
simplify access and administration.

Connectivity

Due to the fact that
PESC
’
s schema development is greatly decentralized
, secure connectivity to
the central database server across a wide
-
area
-
network will be required
.
Individual “o
rganizers
”

are not
co
-
located
, but rather are geographically dispersed. Consequently, while a shared, central
repository is indeed a principal aim, access to it will need to be across the Internet.

According to a dig
italML representative, “
For the organi
z
ers, on the current release (5.0.2) they
can work remotely (Broadband Speed connection
r
equired) to a central server. The performance
will not be as fast as if they were on the same LAN but should be acceptable. With
Version 5.1
we are currently working on a configurable option for WAN
-
based workers where they can work
on a central server but also store their workspace on their local machine. This would give the
performance as if each had a local database with the dat
abases being synchronized. The timing
on 5.1 is end of Q1.
”

Whether using the existing (5.0.2) version, or the 5.1 version, there still seems to be the need for
some type of Virtual Private Network (VPN) to provide secure client access. A VPN is a private

network that uses a public network (usually the Internet) to connect remote sites or users
together. Instead of using a dedicated, real
-
world connection such as leased line, a VPN uses

PESC Technical Advisory Board
–

XML Component Management and Repository Tool

Page
10

“virtual” connections
routed

through the Internet from a private netwo
rk to the remote site or
authorized user.

While the recommendation on a specific VP
N

solution is outside the scope of this
recommendation, one possible solution is OpenVPN, a full
-
featured open source SSL VPN
solution that accommodates a wide range of conf
igurations. OpenVPN offers a cost
-
effective,
lightweight alternative to other VPN technologies that is well
-
targeted for the SME and
enterprise markets.

Connectivity across the Internet will also be necessary for core component “consumers”, again,
due to t
he geographic dispersion of the user community. Again according to a digitalML
representative, “
For the consumers
,

this distributed environment is no issue as we would
recommend the use of the ICS Server. With this approach the consumer interface would be

via a
web browser to the Web server.
” And since ICS can be configured to allow only secure access,
no additional software would be required for “consumers”.

Deployment Diagram

Given the requirements and recommendations above, the following diagram provid
es an
overview of the proposed configuration for PESC.