ebXML Test Framework

normalpetsΛογισμικό & κατασκευή λογ/κού

4 Νοε 2013 (πριν από 3 χρόνια και 10 μήνες)

179 εμφανίσεις

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division





ebXML Test Framework

Version 1.1 Installation, Administration, User and
Developer Guide






Information Technology Laboratory (ITL), Software
Diagnostics and Conformance Testing Division


29 November
, 2004
National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

Authors/Editors:

1


2

Michael Kass, NIST <
michael.kass@nist.gov
>

3

Han Kim Ngo, NIST <
han
kim
.ngo@nist.gov
>

4


5


6


7

Abstract:

8

This document specifies ebXML interoperability testing specification for the eBusiness
9

community.

10


11

Errata to this version:

12

None

13


14


15


16


17


18


19


20


21


22


23


24


25


26


27


28


29


30


31


32


33


34


35


36


37


38


39


40


41


42


43


44


45


46


47

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division



1


2

Table of Contents
3

1

Introduction

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

5

4

1.1

Objectives of this Document

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

5

5

1.2

Project Background

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

5

6

1.3

Audience

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

5

7

1.4

Caveats and Assumptions

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

6

8

1.5

Related Documents

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

6

9

2

Prerequisite Software

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

7

10

2.1

NIST Test Driver Package

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

7

11

2.1.1

Java JRE V1.4.2

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

7

12

2.1.2

Apache Tomcat V 4.1.X

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

7

13

2.1.3

eXist XML Database

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

7

14

2.1.4

Apache Ant

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

7

15

2.2

NIST Hermes Test Serv
ice Implementation

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

8

16

2.2.1

Hermes version 0.9.3.1

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

8

17

3

Installation Instructions

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

9

18

3.1

NIST Test Framework Package
................................
................................
................................
...

9

19

3.1.1

td


Tomcat (so
uce/binary)installation directory for ebXML Test Driver

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

9

20

3.1.2

eXist


Tomcat (binary) installation directory for eXist XML database

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

9

21

3.1.3

msh


Tomcat installation directory for Hermes ebXML
Message Service Handler

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

9

22

3.1.4

The ebXML MS Test Service (for use in ebXML MS Conformance Testing only)

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

10

23

3.1.4.1

Test Service Command
-
Line Parameters:

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

10

24

3.1.4.2

St
arting the ebXML Test Service

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

10

25

4

Administration Guide

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

11

26

4.1

Test Suite Administration

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

11

27

4.1.1

eXist Database

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

11

28

4.1.1.1

Adding a new Tes
t Suite collection

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

13

29

4.1.1.2

Removing a Test Suite collection

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

14

30

4.1.2

Test Suite Administration Tool

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

14

31

4.1.2.1

Starting the Administration Tool

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

14

32

4.1.2.2

The File Menu

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

15

33

4.1.2.3

The Save Button

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

15

34

4.1.2.4

The Process Button

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

15

35

4.1.3

Removing Test Suite Collections from the Test Driver menu

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

17

36

5

User Guide

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

18

37

5.1

The Main Menu:

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

18

38

5.2

The Test Suite Menu

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

19

39

5.2.1

Login and Password Fields

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

19

40

5.2.2

Endpoint

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

19

41

5.2.3

Step duration

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

19

42

5.3

Executing Test Suites

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

20

43

5.3.1

Tier 1


Selecting Test Requirements

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

20

44

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

5.3.2

Selecting Functional Requirements
................................
................................
.......................

21

1

5.3.3

Selecting Test Cases

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

22

2

5.4

Selecting Requirement and Test Case Combinations

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

23

3

5.5

Executing Selected Test Cases

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

23

4

5.6

The Test Report

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

23

5

5.6.1

The meaning of “pass”

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

24

6

5.6.2

The meaning of “fail”

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

24

7

5.6.3

The meaning of “undetermined”

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

24

8

5.6.4

Aggregated Test Results

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

24

9

5.7

Examining Individual Test Case Results

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

25

10

5.8

Examining the Message Store for Received Messages

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

25

11

5.9

Examining the Sent Repository for Outgoing Messages

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

26

12

6

Demo Conformance Test Suites

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

27

13

6.1

ebXML Messaging Services v2.0 Conformance Test Suite

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

27

14

6.2

ebXML Registry Services v2.1 Conformance Test Suite

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

27

15

7

Developer Guide

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

28

16

7.1

Architecture

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

28

17

7.2

Web interface

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

28

18

7.2.1

JSP pages

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

28

19

7.2.2

Javascript pages
................................
................................
................................
....................

28

20

7.3

Test framework

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

29

21

7.3.1

The gui package

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

30

22

7.3.2

The model package

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

30

23

7.3.3

The messageStore package

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

33

24

7.3.4

The testDriver package

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

33

25

7.3.5

The servlet package

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

34

26

7.3.6

The XML package

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

34

27

7.3.7

The messaging package

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

35

28

7.3.8

The transport package

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

35

29

7.3.9

The test service package

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

35

30

7.4

Test Framework Features Not Implemented

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

36

31

7.4.1

Test Driver

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

36

32

7.4.2

Test Service

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

37

33

Appendix A

References

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

38

34

Non
-
Normative References
................................
................................
................................
.........................

38

35

Appendix B

Revision History

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

40

36

37


38


39


40


41


42


43


44

45

46

47

48

49

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


1

Introduction

1


2

1.1

Objectives of this Document

3

"This
document provides the instruction
s

for installing, administering, using
and extending

the NIST
4

ebXML Test Framework v1.1 sample implementation.

5

This document consists of four main sections
:

6



Test Framework Installation


Prerequisite Software, Binary Release Code, Source Code

7



Test Framew
ork Administration


Using the Test Suite Administrator Tool, User
8

Administration

9



Test Framework User Guide


Running Test Suites and Evaluating Test Report Results

10



Test Framework Developer Guide


Extending the Test Framework

11


12

1.2

Project Background

13


14

