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

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

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


Subject: RE: [uddi-spec] Status of JAX-RPC work


Title: RE: [uddi-spec] Status of JAX-RPC work

Rob,

 

I believe IBM has invested as much as any company in the development of the V3 UBR, but I also believe that this issue is too important to leave to V.Next.  I believe we have to resolve this issue before we standardize UDDI V3, which means that it has to be resolved in 3.0.2.

 

I think it is inevitable that further development work will be needed, both for the UBR and UDDI products, as we finish off 3.0.2 and go through the OASIS standardization process.

 

I have a different recollection of Mirek’s comments than you do but I will let him speak for himself (and Systinet).

 

John Colgrave

IBM

 

-----Original Message-----
From: Rob Kochman [mailto:robko@microsoft.com]
Sent: 18 April 2004 20:50
To: Rogers, Tony; Luc Clément; John Colgrave; uddi-spec@lists.oasis-open.org
Cc: Rob Kochman
Subject: RE: [uddi-spec] Status of JAX-RPC work

 

As those of you who were at the last FTF already know, I oppose adopting this CR because I believe it’s too late in the v3 process for such a significant change.  We (Microsoft) have already gone to great expense to develop and test our v3 UBR implementation, which is practically done.  As such, we would most likely have to oppose this CR’s adoption for the UBR.  Also, Mirek can correct me if I’m wrong, but I believe he said at the FTF that Systinet would not support this change in their v3 product.  Do we really want to introduce this kind of fragmentation within v3?

 

I understand the importance of Java support, so I wouldn’t oppose this change for v.Next if JAX-RPC can’t be fixed before then.  It’s just too late for this round.

 

-Rob

 


From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Sent: Saturday, April 03, 2004 12:47 PM
To: Luc Clément; John Colgrave; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Status of JAX-RPC work

 

Actually JAX-RPC's problem is simpler: it fails if the success message is the same as the object returned in a SOAP Fault. That was the original problem John set out to address.

 

The use of the empty message rather than one with constant content (which is essentially meaningless) is a separate issue, and one that I will graciously allow someone else to explain...

-----Original Message-----
From: Luc Clément [mailto:luc@iclement.net]
Sent: Sun 04-Apr-04 5:40
To: Rogers, Tony; 'John Colgrave'; uddi-spec@lists.oasis-open.org
Cc:
Subject: RE: [uddi-spec] Status of JAX-RPC work

Show me...

 

1. Perhaps I glanced too quickly, but I did not find evidence of "empty message" for "success without any significant return value" in the WS-I BP or SOAP

 

2. I'll accept as a given that JAX-RPC flames out in the presence of a non-empty message. Given that we are "adjusting the spec" due implementation-specific issues, did anyone verify that other implementations will not go catatonic in the presence of an empty response message?

 


From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Sent: Saturday, April 03, 2004 02:46
To: Luc Clément; John Colgrave; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Status of JAX-RPC work

Ya know, this was my initial reaction, prior to the FTF. However, at the FTF John (and others) was quite convincing that JAX-RPC will explode into a thousand flaming pieces (I think that's what they said, or it might have been a plague of locusts...) if anything other than an empty message is returned, so I guess we have to go along with them.

 

Apparently "empty message" for "success without any significant return value" is part of the WS-I Basic Profile, too.

-----Original Message-----
From: Luc Clément [mailto:luc@iclement.net]
Sent: Fri 02-Apr-04 11:58
To: 'John Colgrave'; uddi-spec@lists.oasis-open.org
Cc:
Subject: RE: [uddi-spec] Status of JAX-RPC work

John,

I reviewed the CR. I'm warming up to the idea of making this change though I
don't agree with your use of an empty message being returned which is to be
interpreted as "Success". If I understand your proposal correctly what you
intend to return is the following:

<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns="http://schemas.xmlsoaporg.org/soap/envelope/">
        <Body/>
</Envelope>

This is umbiguous; why not simply return a "uddi:result" element as follows:

<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns="http://schemas.xmlsoaporg.org/soap/envelope/">
        <Body>
                <uddi:result errno="0" xmlns="urn:uddi-org:api_v3">
                        <errInfo errCode=“E_success" />
                </uddi:result>
        </Body>
</Envelope>

This isn't any more work either on the server or client. Taking this
approach significantly improves testability; the test folks would not be
happy with <Body/>. This approach also does not require inventing a new
attribute -- it simply calls for the reuse of an existing one that allows
the response to be interpreted unambiguously yet satisfies JAX-RPC's
inability to map to Java an element that is used as both an output and a
fault.

Unless there are precedents to interpreting an empty SOAP:body element as
success, I ask that you change the CR to use the uddi:result element instead
of what you proposed.

Luc Clément
                                                        
Web:        www.iclement.net/luc 
Cell:         425.941.0150


-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Tuesday, March 23, 2004 08:27
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Status of JAX-RPC work

We said that we would revisit the JAX-RPC work I have been doing in March.

As I feared, the fact that dispositionReport is used for both normal success
responses and all faults causes incompatibilities in the code generated by
different JAX-RPC 1.1 implementations.

I have therefore submitted CR-046 which suggests restricting
dispositionReport to faults only.

I have a Technical Note ready describing the changes to the schemas that are
required, but there is no point in progressing it any further unless CR-046
is accepted as the handling of responses and errors affects every
method/operation in the JAX-RPC client interfaces.

John Colgrave
IBM




To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php.



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.



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