[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Eureka!
done,
we are now on: 80.138.161.43, nameservers are adjusted accordingly
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/17/2003 05:29 |
| | PM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Richard Jacob/Germany/IBM@IBMDE |
| cc: wsrp-interop@lists.oasis-open.org |
| Subject: Re: [wsrp-interop] Eureka! |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Thanks again. In the interests of interoperability, could you try forcing a
reconnect now, and we'll see whether our JVM recovers or not!
I assume our registration handle will still be valid (but the session
won't).
Dave
Richard Jacob wrote:
So we had two good guesses today :-)
In general dyndns is simple: you have one registered hostname.domain.
Everytime we get a new IP address associated we ask the dyndns server
(which is an implementation of dynamicDNS) to update our IP Address,
i.e.
the A record in the DNS database (we could also do it for MX records
and so
on).
Why we need this is because we have a standard internet provider over
adsl
which disconnects us after being online for 24 hours, thanks to some
linux
scripts :-) we discover that and reconnect immediatly - that's the
time
when we get a new address assigned.
I wonder that the JDK implementation doesn't handle the standard way
of
expiration handling in the domain name system. At dyndns we have a
very
short expiry set on our records so that secondary and caching name
servers
(and resolvers) drop that record and retrieve it again from the
authoritative DNS of the dyndns.org domain.
I can force a disconnect/reconnect if you want to test this now, just
let
me know...
This is a good point for the primer again, I think!
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/17/2003 04:21 |
| | PM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: David Ward <david.ward@oracle.com>
|
| cc: Richard Jacob/Germany/IBM@IBMDE,
wsrp-interop@lists.oasis-open.org
|
| Subject: [wsrp-interop] Eureka!
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
The problem was that the java.net.InetAddress class by default caches
IP
addresses forever once it has resolved them once. With a dynamic name
like
wsrp.dyndns.org, this was bound to cause problems - I gather that
your
server reassociates itself with a new IP address every so often.
(Don't
know exactly how dyndns works!)
If we were running on JDK 1.4, it appears we would be able to control
the
"time to live" for cached IP addresses through a security policy.
However,
it seems that the 'private' sun.net.inetaddr.ttl System property
mentioned
here also has the same effect on JDK 1.3.
I have restarted our servlet container JVM with the
sun.net.inetaddr.ttl
System property set to 120 (2 minutes). So far, the producer seems to
be
running fine on portalstandards.oracle.com. We'll just need to wait
and see
whether it remains so when you next acquire a new IP address!
I don't know whether it would be worthwhile including this useful gem
of
information in any of the WSRP literature - if you want your Java
consumer
to work with producers with dynamic IP addresses, be aware of these
settings.
Thanks
Dave
David Ward wrote:
Hi Richard
Thanks for investigating this. I've just realised how cool the
WS-I
testing tool is (the log file looked great once I installed all
the
XSL). I'll try to look into getting it installed on our
environment.
If you saw my previous message, you'll know that your theory
was
correct, and our proxy was the source of the problems we were
having
when the HTTP 1.0 Keep-Alive header was sent. It's only our
runtime
component that uses connection persistence (for the initCookie
/
getMarkup / performBlockingAction) calls, and it's only in our
internal testing environment where we need to use a proxy for
this
component. In the portalstandards.oracle.com environment, these
calls
do not need to be proxied.
The successful calls you have in your log file where the
connection
actually was persisted were made from the portalstandards
environment. Here we are experiencing a different problem - the
calls
only work when we register with an IP address rather than a
domain
name. This is weird, because I can ping and telnet to the
domain name
from the same machine with no problems. Any ideas?
Thanks again
Dave
Richard Jacob wrote:
Hi David,
what you state concerning HTTP keep-alive is correct.
I'll try
to summerize
and reword to check if we have the same understanding:
HTTP 1.0 is by default request/response oriented without
keeping the
connection open, thus every new request opens a new
socket and
closes this
after the resonse is received.
To keep the connection open among the request/response
messages, the HTTP
1.0 client sends a connection: keep-alive header. If the
server
supports
this it send a connection: keep-alive in the response to
indicate that the
connection is not closed and can be reused.
HTTP 1.1 remains the connection open by default. The
connection: keep-alive
is nearly meaningless in HTTP 1.1.
If the server wants to close the connection it sends
connection: close in
its response. If it doesn't do so, the connection is kept
open.
I checked the log files which monitored the conversation
between our
producer and your consumer and between our producer and
Citrix's consumer
(thanks Andre for driving that test).
See attached files, 8082 is Citrix, 8083 is Oracle.
(See attached file: log8082.xml)(See attached file:
log8083.xml)
In Citrix's case the keep-alive seem to work. Andre's
messages
start with
message 13, which is conversation 12. As you can see all
the
request/response up to message 66 are in the same
conversation,
i.e.
connection.
67 starts a new conversation (maybe because the client or
server decided to
close the connection in between).
In Oracle's case we see a lot of different connections
for each
request/response.
But interestingly messages 135-138 and 141-144 share the
same
connection.
Looking at 1-134 it seems that you use a proxy in between
for
the
conversation, see header:
Via: 1.1 inet-nc02 (NetCache NetApp/5.3.1R3)
In 135 you are using a direct connection (no via:
header).
That's a guess but maybe the proxy in between doesn't
support
keep-alive?
or is a 1.0 server?
Currently I have no idea why the connection is closed
after 138
and
reopened for 139/140 and then again for 141...
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/16/2003 10:12 |
| | PM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Richard Jacob/Germany/IBM@IBMDE
|
| cc: wsrp-interop@lists.oasis-open.org
|
| Subject: Re: [wsrp-interop] Verify
interoperability
with Oracle Portal
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
Richard
I am attaching the trace I got from a TCP tunnel when our
Portal tries to
make consecutive initCookie and getMarkup requests
through the
same pooled
TCP connection. After further investigation, I found that
the
"Keep-Alive"
value we send in the Connection header of the first
request is
actually
HTTP 1.0 semantics that can be ignored by an HTTP 1.1
server.
That's why it
doesn't appear in the second request. An HTTP 1.1 server
would
return
Connection: close if it doesn't want the connection to be
kept
open, since
the default is that the connection is kept alive. An HTTP
1.0
server would
set the Keep-Alive header on the response if it wanted
the
connection to be
kept open. Because we get an HTTP 1.1 response with no
Connection close
header, our client assumes it can keep the connection
open and
send another
request on it, but this doesn't seem to be working.
We are using the same HTTPClient library we have relied
on for
years (not
that that means it might not have bugs!). You can force
your
JVM to use it
instead of the regular JDK HttpURLConnection by setting
the
java.protocol.handler.pkgs system property to HTTPClient.
Thanks
Dave
David Ward wrote:
Hi David, thanks.
1. yes we have this namespacing issue still open
due to
the JSR168
container reference implementation.
Once this is changed on the container side we can
skip
the
namespacing
here.
2. strange, we tested with both AXIS HTTP1.0 -> no
keep
alive and
with
.NETs HTTP1.1 and keep alive set.
Citrix's consumer also sets the keep-alive flag.
Andre, can you confirm please, and rerun your
consumer
against our
producer
over the monitoring port (8082).
David could you also try to connect via the
monitoring
port 8083,
please.
Maybe we discover something.
I'll attach one WSI-monitor file showing a
conversation
between
Citrix and
IBM, here the keep alive seem to work. You should
have
the xsl files
(from
the WS-I monitor) placed in the directory "../xsl"
relative to your
log
file directory to generate a user-friedly output.
(See attached file:
log8082.xml.030606150200.xml)(See
attached file:
assertions.xsl)(See attached file: common.xsl)(See
attached file:
log.xsl)
(See attached file: report.xsl)
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/16/2003 11:37 |
| | AM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Richard Jacob/Germany/IBM@IBMDE
|
| cc:
wsrp-interop@lists.oasis-open.org
|
| Subject: Re: [wsrp-interop] Verify
interoperability with
Oracle Portal |
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
Thanks
I have altered our WSDL to reference
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_bindings.wsdl
in the import, and will make this fix available
when we
next patch
our
site!
We got the IBM portlet displaying, but there's a
few
glitches I want
to
talk about. I'll investigate further as soon as I
get the
chance,
but:
The portlet seems to be namespacing the input
fields in its
form. Is
this required?
The producer can't seem to cope with HTTP 1.1
keep
alive
behaviour -
we can only register the producer when we
turn off
connection
pooling
Regards
David
Richard Jacob wrote:
Hi David,
there is an absolut location for the wsdl.
You can find them here:
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_types.xsd
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_interfaces.wsdl
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_bindings.wsdl
See chapter 14 of the spec or the wsrp
group's
home page.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server
Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031
16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/12/2003 02:21 |
| | PM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Peter
Fischer3/Germany/IBM@IBMDE
|
| cc: Michael Freedman
<Michael.Freedman@oracle.com>,
wsrp-interop
<wsrp-interop@lists.oasis-open.org>
|
| Subject: Re: [wsrp-interop] Verify
interoperability
with
Oracle Portal
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
This is indeed a bug. We will need to fix the
WSDL
we return so
that
the
imports actually resolve to a location on our
webserver.
It would be useful if there was an absolute
location on OASIS
that
everyone
could use in their imports.
Regards
David
Peter Fischer3 wrote:
Hi Mike,
our consumer is having problems reading
the
wsdl you
provided.
It imports the binding wsdl like this:
<import namespace
="urn:oasis:names:tc:wsrp:v1:bind"
location="
wsrp_v1_bindings.wsdl" />
but at this location (realtive to
http://portalstandards.oracle.com/wsrp/jaxrpc?WSDL)no
such
document
can be
found.
Should a WSRP consumer be able to
handle that
by using a
local
version of
the wsdl or must the producer provide a
correct /
complete
wsdl?
Mit freundlichen Grüßen / Best Regards
Peter
"Don't think of the problem - think of
the
solution!" ;-)
___________________________________________________________________
IBM WebSphere Portal Development
Boeblingen,
Germany
Phone: ++49-7031-16-4497
eMail: peter.fischer@de.ibm.com
|---------+----------------------------->
| | Michael Freedman
|
| |
<Michael.Freedman@|
| | oracle.com>
|
| |
|
| | 06/10/2003 07:45
|
| | PM
|
| |
|
|---------+----------------------------->
>
-----------------------------------------------------------------------------------------------------------------------------|
|
|
| To: WSRP
<wsrp@lists.oasis-open.org>,
wsrp-interop
<wsrp-interop@lists.oasis-open.org>
|
| cc:
|
| Subject: [wsrp-interop]
Verify
interoperability with
Oracle Portal
|
|
|
|
|
>
-----------------------------------------------------------------------------------------------------------------------------|
As of yesterday, Monday June9th, Oracle
is
publically
hosting a
pre-release version of its portal
implementing the TC 1.0
WSRP
specification so other
vendors/customers can
verify their
implementations interoperate with
Oracle. By
making this
publically
available we hope to accelerate the use
and
implementation of
interoperable WSRP producers. The site
is
available at:
http://portalstandards.oracle.com.
Additonal supporting
information
is
available if you click on the "Go back
to
Oracle9iAS
Portal
Center"
link
on this sites welcome page. To use the
site
[to test
your
producer]
you
must be a logged in "Oracle Technology
Network" user.
Login
accounts
are free and available to all. Merely
click
on the
"login"
link in
the
upper right corner and either login to
an
existing
account or
sign up
for a new one. Once logged in you will
be
able to
register
your
producer(s) with the Oracle Portal and
add
portlets from
this
producer
to your own sandboxed portal page. The
site
contains
instructions on
how to do this as well as an existing
sample
page
containing
portlets
from the Oracle WSRP Sample Producer.
This
later is also
hosted
publically so other WSRP consumers can
test
if they
work/interoperate
with Oracle's WSRP/JSR 168 container.
The
WSDL for this
producer is
available at
http://portalstandards.oracle.com/wsrp/jaxrpc?WSDL
.
Though the site requests
problems/support
issues be
directed
to
discussion lists/support, we prefer you
use
the
wsrp-interop@lists.oasis-open.org
mailing
list to
communicate
questions/issues/problems. Dave and I
track
this list
more
closely
ensuring faster turn around on reported
issues.
-Mike-
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
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
--
|--------------------+---------------------------+-----------------------|
| |
|
|
| David Ward | Oracle European
|
|
| Principal | Development Centre
|
|
| Software Engineer | 520 Oracle Parkway
|
Email: |
| Oracle Portal | Thames Valley Park
|
david |
| | Reading
|
.ward |
| | Berkshire RG6 1RA
|
@orac |
| | UK
|
le.co |
| |
|
m
|
| |
|
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
--
|--------------------+---------------------------+-----------------------|
| | |
|
| David Ward | Oracle European |
|
| Principal | Development Centre |
|
| Software Engineer | 520 Oracle Parkway |
Email: |
| Oracle Portal | Thames Valley Park |
david |
| | Reading |
.ward |
| | Berkshire RG6 1RA |
@orac |
| | UK |
le.co |
| | |
m
|
| | |
Tel: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5079 |
| | |
Fax: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5005 |
| | |
|
| | |
|
|--------------------+---------------------------+-----------------------|
--
|--------------------+---------------------------+-----------------------|
| | |
|
| David Ward | Oracle European |
|
| Principal | Development Centre |
|
| Software Engineer | 520 Oracle Parkway |
Email: |
| Oracle Portal | Thames Valley Park |
david |
| | Reading |
.ward |
| | Berkshire RG6 1RA |
@orac |
| | UK |
le.co |
| | |
m |
| | |
Tel: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5079 |
| | |
Fax: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5005 |
| | |
|
| | |
|
|--------------------+---------------------------+-----------------------|
Listen Port: 2222
Target Host: wsrp.dyndns.org
Target Port: 8083
==== Request ====
POST /wsrp/wsrp4j/WSRPBaseService HTTP/1.1
Host: ukp16267.uk.oracle.com:2222
Connection: Keep-Alive, TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3
Oracle-ECID: 1055791210625ApplicationServerThread
SOAPAction: "urn:oasis:names:tc:wsrp:v1:initCookie"
Accept-Encoding: deflate, gzip, x-gzip, compress,
x-compress
Content-type: text/xml; charset="utf-8"
Content-length: 452
<?xml version="1.0" encoding="UTF-8"?>
<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>
<ns0:initCookie>
<ns0:registrationContext>
<ns0:registrationHandle>192.168.200.1_1055790421716_9</ns0:registrationHandle>
</ns0:registrationContext>
</ns0:initCookie>
</env:Body>
</env:Envelope>
POST /wsrp/wsrp4j/WSRPBaseService HTTP/1.1
Host: ukp16267.uk.oracle.com:2222
Connection: TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3
Oracle-ECID: 1055791210625ApplicationServerThread
Cookie: JSESSIONID=5934EF2F75DD19FA504553E09B8C2527
SOAPAction: "urn:oasis:names:tc:wsrp:v1:getMarkup"
Accept-Encoding: deflate, gzip, x-gzip, compress,
x-compress
Content-type: text/xml; charset="utf-8"
Content-length: 2360
<?xml version="1.0" encoding="UTF-8"?>
<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>
<ns0:getMarkup>
<ns0:registrationContext>
<ns0:registrationHandle>192.168.200.1_1055790421716_9</ns0:registrationHandle>
</ns0:registrationContext>
<ns0:portletContext>
<ns0:portletHandle>0.192.168.200.1_1055790532049_10</ns0:portletHandle>
<ns0:portletState/>
</ns0:portletContext>
<ns0:runtimeContext>
<ns0:userAuthentication>wsrp:password</ns0:userAuthentication>
<ns0:portletInstanceKey>253_34169_253_1_1</ns0:portletInstanceKey>
<ns0:namespacePrefix>
__ns253_34169_253_1_1_</ns0:namespacePrefix>
</ns0:runtimeContext>
<ns0:userContext>
<ns0:userContextKey>DXWARD4[1]</ns0:userContextKey>
</ns0:userContext>
<ns0:markupParams>
<ns0:secureClientCommunication>false</ns0:secureClientCommunication>
<ns0:locales>en-gb</ns0:locales>
<ns0:mimeTypes>text/html</ns0:mimeTypes>
<ns0:mimeTypes>text/xml</ns0:mimeTypes>
<ns0:mimeTypes>text/vnd.oracle.mobilexml</ns0:mimeTypes>
<ns0:mode>wsrp:view</ns0:mode>
<ns0:windowState>wsrp:normal</ns0:windowState>
<ns0:clientData>
<ns0:userAgent>Mozilla/4.0
(compatible;
MSIE 6.0;
Windows NT 5.0; Q312461)
RPT-HTTPClient/0.3-3</ns0:userAgent>
<ns0:extensions>
<oracle:GenericExtension
xmlns:oracle="
http://xmlns.oracle.com/portal/wsrp/v1">
<ns0:NamedString name
="X-Oracle-Device.Orientation">
<ns0:value>landscape</ns0:value>
</ns0:NamedString>
<ns0:NamedString name
="X-Oracle-Device.MaxDocSize">
<ns0:value>0</ns0:value>
</ns0:NamedString>
<ns0:NamedString name
="X-Oracle-Device.Class">
<ns0:value>pcbrowser</ns0:value>
</ns0:NamedString>
<ns0:NamedString name
="X-Oracle-Device.Secure">
<ns0:value>false</ns0:value>
</ns0:NamedString>
</oracle:GenericExtension>
</ns0:extensions>
</ns0:clientData>
<ns0:navigationalState></ns0:navigationalState>
<ns0:markupCharacterSets>utf-8</ns0:markupCharacterSets>
<ns0:validNewModes>wsrp:view</ns0:validNewModes>
<ns0:validNewModes>wsrp:edit</ns0:validNewModes>
<ns0:validNewModes>wsrp:help</ns0:validNewModes>
<ns0:validNewWindowStates>wsrp:normal</ns0:validNewWindowStates>
<ns0:validNewWindowStates>wsrp:maximized</ns0:validNewWindowStates>
<ns0:validNewWindowStates>wsrp:minimized</ns0:validNewWindowStates>
</ns0:markupParams>
</ns0:getMarkup>
</env:Body>
</env:Envelope>
==== Response ====
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Mon, 16 Jun 2003 19:18:53 GMT
Content-Type: text/xml; charset=utf-8
Set-Cookie: JSESSIONID=5934EF2F75DD19FA504553E09B8C2527;
Path=/wsrp
Server: Apache Coyote/1.0
Via: 1.1 inet-nc01 (NetCache NetApp/5.3.1R3)
14c
<?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>
<initCookieResponse xmlns
="urn:oasis:names:tc:wsrp:v1:types"/>
</soapenv:Body>
</soapenv:Envelope>
0
HTTP/1.1 500 Server Error
Date: Mon, 16 Jun 2003 19:18:54 GMT
Content-Length: 263
Content-Type: text/html
Server: NetCache appliance (NetApp/5.3.1R3)
<HTML>
<!-- $Id:
//depot/prod/ontap/Rbrutus/prod/netcache/errors/500.html#1
$ -->
<HEAD>
<TITLE>500 Server Error</TITLE>
</HEAD>
<BODY>
<H1>Server Error</H1>
<H4>The following error occurred:
<P>Bad URL</H4>
<HR>Please contact the
administrator.</BODY>
</HTML>
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
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
--
|--------------------+---------------------------+-----------------------|
| | |
|
| David Ward | Oracle European |
|
| Principal | Development Centre |
|
| Software Engineer | 520 Oracle Parkway |
Email: |
| Oracle Portal | Thames Valley Park |
david |
| | Reading |
.ward |
| | Berkshire RG6 1RA |
@orac |
| | UK |
le.co |
| | | m
|
| | |
Tel: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5079 |
| | |
Fax: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5005 |
| | |
|
| | |
|
|--------------------+---------------------------+-----------------------|
--
|--------------------+---------------------------+-----------------------|
| | |
|
| David Ward | Oracle European |
|
| Principal | Development Centre |
|
| Software Engineer | 520 Oracle Parkway |
Email: |
| Oracle Portal | Thames Valley Park |
david |
| | Reading |
.ward |
| | Berkshire RG6 1RA |
@orac |
| | UK |
le.co |
| | | m
|
| | |
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
--
|--------------------+---------------------------+-----------------------|
| | | |
| David Ward | Oracle European | |
| Principal | Development Centre | |
| Software Engineer | 520 Oracle Parkway | Email: |
| Oracle Portal | Thames Valley Park | david |
| | Reading | .ward |
| | Berkshire RG6 1RA | @orac |
| | UK | le.co |
| | | m |
| | | Tel: |
| | | +44 |
| | | 118 |
| | | 924 |
| | | 5079 |
| | | Fax: |
| | | +44 |
| | | 118 |
| | | 924 |
| | | 5005 |
| | | |
| | | |
|--------------------+---------------------------+-----------------------|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]