FW: [regrep] RE: [uddi-spec] ebXML Registry / UDDI Convergence

["Portillo, Christina" <christina.portillo@boeing.com>]

Posting email which bounced from previous send.

	Christina Portillo
	Advanced Computing Technologist
	Data Management Services - Architecture & eBusiness
	The Boeing Company               Phone: 206-544-7474
	PO Box 3707   M/S 2R-91        Fax:     206- 544-5889
	Seattle, WA  98124-2207                christina.portillo@boeing.com
	-----------------------
	xml.web.boeing.com
	xml.ca.boeing.com
	ebusiness on the web = XML + JAVA + Web + Controlled Vocabularies


-----Original Message-----
From: Portillo, Christina 
Sent: Friday, September 27, 2002 11:57 AM
To: 'uddi-spec@lists.oasis-open.org'; 'regrep@lists.oasis-open.org'
Cc: Breininger, Kathryn R; 'bellwood@us.ibm.com';
'lclement@microsoft.com'; 'mmealling@verisignlabs.com'
Subject: RE: [regrep] RE: [uddi-spec] ebXML Registry / UDDI Convergence


Respectfully submitted to the chairs of the UDDI and ebXML Registries:
I have sent this note to both list and both chairs of the UDDI and ebXML
registries in case my posting to your lists fails. Please post this to your
lists for discussion if I do not have permission to post. Thank you.

	DISCLAIMER: The thoughts below represent the current opinions of a
small team of architects focused on the larger eBusiness data sharing
collaboration needs. All the work and thoughts I reference are still very
much in a draft state and total consensus on these notions have not been
achieved in the architecture community. 

Proposal
I support the convergence of the ebXML and UDDI registry information model.
I see the need for the convergence of the IETF ideas (Michael Melling
mmealling@verisignlabs.com ) for a namespace registry information model into
this mix also.
<http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-registry-04.t
xt>

One registry model Discussion
Boeing architects are in the process of trying to find a way to make the
ebXML and UDDI model work to support web services and application
(conversion/Translation) processing work. I have been pulling together
functionality lists of the 2 specifications trying to see where the gaps and
overlaps are in regard to meeting the Data Sharing requirements of Boeing. 

 <<ebxml-UDDI-Comparison-020911.doc>> 
As you can see from the comparison list attached there are gaps in both
registry models and services which do not support the full range of required
functionality to support our eBusiness Collaboration model.

At a lower level the UDDI specification has addressed the need to register
the artifacts which support the management and use of 1 or more web services
within a domain or partition. At a slightly higher level the ebXML Reg/Rep
specification has addressed the need to register artifacts which support
transaction processing. 

There is a need for a higher level focus on the uses of a registry to
accommodate the thinking coming out of the UNCEFACT TWG. 

A business, enterprise, or consortium may be owners of one or more domains.
A domain may represent some area in the Business Operational View of a
business or a set of collaborating businesses. The UNCEFACT TWG (old EBTWG
old ebXML BP teams) see the importance of defining and registering the
artifacts that support the definition and model of a business domain which
may have one or more collaborations specified. All of the ebXML
specifications may generate a whole host of artifacts which need to be
shared in some public, private, or semi-private registry.

See slides 9-13, & 16 in the presentation David Welsh made to the NW EC/EDI
Roundtable in September http://www.ecnw.org/.
 <<Northwest-EC-Roundtable-Presentation-Sept-24.ppt>> 
We see the importance of registering information which would support the
partitioning, management, coordination, and evolution of a domain in respect
to the private and public aspects of this business process.

Based on all these needs a small team or architects sees the need for a
registry model which accommodates registration of:
	1. artifacts that support/define the modeling, semantics,
sequencing, collaboration of a business collaboration
	2. artifacts that support/define the transactions and messaging
	3. artifacts that define resources needed to support web services
(ala WSDL)
	4. artifacts that define resources needed to support
application/namespace processing (ala RDDL).
	5. namespace name (ala IANA or DNS) and have these registered
namespace names associated to documentation or other files which support all
of the above.
	6. artifacts that support/define the relationships of those
organizations which have a dependency on the artifacts in 1 & 2.
	7. artifacts that support/define the events to which these
organizations have a dependency in the business collaborations.
categorization schemes (ala REA and UDEF) which can help in classification,
relationship mapping, and dependency mapping of these many private,
semi-private, and public artifacts to a single domain or specification. Aids
to tying metrics or oversight to these.
	8. metrics on performance of services, models, collaborations,
.....to gauge the efficiency of the specifications in support the management
and further evolution of these specifications.
	9. network navigation schemes which make it easy to allow
specialized views of this information which is independent of the hardcoded
information model of the builders of the registry (needed to do federation)
which might be satisfied with pursuit of topic map enabling in registries.