The NIST

ebXML Test Framework is a proof
-
of
-
concept implementation of the OASIS/IIC ebXML Test
15

Fra
mework Specification v1.1. That

specification defines a testing framework that accommodates both
16

conformance and interoperability testing of ebXML technologies; inc
luding ebXML Messaging Servic
es,
17

Registry/Reposi
tory
, Collaboration Pr
otocol Profile Agreement
and Business Pro
cess Specification
18

Schema
.

19


20

The project is part of NIST’s contribution to the OASIS Implementation, Interoperability and Conformance
21

Technical C
ommittee.
Additionally
, NIST is a contributor to the development of the /IIC ebXML Test
22

Framework Specification v1.1 and conformance test suites for ebXML
Messaging

Services and ebXML
23

Registry Services.

24


25

The NIST ebXML Test Framework is a tool that develo
pers and users of ebXML technologies (and XML
-
26

based web services in general) can use to evaluate (in a “black box manner”) the
conformance

of their
27

implementation to its appropriate
specification’s

28


29

The NIST ebXML Test Framework is a software tool that is
feely available for use, modification and
30

redistribution.

31


32


33

1.3

Audience

34


35

The target audience for this specification is:

36



The community of software developers who implement and/or depl
oy the ebXML
37

implementations.

38


39

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division



The testing or verification authority, which w
ill implement and deploy conformance testing for
1

ebXML implementations.

2


3

1.4

Caveats and Assumptions

4

It is assumed the reader has an understanding of communications p
rotocols, MIME, XML, SOAP, SOAP
5

Messages with Attach
ments and security technologies, in additi
on to ebXML technologies.

6


7

1.5

Related Documents

8

The following set of related specifications is developed independent of this specification as part of the
9

ebXML initiative, they can be found on the OASIS web site (
http
://www.oasis
-
open.org
).

10


11


12



ebXML Test Framework [ebTestFramework]


describes the test architecture, procedures and
13

material that are used to implement the MS Interoperability
Test Suite
, as well as the test harness
14

for this suite.

15



ebXML Messaging Service S
pecification [ebMS]



defines the messaging protocol and
16

service for ebXML, which provide a secure and reliable method for exchanging electronic
17

business transactions using the Internet.

18



ebXML Registry Specification [ebRS]


defines how one party can disc
over and/or agree upon
19

the information the party needs to know about another party prior to sending them a message
20

that complies with this specification. The Test Framework is also designed to support the testing
21

of a registry implementation.

22



ebXML Busines
s Process Specification Schema [
eb
BPSS]


defines how two parties can
23

cooperate through message
-
based collaborations, which follow particular message
24

choreographies. The Test Framework is also designed to support the testing of a business
25

process implemen
tation.

26



ebXML Collaboration Protocol Profile and Agreement Specification [ebCPP
A
]



CPP
A

27

defines one business partner's technical capabilities to engage in electronic business
28

collaborations with other partners by exchanging electronic messages. A CPA doc
uments the
29

technical agreement between two (or more) partners to engage in electronic business
30

collaboration. The MS Test Requirements and Test Cases will refer to CPA documents or data as
31

part of their material, or context of verification.


32


33


34


35


36


37


38


39


40


41


42


43

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


2

Pre
requisite Software

1

2.1

NIST Test Driver Package

2


3

The NIST Test Driver is a Java Serv
let
application that

allows ebXML testing through a “thin client”
4

application. The Test Driver provides a
graphical

user interface with a menu of conformance or
5

interoperab
ility testing requirements to choose from, and their corresponding test cases. A user may
6

select any number of requirements to test against, and execute their corresponding test cases in real
7

time, with a test report generated after all test cases have f
inished execution.

8


9

In order to install the Test Driver, the following software packages MUST be installed first:

10

2.1.1

Java JRE

V1.4.2

11

This implementat
ion was built using the Java JRE

1.4.2_04, available
at
http://java.sun.co
m

Earli
er and
12

later versions of the JRE

may work, but have not been tested.

13


14

2.1.2

Apache Tomcat V 4.1.X

15

This NIST ebXML Test Framework runs
on Apache Tomcat version 4.1.31
, available at
http://apache.org

16

Earlier versions o
f Tomcat 4.1 have successfully worked with the Test Driver. However,
version

5 of
17

Tomcat requires Java SDK V1.5, and has not been tested.

The Test Framework was successfully
18

installed on

earlier version of Tomcat 4.1

as well.

19


20

2.1.3

eXist XML Database

21


22

This N
IST ebXML Test Driver uses the eXist open source XML database as the back
-
end for storage and
23

retrieval of received messages.
The NIST Test Driver is integrated with eXist version 0.9.2, available
24

from SourceForge at:
http://exist.sourceforge.net/

25


26

In

order to simplify
installation, and

provide an “out of box” testing environment

(with the ebXML MS V2.0
27

and RS V2.1 conformance test suites already installed)
, the eXist database
has been bundled

as a .war
28

file


with the Test Driver application for easy installation with Tomcat.

29


30

2.1.4

Apache Ant

31

In order to simplify the build process across different operating systems, Apache Ant is used to compile
32

the source code for the Test Driver. Apache Ant
version

1.6.2, avail
able at
http://ant.apache.org

was
33

used.

34


35


36


37


38


39

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

2.2

NIST Hermes Test Service Implementation

1


2

As a proof
-
of
-
conce
pt of the Test Service componen
t of the NIST ebXML Test Framework, the open
-
3

source Hermes ebXML MSH implementa
tion includes
three

“back
-
end”
ebXML MS service actions
4

develope
d by NIST. These Test Service actions
enable the Test Driver to interact with Hermes and
5

evaluate its conformance to the ebXML Messaging Services V2.0 Specification.

6


7

It should be noted howev
er, that one does not need to install the NIST ebXML Test Service software
8

component unless o
ne wishes to do conformance tes
ting of the Hermes

v 0.9.3.1

MSH. The Test Driver
9

can be used alone, as a separate component for testing any other ebXML applicati
ons, such as ebXML
10

Registry Services, or an ebXML Business Process Specification Schema compliant web application.

11


12

2.2.1

Hermes
versio
n

0.9.3.1

13


14

This NIST ebXML MS Conformance Test Service has been integrated with the Hermes v0.9.3.1, available
15

from
freeebXML
.org at

http://www.freebxml.org/msh.htm

under the Academic Free License. Because
16

Hermes can be redistributed under that license, NIST has bundled it as part of the Test Framework
17

distribution library.

It
is also a “drop
-
in”

.war file distribution.

18


19

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


3

Installation Instructions

1


2

3.1

NIST Test Framework

Package

3


4

The NIST Test Framework V1.1 comes as a ZIP and tar archive format for installation on a

Windows or
5

Linux platform respectively
.

The contents of the archi
ve include:

6


7

3.1.1

td


Tomcat (souce/binary)installation directory for ebXML Test Driver

8

This directory can be “dropped in”

to the Tomcat “webapps”

directory. To provide a context for the Test
9

Driver, modify
the “server.xml” file in Tomcat’s configuration dire
ctory (
/conf) , and add

the line:

10


11

<Context path="/testDriver" docBase="td" debug="0" reloadable="true" crossContext="true"/>

12


13

The NIST Test Driver is automatically started when you start the Tomcat server.

14


15

3.1.2

eX
ist


Tomcat

(binary)

installation directory
for eXist XML database

16

This exist.war file

can also be “dro
pped in” to the Tomcat webapps

directory.
This open
-
source database
17

implementation is the “back
-
end” repository for messages received by the Test Driver.
The distribution in
18

this directory is eXi
st versio 0.9.2. The Test Driver only works with version 0.9.2 or earlier. It is not
19

com
patible with eXist 1.0.

20


21

Included with the eXist distribution
for the Test Framework
is a “base”

ebXML Messaging
Services

V2.0
22

conformance test suite.

23


24

The eXist dat
abase application will also start when the Tomcat server is started

25


26


27

3.1.3

msh


Tomcat installation directory for Hermes ebXML

Message Service
28

Handler

29


30

This
msh.
war file

can also be “
dropped in” to the Tomcat
webapps directory.
After

starting T
omcat, do
31

the

following:

32


33

1)

C
opy the files xalan.jar,
xercesImpl.jar and xmlParserAPIS.jar

from the
34

$
CATALINA_HOME
/webapps/msh/WEB
-
INF/lib directory to the
35

$
CATALINA_HOME
/common/endorsed directory.

Overwrite the existing files if they are present.

36

2)

Copy
exist
.jar
, xmldb.
jar and xmlrpc
-
1.2.jar

from $CATALINA_HOME
/webapps/exist
/WEB
-
INF/lib

37

directory to to the $CATALINA_HOME/common/lib directory

38

3)

Move the msh.propert
ies.xml
provided with the distribution

to the
$
CATALINA_HOME

directory

39

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

4)

In the $CATALINA_HOME/webapps/td directo
ry, modify the conf.txt file with the host and the port
1

values used by Tomcat

2


3


4

3.1.4

The ebXML MS Test Service (for use in ebXML MS Conformance Testing
5

only)

6


7

The Test Driver servlet application directory also
contains the

(optional )

ebXML MS Test Service
8

ap
plication, which is a “standalone” application that can be started when one wishes to test the Hermes
9

ebXML Message Service Handler.

10


11

The Test Service is “configurable”, with 5 parameters that may be set as command
-
line options with the
12

Test Service start
up script.

13


14

3.1.4.1

Test Service Command
-
Line Parameters:

15


16



retries (default=1
)

17



retryInterval (default = 10
000 milliseconds )

18



syncReply

19

o

0 = none (default value)

20

o

1 = MSH Signals Only

21

o

2 = Signals Only

22

o

3 = Response Only

23

o

4 = Signals and Response

24



messageOrder (defaul
t = false)

25



persistDuration (default =
-
1 i.e. “forever”)

26


27


28


29

3.1.4.2

Starting the ebXML Test Service

30


31

To start the Test Service, type “ant starTestService” from the Tomcat webapps/td directory
. If you wish
32

to change the
default startup configuration for the Tes
t Service, edit the build.xml file located in the
33

$CATALINA_HOME/
webapps/td directory.

The “startTestService” <target> content permits changing of
34

the above command line arguments.

35


36


37

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


4

Administration

Guide

1


2

4.1

Test Suite Administration

3


4

Two tools are used to m
odify the back
-
end database and front
-
end interface to the conformance test
5

suites used by the Test Driver.

6


7

4.1.1

eXist Database

8


9

The eXist XML

database stores

3 types of XML files that are used for conformance testing, all of which
10

are defined by XML schemas
in [eb
TestFramework
]
. The three file types are:

11


12

1)

Executable
Test Suite Document



A required document that drives the execution of the Test
13

Driver for each Test Case

14

2)

Test Requirements Document


An “optional” document, only needed if testing is “requirem
ents
-
15

based” (conformance testing)

16

3)

Test Profile Document


An “optional” document, only needed if testing requirements are “sub
-
17

setted” into profiles of functionality to be tested. If a particular specification has no conformance
18

profiles defined, then suc
h a document is not needed for testing.

19


20

All three files above (or a combination of (1), (1,2) or (1,2,3)

above form a Test Suite

“collection” that is
21

stored in eXist as a unique entity.

In order to load a Test Suite into the eXist database that can be
used
22

by the Test Driver you must perform the following steps (assuming that Tomcat and eXist are already
23

installed):

24


25

1)

Start Tomcat

26

2)

Access the eXist database

through a web brow
ser (
http://localhost:8080
/exist/xadmin.xsp

if
27

you Tomcat is installed locally)

You will see the following menu:

28

3)

Log in as user “guest” with password “guest”

You will now be able to create a Test Suite
29

collection through the

interface

