OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [regrep] Extramural Associations proposal

Message text written by "Farrukh"
2. My agenda is to make OASIS ebXML Registry be the best and most
registry in the world

3. Your agenda is to make UDDI registry be the best and most successful
in the world


If I could interject some cold hard thoughts here.

Spec's are great - but what drives this is implementations - and then
the adoption of those implementations for fielded solutions.

As an implementer of Registry solutions I see a clear separation - and
this is driven by user requirements.

a) I'm going to implement ebXML Registry functionality for all things
     to do with ebusiness transaction handling and application integration.

    I'm also going with ebXML message handling, business process and
    CPP underpinning.

    There is no way my customers are going to buy a proprietary solution,
     or even bits of one - in these mission critical areas.

b) In the arena of trading partner and service discovery my customers 
     would be interested in using a variety of sources - X500, Web Search,
     and UDDI.   I am interested in provided a smorgsborg of ability to
     do that - and standard web search tools and XML search tools are
     well equipped to do this by spidering and otherwise trawling these
     external sources.

c) UDDI, or more to the point WSDL, and associated varients provide a
     convenient language to express interfaces - beyond what ebXML
     TRP does.

Before anyone can go off claiming they have "the best widget", I think
we need to qualify this - by stating the use area - and more importantly
customers are going to buy based on strengths.

For instance - I recently went to Frederick Airshow (great day out BTW),
and there saw the worlds fastest truck.  A souped-up Mack truck, with
an F-111 jet engine strapped to the back so it can tear down a runway
at 300+ mph.  Just what I want for deliveries to my local grocery store.

It's time the UDDI folks stopped playing games.  I'm tired of this
world domination nonsense.

From day-one when the XML/edi Group talked up Registry - then we
saw first BizTalk.org and then XML.org trying to own this and then 

Users and customers are not fooled.  They know they need an
open standard that they can own their peice and participate 
openly there-in.

Equally they know they should not spurn commercial services
like UDDI that can add value.

I would like to see the UDDI folks issuing a clear unequivical
statement that they endorse ebXML, and that they intend to use 
and integrate ebXML business interaction services into their
deployment systems, and that their technical specifications
will be focusing on extending the ebXML model into web services
and providing extended collaboration tools.

Laugh not - a week from now events may well have actually
caused this by default....

Where appropriate UDDI should look to submit specifications
peices to ebXML - just like with the W3C - in the spirit of
openness and interoperability.

Now I know that certain facts exist - Microsoft <-> Sun and 
then some jockeying IBM <-> Sun vis UDDI et al.

Even more reason for a open process that is not 
behoven to anyone outfits' flavour of the season.

That's what we just demonstrated with the CCR / CRI work 
within eBTWG - neutral representations and means that
can be independently purposed are key to future
interoperability and upward functionality.

The market talks loudest - and when large corporations
buy a registry solution to drive their internal systems - the
criteria they set will be based on a long term vision and
careful anlysis.

We need to stay focused in ebXML Registry on providing
best-of-breed capabilities WITHIN a core sector - for me
that is always ebusiness integration primarily.  Now if 
someone wants to extend a little by repurposing - thats
fine - you can never stop that - but to outright attempt to
solve world hunger as well is not on the cards.

Having lots of choices in specifications is nice, but 
the bottomline is implementers are only writing code 
to those pieces that customers are requesting.

Both camps may want to pause and ask that
question 'Will anyone actually implement this, and
will anyone actually buy it from them?'.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC