RE: [uddi-spec] Namespace management (corrected spelling)

[Daniel Feygin <feygin@unitspace.com>]

Max, TC,

I would group all the information artifacts you refer to as metadata,
which would help to differentiate it from business content.  As I
briefly mentioned in my previous message, UDDI is capable of storing
references to any metadata files using tModels, although it should be
explored what needs to be done to make service metadata more workable
and useful in UDDI.

It is possible that this can be adequately addressed with additional
guidance/use cases on the current capabilities of UDDI.  Another
possibility is to re-design everything related to tModels/metadata in V4
(or later), because tModels may be perceived as somewhat functionally
overloaded (and therefore overwhelming to the developer community) -
they are used for several *distinct* purposes ranging from
categorizations (real-world taxonomies) and Web service types (e.g.
WSDL) to system-specific concepts (as in owningBusiness and
isReplacedBy) and would-be metadata like schemas (e.g., XSD), process
definitions (e.g., BPEL4WS, WSCI) and other (possibly QoS, fail-over and
load-balancing alternatives, etc.).

It seems that tModels and keyedReferences were intended to be very
flexible so as to satisfy a broad range of unidentified future
requirements through modeling and gluing together of different features
entirely as tModels and keyedReferences.  Indeed they enable a great
variety of unforeseen circumstances and requirements to be addressed.
Now that many of these requirements have become known, perhaps it is
time for them to be modeled differently using more solid task-oriented
structures.

Daniel