below
.

The Test Driver uses the “guest” acc
ount to access
30

Test Suite collections.

31


32


33

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


1


2

4)

Click on the “browse collections” link to view the current collections already in the eXist
3

database
. You will see
an ebxml, log,

sent,

messageStore and system collections already
4

listed in the database.

5

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division



1


2

5)

C
lick on the “ebxml” collection link, and you will see a “messaging” subcollection
. Clicking
3

on the messaging subcollection

link

will show you the “default” ebXML Messaging Services
4

V2.0
Conformance
Test Suite that is installed with the Test Framework. T
he three files
5

contained in the collection are the ebXML MS Test Profile document, the ebXML MS 2.0
6

Conformance Test Requirements XML document, and the ebXML MS V2.0 Executable
7

Conformance Test Suite document.

8


9

6)

If you wish to modify the Test Suite, you can

delete/add any of the files through this interface.
10

However,
if y
ou add or delete

any test
profiles, test
requirements, or test cases

within those
11

collections
,
you MUST “regenerate” a

new
test suite

web page with the Test Suite
12

Administration Tool descri
bed in the following section
(5.1.2)
in order to access the new test
13

requirements or t
est cases. Simply modifying test case or test requirement

content
(not
14

changing the ID)
does not require you to build a new graphical
tree for the test driver.


15


16

4.1.1.1

Adding a new Test Suite collection

17


18

If you have an ebXML (or other)
application that you wish to test, you may create your own collection with
19

the eXist administration tool.
Simply click on the “browse collections” link in the administration page, and
20

go
the “root” of the collection tree. It will contain

the ebxml, log, messageStore and system collections.

21

The “e
bx
ml”collection contains the ebXML Messaging Services 2.0 Conformance Test Suite. The “log”
22

collection contains a log of all received messages b
y the Test Driver from all testing. The
23

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

“messageStore” collection contains all received messages fr
om the current Test Case
.


The “system”
1

collection is reserved for use by the eXist database.

2


3

You can add a collection by adding a new
collection name in

the Create s
ubcollection field of the
4

administration page and pressing the “create” button. You can then click on the the “add document”

link

5

to add your executable test suite, requirements or profi
le document to your collection.

6


7

4.1.1.2

Removing a Test Suite

collection

8


9

You can remove a Test Suite collection from eXist by
clicking the “checkbox” to the left of the collection
10

name, then pressing the “remove” button below it. Any files stored in that collection will also be removed
11

from the database.

12





13

4.1.2

Test Suite Administration Tool

14

In order to make a Test Suite collection

that you created wi
th the eXist administration tool

“visible” to the
15

Test Driver, and appear

as an option in the T
est Driver

thin client
interface

(your web browser)

for
16

selection, a user MUST use the
Test Suite Administration tool to generate
an updated list of Test Suite
s
17

that will appear in the main Test Driver page.

18


19

The Test Suite Administration Tool is a

Java application that guides a test suite developer through the
20

process of compiling a Test Suite collection in the eXist database. Additionally, this tool modifies
a static
21

Ja
vaScript
-
driven menu and presents the new Test Suite as a new testing option for users of the Test
22

Driver web client.

23


24

4.1.2.1

Starting the Administration Tool

25


26

Before staring the Admin
istration Tool, Tomcat ( with its

installed eXist database ) MUST be

started first.

27


28

To execute the Test Suite Administration Tool
, you must run the batch script file

runAdminTool.bat
29

(Windows) or runAdminTool.sh (Unix)

located in the $
CATALINA_HOME
/webapps/td/administration
30

directory
. Invoking the script will bring up
the Test Suite Administration Tool menu

illustrated below
:

31


32

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division



1

4.1.2.2

The File Menu


2


3

In order to create a Test Suite collection, one must first use the File menu

(the top left button)

to load in a
4

Conformance Test Suite XML document, an optional Test Requi
rements XML document and an optional
5

Test Profile XML document. All three of these file formats (and their schemas) are defined in
6

[ebTestFramework].

7


8

The
ONLY
three
combinations of Test Suite collection documents
you may load into a single
are:

9



A single
e
xecutable
test suite file

10



An e
xecut
able
test suite and a test r
equirements

file

11



An executable test suite, a test requirement file and a test profile file

12

4.1.2.3

The Save Button


13


14

The middle button is the “save” button. After selecting a file from the browser l
ist, you may “save” it for
15

processing by pressing this button. The document is examined and validated, and will be accepted if it is
16

valid. Again, as a minimum, you must at least select and save a single executable test suite file to the
17

collection.

18

4.1.2.4

The

Process Button


19


20

Once you have selected and saved the files you want to have in your collection, you must “process” them.
21

Processing the files w
ill generate the necessary Java
Server Pages

and JavaScript

that will be added to
22

the thin client interface
. Th
e result will be a new menu option for test suite selection in the Test Driver
23

thin client web page.

Below is an example of input that would generate the ebXML Test Suite graphical
24

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

menu for the Test Driver thin client. For additional clarity, these items

are highlighted in the “snapshot” of
1

that thin client interface.

2


3


4


5



Messaging t
esting

( Test Suite title bar that appears in thin client menu )

6


7



p
rofiles


(

The profile name of the Test Suite
)

8



9



Here are all the require

( An optional description of the Test Suite )

10




/ebxml/messaging


( The path in the eXist database to the Test Suite)

11




12


( A pulldown menu of existing Test Suites )

13






14



( Name of the new Test Suite
)

15


16


17


18



19


20


21

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division



1


2

e

3

4.1.3

Removing Test Suite Collections

from the Test Driver menu

4


5

Removing a test suite
from the Test Driver thin client interface is not as easy as adding one. This is due
6

to the fact that there is currently no tool for modifying the JSP and JavaScript files to remove the
7

particular code that corresponds to the test suite. However, you ca
n manually
remove the reference to a
8

particular Test Suite collection by editing the file “menu1.js”

located in the
9

