You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gd...@macromedia.com> on 2001/07/25 17:47:24 UTC
Yesterday's chat log (07/24/01)
Welcome Nelson to the community!
Discussion about logging, the release, WSDl, getCurrentMessage, parsers....
Glen Daniels
Macromedia
http://www.macromedia.com/
Building cool stuff for web developers
wsdl output message parts
Posted by Richard Emberson <em...@contact.com>.
In wsdl:
portType/operation/output/@message is the name of a message
(message/@name). A message may have 0 or more part elements.
How does one represent in the soap java code representing the
client and server code a wsdl definition inwhich an output
has multiple return values, i.e.:
<message name="GetNameMsg">
<part name='first' type="xsd:string"/>
<part name='last' type='xsd:string'/>
</message>
<portType name='Name'>
<operation name='get'>
<output message='GetNameMsg'/>
</operation>
</portType>
Richard Emberson
wsdl output message parts
Posted by Richard Emberson <em...@contact.com>.
In wsdl:
portType/operation/output/@message is the name of a message
(message/@name). A message may have 0 or more part elements.
How does one represent in the soap java code representing the
client and server code a wsdl definition inwhich an output
has multiple return values, i.e.:
<message name="GetNameMsg">
<part name='first' type="xsd:string"/>
<part name='last' type='xsd:string'/>
</message>
<portType name='Name'>
<operation name='get'>
<output message='GetNameMsg'/>
</operation>
</portType>
Richard Emberson
href
Posted by Richard Emberson <em...@contact.com>.
I would assume that when the same object appears more than once in an
object
tree being serialized, that 'href' should be used.
I also assume that during deserialization that there are href's then only
one object (per id)
is created and placed in the tree of objects.
Java's builtin object serialization contains support for this notion. As
far as I can
tell neither soap 2.2 nor axis automatically detects multiple instances of
the same
object during serialization nor do they create only one object instance
during
deserialization.
Does such support exist in soap 2.2 and/or axis? Since such multi-reference
object
detection is not something that can be pasted on the outside of
serialization, is the
recommendation for anyone wish to avoid duplications to ......
Richard Emberson
href
Posted by Richard Emberson <em...@contact.com>.
I would assume that when the same object appears more than once in an
object
tree being serialized, that 'href' should be used.
I also assume that during deserialization that there are href's then only
one object (per id)
is created and placed in the tree of objects.
Java's builtin object serialization contains support for this notion. As
far as I can
tell neither soap 2.2 nor axis automatically detects multiple instances of
the same
object during serialization nor do they create only one object instance
during
deserialization.
Does such support exist in soap 2.2 and/or axis? Since such multi-reference
object
detection is not something that can be pasted on the outside of
serialization, is the
recommendation for anyone wish to avoid duplications to ......
Richard Emberson
href
Posted by Richard Emberson <em...@contact.com>.
I would assume that when the same object appears more than once in an
object
tree being serialized, that 'href' should be used.
I also assume that during deserialization that there are href's then only
one object (per id)
is created and placed in the tree of objects.
Java's builtin object serialization contains support for this notion. As
far as I can
tell neither soap 2.2 nor axis automatically detects multiple instances of
the same
object during serialization nor do they create only one object instance
during
deserialization.
Does such support exist in soap 2.2 and/or axis? Since such multi-reference
object
detection is not something that can be pasted on the outside of
serialization, is the
recommendation for anyone wish to avoid duplications to ......
Richard Emberson
Re: Yesterday's chat log (07/24/01)
Posted by Nelson Minar <ne...@monkey.org>.
An important thing to consider when generating proxies is that the
proxies are likely going to be pretty trivial. Just take the
arguments, stuff them into an Object[] array, invoke a static method,
and return/throw whatever comes back. This makes bytecode creation
quite simple, and means any ickiness about using reflection is
contained to one method invocation.
In the spirit of hackability, I would like it to be easy to override
Axis' default proxies for clients and substitute my own proxies. This
is a useful feature in java.rmi.
>Some of the tools I've come across are a number of ByteCode generators.
This is a nice way to do things if you don't have access to Java 1.3.
I know some proxy-using toolkits use dynamic proxies if you have them
in 1.3, otherwise fall back to bytecode generation.
The bytecode is simple enough that we may not need a big library to
create .class files - just write one by hand into a byte[]. I'm a bit
out of my depth here, though.
nelson@monkey.org
. . . . . . . . http://www.media.mit.edu/~nelson/
Re: Yesterday's chat log (07/24/01)
Posted by Pratik Patel <pr...@metalab.unc.edu>.
> Class SSLSocketFactoryClass = Class.forName("javax.net.ssl.SSLSocketFactory");
> Class SSLSocketClass = Class.forName("javax.net.ssl.SSLSocket");
> Method createSocketMethod = SSLSocketFactoryClass.getMethod("createSocket"
> new Class[] {String.class, Integer.TYPE});
> ...
This is a great hack - I was hoping for something that would actually allow actual method invocation that doesn't use .invoke(). The strong typing in Java prevents this, of course. Oh well, on to more constructive things....
On a wsdl-to-java tool:
Some of the tools I've come across are a number of ByteCode generators. I particularly like these because:
a.. using one means we do not have to bundle the JDK (license issues)
b.. can immediately output a .class file instead of first having to do a .java then compiling to .class
c.. we don't have the massive overhead of running a java compiler
d.. I think it would be much faster than calling the compiler
e.. It would be easier to code as we can build the .class file systematically while we walk the WSDL's tree
f.. it's just plain cool
I've already started experimenting with a byte code generator from:
http://opensource.go.com/Trove/index.html
thoughts?
-Pratik
Re: Yesterday's chat log (07/24/01)
Posted by Rob Jellinghaus <ro...@unrealities.com>.
At 06:31 PM 7/25/2001 +0100, Pratik Patel wrote:
>As far as I know, there is *no* way to do anything with a
>class/interface that doesn't exist at compile time. I'd love for you to
>prove me wrong :) as this would make what I'm trying to do with Apache
>SOAP a bit easier.
The trick is ugly as sin. It is just using Class.forName and standard
reflection to call methods on a class that is not explicitly imported. Of
course you get no type checking, and the class must be on your classpath at
runtime, and you must be in a situation that supports runtime class
loading. So you had better get it right!
For instance, this (abridged) code from Axis's HTTPSender.java:
Class SSLSocketFactoryClass = Class.forName("javax.net.ssl.SSLSocketFactory");
Class SSLSocketClass = Class.forName("javax.net.ssl.SSLSocket");
Method createSocketMethod = SSLSocketFactoryClass.getMethod("createSocket"
new Class[] {String.class, Integer.TYPE});
...
Object sslSocket = null;
if (tunnelHost == null || tunnelHost.equals("")) {
// direct SSL connection
sslSocket = createSocketMethod .invoke(factory,
new Object[] {host, new Integer(port)});
}...
Here, the code can make use of javax.net.ssl.SSLSocketFactory, without the
compiler compiling that class.
Cheers!
Rob
Re: Yesterday's chat log (07/24/01)
Posted by Richard Emberson <em...@contact.com>.
Got the answer from the powers-that-be concerning the code I have that can take
xmlschema file (*.xsd) or wsdl file (*.wsdl) and output
java class files (*.java) with serialization/deserialization code (for soap2.2)
and take
wsdl file (*.wsdl) and output
both client and server java proxy class files (*.java)
and take
wsdl file (*.wsdl)
and output
deployment descriptor files (*.xml)...
"we will discuss it further when he gets back from Europe in 2 1/2 weeks".
Richard Emberson
contact.com
Glen Daniels wrote:
> Welcome Nelson to the community!
>
> Discussion about logging, the release, WSDl, getCurrentMessage, parsers....
>
> Glen Daniels
> Macromedia
> http://www.macromedia.com/
> Building cool stuff for web developers
>
> ------------------------------------------------------------------------
> Name: #ApacheAxis.DALnet.20010724.log
> #ApacheAxis.DALnet.20010724.log Type: unspecified type (application/octet-stream)
> Encoding: quoted-printable
> Download Status: Not downloaded with message
Re: Yesterday's chat log (07/24/01)
Posted by Aleksander Slominski <as...@watson.ibm.com>.
> [12:34] <RobJ> It wouldn't quite make client proxies a snap -- you still
> have to write the stub generator for the interfaces implemented by the
> proxy object.
hi,
that is exactly right and you can take a look on SoapRMI on practical
implementation of such runtime - typical use case is:
Interface serviceRef = (Interface)
soaprmi.soaprpc.SoapServices.getDefault().createStartpoint(
"http://foo/service/location",
new Class[]{Interface .class},
"service/soap/action"
);
so basically as long as you have generated interface for service (and some
extra mapping if necessary to bind java interface to SOAP service
operations/xsd types) you create dynamic stub that implements it.
thanks,
alek
Proxies (was Re: Yesterday's chat log (07/24/01))
Posted by Henner Zeller <ze...@stud.fh-heilbronn.de>.
Hi,
PP| As far as I know, there is *no* way to do anything with a
PP| class/interface that doesn't exist at compile time. I'd love for you to
PP| prove me wrong :) as this would make what I'm trying to do with Apache
PP| SOAP a bit easier.
Depends how you put it. For _writing_ the proxy code, you don't need to
know the interface beforehand, so its possible to write this in Axis and
later use it. Of course, the _user_ obviously should know what interface
(s)he wants to call.
>From the users' point of view, he calls the proxy with one or more
Interfaces he wants to have implemented (at _this_ point of course, he
should know them, i.e. they should be available at compile time). And at
this time, the user knows what interface to call, because he writes the
application to use the WebService in the first place, right ?
If the user calls an function on this dynamically generated class, it is
dispatched by the proxy and call the InvokationHandler.invoke(...) method,
passing the function name and all the parameters needed. From this, its
easy to wrap this in s SOAP request. The SOAP result then is then simply
returned (that could as well mean, that an Exception is thrown).
It's pretty easy to write a Proxy; for an experimental SOAP
implementation(1), it took me less than an hour. And I must say, dynamic
proxies are the Coolest Thing(tm) in jdk 1.3!
ciao,
-hen
(1) I was experimenting with Iterators being serialized over the net. If
the last paramter of a function is an Iterator, or the return values
is an Iterator, it can already be read on the peer side while it is
still serialized on the other side. This allows for HUGE sequences to
be transmitted. On serialization level, an Iterator looks like an
Vector. A soon as I have time again (this was part of my master's
thesis I am still working on) I'll have a look how this can be
integrated into Axis. promised.
Re: Yesterday's chat log (07/24/01)
Posted by Pratik Patel <pr...@metalab.unc.edu>.
This is a snippet from the log:
[12:33] <NelsonM> It's just that Java 1.3 has a great in-memory proxy
facility that would make client proxy objects a snap.
[12:33] <DugD> grrrr
[12:33] <RobJ> There's a standard reflection trick for using 1.3+
classes without requiring them at compile time.
[12:33] <RobJ> And I would love to use the 1.3 proxies.
[12:34] <GlenDaniels> I'd prefer to have 1.2 work, but I have no problem
putting in optional 1.3 features, personally.
[12:34] <NelsonM> ok, cool. Just something to think about.
[12:34] <RobJ> It wouldn't quite make client proxies a snap -- you still
have to write the stub generator for the interfaces implemented by the
proxy object.
Will RobJ explain this a bit further please:
<RobJ> There's a standard reflection trick for using 1.3+ classes
without requiring them at compile time.
As far as I know, there is *no* way to do anything with a
class/interface that doesn't exist at compile time. I'd love for you to
prove me wrong :) as this would make what I'm trying to do with Apache
SOAP a bit easier. I'm trying to build a client side proxy (using 1.3's
dynamic proxy stuff) that can invoke a remote object (using SOAP)
*without* having to have the stubs beforehand. I know, this a useless
exercise, as people (inc myself) will be building using stubs anyhow,
but the challenge is there.
cheers
Pratik