> -----Original Message-----
> From: Max Voskob [mailto:mvoskob@msi.com.au] 
> Sent: Thursday, March 06, 2003 12:10 AM
> To: uddi-spec
> Subject: Re: [uddi-spec] Namespace management (corrected spelling)
> 
> 
> Daniel,
> 
> The information artifacts can be almost anything, e.g., XML 
> schemas, documentation, sample XML documents, WSDL files, 
> namespace identifiers, documents for ebXML (CPP, CPA, etc), 
> XML Topic Maps files, taxonomies, etc, etc, etc.
> 
> Web services do not exist on its own. If the webservice is as 
> simple as RPC then it's easy, but what if it's a complex one? 
> Let's say "CreateCustomer" web-service when a complex XML 
> document is passed onto the web-service and an even more 
> complex XML document is returned back. Those documents may 
> contain a dosen of infosets from different namespaces and so 
> on. Another example is a popular 360 degree view of customer 
> information (basically any information) where all entities 
> are described using XML Schemas and linked together to form 
> one enterprise- / government- /
> industry- / national - wide framework. (see the attached picture)
> 
> Take for example an e-Government. They adopt or produce 
> schemas for election, name, address, etc. These schemas, 
> again, form a framework.
> 
> The framework components are registered in the registry and 
> stored elsewhere. If I have a NS identifier I go to the 
> registry and find everything that relates to that NS ID, 
> including the schema, documentation for the schema, sample 
> XML files, who wrote it, who use it, what status of each 
> document is and all sort of other crucial information.
> 
> All those information artifacts still relate to web-services. 
> For example, a WS A recieves an XML document with 3 different 
> namespaces. The web service can deal with 2 only and then has 
> to pass the document to another web service for processing. 
> The WS A looks up the registry to find the webservice by at 
> say NS ID and get all the binding it needs to call it. I 
> think there can be a hundred of other runtime interaction example.
> 
> Web-services do not come on their own. They depend on many 
> other information artifacts that may be required for their 
> processing at runtime or development (design time). Speaking 
> of the multiple purposes I mean that for private registries 
> the content cannot be limited to just "business" and 
> "service". It is much broader than that.
> 
> Customers want to have one registry for all artifacts and do 
> not spread the $$$, time and effort across UDDI for WS, ebXML 
> registry for schemas and other stuff, Tibco for something 
> else and so on. Customers want one registry to rule them all.
> 
> Sorry, I'm not sure I expressed myself clearly. Please, let 
> me know if it's still confusing.
> 
> Cheers,
> Max
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: "Daniel Feygin" <feygin@unitspace.com>
> To: "'Max Voskob'" <mvoskob@msi.net.nz>; "'uddi-spec'" 
> <uddi-spec@lists.oasis-open.org>
> Sent: Wednesday, March 05, 2003 1:36 AM
> Subject: RE: [uddi-spec] Namespace management (corrected spelling)
> 
> 
> > Max,
> >
> > It could certainly make for an interesting discussion, particularly 
> > since it is substantiated by specific client references.  
> We do have 
> > UDDI managing WSDL registrations and there is really nothing 
> > technically preventing anyone from, say, registering process 
> > specifications or schema references in UDDI using tModels 
> (other than 
> > that there are no use cases or guidance for doing so in a 
> uniform and 
> > recognizable way).
> >
> > In terms of business content, I - and UnitSpace - see UDDI already 
> > being a registry of content *services*; these services are where 
> > business information entities can be discovered, retrieved and 
> > managed.  But there is a difference between maintaining service 
> > metadata and business content.  Extending UDDI to perform business 
> > content management would require substantial, though probably 
> > backwards-compatible, changes to the information model and 
> the API's.  
> > My fear is that most business content has a different profile that 
> > metadata with regard to security, applicable operations, functional 
> > role and target users, although that's debatable and perhaps a 
> > plausible alignment other than proposed above ("UDDI is a 
> registry of 
> > content services, which in turn manage content") is possible.
> >
> > I guess it would be helpful to understand more specifically what is 
> > being proposed for discussion.  My questions to Max 
> therefore are: 1. 
> > What sort of information artifacts are you referring to? 2. 
> > Specifically, what are the attempted multiple purposes of 
> using UDDI 
> > that you came across?
> >
> > Best regards,
> > Daniel
> >
> >
> > > -----Original Message-----
> > > From: Max Voskob [mailto:mvoskob@msi.com.au]
> > > Sent: Monday, March 03, 2003 9:52 PM
> > > To: uddi-spec
> > > Subject: Re: [uddi-spec] Namespace management (corrected spelling)
> > >
> > >
> > > Matthew,
> > >
> > > That's the problem. UDDI is being considered by many as a 
> registry 
> > > of informational artifacts for an enterprise. I'm one of them. :) 
> > > And UDDI is almost there! It's got a huge potential, much more 
> > > potential then any competing standard at the moment. All 
> we need is 
> > > a little effort to get the external taxonomies going and probably 
> > > add a couple more minor features without changing the concept. On 
> > > the other hand I can't see the consensus amongst the members to
> > > rephrase the purpose of UDDI.
> > >
> > > I personally came across quite a few cases where organisations 
> > > (incl. NZ Gov, OZ Gov) were seriously considering UDDI as a 
> > > multi-purpose registry. They did so not from misunderstanding of 
> > > UDDI, but from seeing a great potential in the standard and its 
> > > implementations.
> > >
> > > I would suggest to include it in the agenda of one of the 
> upcoming 
> > > telecons and discuss it openly, if the other TC members are 
> > > interested, of coz.
> > >
> > > Cheers,
> > > Max
> > >
> > >
> > > ----- Original Message -----
> > > From: "Matthew Dovey" <matthew.dovey@las.ox.ac.uk>
> > > To: "Max Voskob" <mvoskob@msi.net.nz>; "uddi-spec" 
> > > <uddi-spec@lists.oasis-open.org>
> > > Sent: Tuesday, March 04, 2003 4:16 AM
> > > Subject: RE: [uddi-spec] Namespace management (corrected spelling)
> > >
> > >
> > > This sounds like the problem space that metadata 
> registries and ISO 
> > > 11179 aim to address (see http://www.schemas-forum.org/ for a EU 
> > > project in this area).
> > >
> > >
> > > I'm pretty sure that this isn't a question that UDDI has 
> attempted 
> > > to tackle. I'm not entirely sure whether it is a question 
> that UDDI 
> > > should tackle - my undertanding is that UDDI is a directory of 
> > > WebServices rather than a universal directory for everything 
> > > Web/WebService related (but that's just my opinion)
> > >
> > > Matthew
> > >
> > > -----Original Message-----
> > > <snip>
> > >
> > > Imagine an organisation where 25 departments are creating 
> different 
> > > XML documents and formalise them with all sorts of documentation 
> > > including XML Schemas. How do they ensure that the new 
> namespace ID 
> > > they've just come up with is not already used somewhere 
> else within 
> > > the organisation? Sure, they can write a 25 page guide 
> how to name 
> > > their namespaces (if they can't they email me and I'll 
> write one for 
> > > them :), but it's hard to reinforce anyway.
> > >
> > > <snip>
> > > Can one do it using available UDDI means at the moment?
> > > I don't think so, but I can be wrong. Please correct me.
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> 
> 
> 
> --------------------------------------------------------------
> --------------
> ----
> 
> 
> 
> 


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>