$
CATALINA_HOME
/webapps/td/jsp/js directory. Remove the line beginning with Menu.makeMenu that
10

contains a reference to the particular Test
Suite you wish to delete from the interface, then save that file.

11

Additionally (to keep a clean directory) you may wish to delete the “.js” file that has a corresponding name
12

to the Test Suite and Test Profile you wish to delete.
And finally, you may wish

to remove the

13

corresponding “
.jsp” file with the same corresponding name f
ound in the
webapps/td/jsp directory.

14

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

5

User Guide

1


2

The NIST ebXML Test Driver is a “thin client” application, with an Internet Explorer web browser as the
3

client, and the actual conf
ormance testing taking place on a Tomcat Java servlet engine.
Conformance
4

testing of an ebXML application is initiated through the main web page of the NIST Test Driver. If the
5

Test Driver is installed on the same machine as the web browser, then the URL

to the Test Driver main
6

page would be (after starting the Tomcat server):

7


8

http://localhost:8080/testDriver/servlet/main

9

5.1

The Main Menu:

10


11


12


13

1)

Home

is a link back to the main Test Driver page

14

2)

Tes
t profiles

is a
menu of the available test suites
that can be run by the Test Driver

15

3)

Log Access
is a hyperlink to the eXist database, where one can examine the “log” XML
16

collection to examine the messages that were received by the Test Driver

17

4)

Downloads
is
a hyperlink to the actual XML files used to create the test suites used by the Test
18

Driver

19

5)

Contact
is a hyperlink to the email account of the NIST contact for questions/comments
20

regarding the NIST


21


22

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


5.2

The Test
Suite

Menu

1


2

When selecting any of the Test Suite
s available in the pulldown menu, the user will immediately be asked
3

to log in as the Test Framework administrator.

4


5

5.2.1

Login and Password Fields

6


7


The password

for the administrator

account

is defined in the conf.txt file in the
8

$
CATALINA_HOME
/webapps/td di
rectory. This password is also defined in the testFramework.jks
9

keystore file, and corresponds to the keystore alias “administrator”. The password for the administrator
10

can be changed
, and additional user aliases can be added to the keystore file using
the Java “keytool”
11

utility.

The “default” password for administrator is: sdctNIST

12


13

5.2.2

Endpoint

14


15

The URL of the application to be tested must be provided at the time of login.

16

5.2.3

Step duration

17

Step duration is
time
interval (
in seconds) that is
a reasonable e
xpectation of time that the Test Driver can
18

expect to receive a response from t
he implementation being tested.
This
parameter is based upon the
19

speed of the implementation under test, as well as network latency. The Step duration must be set to a
20

time in
terval greater than the time it would take for an application to receive a test message, process it
21

and respond to the Test Driver.

22


23


24


25

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


1

5.3

Executing Test Suites

2


3

Once logged in, one can select from any of the
available Test Suites for execution. Selecting a

particular
4

Test Suite will

present the user with a
selection tree.
The test framework is a “test requirement
s

driven”
5

execution model.
This means that conformance test cases are executed based upon the conformance
6

test requirements from which they are
derived.

7


8

5.3.1

Tier 1


Selecting
Test Requirements

9


10

The

testing

tree is “three tiered”. The leftmost nodes in the tree are “Test Requirements”. These are
11

broad requirements derived from a specification. For example, “message packaging”, “message
12

reliabili
ty”, and “error handling” are examples of broad categories of testing requirements.
Selecting
13

any of these Test Requirements
(by

checking the associated
box)

will instruct the Test Driver to run all
14

conformance Test Cases that satisfy this Test Require
ment. Depending upon the rigor of testing in the
15

Test Suite, this could encompass thousands of Test Cases.

16


17


18

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


5.3.2

Selecting Functional Requirements

1


2

The second tier
in the selection tree
is “Functional Requirements”.

This is a “finer grain” of detail in the
3

Test Requirement.

Sometimes referred to as “semantic requirements”, these are low level axiomatic
4

assertions of expected behavior for an implementation under specific

testing conditions. There may be
5

many Functional Requirements contained within a singl
e Test Requirement.

Selection of an individual
6

Functional Requirement

7


8


9


10


11


12

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


1

5.3.3

Selecting Test Cases

2

Lastly, the third tier in the tree represents the actual conformance Test Cases that satisfy the testing of a
3

single Functional Requirement. There may be o
nly a single conformance Test Case necessary to
4

adequately test a Functional Requirement, and conversely, there may be many Test Cases necessary to
5

verify that an implementation satisfies a Functional Requirement.

6


7


8

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division



1

5.4

Selecting Requirement and Test Case Co
mbinations

2


3

You may select from any of the 3 levels in the tree to execute Test Cases. If you choose a Test
4

Requirement, then all of its Functional Requirements are implicitly selected, and all of their corresponding
5

Test Cases are also selected.
Care sho
uld be taken in selecting higher in the tree to avoid running Test
6

Cases that one may not wish to execute.

7


8

You can have as many requirements trees as you desire to test against a particular specification. Each
9

tree can represent a different testing
profi
le, each with

its own corresponding set of conformance test
10

requirements.

11


12


13

5.5

Executing Selected Test Cases

14


15

After checking all of the Test Requirements, Functional Requirements and/or Test Cases that you wish to

16

execute, click on the

button. This begi
ns execution of the test cases. Execution follows
17

the
cascading
flow of the selection tree.
If a Test Requirement is selected, then all child Functional
18

Requirements
(and

their individual Test Case children) are executed. If a Functional Requirement is
19

s
elected, then all of its child Test Cases are executed. If individual Test Cases are selected, then they
20

are executed in the order in which they are encountered in the tree.

Currently no “status bar” is
21

implemented to monitor the execution of Test Cases.

The final Test Report only appears at the end of
22

the execution of all Test Cases.

23


24


25

5.6

The Test Report

26


27

The Test Report is a tabular format report that is identical in structure to the Test Case selection tree
28

chosen by the user. It presents
a simple “pas
s
”,

“fail”, or “undetermined” outcome for the Test
29

Requirement, Functional Requirement and individual Test Case(s) that are selected.

30


31


32


33


34

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


1


2


3


4


5

5.6.1

The meaning of “pass”

6


7

A Test Case
(labeled TC in the report)
has a

final result of “pass” if it does not ter
minate with a “failed”
8

Test Assertion operation anywhere within its e
xecution flow, and does not prematurely terminate

with an
9

“undetermined” result because a particular testing precondition was not met.

10


11

5.6.2

The meaning of “fail”

12

A Test Case is given a final
result of “fail” if it must terminate with a “failed” Test Assertion operation
13

anywhere within its execution flow, and does not exit with an “undetermined” result because a particular
14

testing precondition was not met.

15


16

5.6.3

The meaning of “undetermined


17

A Test
Case i
s given a final result of “
un
determined


if it must terminate
because a particular testing
18

precondition was not met during its execution, and therefore any final Test Assertion operation could not
19

be performed with any confidence.

Additionally, a r
esult of undetermined can exist if the Test Case
20

script execution causes an exception within the Test Driver. For example, an malformed XPath query in a
21

TestAssertion operation will generate an exception condition.

22


23

5.6.4

Aggregated Test Results

24


25

Results of F
unctional Requirements
(labeled FR in the report)
and Test Requirements

(labeled TR
) are

26

based upon the aggregate boolean
result of their

descendent

Test Cases. If a single Test Case fails
27

within a selected Functional Requirement, then that Functional Re
quirement is said to also “fail”.
28

Likewise, its parent Test Requirement also fails

for the same reason
.

A Test Requirement or Functional
29

Requirement is only said to “pass” if ALL of its selected descendents in the tree “pass”.

30


31


32


33


34


35


36


37

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


5.7

Examining Individ
ual Test Case Results

1


2

One can examine the result of any Test Case by clicking on the pass/fail/undetermined result that
3

appears to the left of the TC. An abbreviated “trace” of Test Case execution appears in the Test Driver
4

window, with the test operati
on that results in a “fail” or “undetermined” result highlighted in red.

5


6


7


8

Included in the Test Case execution trace is a short description of the test case
that failed
, along with a
9

reference to the actual Test Requirement that this Test Case is execute
d against. The grey text is a
10

minimal trace of the Test Case execution operations
(without

detail for
brevity)
. If a Test Case “fails”, or
11

has an “undetermined” result, then the point of failure is highlighted in red. It contains a detailed trace of
12

the

operation that failed, along with a description of why it failed.

13

5.8

Examining the Message Store
Collection
for Received Messages

14

If you wish to examine the messages that the Test Driver received

for a particular Test Case, cli
ck on the
15

“Log Access” tab at t
he top of t
he Test Driver main menu. This will ta
ke you to the eXist database page.


16


17

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


1


2

S
elect /db/messageStore from the lis
t of available XML collections

on the left
, and type in a query of

3

//TEST:Message

in the XPath ex
pression field to view received
messages.

4


5


6


7

5.9

Examining the Sent Message Collection

for Outgoing Messages

8


9

You can also examine the messages that are sent by the Test Driver by selecting the /db/sent collection
10

in the eXist database. For example, to view SOAP messages using the query int
erface, type in
11

//soap:Envelope to retrieve all sent messages contained in a SOAP envelope element.

12


13

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


6

Demo Conformance

Test Suites

1


2

Two ebXML conformance Test Suites are provided as part of the installation package. An ebXML MS
3

v2.0 Conformance Test Suite,

consisting of over 200 test cases, and a basic

(16 Test Cases)

ebXML
4

Registry Services v2.1 conformance test suite are automatically installed with the Test Driver.

5


6

6.1

ebXML Messaging Services

v2.0 Conformance Test Suite

7


8

Although all test cases are instal
led with the Te
st Driver, only those that
can
actually
run against the

9

installed

Hermes Test Service appear in “blue text” in the selection tree
menu.

Those that cannot be
10

executed with confidence (due to an unimplemented feature in the Test Driver or Te
st Service, or
11

because of a limitation in the Hermes MSH) appear in grey text. Although the “grey” Test Cases can be
12

executed, their result is not valid due to one of the 3 reasons mentioned above.

13


14

If a developer extends the Test Framework or Hermes impl
ementation in a way that permits running a
15

particular test case
, then it is a simple matter to modify the selection tree to change the blue text to grey.
16

Simply e
dit the appropriate javascript file (profile1.js, profile2.js or profile3.js)

containing the
appropriate
17

Test Case
, and select the line containing the Test Case you wish to make selectable (the line begins with
18

a “TC”
). Change the “greyNode” text to “blueNode” for that Test Case.

19


20

Note that some Test Cases do not exist for some Functional Requir
ements. If testing that requirement is
21

beyond the capability of the Test Framework,
then no Test Case has been written
.

22


23


24

6.2

ebXML Registry Services v2.1

Conformance Test Suite

25


26

An initial “basic” test suite consisting of 18 test cases is installed with the
Test Driver as a proof of concept
27

for ebXML Registry Services conformance testing. They are highlighted in “blue” in the test case
28

selection tree.
The remainder of the tree consists of Test Requirements only, with no accompanying
29

executabale Test Cases.

30


31

At this time, XML Digital Signatures is not

a feature

implemented in the Test Driver. Therefore these test
32

cases have not be
en exercised against the Freeebxml open source registry.

Other ebXML registries
33

that do not require digital signatures as an
authentication mechanism may run these Test Cases.

34

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

7

Developer Guide

1


2

The objective of this document is to give an overview of the NIST implementation of the IIC
-
OASIS Test
3

Framework version 1.1 specification. It describes the architecture from end
-
to
-
end an
d explains the
4

different choices made throughout and how to extend the framework. It also mentions the features that
5

are yet to be implemented. Since a global overview is provided in this document, please refer to the api
6

