ebXML Registry 512 MayJanuary 2001[MONTH AND YEAR HERE]February March 20030
Technical Note
Registering Web Services in an ebXML Registry, Version 10.01 Information Model v1.020
ebXML Registry Project Team
24 12 February March 2003
Working Draft 3/19/20018 May 2001[ADD DATE HERE]
This version: Version 0.61
Authors
Joseph M. Chiusano, Booz Allen Hamilton
Farrukh Najmi, Sun Microsystems
Abstract
This document describes the current Bbest Ppractice for registering Web services in an ebXML Registry. It conforms to the following specifications:
OASIS/ebXML Registry Information Model (ebRIM) v23.10, June 2002release pending
OASIS/ebXML Registry Services Specification (ebRS), v23.10, release pendingJune 2002
These specifications can be found at http://www.oasis-open.org/committees/regrep/.
Status of this Document
This document is an OASIS Registry Technical Committee Best PracticesTechnical Note Working Draft – [MONTH AND YEAR HERE].
Distribution of this document is unlimited.
specifies an ebXML DRAFT DRAFT STANDARD for the eBusiness community.
Distribution of this document is unlimited.
The document formatting is based on the Internet Society’s Standard RFC format.
This version:
http://www.ebxml.org/specdraftsproject_teams/registry/private/RegistryInfoModelv1.00.61.pdf
http://www.ebxml.org/specs/ebRIM.pdf
Latest version:
http://www.ebxml.org/specs/ebRIM.pdf
http://www.ebxml.org.org//pspecdraftsroject_teams/registry/private/RegistryInfoModelv1.0.pdf
Previous version:
http://www.ebxml.org/project_teams/registry/privatee/RegistryInfoModelv0.9060.pdf
ebXML participants
We would like to recognize the following for their significant participation to the development of this document.The authors wish to acknowledge the support of the members of the Registry Project Team who contributed ideas to this specification by the group’s discussion e-mail list, on conference calls and during face-to-face meetings.
Lisa Carnahan, – NIST
Joe Dalman, - Tie
Philippe DeSmedt, - Viquity
Sally Fuger, – AIAG
Len Gallagher, - NIST
Steve Hanna, - Sun Microsystems
Scott Hinkelman, - IBM
Michael Kass, NIST
Jong.L Kim, – Innodigital
Kyu-Chul Lee, Chungnam National University
Sangwon Lim, Korea Institute for Electronic Commerce
Bob Miller, - GXS
Kunio Mizoguchi, - Electronic Commerce Promotion Council of Japan
Dale Moberg, – Sterling Commerce
Ron Monzillo, – Sun Microsystems
JP Morgenthal, – eThink Systems, Inc.
Joel Munter, - Intel
Farrukh Najmi, - Sun Microsystems
Scott Nieman, - Norstan Consulting
Frank Olken, – Lawrence Berkeley National Laboratory
Michael Park, - eSum Technologies
Bruce Peat, - eProcess Solutions
Mike Rowley, – Excelon Corporation
Waqar Sadiq, - Vitria
Krishna Sankar, - Cisco Systems Inc.
Kim Tae Soo, - Government of Korea
Nikola Stojanovic, - Encoda Systems, Inc.
David Webber, – XML Global
Yutaka Yoshida, - Sun Microsystems
Prasad Yendluri, - webmethods
Peter Z. Zhoo, - Knowledge For the new Millennium
Table of Contents
[TO DOPENDINGTO DO] Authors 1
Abstract 1
Status of this Document 1
1 Introduction 4
1 Introduction 4
2 Web Services 4
A Web service is “a software system identified by a URI whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner described by its definition, using XML based messages conveyed by Internet protocols.” [WSA] 4
3 Relevant ebXML Registry Classes 4
A Web service can be represented 4
3.1 Class Service 5
3.2 Class ServiceBinding 6
3.3 Class SpecificationLink 7
4 Full SubmitObjectsRequest Example 8
5 Extended Scenarios 9
5.1 Versioning of Web Services 9
5.2 Associating a Web Service with an Organization 10
5.3 Associating a Web Service with an Access Control Policy 11
5.4 Registering a Service Description that is External to the Registry 12
5.5 Web Service Redirection 12
5.6 Customizing Metadata Using Slots 13
6 14
Appendix A WSDL Introduction 14
Appendix B OASIS/ebXML Collaboration-Protocol Profile and Agreement (CPP/A) Introduction 14
Appendix C DAML-S Introduction 15
1 Status of this Document 1
2 ebXML participants 2
3 Introduction 6
3.1 Summary of Contents of Document 6
3.2 General Conventions 6
3.2.1 Naming Conventions 7
3.3 Audience 7
3.4 Related Documents 7
4 Design Objectives 8
4.1 Goals 8
5 System Overview 8
5.1 Role of ebXML Registry 8
5.2 Registry Services 8
5.3 What the Registry Information Model Does 8
5.4 How the Registry Information Model Works 9
5.5 Where the Registry Information Model May Be Implemented 9
5.6 Conformance as an ebXML Registry 9
6 Registry Information Model: High Level Public View 9
6.1 RegistryEntry 10
6.2 Slot 11
6.3 Association 11
6.4 ExternalIdentifier 11
6.5 ExternalLink 11
6.6 ClassificationNode 11
6.7 Classification 11
6.8 Package 11
6.9 AuditableEvent 12
6.10 User 12
6.11 PostalAddress 12
6.12 Organization 12
7 Registry Information Model: Detail View 12
7.1 Interface RegistryObject 13
7.2 Interface Versionable 15
7.3 Interface RegistryEntry 15
7.3.1 Pre-defined RegistryEntry Status Types 17
7.3.2 Pre-defined Object Types 18
7.3.3 Pre-defined RegistryEntry Stability Enumerations 19
7.4 Interface Slot 19
7.5 Interface ExtrinsicObject 20
7.6 Interface IntrinsicObject 21
7.7 Interface Package 22
7.8 Interface ExternalIdentifier 22
7.9 Interface ExternalLink 22
8 Registry Audit Trail 23
8.1 Interface AuditableEvent 23
8.1.1 Pre-defined Auditable Event Types 24
8.2 Interface User 25
8.3 Interface Organization 26
8.4 Class PostalAddress 26
8.5 Class TelephoneNumber 27
8.6 Class PersonName 27
9 RegistryEntry Naming 28
10 Association of RegistryEntry 28
10.1 Interface Association 28
10.1.1 Pre-defined Association Types 29
11 Classification of RegistryEntry 31
11.1 Interface ClassificationNode 33
11.2 Interface Classification 34
11.2.1 Context Sensitive Classification 35
11.3 Example of Classification Schemes 36
11.4 Standardized Taxonomy Support 36
11.4.1 Full-featured Taxonomy Based Classification 36
11.4.2 Light Weight Taxonomy Based Classification 37
12 Information Model: Security View 37
12.1 Interface AccessControlPolicy 38
12.2 Interface Permission 39
12.3 Interface Privilege 39
12.4 Interface PrivilegeAttribute 40
12.5 Interface Role 40
12.6 Interface Group 40
12.7 Interface Identity 41
12.8 Interface Principal 41
13 References 42
14 Disclaimer 42
15 Contact Information 43
Copyright Statement 44
1 Status of this Document 1
2 ebXML participants 2
3 Introduction 6
3.1 Summary of Contents of Document 6
3.2 General Conventions 6
3.3 Audience 6
3.4 Related Documents 7
4 Design Objectives 7
4.1 Goals 7
4.2 Caveats and Assumptions 7
5 System Overview 7
5.1 Role of ebXML Registry 7
5.2 Registry Services 8
5.3 What the Registry Information Model Does 8
5.4 How the Registry Information Model Works 8
5.5 Where the Registry Information Model May Be Implemented 8
5.6 Conformance as an ebXML Registry 8
6 Registry Information Model: Public View 9
6.1 RegistryEntry 10
6.2 Slot 10
6.3 Association 10
6.4 ExternalIdentifier 10
6.5 ExternalLink 10
6.6 ClassificationNode 10
6.7 Classification 11
6.8 Package 11
6.9 AuditableEvent 11
6.10 User 11
6.11 PostalAddress 11
6.12 Organization 11
7 Registry Information Model: Detail View 11
7.1 Interface Object 12
7.2 Interface Versionable 14
7.3 Interface RegistryEntry 14
7.3.1 Pre-defined RegistryEntry Status Types 16
7.3.2 Pre-Defined Object Types 17
7.3.3 Pre-defined RegistryEntry Stability Enumerations 18
7.4 Interface Slot 18
7.5 Interface ExtrinsicObject 19
7.6 Interface IntrinsicObject 20
7.7 Interface Package 20
7.8 Interface ExternalIdentifier 21
7.9 Interface ExternalLink 21
8 Registry Audit Trail 22
8.1 Interface AuditableEvent 22
8.1.1 Pred-defined Auditable Event Types 23
8.2 Interface User 23
8.3 Interface Organization 24
8.4 Class PostalAddress 25
8.5 Class TelephoneNumber 26
8.6 Class PersonName 26
9 Registry Entry Naming 26
10 Association of Registry Entries 27
10.1 Interface Association 27
10.1.1 Pre-defined Association Types 28
11 Classification of Registry Entries 29
11.1 Interface ClassificationNode 31
11.2 Interface Classification 32
11.2.1 Context Sensitive Classification 33
11.3 Example of Classification Schemes 34
11.4 Standardized Taxonomy Support 35
11.4.1 Full-featured Taxonomy Based Classification 35
11.4.2 Light Weight Taxonomy Based Classification 35
12 Information Model: Security View 36
12.1 Interface AccessControlPolicy 37
12.2 Interface Permission 38
12.3 Interface Privilege 38
12.4 Interface PrivilegeAttribute 39
12.5 Interface Role 39
12.6 Interface Group 39
12.7 Interface Identity 39
12.8 Interface Principal 40
13 References 41
14 Disclaimer 41
15 Contact Information 42
Copyright Statement 43
Table of Figures
Figure 1: Information Model Public View 9
Figure 2: Information Model Inheritance View 12
Figure 3: Example of Registry Entry Association 27
Figure 4: Example showing a Classification Tree 30
Figure 5: Information Model Classification View 31
Figure 6: Classification Instance Diagram 31
Figure 7: Context Sensitive Classification 34
Figure 8: Information Model: Security View 37
Table of Tables
Table 1: Sample Classification Schemes 35
1 Introduction
TestAn ebXML Registry provides a stable store where information submitted by a Submitting Organization is made persistent. Such information is used to facilitate ebXML-based Business to Business (B2B) partnerships and transactions. Submitted content may be XML schema and documents, process descriptions, Web services, ebXML Core Components, context descriptions, UML models, information about parties and even software components.
The purpose of this document is to provide a Best Practice for registering Web services and their associated entities in an ebXML Registry.
2
2.1 Summary of Contents of Document
This document specifies the information model for the ebXML Registry.
A separate document, ebXML Registry Services Specification [ebRS], describes how to build Registry Services that provide access to the information content in the ebXML Registry.
2.2 General Conventions
o UML diagrams are used as a way to concisely describe concepts. They are not intended to convey any specific iImplementation or methodology requirements.
o Interfaces are often used in UML diagrams. They are used instead of Cclasses with attributes to provide an abstract definition without implying any specific iImplementation. Specifically, they do not imply that objects in the Registry will be accessed directly via these interfaces. Objects in the Registry are accessed via interfaces described in the ebXML Registry Services Specification. . Each get method in every interface has an explicit indication of the attribute name that the get method maps to. For example getName method maps to an attribute named name.
o The term “repository item” is used to refer to an object that has been submitted to a Registry for storage and safekeeping (e.g. an XML document or a DTD). Every repository item is described by a RegistryEntry instanceThe term “repository item” is used to refer to actual Registry content (e.g. a DTD, as opposed to metadata about the DTD). It is important to note that the information model is not modeling actual repository items.
o The term “RegistryEntry” is used to refer to an object that provides metadata about a content instance (repository item).
o The term “RegistryObject” is used to refer to the base interface in the information model to avoid the confusion with the common term “object”. However, when the term “object” is used to refer to a class or an interface in the information model, it may also mean RegistryObject because almost all classes are descendants of RegistryObject.
The information model does not containdeal with any elements that are the actual content of the Registry (repository item)repository. All eElements of the information model represent metadata about the content and not the content itself.
Software practitioners MAY use this document in combination with other ebXML specification documents when creating ebXML compliant software.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
2.2.1 Naming Conventions
In order to enforce a consistent capitalization and naming convention in this document, "Upper Camel Case" (UCC) and "Lower Camel Case" (LCC) Capitalization styles are used in the following conventions
· Element name is in UCC convention
(example: <UpperCamelCaseElement/>).
· Attribute name is in LCC convention
(example: <UpperCamelCaseElement lowerCamelCaseAttribute="Whatever"/>).
· Class, Interface names use UCC convention
(examples: ClassificationNode, Versionable).
· Method name uses LCC convention
(example: getName(), setName())
Also, Capitalized Italics words are defined in the ebXML Glossary [ebGLOSS].
2.3 Audience
The target audience for this specification is the community of software developers who are:
o Implementers of ebXML Registry Services
o Implementers of ebXML Registry Clients
2.4 Related Documents
The following specifications provide some background and related information to the reader:
ebXML Registry Business Domain Model [BDM] - defines requirements for ebXML Registry Services
a) ebXML Registry Services Specification [ebRS] - defines the actual Registry Sservices based on this information model
b) ebXML Collaboration- Protocol Profile and Agreement Specification [ebCPPA] (under development) - defines how profiles can be defined for a pParty and how two pParties’ profiles maymay be used to define a pParty agreement
c) ebXML Business Process Specification Schema [BPMebBPSS]
d) ebXML Technical Architecture Specification [ebTA]
3 Design ObjectivesWeb Services
A Web service can be defined as is ““a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner described by its definition, using XML based messages conveyed by Internet protocols.” [WSA]Goals
The goals of this version of the specification are to:
o Communicate what information is in the Registry and how that information is organized
o Leverage as much as possible the work done in the OASIS [OAS] and the ISO 11179 [ISO] Registry models
o Align with relevant works in progress within other ebXML working groups
o Be able to evolve to support future ebXML Registry requirements
o Be compatible with other ebXML specifications
3.1 Caveats and Assumptions
The Registry Information Model specification is first in a series of phased deliverables. Later versions of the document will include additional functionality planned for current and future development.. The characteristics, capabilities, and requirements of a Web service can be described and published, thereby enabling automatic discovery and invocation of the service by automatic means. ; however, the Service description that is registered can be in any format[1]One mechanism by which thiese descriptions can be published is in an ebXML Registry.
The most common mechanism for describing Web services today is the Web Services Description Language, or WSDL [WSDL]; however, the Service description that is registered can be in any format such as OASIS/ebXML Collaboration-Protocol Profile and Agreement (CPP/A [ebCPP/A]) or the emerging DAML-S [DAML-S].