[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 successful registry in the world 3. Your agenda is to make UDDI registry be the best and most successful registry 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 UDDI. 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?'. DW.
Powered by eList eXpress LLC