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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

[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:rss@sutor.com]
Sent:	Thursday, January 11, 2001 4:52 PM
To:	ebxml-regrep@lists.ebxml.org
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



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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC