ebXML Registry and Repository Business Requirements
- Last Updated: Wednesday, March 22, 2000
The ebXML registry and repository project team has defined the following business requirements for the creation and use of a registry and repository.
Category: Technical Specification Submission, Development, and Support
- Technical Specification Storage and Retrieval for Development and Runtime Views
- The business desires support for mapping templates, enabling a migration path from existing standards to future ebXML standards.
- Storage: The ability to store objects their original form, not limited to:
transaction definition, e.g., purchaseItem (transport group uses "exchange"?)
document definition, e.g., purchase order,
classification schemes,
ontology sub-trees,
trading partner profile instances,
code lists,
related data, example instances of document definitions, executable code, style sheets,
relationships between objects, e.g., storage of semantically equivalent objects
business models
A flexible workflow must exist to allow an existing specification to progress through varying sequences of classifications, e.g., progressing a company standard into an industry group and finally into an ebXML technical specification.
The business would like to know in what context data is being used in the business process, which may reside within the original package submission.
The business requires change management facilities.
The repository services should allow hooks into a variety of modeling and development tools.
The registry and repository will support a role-based security model
With a work request submission, the repository should be able to store and associated supporting materials in any electronic format, e.g., Powerpoint documents, audio files, images.
- Usage of data elements should be indexed across all the specifications and vertical domains in the repository.
Category: System Services
Required Services
:
Query services: the ability to send a request and retrieve results from a physical storage mechanism, e.g., exact or similar matches and navigation.
Workflow services: the ability to assign, route, sign-off, and define rules to support the workflow.
Logging services: the ability the store transactional and query events and metrics
Repository Interface Discovery service: the ability to expose (sub)set of ebXML interfaces implemented by a repository.
Quality Assurance Service: the ability to validate content based on its classification.
Desired:
- Transformation services: the ability to transform objects into another form. (e.g., IDEF-1X to XMI, XMI to XML Schema).
Category: Best Practices
- The design of a registry and repository should utilize existing software and standards that are already in place. (reuse-before-buy-before-build principle)
- The business would like to avoid reinventing the wheel, by reusing objects within the repository to construct new file specifications.
- The business would prefer names of items that are predictable, based on a formal scheme.
- The business would prefer version identifiers that are predictable, based on a formal scheme.