wsrp-interop message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fw: Fault Messages
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp-interop@lists.oasis-open.org
- Date: Wed, 9 Jul 2003 15:11:33 -0400
Forwarding private comments for basis
of references.
Rich Thompson
----- Forwarded by Rich
Thompson/Watson/IBM on 07/09/2003 03:10 PM -----
|
| Stephan Laertz@IBMDE
05/22/2003 10:36 AM
|
To:
David Ward <david.ward@oracle.com>
cc:
Andre Kramer <andre.kramer@eu.citrix.com>,
Rich Thompson/Watson/IBM@IBMUS, Richard Jacob/Germany/IBM@IBMDE
From:
Stephan Laertz/Germany/IBM@IBMDE
Subject:
Re: Fault MessagesLink |
The specific codes from the spec do
not have a dot in their names. Only the accumulation of spefic code scoped
by the top level code.
But since this a potential for confusions
we could state something like that
2) The SOAP faultcode SHOULD be set to the
WSRP specific code scoped by the top level code being raised, namespace
qualified to be in the "urn:oasis:names:tc:wsrp:v1:types"
namespace.
MfG / Best regards,
Stephan Laertz
--------------------------------------------------------------------------
WebSphere Portal Server Development
IBM Deutschland Entwicklung GmbH
Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49 7031 16-3313 (*120 3313)
Email: Stephan.Laertz@de.ibm.com
---------------------------------------------------------------------------
|
| David Ward <david.ward@oracle.com>
22.05.2003 16:04
|
To:
Andre Kramer <andre.kramer@eu.citrix.com>
cc:
Stephan Laertz/Germany/IBM@IBMDE, Richard
Jacob/Germany/IBM@IBMDE, Rich Thompson/Watson/IBM@IBMUS
Subject:
Re: Fault Messages
|
RWould you consider giving a concrete example for 2) e.g.
<faultcode xmlns:types="urn:oasis:names:tc:wsrp:v1:types">types:Interface.InvalidCookie</faultcode>?
Also, I think the last sentence of 3) is confusing, as
the fault "codes" have dots in them, but the WSDL element names
don't.
Regards
Dave
Andre Kramer wrote:
Yes, I believe that maximizes interoperability.
We should still verify this by testing, but here is a recap
of the suggested spec errata / enhancements. With JAX-RPC bug
fixing, we can relax the "MUST be the only content" and ensure
the "fault code SHOULD be set to".
Chapter 13
1) P76 / 4
old text: WSDL
defines fault codes to be strings using "." as a delimiter
to scope the error codes.
new text: This spec defines fault codes
to be strings using "." as a delimiter to scope the error
codes.
2) P74 before table
new text:
The SOAP faultcode
SHOULD be set to the WSRP error code being raised, namespace qualified
to be in the "urn:oasis:names:tc:wsrp:v1:types" namespace.
3) P74 after (2)
new text:
The SOAP fault's
detail MUST contain the corresponding namespaced fault element from the
WSRP v1 WSDL. In order to maximize interoperability, this element
MUST be the only content in the fault detail element. Note that the
WSRP WSDL's fault element names are the specific codes from the following
table with "Fault" appended.
regards,
Andre
-----Original Message-----
From: David Ward [mailto:david.ward@oracle.com]
Sent: 22 May 2003 14:14
To: Andre Kramer
Cc: 'Stephan Laertz'; 'Richard Jacob'
Subject: Re: Fault Messages
So the detail part is going to be a MUST (must contain
the correctly namespaced element and nothing else) and the faultcode part
is going to be a SHOULD, meaning that ideally we should
have
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns0="urn:oasis:names:tc:wsrp:v1:types">
<env:Body>
<env:Fault xsi:type="env:Fault">
<faultcode>ns0:Interface.InvalidCookie</faultcode>
<faultstring>a meaningful description</faultstring>
<detail>
<ns0:InvalidCookieFault/>
</detail>
</env:Fault>
</env:Body>
</env:Envelope>
but we can get away with:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns0="urn:oasis:names:tc:wsrp:v1:types">
<env:Body>
<env:Fault xsi:type="env:Fault">
<faultcode>env:Server</faultcode>
<faultstring>oracle.webdb.wsrp.InvalidCookie</faultstring>
<detail>
<ns0:InvalidCookieFault/>
</detail>
</env:Fault>
</env:Body>
</env:Envelope>
Correct?
Regards
Dave
Andre Kramer wrote:
I just went back to the wsdl and the
fault *element* is actually called InitCookieFault.
Both the fault's complexType and element end in "Fault" and
the message part references the element, so I was wrong!
It is probably better not to make an wsdl changes at
this stage so let's go with <detail>
<xyz:InvalidCookieFault/></detail>?
regards,
Andre
-----Original Message-----
From: Stephan Laertz [mailto:Stephan.Laertz@de.ibm.com]
Sent: 22 May 2003 13:21
To: Andre Kramer
Cc: Andre Kramer; 'David
Ward'; 'Richard Jacob'
Subject: RE: Fault Messages
I managed to produce fault
messages like this.
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<soapenv:Fault>
<faultcode xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types">ns1:Security.InvalidRegistration</faultcode>
<faultstring>Consumer supplies
a registrationHandle/registrationState pair that is not recognized
by the Producer.</faultstring>
<detail>
<ns2:InvalidRegistration xmlns:ns2="urn:oasis:names:tc:wsrp:v1:types"/>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
But without renaming, in particular omitting the
suffix "Fault " from the name of the fault
types in the schema definition Axis will not
deserialize the exception since it seems that axis relies
on
the first detail child element for deserializing.
MfG / Best regards,
Stephan Laertz
--------------------------------------------------------------------------
WebSphere Portal Server Development
IBM Deutschland Entwicklung GmbH
Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49 7031 16-3313 (*120
3313)
Email: Stephan.Laertz@de.ibm.com
---------------------------------------------------------------------------
Below is the fault that I now create and catch with
.NET. If this is OK with us all, we should get
an errata (more an interop clarification) into
the spec and try it with the IBM producer?
regards,
Andre
<?xml version="1.0"
encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<soap:Fault>
<faultcode
xmlns:q0="urn:oasis:names:tc:wsrp:v1:types">q0:Interface.InvalidCookie</faultcode>
<faultstring>System.Web.Services.Protocols.SoapException:
NETlets
at NETlet.NETletServer.MarkupServer.getMarkup(getMarkup
getMarkup1, HttpContext Context, HttpSessionState
Session) in c:\inetpub\wwwroot\netlets\netletserver.cs:line
1447
at NETlet.NETletService.WSRP_v1_Markup_Binding_SOAP.getMarkup(getMarkup
getMarkup1) in C:\Inetpub\wwwroot\NETlets\NETletsService.cs:line
89</faultstring>
<faultactor>urn:citrix.com/netlets</faultactor>
<detail>
<InvalidCookie
xmlns="urn:oasis:names:tc:wsrp:v1:types"
/>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
-----Original Message-----
From: Andre Kramer
Sent: 22 May 2003 11:58
To: 'Stephan Laertz'; Andre
Kramer
Cc: David Ward; Richard Jacob
Subject: RE: Fault Messages
So that explains the "Fault"
ending on the trace you provided! I was going to come back
to that... This is a bug and should be reported to
Axis?
Is it possible to just
create a generic SOAP Fault and add a detail node by hand?
i.e. not using the fault class generated from the wsdl.
-- Andre
-----Original Message-----
From: Stephan Laertz [mailto:Stephan.Laertz@de.ibm.com]
Sent: 22 May 2003 11:44
To: Andre Kramer
Cc: David Ward; Richard
Jacob
Subject: RE: Fault Messages
I haven't found a way to generate
fault messages according to your approach with Axis.
I have no problem to handle
with namespaced and scoped fault codes.
But per default Axis always
adds an element wich is called after the fault type e,g.
<ns2:InvalidRegistrationFault xmlns:ns2="urn:oasis:names:tc:wsrp:v1:types"/>
to the detail element.
This means I can only have
a detail element with the first child element named
after the type and at least one other child element
which can be any other element I create
(e.g. <ns2:InvalidRegistration
xmlns:ns2="urn:oasis:names:tc:wsrp:v1:types"/>).
Our consumer relies on the first detail
element named after the type.
MfG / Best regards,
Stephan Laertz
--------------------------------------------------------------------------
WebSphere Portal Server Development
IBM Deutschland Entwicklung GmbH
Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49 7031 16-3313 (*120 3313)
Email: Stephan.Laertz@de.ibm.com
---------------------------------------------------------------------------
I think this unfortunately satifies neither
Dave or I fully.
My approach was to define fault codes
in our own (wsrp) namespace. This seems to have
become confused with soap's custom fault
codes. In particular both use a ".".
I now think that this is a SHOULD. i.e. the fault
code SHOULD be set to the values in Section 13.
The mention of WSDL in section 13 is wrong,
but I would still use the "."
to scope our (namespaced) fault/error codes.
I also worry that the <detail>
content model is too vague. We should make the messages
conform to a strict pattern. Especially
for faults like InvalidCookie that
we need specific handlers for. My thinking is to
add a MUST for interoperability: InvalidCookie and
InvalidSession faults MUST contain only one element
and this must be called InvalidCookie or Invalid
Session (respectively) and MUST be qualified with the
"urn:oasis:names:tc:wsrp:v1:types" namespace.
I'm going to spend some
time this morning checking that I can generate
appropriate fault details in .NET. Could you and Dave
see if we can meet the above SHOULDs and MUSTs?
regards,
Andre
-----Original Message-----
From: Stephan Laertz
[mailto:Stephan.Laertz@de.ibm.com]
Sent: 22 May 2003 08:37
To: David Ward; Andre
Kramer
Cc: Richard Jacob; Richard Jacob
Subject: Fault Messages
Hello
summing up the WS-I statements regarding
fault messages, I suggest to handle with fault
message like below.
R1000 When a MESSAGE contains
a soap:Fault element, that element MUST NOT have element
children other than faultcode, faultstring, faultactor
and detail.
> We do not have any
other elements.
R1002 A RECEIVER MUST accept fault messages
that have any number of elements,
including zero, appearing as children of the
detail element. Such children can be qualified or unqualified.
> We should not fail
if the <detail> element has any number of children
elements.
R1003 A RECEIVER MUST accept
fault messages that have any number of qualified attributes,
including zero, appearing on the detail element.
The namespace of such attributes can be
anything other than "http://schemas.xmlsoap.org/soap/envelope/".
R1031 When a MESSAGE
contains a faultcode element the content of that element
SHOULD NOT use of the SOAP 1.1 "dot"
notation to refine the meaning of the Fault.
It is recommended that applications
that require custom fault codes either
use the SOAP1.1 defined fault codes and supply
additional information in the detail element, or that they
define these codes in a namespace that is controlled by the
specifying authority.
> We should not use faultcodes
with "dot" notation like Interface.InvalidCookie.
Instead use faultcodes that are namespaced.
Since they recommend using
the detail element and most stacks use the detail
element to deserialize exceptions we should additionaly
provide the detail element, but
allow any number of childrens.
What I suggest is to provide both options :
a) provide namespaced faultcodes
b) have a detail element
Example:
<?xml version="1.0"
encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<soapenv:Fault>
<faultcode xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types">ns1:InvalidRegistrationFault</faultcode>
<faultstring>RegistrationHandle
'192.168.0.3_1053551289072_0' invalid on
this producer</faultstring>
<detail>
<ns2:InvalidRegistrationFault
xmlns:ns2="urn:oasis:names:tc:wsrp:v1:types"/>
<string>RegistrationHandle
'192.168.0.3_1053551289072_0'
invalid on this producer</string>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
MfG / Best regards,
Stephan Laertz
--------------------------------------------------------------------------
WebSphere Portal Server Development
IBM Deutschland Entwicklung
GmbH
Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49 7031 16-3313 (*120
3313)
Email: Stephan.Laertz@de.ibm.com
---------------------------------------------------------------------------
If we're going to start quoting WS-I, here's
some ammunition to back up my case.
It only suggests custom namespaced faultcodes as an alternative
to using the detail element and recommends using the detail
element.
4.1.6 SOAP Custom Fault
Codes
SOAP 1.1 allows custom fault
codes to appear
inside the faultcode element,
through
the use of the "dot" notation.
Use of this mechanism to extend the meaning
of
the
SOAP 1.1-defined fault codes can lead to
namespace
collision. Therefore, its use should be
avoided, as doing
so may cause interoperability issues
when the same
names are used in the right-hand side of
&! nbsp;
&nbs! p;
the
"." (d! ot) to convey different
meaning.
Instead, the Profile
encourages the use of the
fault codes
defined in SOAP 1.1, along with
additional information
in the detail
element to convey the nature of
the Fault.
&nbs! p;
!
Alternatively, it is acceptable
to
define custom fault codes in a namespace
controlled by
the specifying authority.
A number of specifications have already
defined
custom fault codes. Despite
this, their use in
future specifications is
discouraged.
Regards
Dave
David Ward wrote:
Another question below....
Andre Kramer wrote:
RE: IBM producer
David,
I believe any valid xml can go into the
detail so you may have an JAX-RPC bug.
But,
Peter & Stephan:
a) I expected the wsrp exception
name to be carried in the fault code (i.e. in
<faultcode> not <exceptionName>)!
e.g. using:
AxisFault f = new InvalidCookieFault();
f. setFaultCode( new
QName("urn:oasis:names:tc:wsrp:v1:types", "Interface.InvalidVookieFault"));
throw f;
b) I expect the "Interfaces." or
"Security." "Top Level" (chapter 13) as well
as the "Specific Code" (separated
by a '.') in the fault code.
JAX-RPC provides no control over the QName
used as the fault code - it's
always soapenv:Server. Is this a mandatory part
of the spec, and if so, why? Won't
most stacks deserialize the exception using
the typing of the contents of <detail>?
I'll try and catch a fault
once you have updated the producer.
regards,
Andre
-----Original Message-----
From: David Ward mailto:david.ward@oracle.com]
Sent: 21 May 2003 15:07
To: Stephan Laertz
Cc: Andre Kramer; Peter
Fischer3; Richard Jacob
Subject: Re: IBM producer
We still have a problem handling
your fault messages. This is what the
InvalidCookieFault generated by
your producer looks like:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server.generalException</faultcode>
<faultstring>Timeout of HTTP-session.
Consumer needs to
invoke initCookie() again.</faultstring>
<detail>
<ns1:InvalidCookieFault
xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types"/>
<ns2:exceptionName
xmlns:ns2="http://xml.apache.org/axis/">oasis.names.tc.wsrp.v1.types.InvalidCookieFault</ns2:exceptionName>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
Our problem is the exceptionName element
- our serializers don't expect
it so it trips them up. Does
the WSDL allow this?
Thanks
David
Stephan Laertz wrote:
>
> I'm glad it finally
works.
> The only difference
between the two display portlets is the
fact that
> they have different portlet sessions. Besides
that they are the same
>
> MfG / Best regards,
>
> Stephan Laertz
>
> --------------------------------------------------------------------------
> WebSphere Portal Server Development
>
> IBM Deutschland Entwicklung
GmbH
> Schoenaicher Str. 220, 71032
Boeblingen
> Phone: +49 7031
16-3313 (*120 3313)
> Email: Stephan.Laertz@de.ibm.com
> ---------------------------------------------------------------------------
>
>
>
>
> David Ward <david.ward@oracle.com>
>
> 21.05.2003 12:46
>
>
>
To:
Stephan Laertz/Germany/IBM@IBMDE
>
cc:
Andre Kramer <andre.kramer@eu.citrix.com>,
Richard
> Jacob/Germany/IBM@IBMDE, Peter
Fischer3/Germany/IBM@IBMDE
>
Subject:
Re: IBM producer
>
>
>
>
>
>
> It seems to be working well now. The
date portlet seems to change the
> cartoons displayed in the display
portlet and the action links
> increment portlet and application
counters. Is there any difference
> between the two display
portlets?
>
> Here's what it looks
like on Oracle Portal....
>
> Screenshot
>
> Regards
>
> David
>
> Stephan Laertz wrote:
>
> Hello,
>
> I have fixed most of the problems and it
works correctly with our
> consumer implementation.
>
> But still we have a setup problem on our
interop machine that keeps
> the portlet from connecting to the
dilbert site.
> For now I've enabled the local
mode for portlet 0.2 and 0.3. This
> means that clicking a date in the
date portlet won't change
> the picture displayed by the other
portlets.
>
> David, I could
not verify that our producer always sends a
session
> context with new ID. It does always send
a session context but keeping
> the ID of
> the established session. Even though I
have not testet HTTP/1.1 with
> keep-alive I wouldn't be surprised if
it doesn't work since we use
> Axis as SOAP stack.
>
> Best regards,
>
> Stephan Laertz
>
> --------------------------------------------------------------------------
>
> WebSphere Portal Server
Development
>
> IBM Deutschland Entwicklung GmbH
> Schoenaicher Str. 220, 71032
Boeblingen
> Phone: +49 7031 16-3313
(*120 3313)
> Email: Stephan.Laertz@de.ibm.com
<mailto:Stephan.Laertz@de.ibm.com>
> ---------------------------------------------------------------------------
>
>
>
>
> Andre Kramer <andre.kramer@eu.citrix.com>
> <mailto:andre.kramer@eu.citrix.com>
>
> 20.05.2003 13:40
>
>
To:
Stephan Laertz/Germany/IBM@IBMDE
>
cc:
>
Subject:
RE: testing IBM producer
>
>
>
>
>
>
>
> ok, I'll display portlet 0.1 and portlet 0.2
or 0.3 together. What's
> the difference between 0.2 and
0.3?
>
> regards,
> Andre
> -----Original Message-----
> From: Stephan Laertz
[mailto:Stephan.Laertz@de.ibm.com]
> Sent: 20 May 2003 12:27
> To: Andre Kramer
> Cc: david.ward@oracle.com
<mailto:david.ward@oracle.com>;
Peter
> Fischer3; 'Richard Jacob'
> Subject: Re: testing IBM
producer
>
>
>
> Hi Andre,
>
> comments below
>
> MfG / Best regards,
>
> Stephan Laertz
>
> --------------------------------------------------------------------------
>
> WebSphere Portal
Server Development
>
> IBM Deutschland Entwicklung GmbH
> Schoenaicher Str. 220, 71032
Boeblingen
> Phone: +49 7031
16-3313 (*120 3313)
> Email:
Stephan.Laertz@de.ibm.com
> ---------------------------------------------------------------------------
>
>
>
>
> Andre Kramer <andre.kramer@eu.citrix.com>
> <mailto:andre.kramer@eu.citrix.com>
>
> 20.05.2003 12:44
>
>
To:
Stephan Laertz/Germany/IBM@IBMDE,
Peter
> Fischer3/Germany/IBM@IBMDE
>
cc:
Andre Kramer <andre.kramer@eu.citrix.com>
> <mailto:andre.kramer@eu.citrix.com>,
Richard Jacob/Germany/IBM@IBMDE,
> "'David Ward'"
<david.ward@oracle.com>
<mailto:david.ward@oracle.com>
>
Subject:
testing IBM producer
>
>
>
>
>
>
>
> Much better today! But I notice that
the wsp-mode rewrite token is
> called wsrp-Mode.
> <step>You're
right. Just a typo. Thanks</step>
>
> For portlet 0.1 (see
attached ibm0.3-action&mode), clicking a link
> now results in a performBlockingInteraction.
This sets the
> navigationalState to "none" but
seems to have no other impact, as
> the following getMarkup
returns the same table of date/links. What
> is the expected
behaviour?
> <step> Portlet 0.1
only writes something (a date string)
in the
> GroupSession. This
string is read by portlet 0.2 and
0.3 and used to
> fetch the dilbert comic of that
specific day (you clicked on in 0.1)
> from the dilbert site.</step>
>
> Also, calling getMarkup with
<mode>wsrp:edit</mode> causes
the
> "Error occurred while
invoking portlet service!" markup to get
> returned (only for
portlet 0.3).
> <step>I wonder
why this doesn't happen with 0.2. They have the
same
> code.</step>
>
> For portlet 0.2, I (see
attached ibm0.1) get the "Could not connect
> to Dilbert home page"
markup. I can now click on the "Edit" link
> (with a work around
for wsrp-Mode) to get to the edit mode
dialog,
> but:
> <step>I don't know why the portlet
cannot connect to the dilbert
> site. I will check
that.</step>
>
> - I do not know what
to enter for proxy host and
port.
> <step>These fields
can be used to enter the proxy server and port
> which are used by the
portlets to connect to the dilbert site.
>
You should not enter any values
here, unless you want to
> see what happens
if the portlet can not connect (The markup
you've
> seen already).
>
Once I've fixed some bugs you can
use this form to test
> form parameters and
namespacing.</step>
>
> - Checking
the "display a local Dilbert
image" and then Submit
> simply goes back to the
"Could not connect ... " markup.
> <step>Yes, I also recognized
this bug this morning. I'm still
> working on it. I'll let you
know!</step>
>
> Anything else I could be
testing?
> <step>I'm afraid no, as long
as I'm not finished working on that
> issues. I hope this will
be tomorrow.</step>
>
> regards,
> Andre
>
>
>
> #### ibm0.2.xml has been
removed from this note on May 20 2003 by
> Stephan Laertz
> #### ibm1.0-action&mode.xml
has been removed from this note on May 20
> 2003 by Stephan
Laertz
>
>
>
>
> --
> ------------------------------------------------------------------------
>
>
> 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
|
|
--
David Ward
Principal Software Engineer
Oracle Portal
| Oracle European Development Centre
520 Oracle Parkway
Thames Valley Park
Reading
Berkshire RG6 1RA
UK
|
|
--
David Ward
Principal Software Engineer
Oracle Portal
| Oracle European Development Centre
520 Oracle Parkway
Thames Valley Park
Reading
Berkshire RG6 1RA
UK
|
|
--
|
David Ward
Principal Software Engineer
Oracle Portal
| Oracle European Development Centre
520 Oracle Parkway
Thames Valley Park
Reading
Berkshire RG6 1RA
UK
|
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]