[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: JSR-000093: JAXR - your opinions?
-----Original Message----- From: Bob Sutor [SMTP:firstname.lastname@example.org] Sent: Thursday, January 11, 2001 4:52 PM To: email@example.com Subject: JSR-000093: JAXR - your opinions? I would be interested in hearing the opinions of this group regarding the proposed JSR-000093 Java(TM) API for XML Registries 1.0 (JAXR) at http://java.sun.com/aboutJava/communityprocess/jsr/jsr_093_jaxr.html particularly because it includes as contributions ebXML Registry Information Model Specification and the ebXML Registry Services Specification. In particular, it raises again the issue of specific language bidings for XML-related specifications and who should do them (reminds me of the DOM), and how to deal with such bindings when the primary means of accessing an application is via XML messaging. Bob Sutor, IBM ebXML Vice-Chair ----------------------------------------- Bob: My take on it is this: 1. Most e-business application vendors (such as myself) will probably have to have some way to support interoperation with ebXML AND UDDI AND BizTalk AND RosettaNet AND ???, etc. etc. etc., unless they want to put all their eggs in one basket. As much as we would like to see there be only one "winner", it is unrealistic to expect it. We really don't have a choice. 2. Most e-business application vendors (heck, most software vendors) also do not want to limit themselves to one platform. Even though we have not yet achieved platform-independence Nirvana, Java is a heck of a lot closer to it than anything else I have ever seen. (IBM sure seems to understand this one!) 3. If there is a process we can join which helps us leverage a common API to do a small part of this job, it's probably a good idea. I know that I sure would rather write to a generic registry API than have to write to a separate one for each flavor of registry. Heck, I will have to build a common registry API layer myself, if no one else helps me it. <bob> "it raises again the issue of specific language bidings for XML-related specifications and who should do them " </bob> I'm not sure if you see a problem with the idea that there should be specific language bindings, or just with whether they should be developed under the JSR process. Or maybe you don't see a problem at all, but rather are just calling our attention to it. In any case, specific language bindings are inevitable - it is just a matter of whether we each invent our own or not. As far as whether the JSR process is the "right" place for it to happen, it seems to me to be as good as any. After all, it is a Java-specific issue, and it crosses the lines between all of the competing registry-like things going on. I wouldn't expect ebXML to take up the issue - it's an implementation detail, for one thing, and it's way out of scope for ebXML to write APIs for other initiatives. The same could be said for the UDDI folks, the BizTalk folks, etc. Where else is it going to get done? For anyone who is interested, I think the summary of the JSR is worth reading: ========================== This specification will describe Java API's designed specifically for an open and interoperable set of registry services that enable sharing of information between interested parties. The shared information is maintained as objects in a compliant registry. All access to registry content is exposed via the interfaces defined for the Registry Services. Currently there are numerous open standards for distributed registries. Examples include OASIS, eCo Framework, ebXML. In addition there also exists industry consortium led efforts such as UDDI which may eventually be donated to a standard body. JAXR will provide a uniform and standard API for accessing information from these registries within the Java platform. It is planned that this JSR will leverage work currently under way in the ebXML Registry Working Group, Oasis, ISO, W3C, IETF and potentially other relevant open standardsbodies. This JSR does not aim to define either business Registry standards, XML messaging standards or XML schemas for particular tasks. These standards belong in standards bodies such as OASIS or IETF. Instead this JSR aims to define standard Java APIs to allow convenient access from Java to emerging open Registry standards, such as the ebXML Registry standard. =========================== Joe Baran
Powered by eList eXpress LLC