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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

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


Subject: Re: [wsrp-interop] Re: Oracle producer throwing fault ongetServiceDescription



I also agree that the reference Subbu cites is an inconsistency. The key points are:
  Registration portType exposed => In-band registration supported
  requiresRegistration metadata flag => states whether all other operations will require a valid registrationHandle

Rich Thompson



Subbu Allamaraju <subbu@bea.com>

08/11/2003 10:39 AM

       
        To:        wsrp-interop@lists.oasis-open.org
        cc:        
        Subject:        Re: [wsrp-interop] Re: Oracle producer throwing fault on getServiceDescription



David,

You convinced me, and I agree that the reference I mentioned is not
consistent (although there is no conformance statement associated) with
the references you pointed out.
Regards,

Subbu

David Ward wrote:
> Subbu
>
> This is indeed a misleading phrase in the spec, which seems to imply
> "!requiresRegistration => !(registration supported)" [Read "A => B" as
> "implies", i.e. "if A then B"]. However, this is not the part of the
> spec which specifies the meaning of the requiresRegistration flag, so
> shouldn't be taken too literally.
>
>  From the definition of requiresRegistration:
>
>     requiresRegistration: A boolean indicating whether or not the
>     Producer requires Consumer registration. If requiresRegistration is
>     set to “false” then it MUST be valid to not pass a
>     RegistrationContext parameter to all operations with this parameter.
>     If requiresRegistration is set to “true” then the Producer MUST
>     return a fault message when no RegistrationContext is supplied to an
>     operation, other than getServiceDescription(), which takes this field.
>
> So we definitely have "requiresRegistration => registration supported",
> which is logically equivalent to "!(registraion supported) =>
> !requiresRegistration", but it still doesn't state the converse, so it
> is still valid for us to assume registration is supported when
> !requiresRegistration.
>
> Also, from the description of the registration port type
>
>     A Producer that supports in-band registration of Consumers exposes
>     the optional registration interface.
>
> This also seems to imply that if the interface is exposed by the
> producer, the producer supports registration (whether or not
> requiresRegistration is set).
>
> So could someone from the TC please clarify that it is wrong for a
> Consumer to assume "!requiresRegistration => !(registration supported)"
> and perhaps think about fixing the reference that Subbu mentions?
>
> Dave
>
> Subbu Allamaraju wrote:
>
>> Could you point me to the spec where this is specified? From page 52,
>> line 25,
>>
>> "the Producer’s metadata declares registration is not supported (i.e. 25
>> requiresRegistration flag was set to “false”), ..."
>>
>> it is quite valid to interpret that the producer is indicating that it
>> does not support registration by setting this flag.
>>
>> Regards,
>>
>> Subbu
>>
>>
>> David Ward wrote:
>>
>>> If your producer has a registration port, our consumer will call it.
>>> Registration is still allowed by the spec when requiresRegistration =
>>> false. If you don't want our consumer to register you, you will have
>>> to remove the registration port from your WSDL.
>>>
>>> Regards
>>>
>>> Dave
>>>
>>> Subbu Allamaraju wrote:
>>>
>>>> Thanks.
>>>>
>>>> On a related note, we tried to register our producer with your
>>>> consumer. The producer we deployed does not support registration
>>>> (hence returns false for requiresRegistration) and throws a fault
>>>> when register() is called. But Oracle consumer is always trying to
>>>> call register() after getting service description.
>>>>
>>>> Regards
>>>>
>>>> Subbu
>>>>
>>>> David Ward wrote:
>>>>
>>>>> The schema doesn't define registrationHandle as nillable, therefore
>>>>> it is invalid to send xsi:nil for the registrationHandle. The
>>>>> registrationHandle should be ommitted altogether if it is not set.
>>>>>
>>>>> I guess this is what is tripping up JAX-RPC.
>>>>>
>>>>> Regards
>>>>>
>>>>> David
>>>>>
>>>>> Subbu Allamaraju wrote:
>>>>>
>>>>>> David,
>>>>>>
>>>>>> I'm getting a server fault when our consumer is trying to get
>>>>>> service description. Details are below.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Subbu
>>>>>>
>>>>>> Request >>>>>>>>>>>>>>>>
>>>>>>
>>>>>> Content-Length      369
>>>>>> User-Agent     BEA WLP 8.1
>>>>>> SOAPAction     urn:oasis:names:tc:wsrp:v1:types:getServiceDescription
>>>>>> Content-Type     application/x-www-form-urlencoded; UTF-8
>>>>>> Accept     text/xml, application/xml, */*
>>>>>>     <soapenv:Envelope
>>>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
>>>>>>    <soapenv:Body>
>>>>>>       <urn:getServiceDescription
>>>>>> xmlns:urn="urn:oasis:names:tc:wsrp:v1:types">
>>>>>>          <urn:registrationContext>
>>>>>>             <urn:registrationHandle xsi:nil="true"
>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>>>>>>          </urn:registrationContext>
>>>>>>       </urn:getServiceDescription>
>>>>>>    </soapenv:Body>
>>>>>> </soapenv:Envelope>
>>>>>>
>>>>>> Response <<<<<<<<<<<<<<<<
>>>>>>
>>>>>> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
>>>>>>    <env:Body>
>>>>>>       <env:Fault>
>>>>>>          <faultcode>env:Server</faultcode>
>>>>>>          <faultstring>Internal server error</faultstring>
>>>>>>       </env:Fault>
>>>>>>    </env:Body>
>>>>>> </env:Envelope>
>>>>>>
>>>>>
>>>>> --
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> *David Ward*
>>>>> Principal Software Engineer
>>>>> Oracle Portal
>>>>>     Oracle European Development Centre
>>>>> 520 Oracle Parkway
>>>>> Thames Valley Park
>>>>> Reading
>>>>> Berkshire RG6 1RA
>>>>> UK    *Email:*     david.ward@oracle.com
>>>>> <mailto:david.ward@oracle.com>
>>>>> *Tel:*     +44 118 924 5079
>>>>> *Fax:*     +44 118 924 5005
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> ------------------------------------------------------------------------
>>>
>>> *David Ward*
>>> Principal Software Engineer
>>> Oracle Portal
>>>     Oracle European Development Centre
>>> 520 Oracle Parkway
>>> Thames Valley Park
>>> Reading
>>> Berkshire RG6 1RA
>>> UK    
>>> *Email:*     david.ward@oracle.com <mailto:david.ward@oracle.com>
>>> *Tel:*     +44 118 924 5079
>>> *Fax:*     +44 118 924 5005
>>>
>>>
>>>
>>
>>
>
> --
> ------------------------------------------------------------------------
>
> *David Ward*
> Principal Software Engineer
> Oracle Portal
>                  Oracle European Development Centre
> 520 Oracle Parkway
> Thames Valley Park
> Reading
> Berkshire RG6 1RA
> UK                  
> *Email:*                  david.ward@oracle.com <mailto:david.ward@oracle.com>
> *Tel:*                  +44 118 924 5079
> *Fax:*                  +44 118 924 5005
>
>
>



You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php




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