e-Business Information Sharing (eBIS) Architecture Baseline
eBIS Team
April 3, 2000
Table of Contents
1. Overview_______________________________________________________ 1
2. eBIS Framework________________________________________________ 2
2.1. eBIS
Framework Services_____________________________________ 2
2.1.1. Acquire Services_____________________________________________ 3
2.1.2. Administer Services___________________________________________ 4
2.1.3. Distribute Services____________________________________________ 6
2.1.4. Life Cycle Management Services_________________________________ 7
2.2. eBIS
Framework Standards___________________________________ 8
2.3. eBIS
Framework Tools and Applications_______________________ 9
2.4. eBIS
People Skills___________________________________________ 12
2.5. eBIS Views___________________________________________________ 13
2.5.1. Process View_______________________________________________ 13
2.5.2. Data-Centric View____________________________________________ 13
2.5.3. Use Cases_________________________________________________ 15
3. eBIS Architecture Elements__________________________________ 15
3.1. Structure
Information Objects______________________________ 16
3.1.1. Associated Metadata Content___________________________________ 16
3.1.2. Content
- Content Objects and Metadata Objects___________________ 17
3.2. XML
Package_________________________________________________ 20
3.2.1. XML Packaging Mechanism___________________________________ 20
3.2.2. XML Packaging Processor_____________________________________ 22
3.3. Requestor
Mechanisms______________________________________ 23
3.4. Storage
and Access Mechanisms____________________________ 23
3.5. Registries___________________________________________________ 24
3.5.2. Other Internal or External Registries______________________________ 30
Table
of Figures
Figure 1 eBIS Framework___________________________________________ 2
Figure 2 eBIS
Core Services________________________________________ 2
Figure 3 eBIS
Framework Standards________________________________ 8
Figure 4 eBIS
Framework Tools and Applications____________________ 9
Figure 5 Tools
supporting Data Creations and Distribution_________ 10
Figure 6 Tool
Types supporting Portal distribution of data________ 11
Figure 7 eBIS
Framework People Skills____________________________ 12
Figure 8
Framework-Process View_________________________________ 13
Figure 9
Framework – Data View___________________________________ 14
Figure 10 eBIS
Elements Key Concepts_____________________________ 16
Figure 11
Associated Metadata Content___________________________ 16
Figure 12
Content Object__________________________________________ 17
Figure 13
Content Object composition_____________________________ 18
Figure 14
Metadata Objects_______________________________________ 18
Figure 15
Structured Information Objects_________________________ 19
Figure 16
Packing Mechanism for Content Objects and Metadata Objects 20
Figure 17
Assembled Data in Packaging Mechanism_________________ 21
Figure 18
Requestor Mechanisms__________________________________ 23
Figure 19
Storage and Access Mechanisms________________________ 23
Figure 20
Different types of registries____________________________ 25
Figure 21
Draft Framework Data Model of Clearing House Registries 26
Figure 22 eBIS
Centralized Clearing House Registry________________ 27
In order to set up an
e-Business Information Sharing (eBIS) environment there must be some way to
capture community agreements on the structure and types of data that
will be interchanged. There must be some agreement made on use of an
interchange syntax that is understood across a variety of platforms and applications. The World Wide Web Consortium
(W3C) has defined such a syntax: the Extensible Markup Language (XML). XML and its structure definition approach,
using either XML Document Type Definitions (DTDs) or XML Schemas fits these
requirements.
XML has become
widely embraced by the web and data interchange communities. XML has become the
defacto data interchange syntax to support e-business information sharing.
While there is general agreement on the use of XML to support an eBIS environment, there is no wide spread agreement on the structural parts of the Architecture that would enable such an environment. Many vendors, industry groups, and consortiums are proposing diverse visions for the architectural structures that will enable a company to enter fully into the e-business arena.
The Boeing eBIS Architecture Baseline is a vehicle to reach a common vision with Boeing's partners, customers, and suppliers on these structural parts. This baseline will also be used to reach a Boeing consensus in defining and deploying an eBIS Infrastructure.
Exploration and examination of differences in diverse visions will help The Boeing Company define architectural structures that will work best in our current computing environment to meet our business needs. Having an eBIS Architecture Baseline will help us better assess alternative e-business solutions in this area, now and in the future.
A team of Boeing architects has identified an initial eBIS Architecture Baseline that supports this type of exploration and examination. Described below are the structural parts of the eBIS Architecture Baseline:
· Framework
· Elements
· Core Data Services
· Conceptual Architecture and Use Cases
· Organization and Management Support Services
The eBIS Framework identifies 4 main services: Acquire Services, Administer Services, Distribute Services, and Life Cycle Management Services. These services are shown in more detail in figure 2.
These services support creation or
procurement of electronic information.
The information is packaged as structured information objects (SIOs),
which can be content objects or metadata objects in the eBIS environment.
Note: For more information on SIOs see
section 3.
Model Services provide:
· Model and schema definition service
· Taxonomy development service
· Mediation service for structures, tag semantics, tag use
· Mapping service between taxonomies, structures, and tags
Classification and Categorizing Services provide:
· Classification service for organizing SIOs per defined metatags or approved taxonomy categories (classification scheme)
· “Lookup” service for finding appropriate metadata structures (Schemas and DTDs) for use in categorizing SIOs
· Indexing service for SIOs (full text automated indexing, cross-referencing, etc.)
· “Lookup” service for searching through abstracts (summaries) of the SIOs
· Ranking service to determine the relevance of "found" SIOs; and as an aid to determine how to proceed
The Build/Procure services support the use
of consistent structure and content for SIOs when they are created or procured.
This consistency is needed for sharing SIOs among multiple applications in the
eBIS environment. These services operate
over and above the normal editing and formatting services found in any word
processing package.
Build and Procure services provide:
· Search and selection of resources (content or metadata objects) -- general or use specific
· Search and selection of appropriate version of a content object (with all the associated metadata) or metadata object.
· Assignment identifiers to content objects or metadata objects
Ø Appropriate or unique names,
Ø Unique qualifiers (namespace, date, etc.)
Ø Metadata within the appropriate ontology and schema.
Aid the creator in creating, updating, and
validating the content object or metadata object by enabling:
· Addition of structured information to the content object or metadata object under construction.
· Attachment or merger of structured information, content objects, or metadata objects to a content object or metadata object being updated or created.
· Generation in part or in whole, of content object or metadata objects through use of a form.
· Validation of the content of the content object to language rules (spelling, grammar, vocabulary (i.e. Simplified English)).
· Validation of the links to resources attached during the attach/merge processes.
· Establish relationships/associations between content objects and metadata objects.
·
Validation of the content of the metadata object to
established metadata rules.
Administer Services support identification, storage, and retrieval of SIOs, and provide summaries of SIOs for the user. Cataloging tools provide multiple views of SIOs to facilitate their creation, identification, storage, retrieval, and distribution.
Release/Register Services provide a
standardize method to ensures that the validation and release rules are met
before the content object or metadata object is registered for use or access.
Release/Register services provide:
· Validation that the structure of the object conforms to syntactic rules embodied in the DTD or schema
· Validation that the encoding format conforms to the formal syntactic rules
· Validation that the SIO's content is in conformance to value, range, or other data creation rules for objects of that type.
· Validation that the business rules, policies, and guidelines (e.g., appropriate Quality Control operations, reviews and approvals) have been followed before the content or metadata objects are made available for use.
· Status indicators for SIOs indicating their current state (in-work, in-test, deprecated, in-use, etc.).
Profile Services capture business rules or contractual agreements (profile metadata) about interchange of data or access to data.
Profile Services provide:
· Metadata definitions for such items as user role, application type, default modes of presentation, default uses, etc.
· Metadata definitions for timing conditions and quantity distributions, which must occur at a certain date or time intervals
· Support for the distribution or access to content SIOs by groups of users or applications.
Naming and Linking Services ensure that unique identifiers (name, version, and namespace) are assigned to content object and metadata objects and appropriate registries are updated.
Naming and Linking Services provide:
· URI Assignment mechanism
· SIO location aids
· Maintenance service for URI links to schema objects, metadata objects (descriptions, abstracts, and definitions), rules within registries, dictionaries, lookup tables, catalogs and directories
· URIs for objects
· Unique names
· Administration service for linking relationships/associations
Secure and Authenticate Services generate and validate security, authenticate, and integrity metadata based on established rules specific to an SIO or an SIO type.
Secure and Authenticate Services provide:
· Authentication and verification service for the identity of a user or a software process attempting to access a resource
· Access authorization service for entities such as users, user roles, programs, or processes access to system resources.
· Security disclosure service to ensure that data is not disclosed either intentionally or accidentally to unauthorized individuals, entities, or processes
· Change authorization service to ensure that no unauthorized changes are made to data or the system
· Monitor and alert service for system administrators regarding conditions that may violate established security measures.
· Security update service to ensure all the appropriate catalogs, directories, registries, logs, etc. contain the appropriate information reflecting the current security and authenticate values for the SIO or SIO type.
Integrity Services provide:
· SIO metadata configuration management service to ensure creation and modifications to SIOs are based on rules appropriate to the process being performed against it or based on configuration control rules. Ensures that:
Ø Versioning and control information on the SIO is updated per established rules.
Ø Transaction metadata information is updated to show which services have used the content object in its process. Business rules establish which content objects require this kind of transaction tracking.
Ø Only authorized access content objects or metadata objects is made by users, applications, or agents.
· Version control service to ensure all the appropriate catalogs, directories, registries, logs, etc. are updated with the appropriate information reflecting this creation or modification of an SIO.
Distribute Services ensure that the content object is delivered in the right format, in the right quantities, to the right people, at the right location, at the right time.
Push Service enables delivery of SIO to recipients.
Web Assembly Service supports the location, retrieval, transformation, and assembly of SIOs into a web-able delivery package.
Web Convert Service supports the transformation and rendering of SIOs for consumption by the recipient through the web.
Notify Service provides push notification that an SIO has been changed or re-located.
Subscribe Service provides the ability to
locate one or more SIOs meeting the criteria specified. Requests to locate SIOs
can be made on a subscription basis
Search Service provides the ability to lookup information based on default parameters. This service also provides notification when the content object has been found or is available for some use.
Filtering Service provides the ability for
users to customize the parameters that will be used to determine the space
(number of candidates, sublevels followed, areas of interest) that will be
searched based on criteria that is set by the searcher.
Life Cycle Plan Services make available SIOs for use and reuse for the specified period the object is deemed to have business value or a legal requirement for its existence.
Storage Services provide optimal physical placement of content objects on one or more servers that facilitate access and retrieval across a distributed environment.
Storage Services
provide:
· Determination of the appropriate/optimal storage location(s) for the SIO and the appropriate/optimal storage formats for the SIO.
·
Life cycle storage service to ensure that all the
appropriate catalogs, directories, registries, logs, etc. contain the
appropriate information in regard to the storage of SIOs.
Disposition Services remove SIOs from the web using established rules for this type of SIO.
Disposition Services provide:
· Backup service to copy the SIOs contained in active data stores into a backup data store.
· Retirement service to assign sunset dates on SIOs.
· Refresh service to maintain the SIOs in a format that is useable and accessible in the current computing environment.
· Disposition management service to ensure all the appropriate catalogs, directories, registries, logs, etc. contain the appropriate information in regard to the disposition of the SIOs.
· Retrieval and restoration service to move backup copies of SIOs from the appropriate short-term archive into a web accessible data store.
Disposal Services provide:
· Removal of SIOs from the web accessible data store.
· Disposal management service to ensure all the appropriate catalogs, directories, registries, logs, etc. contain the appropriate information in regard to the archival/disposal of SIOs.
·
Archive management service to package SIOs with all the
registry metadata and other appropriate metadata supportive of long term
archival.
Restoration Services provide:
·
Retrieval and restoration of archived copies of SIOs
from the appropriate long term archive into a web accessible data store.
·
Restoration management service to ensure all the
appropriate catalogs, directories, registries, logs, etc. contain the
appropriate information in regard to the restoration of SIOs.
The eBIS framework services are supported by a set of technical standards. A preliminary set of XML-based standards has been identified that need to be put in place as Boeing Architectural Standards Bulletins (ASBs).
Figure 3
eBIS Framework Standards
The eBIS framework services are supported by a set of tools and applications for data interchange. A matrix of these tools and applications has yet to be developed. The development of this matrix should be done in conjunction with already established companywide technical, process, and product standards. It should use processes and infrastructure established by the Architecture Sub-council of the Information Systems Process Council.
Figure 4
eBIS Framework Tools and Applications
The eBIS
tools and applications should:
·
Enable deployment
of eBIS services and architectural elements.
·
Make use of the
targeted technical standards.
·
Be lightweight and
have the capability of being rapidly reconfigured to support changing business
rules and technical models.
Figure 5
Tools supporting Data Creations and Distribution
Figure 6
Tool Types supporting Portal distribution of data
The appropriate groups within Boeing should be tasked to:
·
Prepare a matrix
software tools and prepare a Standard Software Services Offering Website to
describe:
Ø
Specifics about the
common tools
Ø
Use of common tools
Ø
Location of common
tools.
·
Prepare a Standard
Software Services Offering Website to describe:
Ø
Specifics about the
common tools
Ø
Use of common tools
Ø
Location of common
tools.
·
Define and enable:
Ø
Services to
exchange mechanism to share information between application
Ø
Transport mechanism
Ø
XML interfaces (for
each platform)
Ø Tools supporting eBIS processes (may make available on an enterprise-wide basis as required).
The appropriate groups within Boeing should be tasked of developing a matrix
of the eBIS people skills that would enable
deployment of eBIS services and architectural elements.
Figure 7
eBIS Framework People Skills
The
skills required are centered on understanding how to implement and use:
·
Targeted technical
standards.
·
Targeted tools and
applications
·
Targeted services
The following eBIS Framework Process View shows
how the eBIS services can support applications in a business process.
Figure 8 Framework-Process View
In this view, business processes make use of
common Administration, Distribution, and Life Cycle Management Services offered
by an eBIS Infrastructure. In effect, the business processes make use of an
eBIS Information Bus to move data from point to point. In our view, the eBIS
Architectural Services are distributed and can be utilized on an as needed
basis to support the business process. Processes can utilize the eBIS
"Bus" to flow the data into and out of Shared Storage and Access
Mechanisms and flow the data into whatever sequence of applications support the
processes.
Currently, there is limited coordination across
traditional stovepipe groups wanting to implement these core services at an
enterprise-wide level. The eBIS Business Unit coordination organization will
provide this coordination support to traditional stovepipe groups who are
desirous of building this eBIS "Bus".
The
following eBIS Framework view is data-centric.
Figure 9
Framework – Data View
Systems make use of a set of Core Data
Services to support the acquisition and administration of data. SIOs with their
associated metadata content are designed, built, and administered through a
combination of human or machine activities:
·
Locate resources
·
Design/model
structures
·
Make community
agreements on model and structures supporting sharing and interchange
·
Tweak existing
models and structures
·
Wire up and connect
structures
·
Build Content
Objects, Metadata Objects, and associated metadata content from structures and
available information
Content
Objects, Metadata Objects, and associated metadata content to support these
activities comes from internal and external sources.
The
human Acquisition and Administration service activities are coordinated through
and supported by a central service organization However; since the eBIS Architectural Services are distributed and can be
subscribed to separately, groups do not have to make use of all of these
services.
Current
organizations and systems provide a set of services in support of their
business processes. These traditional stovepipes make use of a set of Core Data
Services to distribute and collect data. These Core Data Services provided are:
·
Common Data
Collection Services
·
Common Data Access
Services
·
Common User
Interaction Services
·
Common Data
Interchange Services
Boeing is developing Use Cases to illustrate where and how XML might be used within the company. Additional Use Cases will be developed over time.
There are different categories of Use Cases:
Business Sharing and Interchange Scenarios
One to One - When one application or person is sharing or interchanging information with only one other application or person.
One to Many - When one application or person is sharing or interchanging information with two or more applications and/or people.
Many to One - When many are sharing or interchanging information with one application or person.
Many to Many - When many applications or people are sharing information or interchanging information with many other applications or people.
Infrastructure Scenarios
Registry and Authorization - Creating access profiles.
Data Conversion - Translate / Convert out of and into databases
Structure Conversion - Translation Mapping across applications
The eBIS architecture elements are:
· Structured Information Objects
o Content Objects
o Metadata Objects
· XML Packaging Mechanism
· Storage and Access Mechanisms
· Requestor Mechanisms
· Registries
Each will be explained in detail below.
Figure 10
eBIS Elements Key Concepts
Structured Information Objects (SIOs) are composed of some type of content and the associated metadata content. SIOs support the interchange or reuse of Content Objects and Metadata Objects.
Figure 11 Associated Metadata Content
Many different types of associated metadata content and structures may exist for a Content Object or Metadata Object at any given time in non-shareable databases, applications, and registries. When the metadata content associated with a content object or metadata object is made available for sharing or interchange, it must be in the XML syntax.
The associated metadata content is composed of one or more metadata structures. There is a XML Schema or XML DTD for each type of metadata content structure. The associated metadata content enables the Content Objects (non-XML structured or unstructured) and Metadata Objects (non-XML) to be self-describing. This self-describing quality is what enables use, reuse, and repurposing of the Content Object or Metadata Object in an XML-based eBIS environment.
The metadata associated to a Content Object or Metadata Object can used to populate the registry entries.
The benefit of separating the associated metadata content from the content object or metadata object is that the structures for these objects do not become overburdened with unnecessary structures. This may not be a problem when the information is tightly bound to the receiving system. Once the data needs to suit multiple users and multiple purposes the advantages of carrying the application or process specific metadata separate from the content become obvious. This is the design approach recommended in the eBIS Baseline.
The content can be either a Content Object or a Metadata Object.
A Content Object can be a document, a message, a document fragment, or some unit of information that needs to be shared. Content Objects contain information structured in XML. The Content Objects can be composed of other types of non-XML structured data such as SGML, HTML, X12 EDI, STEP Part 21, etc. Content Objects can be composed of unstructured data.
Figure 13 Content Object composition
Content Objects can be modules or fragments of information, SIOs, which make up a whole unit. Content Objects can be made up of collections of these modules and fragments. The associated metadata content would then contain information to indicate that the content object is made up of a module or fragment or collections of these modules and fragments.
Content Objects can be aggregations -- composed of XML and non-XML Content SIOs and/or Metadata SIOs. Such SIOs could be SVG graphics, XML files, RDF blocks, XSLT scripts, style sheets, CGM graphics, graphs, spreadsheets, etc.
How much of the metadata is packed into associated metadata content is a design decision that will have to be made. It is dependent on the processing, interchange, repurposing, and/or the storage requirements. It is also dependent on the business requirements.
Metadata Objects are specialized forms of content objects. Metadata objects must be some form of structured data either in XML or some non-XML format.
Some examples of Metadata objects are:
·
XML DTDs, XML
Schemas
·
Transformation
Scripts (into and out of), Architectural Forms
·
Stored procedures
to access/query/retrieve XML content against XML registry or registered
namespace databases
·
Templates, forms,
formulas, style sheets
·
Pointer to
Registries of external namespaces/databases containing XML content
·
Search/Semantic
Resources - catalogs, dictionaries, indexes, abstracts, vocabularies, glossary,
thesauri, ontologies, pointers to other registries --internal and external
domain authority/owner, Topic Maps, URLs, etc.
·
UML Models, Express
Models, SQL Schema Specifications
Figure 15 Structured Information Objects
These metadata objects support the use, creation, transformation of the Content Objects, other Metadata Objects, the associated Metadata content, and XML Packaging Mechanism.
Metadata objects support the modeling or classification of the Content Objects, Metadata Objects, and associated Metadata content.
How much of the metadata is packed into associated metadata content is a
design decision that will have to be made. It is dependent on the processing,
interchange, repurposing, and/or the storage requirements. It is also dependent
on the business requirements. Framework designers for OAG, Arriba, and Commerce
One have put the associated content into the DTD structure for the
content. The BizTalk Framework design
has placed this associated metadata data content into the packaging mechanism.
An XML Package enables the instantiation of a SIO (content object and its associated metadata content) with all the characteristics described in the previous section. The most important of these is enabling all variations of SIOs to look like a single “flavor” of SIO as it flows through the eBIS infrastructure. This consistency would enable a set of core-services to be established to handle the processing of these XML packages.
Currently there is no Packaging Mechanism defined by the W3C. Each IT supplier or Framework Definer (BizTalk, OAG, Commerce One, Rosetta Net, etc.) is employing their own packaging mechanism and strategy to satisfy similar requirements. We will have to deal with these multiple packaging solutions until a common mechanism and strategy is agreed upon.
The following text describes the eBIS requirements in an XML Packaging Mechanism.
Figure 16 Packing Mechanism for Content Objects and Metadata Objects
A Packaging Mechanism must be hardware- or software-independent packaging
mechanism therefore the XML syntax must be used. A Packaging Mechanism
must be able to support:
·
On-Demand Assembly
·
Repurposing
·
Interchange
·
Access and
Retrieval
·
Creation,
Maintenance, Deletion of Content
Objects and its associated Metadata
·
Creation,
Maintenance, Deletion of Metadata Objects and its associated Metadata
·
Long-term storage
·
Short-term storage
The design of a XML Packaging Mechanism must enable processors to:
· Identify, read, and handle the SIO's content (content object or metadata object) and associated metadata content with or without “bursting “ the XML Package.
· Identify the specific Schemas or DTDs used to create the various metadata units carried as associated metadata content .
·
Repopulate
registries and databases with the associated metadata.
The XML Packaging Mechanism must be able to contain aggregation of other packages. Large documents could be modularized into smaller units of associated metadata content and content objects. These smaller units, SIOs, could be repurposed into new assemblages of information.
Figure 17 Assembled Data in Packaging Mechanism
An XML Packaging Mechanism must be able to be nested within another XML Packaging Mechanism. The associated metadata would provide a packing list of the items placed in a single package. Therefore, Content Objects that are composed of aggregations (assemblies) of XML and non-XML data content and metadata objects can be encapsulated in an XML Packaging Mechanism.
An XML Packaging Mechanism must be able to contain multiple occurrences of the same data type. The associated metadata would provide a packing list of the items placed in single package. Therefore, aggregations of non-XML data content can be placed into a single Packaging Mechanism. For example, all 4000 CGM graphics for a Maintenance Manual could be encapsulated in one package.
A processor is any tool or application that is employed to read, use, or create XML packages. A processor must be able to:
· Identify that the content object is part of a set of specific Schemas or DTDs
· Add, modify, or delete the content object based on the specified Schemas or DTDs.
· Identify that the associated metadata content can make use of one or more specific Schemas or DTDs.
· Add, modify, or remove associated metadata content structured to/from a specific Schema or DTD.
· Add, modify, or delete XML Packaging Mechanisms within an XML Packaging Mechanism.
· Add, modify, or delete associated metadata content, packing list, for XML Packaging Mechanisms within the XML Packaging Mechanism.
· Access or process files in a XML Packaging Mechanism as a block or as single files.
· Add, modify, or delete aggregations of the same type in an XML Packaging Mechanism
· Add, modify, or delete associated metadata content, packing list, in an XML Packaging Mechanism.
· Add, modify, or delete associated metadata content belonging to a specific DTD or Schema.
Figure 18 Requestor Mechanisms
The Requestor mechanisms can be applications, software agents, people, role types, or groups. Requestor Mechanisms make requests to Registries and to Storage and Access Mechanisms. Metadata about these Requestor Mechanisms (i.e. authorization level) and its requests (i.e. XML or non-XML) are located in the appropriate registry. A processor is able to handle the request appropriately in combination with the content of the request and associated metadata contained in the Registry.
Figure 19
Storage and Access Mechanisms
There are multiple Storage and Access Mechanisms that enable access and
use of Content and Metadata Objects in an eBIS environment.
Types of Storage and Access Mechanisms
·
Enterprise Specific Repository
·
Domain Specific Repositories
·
External Group Specific Repository
·
Data Marts
·
Data Warehouses
·
Short- and
Long-Term off-line Storage
·
Websites.
These storage and access mechanisms are registered. The metadata
associated with these Storage and Access Mechanisms (i.e. location and access
method) are registered also. The objects contained within these storage
mechanisms can also be registered.
Registries will point to and will contain information about:
·
Registries and
their associated metadata
·
Requestor
mechanisms and their associated metadata
·
Access mechanisms
and their associated metadata
·
Storage mechanisms
and their associated metadata
Ø
Metadata objects
and their associated metadata
Ø
Content objects and
their associated metadata
· Tools and applications and their associated metadata
Figure 20
Different types of registries
Internal and external registries can be located and accessed by using the associated metadata stored in the Clearing House registries.
Figure 21 Draft Framework Data Model of Clearing House Registries
Figure 22 eBIS Centralized Clearing House Registry
The following are registries that need to be managed and maintained on an enterprise-wide level. These registries provide the centralized point from which tools, applications, requestor mechanisms can locate other registries, repositories, and other tools and applications. This list is not exhaustive.
A Global Namespace Registry contains:
·
An index of
uniquely named namespaces whether they are internal and external
·
The namespace owner
·
Any other
associated metadata content that would further identify the Namespace origin
and authority.
·
Pointer to the
Namespace Registry
·
Pointer to the
Namespace Repository
A <Name> Namespace Registry registers the models
and their elements for a unique namespace.
A <Name> Namespace
Registry contains:
·
An index of all DTDs
and Schemas contained in the <Name> Namespace Repository.
Ø
Defines the
official names for each DTD and schema within the repository.
Ø
Their status or
state for use (in work, in test, In production)
Ø
Life cycle
management information (creation date, owner, sunset date, etc.).
Ø
URI to it or the
repository where it lives
·
An index of all
metadata objects necessary for the use and understanding of the DTDs and
schemas (e.g. stylesheets, transformation scripts, etc. and examples on how to
use schemas).
Ø
Defines the
official names for each metadata object within the repository utilized by this
registry.
Ø
Their status or
state for use (in work, in test, In production)
Ø
Life cycle
management information (creation date, owner, sunset date, etc.).
Ø
URI to it or the
repository where it lives
·
Models of the
<Name> Namespace (UML, ER, Express)
·
Reference materials
for semantic understanding of the Namespace
Ø
Glossaries, Data
Dictionaries, and other information to provide semantic understanding of tags. Each tag name or element must be unique
within a namespace.
Ø
Rules and examples
on use the use of the DTDs and schemas
Ø
Boeing variations
and restrictions on use of external (industry or public) metadata objects.
Ø
Internal rules for
use of internal schemas.
·
<Name>
Namespace Management
Ø
Rules on how tags,
DTDs, schemas, or other metadata objects are maintained and added to the
namespace
Ø
Rules on how
namespace DTD, schema, or tag conflict resolution will be handled
Ø
Rules on delegation
of responsibility to assign something to the namespace
The DTD and Schema Registry registers all the XML DTDs and XML Schemas:
·
Authorized for use
within the Boeing Company. Note: Not
all DTDs/Schemas in a Namespace may be active or authorized for general use at
any given time.
·
Associated metadata
content that may help in search and retrieval.
·
Their status or
state for use (in work, in test, In production)
·
Life cycle
management information (creation date, owner, sunset date, etc.).
·
Namespace it
belongs to
·
URI where it lives
The Where Used Registry contains a registry which indicates where a DTD, schema, or
namespace is being used in repositories. It can contain mappings of which
documents point to or make reference to particular DTDs, schemas, or
namespaces. Examples of other where used mappings are:
·
Namespace by
DTD,
·
Information object
by information object
·
Metatag by DTD
·
DTD by document
The Equivalence Registry contains equivalent structures and names. It contains:
·
Equivalence mappings
from one model to XML e.g. EXPRESS to XML.
·
Equivalence
mappings within a namespace
·
Equivalence
mappings across namespaces
The
Transformation and Mapping Rules Registry contains
strongly typed transformation scripts and mapping rules. Scripts could have
data dictionary type explanations to support correct understanding and use. For
example the registry could contain:
·
Transformation
scripts from one tagged structure to another,
·
Rules to transform
date to date,
·
Scripts or rules to
transform employee record in native format to XML,
·
Scripts or rules to
transform PO for Westinghouse to PO for GE.
The Topic Map Registry contains style sheets for knowledge, which are views or
navigation paths through data particular to a group, use, or topic. One or more
topic maps may be created to remap or restyle the information or knowledge
presented in a repository or across a set of documents. The registry contains
all the topic maps:
·
Authorized for use
within the Boeing company
·
Associated metadata
content that may help in search and retrieval.
·
Their status or
state for use (in work, in test, in production)
·
Life cycle
management information (creation date, owner, sunset date, etc.).
·
Owner
·
URI where it lives
The following are registries that need to be managed and maintained on a group, domain, or project level. This list is not exhaustive.
The Instance Repository Registry contains an:
·
Index of documents
in repository. There is no restriction on the number of schemas and/or
referenced namespaces the repository or its documents can reference.
·
Associated metadata
content for the Instance Repository which provides the:
Ø
Location
Ø
Access methods
Ø
Authorization
levels required to access
Ø
Official name
Ø
Owner for the
Instance Repository
The Access and Roles Registry
contains:
·
Index of Requestor
Mechanisms
Ø
roles
Ø
role types,
Ø
software agents,
Ø
people,
Ø
groups
·
Authorization
levels for each Requester Mechanism assigned per types or classes of metadata
objects, content objects, associated metadata, registries, tools, application,
or repositories.
The Profile Registry
contains a registry of information that forms a profile of customer, supplier,
people, applications, agents, requirements that support the interchange of
information (e.g. information on address, contacts, delivery requirements,
handshaking).
The Tools and Applications Registry contains a registry of tools and applications and their
associated metadata.
The Requestor Mechanism Registry contains a registry of requestor mechanisms and their
associated metadata. Contains the structures for these requestors and
authorization levels.
The Storage Mechanism Registry contains a registry of storage and access mechanisms and their
associated metadata.