javadoc for specific detail about

any particular class.

7


8

7.1

Architecture

9


10

This implementation is based upon on the IIC
-
OASIS Test Framework v1.1 specification. It embodies:

11

-

A web interface to select the test requirements to be run and to set runtime parameters.

12

-

A test driver implementation

that will coordinate the execution of the conformance tests.

13

-

An XML database, implementing a message store that will save received message.
14

Additionally, the XML database acts as the data source for test profile, test requirement and
15

executable test s
uite XML documents.

16


17

Note: Each piece of software can be installed on different remote machines if desired.

18


19

7.2

Web interface

20


21

All pages are JSP pages. Dynamic content or display in those is handled throughout javascript functions.
22

Thus, performance issue al
so relies heavily at some point on the client machine capability.

23


24

7.2.1

JSP

pages

25


26

The main JSP pages are located at the root of the test driver jsp directory (located in the Tomcat
27

webapps/td directory). Each page only provides the code for its main content. T
he rest of the code (such
28

as the navigation bar) is provided by specific layers present in the layers directory, also implemented in
29

JSP and gathered together via the “import” directive. Thus, modifications of the code of one those “layer”
30

pages will be s
een in all pages. , If a new common section must be added to any main page, a new jsp
31

page containing a layer with its content and its positions in the main page must be created and added to
32

the layers directory. Then, the name of the new layer must be add
ed in a import directive for it to be
33

added every time.

34

Other main pages can be added directly at the root of the jsp directory.

35


36

7.2.2

Javascript pages

37


38

Here is a description of each file present in the js directory:

39

-

floatingLayer.js enables the scrolling of th
e Execute button in the profile page

40

-

menu1.js and coolmenus4.js handle the animation of the menu in the navigation bar.

41

-

Actions.js contains the different actions related to the web forms.

42

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


-

Ftiens4.js and ua.js process and display the folder
-
file
-
like tree

1

A
ll the other js files contain data for tree building.

2



3


4


5

7.3

Test framework

6


7

The NIST test driver execution encompasses two main phases (Results are then available directly in the
8

web browser and links are included to supply extra information such as exceptio
n name and description.)
9

:

10


11

-

A data extraction from the test documents (stored in the eXist XML database) according to the
12

users input, where the script formatted in ebXML terminology is converted to an internal tree
13

representation.

14

-


15

-

Once the
Test Object

tr
ee is built, execution relative to each XML instruction starts.

16


17

Every xml tag within that test suite document is considered as an instruction and is represented by a java
18

node. Those nodes are initialized at data extraction and launch their children node

execution in the same
19

order as they are written in the xml test suite.

20


21

Thus, class
-
wise, almost each XML tag has its own corresponding object. Only leaves of the tree are
22

regrouped into one class except when, because of their unique behavior require thei
r own classes .
23

Dynamic loading is
then used

to instantiate objects. This allows much more flexibility come maintenance
24

or development time.

25


26

The same approach was also used to implement the envelope, the transport and the database sections.

27

Thus, to add
a new instruction, a new type of envelope, a new type of transport protocol or a new type of
28

back end, one has just to implement the class representing the new feature and add it in the respective
29

package without any modification of the test framework code
.

30


31

Moreover, if a test suite contains an unknown instruction, the test driver will stop the execution and mark
32

the test case unavailable.

33

Following are the java packages present in this distribution.

34

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

gui
messageStore
messaging
model
testDriver
testService
transport
util
xml

1

-

The gui package contains the swing interface for the a
dministration tool.

2

-

The messageStore package provides functions to store data into the database.

3

-

The messaging package builds messages.

4

-

The model package includes classes representing the ebxml terminology.

5

-

The testDriver package handles data other than th
e xml one. It also embodies the servlet
6

package that communicates with the web browser.

7

-

The xml package is there to process any xml content, from documents generation and data
8

extraction to interactions with the XML native database when used.

9

-

The transport

package sends and receives messages from one party to another.

10

-

The util package supplies common functions to all classes.

11

-

The test service simulates one application behind the msh, processing incoming messages and
12

generating new ones.

13


14

7.3.1

The gui package

15


16

Pl
ease refer to the administration for further details on that section.

17


18

7.3.2

The model package

19


20

The model can be divided into two types of elements namely:

21

-

Tree objects, whose results are sent back to the web browser for display purposes.

22

-

Test objects, which ha
ndle all the instructions from the test suite document.

23


24

Both types of object have the same parent LightTestObject, a minimal entity representing one node in the
25

tree. All classes actually derive from this super class and either print results back to the b
rowser or
26

interact with other classes from other packages like the messaging and the transport ones.

27


28

The following are extracts of the class diagram.

29


30

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division



1

As previously mentioned, objects that appear in the tree in the web browser inherit from the TreeObjec
t
2

class. Since FunctionalRequirement and TestRequirement have similar behavior, they are sharing one
3

common parent, Requirement. A LightTestCase represents a Testcase but this name is reserved to the
4

test case handling actually the execution.

5

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


1

Every test
object is derived from the LightTestObject and has a reference to the test suite which
2

represents semantically the root.

3


4

It is possible to add new instructions by developing the corresponding classes. Classes must derive from
5

the LightTestObject class or

any of its descendant. Only two functions in a new class need to be
6

implemented to be integrated with the rest of the framework.

7


8

-

initialize, which as it sounds is used to initialize the object. For example, one instance can
9

prepare data so that parents
re
-
use them. Note : Children are initialized before parents. If no
10

initialize method is present, then no action will be taken since the LightTestObject default
11

initialization behavior is to do nothing.

12

-

CoreExecute, which translates the instruction meaning.

If this function is not implemented, use of
13

its parent will be made. If that parent node is the LightTestObject class, the default execution is to
14

launch each child node execution function.

15


16

With such an architecture, when a modifying one instruction beha
vior needs no change of the test
17

framework code.

18


19


20

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


7.3.3

The messageStore package

1


2

Classes within that package can load messages coming synchronously or asynchronously.

