Simon Nash wrote:
Millies, Sebastian wrote:
-----Original Message-----
From: Simon Nash [mailto:n...@apache.org]
Sent: Monday, November 21, 2011 7:42 PM
To: user@tuscany.apache.org
Subject: Re: Dynamic service references ?
[snip]
Thanks for confirming this. That's actually a more serious problem
because it violates the SCA specification requirement that service
references must support Java serialization and deserialization.
Please can you create a JIRA for this and if possible attach a
test case that shows the problem. If this isn't practical because
the problem only shows up when you're using SAP as the server, please
include all the client-side information including the composites and
bindings for the service reference. Please also include the XML string
that's produced when you serialize the service reference to XML.
I know very little about how authentication works, but I'll see if
I can spot anything when I see the additional information.
Simon
-- Sebastian
Hello Simon,
I have not been able to reproduce the original authentication error,
but instead get a WSDL generation error even during the
deserialization stage
(i. e. before making any service call) because no WSDL definition is
found for
the deserialized binding.
I attach modified versions of two Tuscany samples. In
helloworld-ws-service-secure
I have modified the definitions.xml to use
BasicAuthenticationPolicySet, as in my
original setup with SAP. In helloworld-ws-reference-secure I have
split the
HelloWorldService interface into a part referring to the external web
service,
and a part containing additional methods that attempt the remote call
while
first serializing the embedded reference. I have deleted the test class
just tested the Socket connection.
You can try starting the service component with "ant run" and then
manually
starting (no build target) helloworld.HelloWorldClientTestCase in the
client component.
This test case contains two new tests, one with "normal"
serialization, one with
your coding for explicit XML serialization.
I have added some elements to the composite file and some annotations
to the coding
(both hopefully redundant) in order to get clearer about the code
structure. (Did I ever
mention that I do not like frameworks inferring stuff on their own?
Just too much
opportunity for error through oversight, I much prefer saying it all
explicitly.)
I'll wait with opening any JIRA for this putative serialization
problem until you
have had time to have a look at this.
-- Sebastian
IDS Scheer Consulting GmbH
Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev
Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken,
Germany - Registergericht/Commercial register: Saarbrücken HRB 19681
http://www.softwareag.com
Hi Sebastian,
Thanks for doing this. I have reproduced the WSDL problem and I have
a theory (actually more like a wild guess) as to what may be wrong.
It will take me a little while to run a build and apply an experimental
change to see what happens. I'll keep you posted.
Simon
Hi Sebastian,
I'm making fairly good progress with this. Please can you create a JIRA
to formally document and track this issue, attaching your two zip files
that show the problem.
The deserialization code for service references is missing a few
important pieces. It does enough to work for the simplest case
of binding.sca with interface.java, but it doesn't work correctly
for binding.ws/wsdlElement or interface.wsdl. I suspect the same
applies for policies, but I haven't got quite that far yet.
I'm adding the missing pieces one by one. With each addition I get
further through the invocation code path and discover the next
missing piece.
One change that will be necessary in user code is to change the XML
deserialization call from
new ServiceReferenceImpl<SomeType>(xmlReader)
to
new ServiceReferenceImpl<SomeType>(SomeType.class, xmlReader)
This is necessary for a service reference with interface.wsdl because
there's no other way for the deserialization code to obtain a Java
interface from the WSDL interface in the XML. It isn't necessary
if the service reference uses interface.java. It also shouldn't be
necessary when using regular Java serialization/deserialization, as
the service reference can write out the necessary class information
when it's serialized.
Simon