We would like to see a registry model where all of these artifacts would be
stored in the registry with information model strategies between these
registries working as a single registry information model if not in fact
becoming a single registry architecture. I would like the appropriate
metadata elements of the WSDL and RDDL folded into the RIM. However, we
still see the need for the continuation specification of sets of Registry
Services targeted to specific audience such as:
*	web service interfaces between systems, 
*	business collaboration Modeling and analysis,  
*	business collaboration choreography & management, 
*	Namespace registration and, 
*	Domain (partitioning) ownership registration.

 <<ebXML-UDDI-Information-Models-020911.ppt>> 
The information model should be able to accommodate new thinking for
resource discovery coming out of the Semantic Web effort. We would like the
RIM and Registry services to be able to take advantage of the functionality
of navigation and discovery being specified in the Topic maps and RDF
specification accommodated into the registry architectures so all of these
could be architected to work on the same sets of information. We would like
to have a common resource discovery model that would support services,
applications, architects, business owners, customers, suppliers, and
partners in the need to analyze information.

Namespace Discussion
We suspect that we will have hundreds or thousands of namespaces specified
which may support one web service or a whole community of users (we call
them domains). 

We need a way to keep the user specific and application specific uses of the
namespace as a qualifying name independent of the uses of the namespace as a
categorization mechanism to establish the semantic and modeling definitions
of the set of information used by a domain to support data
interchange/sharing. The name of the namespace should be registered. It
should not point to any file. Files or records should point to it as a
categorization mechanism which may support different services in different
ways.

	"URI is a stable and a unique identifier. Once assigned it should
not be reused or altered in any way. 

	People and applications need to find out information about the
agreements and specifications which went behind the thought of establishing
this namespace. People could find the necessary information about a
namespace through location of information assets records and their
referenced objects registered in the registry. Location of these does not
require that the URI be resolved down to a URL or to a RDDL file. It
requires that standardized search criteria (metadata) be established to
locate the namespace via its domain association, domain type, categorization
terms, or its unique name. A namespace record gets handled pretty much like
registration of a domain. 

	The actual URL this namespace resolves to if required could be
handled via an indirection table (alias table) much like the identifier
http://xml.ca.boeing.com is resolved down to http://bruin.ca.boeing.com/xml/
is resolved down to http://nt-img-01.ca.boeing.com/xml/ which is further
resolved down to 132.224.203.174. There are tools and services in place that
run in the background which do the resolution. I question whether we are
setting ourselves up for problems by having the URI be used as a hardcoded
URL which resolves down to a single file.

	A registry can provide some of the support of  a DNS like registry
for uniquely naming/registering a namespace. But there are other tools that
need to be put in place which do the heavy lifting of the namespace
resolution down to a resource file or resource." 

The namespace registry  indirection table should point down to the resources
which:
*	provide the models, worksheets, collaborations, patterns, glossaries
providing semantic understanding
*	provide the resources needed by a web service (ala WSDL)
*	provide the resources needed by an application (ala RDDL)
*	provide the resources needed for navigation (topic map or RDF)
*	identify what belongs to that namespace
*	what has a dependency on that namespace
*	what metrics have been gathered about the functioning of that
namespace.

These in turn point back to their association to a namespace.

Hence I think what is needed in the registries is an architecture, a concept
of an indirection table, to help services or applications resolve a
namespace down to specific set of resources needed to support that
application or service whatever those might be. A namespace should be able
to support multiple application specific or service specific RDDL or WSDL
files all of which play nicely in that namespace or multiple namespaces. 

The ownership and the overall specification of the namespace boundaries
would be under the configuration control of the owner but would not tie the
hands of the users of the namespace to tightly to implement (or extend) the
specified structures given their different toolsets and platform.

 <<Services-Reg-Rep-020829.ppt>>  <<Namespaces-Reg-Rep-020813.ppt>> 

	Christina Portillo
	Advanced Computing Technologist
	Data Management Services - Architecture & eBusiness
	The Boeing Company               Phone: 206-544-7474
	PO Box 3707   M/S 2R-91        Fax:     206- 544-5889
	Seattle, WA  98124-2207                christina.portillo@boeing.com
	-----------------------
	xml.web.boeing.com
	xml.ca.boeing.com
	ebusiness on the web = XML + JAVA + Web + Controlled Vocabularies

Attachment: ebxml-UDDI-Comparison-020911.doc
Description: MS-Word document

Attachment: Northwest-EC-Roundtable-Presentation-Sept-24.ppt
Description: MS-Powerpoint presentation

Attachment: ebXML-UDDI-Information-Models-020911.ppt
Description: MS-Powerpoint presentation

Attachment: Services-Reg-Rep-020829.ppt
Description: MS-Powerpoint presentation

Attachment: Namespaces-Reg-Rep-020813.ppt
Description: MS-Powerpoint presentation