3

It contains a basic MIME message parser and may need re
-
writing.

4


5

7.3.4

The testDriver package

6


7

Thi
s package is the main core of the test framework since it deals with every other component. Here is a
8

brief description of each class:

9

-

Database, this interface is to be implemented for every new back end introduced. No modification
10

is to be made on the tes
t framework to include the new database backend. However, the conf.txt
11

in the td directory must be updated with the new database full class name. Dynamic loading will
12

enable use of the new back end then.

13

-

DataHandler, handles data coming from test documents

input in the administration interface.

14

-

PathHandler processes a user's selection of test cases to be run and build the corresponding
15

tree.

16

-

TestProfileHandler, FunctionalRequirementHandler and TestRequirementsHandler supply
17

specific processing to the DataHa
nlder class.

18

-

TestCasesHandler extracts information from the database according to the PathHandler data,
19

initialize the tree of instructions and completes then the main tree built by PathHandler.

20

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


1


2



3

7.3.5

The servlet package

4


5

That package contains all servlet
s of the test framework. Every servlet describes one particular phase.
6

Please refer to the api javadoc for further information.

7


8

Note: A listener was written specifically to handle Hermes messages. Thus, packaging tests that try to
9

access headers may not w
ork successfully. Another listener can be added and the easiest way to do so
10

may be to integrate it within a new servlet.

11


12

7.3.6

The XML package

13


14

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


This package handles any XML
-
related data regarding generation, storage and extraction.

1


2

Generation is based upon X
SLT stylesheets.

3


4

Data extraction is achieved by using SAX handler. It provides the basic class and the top one is
5

implemented by the TestCasesHandler.

6


7

Storage is done via the exist API.

8


9

7.3.7

The messaging package

10


11

This package builds messages according to th
e envelope type specified in the Configuration group. That
12

value is actually used to load the respective class.

13

Two types of envelope that are available so far are the ebxml and soap.

14


15

7.3.8

The transport package

16


17

Two protocols, SOAP and HTTP, are implemented fo
r this distribution. The structure of the connection
18

and the exchange are very similar at some levels but the main difference relies on the explicit use of a
19

SOAP API in one case and a raw HTTP connection in the other.

20


21

7.3.9

The test service package

22


23

This piece

of software provides a simple entity to test. It was written with the Hermes MSH api. Thus, it
24

may not work with another MSH.

25

Dynamic loading is also used to choose the action specified in the incoming message.

26

Other actions may be added in the future.
Then, the new action must implement the TestServiceAction
27

and supply the code for the execute routine.

28

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


1

7.4

Test Framework Features N
ot

I
mplemented

2


3

The NIST Test Framework is not a complete implementation of the IIC Test Framework v1.1
4

Specification. Certa
in features of both the Test Driver and Test Service are not implemented for the Test
5

Driver and Test Service components. As a result, not all
conformance
Test Cases provided with this
6

implementation can be executed. Below are the list of features
in the

IIC Test Framework v1.1
7

Specification
that must still be implemented for both components.

8

7.4.1

Test Driver

9


10



StoreAttachments


11



DSign

12



DSignPayload

13



LockParameter

14



UnlockParameter

15



ValidateContent

16



VerifyTimeDifference

17



VerifyParameter

18



Return

19



ValidateContent

20



Message “
repeatWithSameContext” and “repeatWithNewContext” feature of PutMessage

21



MIME header/attribute
creation/
manipulation through PutMessage

22



Message “mask” feature

for GetMessage

23



MIME hea
der storage

24



XML Attachment storage in message store

25



Initiator

and TestServi
ceConfigurator

RPC

26

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division


7.4.2

Test Service

1


2

Actions not yet implemented

in the Hermes Test Service

include:

3


4



Reflector

5



PayloadVerify

6



Initiator RPC

7



TestServiceConfigurator RPC

8


9

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

Appendix A

References

1


2

Non
-
Normative References

3

[ebTestFramework]

ebXML Test Framework specification,
Version 1.0, Technical Committee
4

Specification, March 4, 2003,

5

http://www.oasis
-
open.org/committees/tc_home.php?wg_abbrev=ebxml
-
iic


6

[ebMS]


ebXML Messaging Servi
ce Specification, Version 2.0,

7

http://www.oasis
-
open.org/committees/tc_home.php?wg_abbrev=ebxml
-
msg

8


[ebCPP
A
]

ebXML Collaboration Protocol Profile and Agreement specificati
on, Version 1.0,
9

published 10 May, 2001,

10

http://www.ebxml.org/specs/ebCCP.doc

11

[ebBPSS]

ebXML Business Process Specification Schema, version 1.0, published 27 April 2001,

12

http://www.ebxml.org/specs/
ebBPSS.pdf
.

13

[ebRS]

ebXML Registry Services Specification, version 2.0, published 6 December 2001

14

http://www.oasis
-
open.org/
committees/regrep/documents/2.0/specs/ebrs.pdf
,

15

published, 5 December 2001.

16


17


18


19


20


21


22


23


24


25


26


27


28


29


30


31


32


33


34


35


36


37


38


39


40


41

National Institute of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division



1


2


3


4


5


6


7


8


9


10


11

National Institute

of Standards and Technology

Information Technology Laboratory

Software Diagnostics and Conformance Testing Division

Appendix B

Revision History

1


2


3


4

Rev

Date

By Whom

What

cs
-
10

2003
-
03
-
07

Michael Kass

Initial version

cs
-
11

2004
-
03
-
30

Michael Kass

First revision (DRAF
T)

cs
-
12

2004
-
04
-
12

Michael Kass

Second revision (DRAFT)

Cs
-
13

2004
-
04
-
27

Michael Kass

Third revision (DRAFT)

Cs
-
14

2004
-
10
-
11

Michael Kass

Fourth revision (DRAFT)

Cs
-
15

2004
-
29
-
11

Michael Kass

Fifth revsision (FINAL)


5


6


7