You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Alex Homburg <al...@dackelgesicht.de> on 2001/05/03 16:00:48 UTC
proposal 4 a change in the RPCRouter
Hi all,
I had a hard time trying to use an interface in order to be able to use generic return values. As far as I'm concerned this is mentioned in the SOAP specs. in 5.3. However it won't work in Apache SOAP as long as we get the information via reflection. That's why I changed the folloing line (RPCRouter.java):
result = new Bean (m.getReturnType (), m.invoke (targetObject, args));
to:
Object methodInvoke = m.invoke( targetObject, args );
result = new Bean( methodInvoke.getClass(), methodInvoke );
Are there going to be any problems using this change? Please let me know!!!
Alex
Re: ANSI or Unicode ?
Posted by Scott Nichol <sn...@computer.org>.
Apache SOAP always sends messages as utf-8. The SOAP specification does not make this restriction. If your payloads only contain ASCII characters, of course, the utf-8 encoded stream is the an ASCII encoded stream, other than the encoding specified in the XML declaration.
Scott
----- Original Message -----
From: "Naggi Rao" <na...@softhome.net>
To: <so...@xml.apache.org>
Sent: Friday, May 04, 2001 12:42 PM
Subject: ANSI or Unicode ?
> Hi all,
> Can we use a ANSI Encoding for a SOAP Message (instead of utf-8)?
>
>
>
>
ANSI or Unicode ?
Posted by Naggi Rao <na...@softhome.net>.
Hi all,
Can we use a ANSI Encoding for a SOAP Message (instead of utf-8)?
Re: proposal 4 a change in the RPCRouter
Posted by Scott Nichol <sn...@computer.org>.
> I'm trying to say that when one has to implement one side of a SOAP protocol,
> that is the documented interfaces making up the possible calls advertised
> as been accessible through a SOAP service, one should have to worry about
> implementing the types defined by the protocol and not anything else.
> There shouldn't be any other types to implement, or implement serializers for,
> than the types defined in the methods defining the SOAP exported protocol (or
> service). This excludes subclasses of such types or specific classes
> implementing interfaces.
I agree with your point.
> If your customers are these remote implementors then it's going to cost you a
> lot more documenting the intricate implementation details of your side, most
> of which I'm willing to bet are irrelevant to the remote implementor anyway.
> (They may have such implementation details on their side as well and having to
> match your implementation types is going to make their task that much harder).
Maintaining the documentation is not that difficult, really, but you are correct that consumers of
the services are not always interested in the implementation details, as evidenced by the requests
for RPCs that use only simple types. I find it quite analogous to exporting database data for third
parties. I have often prepared extracts that are extremely denormalized, e.g. a 10- or 20-table
subject area is flattened out to a single file.
Scott
Re: proposal 4 a change in the RPCRouter
Posted by Andi Vajda <av...@nanospace.com>.
On Thu, 3 May 2001, Scott Nichol wrote:
> > Because of its language independance goal, one needs to limit the number
> > of implementation specific types circulating on the SOAP net and focus on
> > the protocol types instead.
>
> Hmmm. This I don't quite get. In what way does the number of types relate to language independence? The SOAP spec specifies the format of a struct that is language independent, so why should I restrict the number of structs I use? To what limit should I try to restrict myself? Will IBM and Microsoft likewise restrict themselves? Pragmatically, I agree that the more types I require you to handle as a consumer of my service, the less likely you are to actually become a consumer because of the work involved, but I do not view this as a language independence issue. I avoid the Java-specific types that Apache SOAP makes it so easy to use, like Vector and Hashtable, because they are not so much fun for programmers using other tools to deal with. But if I want to use types specific to my domain, such as Customer, Product or Location, I use them.
I'm trying to say that when one has to implement one side of a SOAP protocol,
that is the documented interfaces making up the possible calls advertised
as been accessible through a SOAP service, one should have to worry about
implementing the types defined by the protocol and not anything else.
There shouldn't be any other types to implement, or implement serializers for,
than the types defined in the methods defining the SOAP exported protocol (or
service). This excludes subclasses of such types or specific classes
implementing interfaces.
Of course depending on the needs of your SOAP service, there may have to be
many such types, but by limiting them to what's actually 'documented' in the
exposed protocol you're simplifying remote implentors' task.
> In my case, I don't use Java serialization because I don't have Java on both ends of the wire. The reason I want to serialize the actual run-time type rather than the interface type is that sometimes I do not want to lose the additional information available in the run-time type.
If you don't want to lose such information, then to make it clear to remotes,
you should expose the actual types as being part of the protocol or else
you're assuming that remote implementors have to know about the various
implementation details of your service, which may be difficult at best, unless
you're the remote implementor as well...
> Of course, just because I want to do something does not mean I always do it. This is the real world. The companies I work for could care less about what I want; they want to sell their products. I want to help them sell their products, as much as I hate to admit to being a capitalist. As such, many of my design decisions are based on the requests of customers, some of whom, as I've said, want messages that use nothing but simple types. The SOAP interfaces I work with every day have an increasing amount of redundancy. There are messages using nothing but simple types that are available for use by customers and messages performing similar functions using compound types that are available for both customers and internal, inter-product integration needs.
If your customers are these remote implementors then it's going to cost you a
lot more documenting the intricate implementation details of your side, most
of which I'm willing to bet are irrelevant to the remote implementor anyway.
(They may have such implementation details on their side as well and having to
match your implementation types is going to make their task that much harder).
Andi..
Re: proposal 4 a change in the RPCRouter
Posted by Scott Nichol <sn...@computer.org>.
> > Interesting. I rather mourn the loss of polymorphism and am more than willing to write serializers for all types I want to pass either direction in the call.
> >
> > I know of nothing in the SOAP spec that restricts polymorphism. Am I missing something? I believe WSDL, on the other hand, requires one to define the exact type of each parameter or return value, i.e. one cannot specify a list of actual types that a particular parameter may represent.
>
> You may be willing to write all the serializers but what about people
> implementing them in another language than the one you anticipated ?
I definitely agree with your point here. In fact, I have found that some people I work with do not want to have to write serializers at all. They want all values flattened out into simple types and arrays thereof, no structs at all. I do not blame them. They want to use the SOAP Toolkit's high level API and basically get SOAP connectivity automagically.
> Because of its language independance goal, one needs to limit the number
> of implementation specific types circulating on the SOAP net and focus on
> the protocol types instead.
Hmmm. This I don't quite get. In what way does the number of types relate to language independence? The SOAP spec specifies the format of a struct that is language independent, so why should I restrict the number of structs I use? To what limit should I try to restrict myself? Will IBM and Microsoft likewise restrict themselves? Pragmatically, I agree that the more types I require you to handle as a consumer of my service, the less likely you are to actually become a consumer because of the work involved, but I do not view this as a language independence issue. I avoid the Java-specific types that Apache SOAP makes it so easy to use, like Vector and Hashtable, because they are not so much fun for programmers using other tools to deal with. But if I want to use types specific to my domain, such as Customer, Product or Location, I use them.
> If a method is defined to return an interface
> then there should be a serializer for that interface instead of a serializer
> for each type implementing the interface. That way each and anyone is free
> to implement that interface on their end as they see fit.
> Of course, one could wish the opposite. It really depends on what side of
> the issue you are. If you want to ship all actual types then why not use
> java serialization instead ?
In my case, I don't use Java serialization because I don't have Java on both ends of the wire. The reason I want to serialize the actual run-time type rather than the interface type is that sometimes I do not want to lose the additional information available in the run-time type.
Of course, just because I want to do something does not mean I always do it. This is the real world. The companies I work for could care less about what I want; they want to sell their products. I want to help them sell their products, as much as I hate to admit to being a capitalist. As such, many of my design decisions are based on the requests of customers, some of whom, as I've said, want messages that use nothing but simple types. The SOAP interfaces I work with every day have an increasing amount of redundancy. There are messages using nothing but simple types that are available for use by customers and messages performing similar functions using compound types that are available for both customers and internal, inter-product integration needs.
Scott
Re: proposal 4 a change in the RPCRouter
Posted by Andi Vajda <av...@nanospace.com>.
> Interesting. I rather mourn the loss of polymorphism and am more than willing to write serializers for all types I want to pass either direction in the call.
>
> I know of nothing in the SOAP spec that restricts polymorphism. Am I missing something? I believe WSDL, on the other hand, requires one to define the exact type of each parameter or return value, i.e. one cannot specify a list of actual types that a particular parameter may represent.
You may be willing to write all the serializers but what about people
implementing them in another language than the one you anticipated ?
Because of its language independance goal, one needs to limit the number
of implementation specific types circulating on the SOAP net and focus on
the protocol types instead. If a method is defined to return an interface
then there should be a serializer for that interface instead of a serializer
for each type implementing the interface. That way each and anyone is free
to implement that interface on their end as they see fit.
Of course, one could wish the opposite. It really depends on what side of
the issue you are. If you want to ship all actual types then why not use
java serialization instead ?
Andi..
>
> Scott
>
> ----- Original Message -----
> From: "Andi Vajda" <av...@nanospace.com>
> To: <so...@xml.apache.org>
> Sent: Thursday, May 03, 2001 12:00 PM
> Subject: Re: proposal 4 a change in the RPCRouter
>
>
> >
> > This change is a problem since:
> > - it will crash if the return value is null
> > - there is a significant semantic difference between taking the method
> > return type and taking the actual type of the object. If the return type is
> > an interface then all one has to write is a serializer for that interface.
> > And any object implementing that interface will be serialized as of that
> > interface only. In my opinion, this is a significant advantage of SOAP over
> > regular Java serialization and is a major contributor in making SOAP a
> > so-called language independant protocol by hiding implementation classes
> > behind one or several interfaces at the protocol level.
> >
> > Andi..
> >
> > On Thu, 3 May 2001, Scott Nichol wrote:
> >
> > > I am using the same type of modification with no problem. I run a similar modification (using run time type instead of reflection) in the BeanSerializer.
> > >
> > > Scott
> > >
> > > ----- Original Message -----
> > > From: "Alex Homburg" <al...@dackelgesicht.de>
> > > To: "SOAP developers" <so...@xml.apache.org>
> > > Sent: Thursday, May 03, 2001 10:00 AM
> > > Subject: proposal 4 a change in the RPCRouter
> > >
> > >
> > > Hi all,
> > >
> > > I had a hard time trying to use an interface in order to be able to use generic return values. As far as I'm concerned this is mentioned in the SOAP specs. in 5.3. However it won't work in Apache SOAP as long as we get the information via reflection. That's why I changed the folloing line (RPCRouter.java):
> > >
> > > result = new Bean (m.getReturnType (), m.invoke (targetObject, args));
> > >
> > > to:
> > >
> > > Object methodInvoke = m.invoke( targetObject, args );
> > > result = new Bean( methodInvoke.getClass(), methodInvoke );
> > >
> > >
> > > Are there going to be any problems using this change? Please let me know!!!
> > >
> > > Alex
> > >
> > >
> > >
> > >
> >
>
>
Re: proposal 4 a change in the RPCRouter
Posted by Scott Nichol <sn...@computer.org>.
Interesting. I rather mourn the loss of polymorphism and am more than willing to write serializers for all types I want to pass either direction in the call.
I know of nothing in the SOAP spec that restricts polymorphism. Am I missing something? I believe WSDL, on the other hand, requires one to define the exact type of each parameter or return value, i.e. one cannot specify a list of actual types that a particular parameter may represent.
Scott
----- Original Message -----
From: "Andi Vajda" <av...@nanospace.com>
To: <so...@xml.apache.org>
Sent: Thursday, May 03, 2001 12:00 PM
Subject: Re: proposal 4 a change in the RPCRouter
>
> This change is a problem since:
> - it will crash if the return value is null
> - there is a significant semantic difference between taking the method
> return type and taking the actual type of the object. If the return type is
> an interface then all one has to write is a serializer for that interface.
> And any object implementing that interface will be serialized as of that
> interface only. In my opinion, this is a significant advantage of SOAP over
> regular Java serialization and is a major contributor in making SOAP a
> so-called language independant protocol by hiding implementation classes
> behind one or several interfaces at the protocol level.
>
> Andi..
>
> On Thu, 3 May 2001, Scott Nichol wrote:
>
> > I am using the same type of modification with no problem. I run a similar modification (using run time type instead of reflection) in the BeanSerializer.
> >
> > Scott
> >
> > ----- Original Message -----
> > From: "Alex Homburg" <al...@dackelgesicht.de>
> > To: "SOAP developers" <so...@xml.apache.org>
> > Sent: Thursday, May 03, 2001 10:00 AM
> > Subject: proposal 4 a change in the RPCRouter
> >
> >
> > Hi all,
> >
> > I had a hard time trying to use an interface in order to be able to use generic return values. As far as I'm concerned this is mentioned in the SOAP specs. in 5.3. However it won't work in Apache SOAP as long as we get the information via reflection. That's why I changed the folloing line (RPCRouter.java):
> >
> > result = new Bean (m.getReturnType (), m.invoke (targetObject, args));
> >
> > to:
> >
> > Object methodInvoke = m.invoke( targetObject, args );
> > result = new Bean( methodInvoke.getClass(), methodInvoke );
> >
> >
> > Are there going to be any problems using this change? Please let me know!!!
> >
> > Alex
> >
> >
> >
> >
>
Re: proposal 4 a change in the RPCRouter
Posted by Andi Vajda <av...@nanospace.com>.
This change is a problem since:
- it will crash if the return value is null
- there is a significant semantic difference between taking the method
return type and taking the actual type of the object. If the return type is
an interface then all one has to write is a serializer for that interface.
And any object implementing that interface will be serialized as of that
interface only. In my opinion, this is a significant advantage of SOAP over
regular Java serialization and is a major contributor in making SOAP a
so-called language independant protocol by hiding implementation classes
behind one or several interfaces at the protocol level.
Andi..
On Thu, 3 May 2001, Scott Nichol wrote:
> I am using the same type of modification with no problem. I run a similar modification (using run time type instead of reflection) in the BeanSerializer.
>
> Scott
>
> ----- Original Message -----
> From: "Alex Homburg" <al...@dackelgesicht.de>
> To: "SOAP developers" <so...@xml.apache.org>
> Sent: Thursday, May 03, 2001 10:00 AM
> Subject: proposal 4 a change in the RPCRouter
>
>
> Hi all,
>
> I had a hard time trying to use an interface in order to be able to use generic return values. As far as I'm concerned this is mentioned in the SOAP specs. in 5.3. However it won't work in Apache SOAP as long as we get the information via reflection. That's why I changed the folloing line (RPCRouter.java):
>
> result = new Bean (m.getReturnType (), m.invoke (targetObject, args));
>
> to:
>
> Object methodInvoke = m.invoke( targetObject, args );
> result = new Bean( methodInvoke.getClass(), methodInvoke );
>
>
> Are there going to be any problems using this change? Please let me know!!!
>
> Alex
>
>
>
>
Re: proposal 4 a change in the RPCRouter
Posted by Scott Nichol <sn...@computer.org>.
I am using the same type of modification with no problem. I run a similar modification (using run time type instead of reflection) in the BeanSerializer.
Scott
----- Original Message -----
From: "Alex Homburg" <al...@dackelgesicht.de>
To: "SOAP developers" <so...@xml.apache.org>
Sent: Thursday, May 03, 2001 10:00 AM
Subject: proposal 4 a change in the RPCRouter
Hi all,
I had a hard time trying to use an interface in order to be able to use generic return values. As far as I'm concerned this is mentioned in the SOAP specs. in 5.3. However it won't work in Apache SOAP as long as we get the information via reflection. That's why I changed the folloing line (RPCRouter.java):
result = new Bean (m.getReturnType (), m.invoke (targetObject, args));
to:
Object methodInvoke = m.invoke( targetObject, args );
result = new Bean( methodInvoke.getClass(), methodInvoke );
Are there going to be any problems using this change? Please let me know!!!
Alex