Compare IBM to Apache

[Johnson, Michael1 [IT]]

What are the advantages to using apache SOAP vs say IBMs SOAP bundled with
websphere or MS SOAP bundled with .NET?

-MJ 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Confusing issue on Maps

[Chris Francis]

Not quite, if the type is a Map then a new 
Hashtable is created with the maps contents.
This hashtable is then serialized.
At least this is what happened in 2.2.

-Original Message-
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]]
Sent: 01 July 2002 06:21
To: [EMAIL PROTECTED]
Subject: Confusing issue on Maps



I'm pretty new on SOAP, but now I have a need;

If I read
http://xml.apache.org/soap/releases.html#v2.2
it says;

"Added support for serializing/deserializing java.util.Maps."

If I download 
http://xml.apache.org/dist/soap/version-2.3.1/soap-src-2.3.1.tar.gz
and look at the file

soap-2_3_1/src/org/apache/soap/encoding/soapenc/MapSerializer.java

it delegates to HashtableSerializer.java

which checks if the type is java.util.Hashtable


SO, Is it supported or not??

If it is, then what am I supposed to do to get it to work?

If it is not, then what is the claim in the documentation all about then?

Niclas

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Scott Nichol]

Niclas,

Have you written and executed code that is giving you an error, or are you
just raising the issue based on reading code?  Chris is quite correct about
serialization, and that should work just fine.  I am concerned about
de-serialization, though, since it appears you will get back a Hashtable,
which is not compatible with, e.g., a HashMap as a method parameter.  So, if
you are getting an error executing code, please post it to this list or
Bugzilla so we can have a look at it.

Thanks.

Scott Nichol

- Original Message -
From: "Chris Francis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 07:43
Subject: RE: Confusing issue on Maps


> Not quite, if the type is a Map then a new
> Hashtable is created with the maps contents.
> This hashtable is then serialized.
> At least this is what happened in 2.2.
>
> -Original Message-
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED]]
> Sent: 01 July 2002 06:21
> To: [EMAIL PROTECTED]
> Subject: Confusing issue on Maps
>
>
>
> I'm pretty new on SOAP, but now I have a need;
>
> If I read
> http://xml.apache.org/soap/releases.html#v2.2
> it says;
>
> "Added support for serializing/deserializing java.util.Maps."
>
> If I download
> http://xml.apache.org/dist/soap/version-2.3.1/soap-src-2.3.1.tar.gz
> and look at the file
>
> soap-2_3_1/src/org/apache/soap/encoding/soapenc/MapSerializer.java
>
> it delegates to HashtableSerializer.java
>
> which checks if the type is java.util.Hashtable
>
>
> SO, Is it supported or not??
>
> If it is, then what am I supposed to do to get it to work?
>
> If it is not, then what is the claim in the documentation all about then?
>
> Niclas
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Indrasish N Basuroychowdhury]

Scott,

Can you point me to an example of how to Serialize/Deserialize a Vetor of
Objects and send/receive them.

Thanks,

Indrasish.

Scott Nichol wrote:

> Niclas,
>
> Have you written and executed code that is giving you an error, or are you
> just raising the issue based on reading code?  Chris is quite correct about
> serialization, and that should work just fine.  I am concerned about
> de-serialization, though, since it appears you will get back a Hashtable,
> which is not compatible with, e.g., a HashMap as a method parameter.  So, if
> you are getting an error executing code, please post it to this list or
> Bugzilla so we can have a look at it.
>
> Thanks.
>
> Scott Nichol
>
> - Original Message -
> From: "Chris Francis" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 01, 2002 07:43
> Subject: RE: Confusing issue on Maps
>
> > Not quite, if the type is a Map then a new
> > Hashtable is created with the maps contents.
> > This hashtable is then serialized.
> > At least this is what happened in 2.2.
> >
> > -Original Message-
> > From: Niclas Hedhman [mailto:[EMAIL PROTECTED]]
> > Sent: 01 July 2002 06:21
> > To: [EMAIL PROTECTED]
> > Subject: Confusing issue on Maps
> >
> >
> >
> > I'm pretty new on SOAP, but now I have a need;
> >
> > If I read
> > http://xml.apache.org/soap/releases.html#v2.2
> > it says;
> >
> > "Added support for serializing/deserializing java.util.Maps."
> >
> > If I download
> > http://xml.apache.org/dist/soap/version-2.3.1/soap-src-2.3.1.tar.gz
> > and look at the file
> >
> > soap-2_3_1/src/org/apache/soap/encoding/soapenc/MapSerializer.java
> >
> > it delegates to HashtableSerializer.java
> >
> > which checks if the type is java.util.Hashtable
> >
> >
> > SO, Is it supported or not??
> >
> > If it is, then what am I supposed to do to get it to work?
> >
> > If it is not, then what is the claim in the documentation all about then?
> >
> > Niclas
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
> >
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Compare IBM to Apache

[Scott Nichol]

While this is no definitive, expert comparison, here are some things that
come to mind.

.NET

1. Best interop with other .NET, including Microsoft extensions to standards
2. You can code in nearly every language but Java (with J# coming soon)
3. With Visual Studio.NET, developers barely need to know what they are
doing to get something to mostly work ;-)
4. Runs only on OS platforms supporting .NET (can you guess which ones)

Apache SOAP (really Axis, which is roughtly "Apache SOAP 3.0"
---
1. Full source is available
2. Attempts to stick to standards (W3C, IETF, JCP, OASIS, etc.)
3. Client runs on all platforms supporting J2SE, server on J2EE subset

WebSphere
-
1. Based on Axis (I hope)
2. Tools to help developer that are not built into Axis

To me, the big question is whether you want to be limited to deploying SOAP
services on Wintel platforms, which the decision to go with .NET effectively
does.  Yes, I know, Microsoft is releasing a source reference implementation
on FreeBSD (which cannot be used for commercial development) and Ximian is
working on a portable .NET based on ECMA specs, but it's hard to imagine
significant .NET adoption anywhere but Win32.

You should also note that, in the Java world, there are implementations
beyond Axis and WebSphere.  FWIW, eWeek just ran a glowing review of WASP
from Systinet, for example.

Scott Nichol

- Original Message -
From: "Johnson, Michael1 [IT]" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 08:47
Subject: Compare IBM to Apache


> What are the advantages to using apache SOAP vs say IBMs SOAP bundled with
> websphere or MS SOAP bundled with .NET?
>
> -MJ
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Compare IBM to Apache

[Johnson, Michael1 [IT]]

For myself I was looking at using apache SOAP on websphere. I was look for
reasons why it would be beneficial rather than just using what IBM created.

Thanks
-MJ

-Original Message-
From: Scott Nichol [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 11:35 AM
To: [EMAIL PROTECTED]
Subject: Re: Compare IBM to Apache


While this is no definitive, expert comparison, here are some things that
come to mind.

.NET

1. Best interop with other .NET, including Microsoft extensions to standards
2. You can code in nearly every language but Java (with J# coming soon)
3. With Visual Studio.NET, developers barely need to know what they are
doing to get something to mostly work ;-)
4. Runs only on OS platforms supporting .NET (can you guess which ones)

Apache SOAP (really Axis, which is roughtly "Apache SOAP 3.0"
---
1. Full source is available
2. Attempts to stick to standards (W3C, IETF, JCP, OASIS, etc.)
3. Client runs on all platforms supporting J2SE, server on J2EE subset

WebSphere
-
1. Based on Axis (I hope)
2. Tools to help developer that are not built into Axis

To me, the big question is whether you want to be limited to deploying SOAP
services on Wintel platforms, which the decision to go with .NET effectively
does.  Yes, I know, Microsoft is releasing a source reference implementation
on FreeBSD (which cannot be used for commercial development) and Ximian is
working on a portable .NET based on ECMA specs, but it's hard to imagine
significant .NET adoption anywhere but Win32.

You should also note that, in the Java world, there are implementations
beyond Axis and WebSphere.  FWIW, eWeek just ran a glowing review of WASP
from Systinet, for example.

Scott Nichol

- Original Message -
From: "Johnson, Michael1 [IT]" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 08:47
Subject: Compare IBM to Apache


> What are the advantages to using apache SOAP vs say IBMs SOAP bundled with
> websphere or MS SOAP bundled with .NET?
>
> -MJ
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Compare IBM to Apache

[James M Snell]

Apache SOAP is what IBM uses (and originally created... IBM donated it to 
Apache a while back). 

- James M Snell/Fresno/IBM
Web services architecture and strategy
Internet Emerging Technologies, IBM
544.9035 TIE line
559.587.1233 Office
919.486.0077 Voice Mail
[EMAIL PROTECTED]
 Programming Web Services With SOAP, O'reilly & Associates, ISBN 
0596000952 

==
Have I not commanded you?  Be strong and courageous.  Do not be terrified, 

do not be discouraged, for the Lord your God will be with you wherever you 
go.  
- Joshua 1:9

Please respond to [EMAIL PROTECTED] 
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc: 
Subject:RE: Compare IBM to Apache



For myself I was looking at using apache SOAP on websphere. I was look for
reasons why it would be beneficial rather than just using what IBM 
created.

Thanks
-MJ

-Original Message-
From: Scott Nichol [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 11:35 AM
To: [EMAIL PROTECTED]
Subject: Re: Compare IBM to Apache


While this is no definitive, expert comparison, here are some things that
come to mind.

.NET

1. Best interop with other .NET, including Microsoft extensions to 
standards
2. You can code in nearly every language but Java (with J# coming soon)
3. With Visual Studio.NET, developers barely need to know what they are
doing to get something to mostly work ;-)
4. Runs only on OS platforms supporting .NET (can you guess which ones)

Apache SOAP (really Axis, which is roughtly "Apache SOAP 3.0"
---
1. Full source is available
2. Attempts to stick to standards (W3C, IETF, JCP, OASIS, etc.)
3. Client runs on all platforms supporting J2SE, server on J2EE subset

WebSphere
-
1. Based on Axis (I hope)
2. Tools to help developer that are not built into Axis

To me, the big question is whether you want to be limited to deploying 
SOAP
services on Wintel platforms, which the decision to go with .NET 
effectively
does.  Yes, I know, Microsoft is releasing a source reference 
implementation
on FreeBSD (which cannot be used for commercial development) and Ximian is
working on a portable .NET based on ECMA specs, but it's hard to imagine
significant .NET adoption anywhere but Win32.

You should also note that, in the Java world, there are implementations
beyond Axis and WebSphere.  FWIW, eWeek just ran a glowing review of WASP
from Systinet, for example.

Scott Nichol

- Original Message -
From: "Johnson, Michael1 [IT]" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 08:47
Subject: Compare IBM to Apache


> What are the advantages to using apache SOAP vs say IBMs SOAP bundled 
with
> websphere or MS SOAP bundled with .NET?
>
> -MJ
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Scott Nichol]

To clarify something: MapSerializer serializes and deserializes Maps.  On
the serializer side, this means you can serialize anything that implements
Map.  On the deserializer side, this means you get something that implements
a Map, but you have no control over the actual class.  So, you can use a
method like

void setProperties(Map props)

in a service, but you cannot use

void setProperties(HashMap props)

Also, if you have the following service method

HashMap getProperties()

the client must treat the return value as a Map (not a HashMap).  If the
client wants a HashMap, the client must create it from the Map that is
returned.

Scott Nichol

- Original Message -
From: "Scott Nichol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 11:15
Subject: Re: Confusing issue on Maps


> Niclas,
>
> Have you written and executed code that is giving you an error, or are you
> just raising the issue based on reading code?  Chris is quite correct
about
> serialization, and that should work just fine.  I am concerned about
> de-serialization, though, since it appears you will get back a Hashtable,
> which is not compatible with, e.g., a HashMap as a method parameter.  So,
if
> you are getting an error executing code, please post it to this list or
> Bugzilla so we can have a look at it.
>
> Thanks.
>
> Scott Nichol
>
> - Original Message -
> From: "Chris Francis" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 01, 2002 07:43
> Subject: RE: Confusing issue on Maps
>
>
> > Not quite, if the type is a Map then a new
> > Hashtable is created with the maps contents.
> > This hashtable is then serialized.
> > At least this is what happened in 2.2.
> >
> > -Original Message-
> > From: Niclas Hedhman [mailto:[EMAIL PROTECTED]]
> > Sent: 01 July 2002 06:21
> > To: [EMAIL PROTECTED]
> > Subject: Confusing issue on Maps
> >
> >
> >
> > I'm pretty new on SOAP, but now I have a need;
> >
> > If I read
> > http://xml.apache.org/soap/releases.html#v2.2
> > it says;
> >
> > "Added support for serializing/deserializing java.util.Maps."
> >
> > If I download
> > http://xml.apache.org/dist/soap/version-2.3.1/soap-src-2.3.1.tar.gz
> > and look at the file
> >
> > soap-2_3_1/src/org/apache/soap/encoding/soapenc/MapSerializer.java
> >
> > it delegates to HashtableSerializer.java
> >
> > which checks if the type is java.util.Hashtable
> >
> >
> > SO, Is it supported or not??
> >
> > If it is, then what am I supposed to do to get it to work?
> >
> > If it is not, then what is the claim in the documentation all about
then?
> >
> > Niclas
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
> >
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Niclas Hedhman]

On Monday 01 July 2002 23:15, Scott Nichol wrote:
> Niclas,
>
> Have you written and executed code that is giving you an error, or are you
> just raising the issue based on reading code?  Chris is quite correct about
> serialization, and that should work just fine.  I am concerned about
> de-serialization, though, since it appears you will get back a Hashtable,
> which is not compatible with, e.g., a HashMap as a method parameter.  So,
> if you are getting an error executing code, please post it to this list or
> Bugzilla so we can have a look at it.

Ok, I agree I looked thorugh the code a bit hasty, but it was triggered by an 
exception saying that there was no serializer available for 
java.util.TreeMap, and changing the type to java.util.HashMap, just replaced 
the exception with such a message instead.

So, what I did yesterday was to implement my own MapSerializer, by using the 
HashtableSerializer code, declare it in SOAPMappingRegistry and in the 
deployment descriptor, and that works. Is it that I have to explicitly 
declare the org.apache.soap.encoding.soapencoding.MapSerializer?


I'll regenerat the exception in a moment.

Stay tuned.

Niclas

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Niclas Hedhman]

On Tuesday 02 July 2002 09:22, Niclas Hedhman wrote:
> I'll regenerat the exception in a moment.

2002-07-01 17:26:28,742 ERROR [Module-Actions] 
ts.TargetSpecificationWizardIterator 
(TargetSpecificationWizardIterator.java:306) - Unable to create Target 
Specification.
[SOAPException: faultCode=SOAP-ENV:Client; msg=No Serializer found to 
serialize a 'java.util.TreeMap' using encoding style 
'http://schemas.xmlsoap.org/soap/encoding/'.; 
targetException=java.lang.IllegalArgumentException: No Serializer found to 
serialize a 'java.util.TreeMap' using encoding style 
'http://schemas.xmlsoap.org/soap/encoding/'.]
at 
org.apache.soap.transport.http.SOAPHTTPConnection.send(SOAPHTTPConnection.java:354)
at org.apache.soap.rpc.Call.invoke(Call.java:248)
at com.ewarna.xzone.soap.SoapProxy.invoke(SoapProxy.java:211)
at $Proxy7.createTargetSpecification(Unknown Source)
at 
com.ewarna.scm.view.ts.TargetSpecificationWizardIterator.instantiate(TargetSpecificationWizardIterator.java:252)
at 
org.openide.loaders.TemplateWizard.handleInstantiate(TemplateWizard.java:545)
at 
org.openide.loaders.TemplateWizard.instantiateImpl(TemplateWizard.java:508)
at 
org.openide.loaders.TemplateWizard.instantiate(TemplateWizard.java:427)
at 
com.ewarna.scm.view.tst.CreateTargetSpecificationAction.performAction(CreateTargetSpecificationAction.java:139)
at 
org.openide.util.actions.NodeAction.performAction(NodeAction.java:179)
at 
org.openide.util.actions.NodeAction.actionPerformed(NodeAction.java:170)
at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:100)
at org.openide.util.Task.run(Task.java:136)
at 
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Niclas Hedhman]

On Tuesday 02 July 2002 09:22, Niclas Hedhman wrote:
> On Monday 01 July 2002 23:15, Scott Nichol wrote:
> > Have you written and executed code that is giving you an error, or are
> > you just raising the issue based on reading code?  

Also in HashtableSerializer it has a NICE comment at the top;
/**
 * A HashtableSerializer can be used to serialize and
 * deserialize Hashtables using the SOAP-ENC
 * encoding style.
 *
 * TODO: This should eventually deal with Maps, but doesn't yet.
 *
 * @author Glen Daniels ([EMAIL PROTECTED])
 */

Which triggers a bit of suspiscion (?spelling?).

> > I am concerned
> > about de-serialization, though, since it appears you will get back a
> > Hashtable

That is typically OK, since we are dealing with Maps and not implementation 
specific aspect of them on the "consumer" side. The "producer" side will 
choose an implementation that suits its needs.

Niclas

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Scott Nichol]

To get a TreeMap or HashMap to serialize using MapSerializer, you can either
register the MapSerializer for those types, or specify the parameter as
having a Java type of Map, e.g.

TreeMap myMap;
Vector params = new Vector();
params.addElement(new Parameter("myMap", Map.class, myMap, null));

Scott Nichol

- Original Message -
From: "Niclas Hedhman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 9:22 PM
Subject: Re: Confusing issue on Maps


> On Monday 01 July 2002 23:15, Scott Nichol wrote:
> > Niclas,
> >
> > Have you written and executed code that is giving you an error, or are
you
> > just raising the issue based on reading code?  Chris is quite correct
about
> > serialization, and that should work just fine.  I am concerned about
> > de-serialization, though, since it appears you will get back a
Hashtable,
> > which is not compatible with, e.g., a HashMap as a method parameter.
So,
> > if you are getting an error executing code, please post it to this list
or
> > Bugzilla so we can have a look at it.
>
> Ok, I agree I looked thorugh the code a bit hasty, but it was triggered by
an
> exception saying that there was no serializer available for
> java.util.TreeMap, and changing the type to java.util.HashMap, just
replaced
> the exception with such a message instead.
>
> So, what I did yesterday was to implement my own MapSerializer, by using
the
> HashtableSerializer code, declare it in SOAPMappingRegistry and in the
> deployment descriptor, and that works. Is it that I have to explicitly
> declare the org.apache.soap.encoding.soapencoding.MapSerializer?
>
>
> I'll regenerat the exception in a moment.
>
> Stay tuned.
>
> Niclas
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Niclas Hedhman]

On Tuesday 02 July 2002 09:45, Scott Nichol wrote:
> To get a TreeMap or HashMap to serialize using MapSerializer, you can
> either register the MapSerializer for those types, or specify the parameter
> as having a Java type of Map, e.g.
>
> TreeMap myMap;
> Vector params = new Vector();
> params.addElement(new Parameter("myMap", Map.class, myMap, null));

So it is not "inherent" to the system?

Niclas

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Scott Nichol]

It is "inherent", but only for an exact match of the type Map.  When the
Parameter instance is created, the type specified there is used to determine
the serializer.  Specifying the type using HashMap.class does not match the
serializer for Map, which is registered using Map.class.

Alternatively, you can specify HashMap.class when instantiating the
Parameter, but then you must add a mapping using
SOAPMappingRegistry#mapTypes for HashMap.

Scott Nichol

- Original Message -
From: "Niclas Hedhman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 9:46 PM
Subject: Re: Confusing issue on Maps


> On Tuesday 02 July 2002 09:45, Scott Nichol wrote:
> > To get a TreeMap or HashMap to serialize using MapSerializer, you can
> > either register the MapSerializer for those types, or specify the
parameter
> > as having a Java type of Map, e.g.
> >
> > TreeMap myMap;
> > Vector params = new Vector();
> > params.addElement(new Parameter("myMap", Map.class, myMap, null));
>
> So it is not "inherent" to the system?
>
> Niclas
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Niclas Hedhman]

On Tuesday 02 July 2002 10:00, Scott Nichol wrote:
> It is "inherent", but only for an exact match of the type Map.  When the
> Parameter instance is created, the type specified there is used to
> determine the serializer.  Specifying the type using HashMap.class does not
> match the serializer for Map, which is registered using Map.class.

> Alternatively, you can specify HashMap.class when instantiating the
> Parameter, but then you must add a mapping using
> SOAPMappingRegistry#mapTypes for HashMap.

I don't call either way "inherent".

Inherent means to me; "I need to do nothing and it will work".

Map.class is meaningless as "exact match". There is nothing that returns a 
"class java.util.Map" for getClass(), if that is what you mean.

Parameter types are typically not a problem, since they are pretty much under 
control and can be modified for the occassion. It is the content of objects 
that really is annoying.


Don't get me wrong. I like SOAP and I like the Apache SOAP implementation. We 
have used it in three parts of our system. A Login service, a business logic 
service, and a File System that can be plugged into NetBeans. Only the 
business logic is giving us a hard time, since we are dealing with objects 
instead of primitives.

Niclas

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Scott Nichol]

- Original Message -
From: "Niclas Hedhman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 10:26 PM
Subject: Re: Confusing issue on Maps


> On Tuesday 02 July 2002 10:00, Scott Nichol wrote:
> > It is "inherent", but only for an exact match of the type Map.  When the
> > Parameter instance is created, the type specified there is used to
> > determine the serializer.  Specifying the type using HashMap.class does
not
> > match the serializer for Map, which is registered using Map.class.
>
> > Alternatively, you can specify HashMap.class when instantiating the
> > Parameter, but then you must add a mapping using
> > SOAPMappingRegistry#mapTypes for HashMap.
>
> I don't call either way "inherent".
>
> Inherent means to me; "I need to do nothing and it will work".
>
> Map.class is meaningless as "exact match". There is nothing that returns a
> "class java.util.Map" for getClass(), if that is what you mean.

Here's how I see it.

1. MapSerializer is registered by Apache SOAP as a serializer and
deserializer for the Java type Map.  You do not need to call mapTypes to get
this functionality.  To me, that is "inherent".

2. When you create a Parameter, you specify the Java type as which you want
it to be serialized.  Having this flexibility is extremely important.  What
if Apache SOAP always did a getClass() on the value you specified for the
parameter?  In that case, you could never serialize by interface.

3. You may want to ignore the freedom of #2 by always specifying the Java
type as value.getClass().  Since this type chooses the serializer, however,
you may not get the result you intended.  In your case, you would specify a
Java type of TreeMap or HashMap, but want to serialize as a Map.
Unfortunately, Apache SOAP is not clairvoyant
;-).  I supposed that if Apache SOAP did not find a match for the specified
class, it could try to find serializer matches for superclasses and/or
implemented interfaces, but in the case of multiple matches, which would it
use?  Instead, the code forces you to be explicit about the type.

>
> Parameter types are typically not a problem, since they are pretty much
under
> control and can be modified for the occassion. It is the content of
objects
> that really is annoying.
>
>
> Don't get me wrong. I like SOAP and I like the Apache SOAP implementation.
We
> have used it in three parts of our system. A Login service, a business
logic
> service, and a File System that can be plugged into NetBeans. Only the
> business logic is giving us a hard time, since we are dealing with objects
> instead of primitives.

Indeed, this is where SOAP becomes less simple.  One project I worked on
about 2 years ago that was using Microsoft's SOAP Toolkit was abandoned
after a programmer revolt: no one wanted to write and debug the serializers
and deserializers for all the custom types.  Up the chain of command it was
agreed that SOAP "had too much baggage", the project was killed, SOAP was
removed from the architectural direction, and my contract with the company
was terminated.

Forunately, not everyone has such a reaction to a little grunt work.

Scott Nichol



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Confusing issue on Maps

[SoumenS]

The idea that "Apache SOAP forces you to be
explicit about type" is a barrier in good system design.
This breaks abstraction. I should be able to use a serializer
for HashMap class where a serializer for Map is expected. Some
runtime interaction causes search for Map serializer. If there
is one -- good, use it. If there is none for Map, but one for
HashMap -- ok use it.

I would not allow such behavior in my O-O program -- "Liskov
Substitution principle is lost". Somewhere in Apache serialization
design this OO principle is lost.

Just my opinion, I could be wrong on design philosophy.
In CORBA such issues are not there -- all the time I deal
with OO programming language types whose semantics extend
to wireline protocol (via code generation and inheritance).
I am having problem to understand why Apache SOAP would
not allow such facility to OO programnmers -- why the
abstraction is suddenly breaking (and discussion
taking place on serilizers).

Soumen Sarkar.

-Original Message-
From: Scott Nichol [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Confusing issue on Maps



- Original Message -
From: "Niclas Hedhman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 10:26 PM
Subject: Re: Confusing issue on Maps


> On Tuesday 02 July 2002 10:00, Scott Nichol wrote:
> > It is "inherent", but only for an exact match of the type Map.  When the
> > Parameter instance is created, the type specified there is used to
> > determine the serializer.  Specifying the type using HashMap.class does
not
> > match the serializer for Map, which is registered using Map.class.
>
> > Alternatively, you can specify HashMap.class when instantiating the
> > Parameter, but then you must add a mapping using
> > SOAPMappingRegistry#mapTypes for HashMap.
>
> I don't call either way "inherent".
>
> Inherent means to me; "I need to do nothing and it will work".
>
> Map.class is meaningless as "exact match". There is nothing that returns a
> "class java.util.Map" for getClass(), if that is what you mean.

Here's how I see it.

1. MapSerializer is registered by Apache SOAP as a serializer and
deserializer for the Java type Map.  You do not need to call mapTypes to get
this functionality.  To me, that is "inherent".

2. When you create a Parameter, you specify the Java type as which you want
it to be serialized.  Having this flexibility is extremely important.  What
if Apache SOAP always did a getClass() on the value you specified for the
parameter?  In that case, you could never serialize by interface.

3. You may want to ignore the freedom of #2 by always specifying the Java
type as value.getClass().  Since this type chooses the serializer, however,
you may not get the result you intended.  In your case, you would specify a
Java type of TreeMap or HashMap, but want to serialize as a Map.
Unfortunately, Apache SOAP is not clairvoyant
;-).  I supposed that if Apache SOAP did not find a match for the specified
class, it could try to find serializer matches for superclasses and/or
implemented interfaces, but in the case of multiple matches, which would it
use?  Instead, the code forces you to be explicit about the type.

>
> Parameter types are typically not a problem, since they are pretty much
under
> control and can be modified for the occassion. It is the content of
objects
> that really is annoying.
>
>
> Don't get me wrong. I like SOAP and I like the Apache SOAP implementation.
We
> have used it in three parts of our system. A Login service, a business
logic
> service, and a File System that can be plugged into NetBeans. Only the
> business logic is giving us a hard time, since we are dealing with objects
> instead of primitives.

Indeed, this is where SOAP becomes less simple.  One project I worked on
about 2 years ago that was using Microsoft's SOAP Toolkit was abandoned
after a programmer revolt: no one wanted to write and debug the serializers
and deserializers for all the custom types.  Up the chain of command it was
agreed that SOAP "had too much baggage", the project was killed, SOAP was
removed from the architectural direction, and my contract with the company
was terminated.

Forunately, not everyone has such a reaction to a little grunt work.

Scott Nichol



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Confusing issue on Maps

[Scott Nichol]

Soumen,

I am not a CORBA expert.  When calling a method on a remote object, is the
IDL for the method used to determine how to marshal the parameters, or is an
instance of a type in a particular language always marshalled the same way?

Something that distinguishes SOAP from, say, RMI is that there is no
standard way to reflect the fact that an "object" may implement multiple
interfaces.  For example, if I have a class that implements 4 interfaces,
there is no standard way to marshal this in SOAP such that the unmarshalling
side understands there are 4 interfaces that it could choose to "cast" to if
it wants.  This creates the issue of how to serialize such a class in a way
that the receiver will understand.  I haven't really given it much thought,
but this may just be one of a class of issues created by the lack of SOAP
language bindings.

I am curious: are you still doing a lot of CORBA work, or are you replacing
some of your CORBA-based implementations with SOAP?  Although I like SOAP,
in some situations I think it is being mis-used where a more robust
distributed object system is more appropriate.

Scott Nichol

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 11:39 PM
Subject: RE: Confusing issue on Maps


> The idea that "Apache SOAP forces you to be
> explicit about type" is a barrier in good system design.
> This breaks abstraction. I should be able to use a serializer
> for HashMap class where a serializer for Map is expected. Some
> runtime interaction causes search for Map serializer. If there
> is one -- good, use it. If there is none for Map, but one for
> HashMap -- ok use it.
>
> I would not allow such behavior in my O-O program -- "Liskov
> Substitution principle is lost". Somewhere in Apache serialization
> design this OO principle is lost.
>
> Just my opinion, I could be wrong on design philosophy.
> In CORBA such issues are not there -- all the time I deal
> with OO programming language types whose semantics extend
> to wireline protocol (via code generation and inheritance).
> I am having problem to understand why Apache SOAP would
> not allow such facility to OO programnmers -- why the
> abstraction is suddenly breaking (and discussion
> taking place on serilizers).
>
> Soumen Sarkar.
>
> -Original Message-
> From: Scott Nichol [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 01, 2002 8:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Confusing issue on Maps
>
>
>
> - Original Message -
> From: "Niclas Hedhman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 01, 2002 10:26 PM
> Subject: Re: Confusing issue on Maps
>
>
> > On Tuesday 02 July 2002 10:00, Scott Nichol wrote:
> > > It is "inherent", but only for an exact match of the type Map.  When
the
> > > Parameter instance is created, the type specified there is used to
> > > determine the serializer.  Specifying the type using HashMap.class
does
> not
> > > match the serializer for Map, which is registered using Map.class.
> >
> > > Alternatively, you can specify HashMap.class when instantiating the
> > > Parameter, but then you must add a mapping using
> > > SOAPMappingRegistry#mapTypes for HashMap.
> >
> > I don't call either way "inherent".
> >
> > Inherent means to me; "I need to do nothing and it will work".
> >
> > Map.class is meaningless as "exact match". There is nothing that returns
a
> > "class java.util.Map" for getClass(), if that is what you mean.
>
> Here's how I see it.
>
> 1. MapSerializer is registered by Apache SOAP as a serializer and
> deserializer for the Java type Map.  You do not need to call mapTypes to
get
> this functionality.  To me, that is "inherent".
>
> 2. When you create a Parameter, you specify the Java type as which you
want
> it to be serialized.  Having this flexibility is extremely important.
What
> if Apache SOAP always did a getClass() on the value you specified for the
> parameter?  In that case, you could never serialize by interface.
>
> 3. You may want to ignore the freedom of #2 by always specifying the Java
> type as value.getClass().  Since this type chooses the serializer,
however,
> you may not get the result you intended.  In your case, you would specify
a
> Java type of TreeMap or HashMap, but want to serialize as a Map.
> Unfortunately, Apache SOAP is not clairvoyant
> ;-).  I supposed that if Apache SOAP did not find a match for the
specified
> class, it could try to find serializer matches for superclasses and/or
> implemented interfaces, but in the case of multiple matches, which would
it
> use?  Instead, the code forces you to be explicit about the type.
>
> >
> > Parameter types are typically not a problem, since they are pretty much
> under
> > control and can be modified for the occassion. It is the content of
> objects
> > that really is annoying.
> >
> >
> > Don't get me wrong. I like SOAP and I like the Apache SOAP
implementation.
> We
> > have used it in three parts of our system. A 

RE: Confusing issue on Maps

[SoumenS]

Scott,

Neither am I a CORBA expert. However, as a OO Software developer
with CORBA experience, I can answer your first question with the
following statements:

   SOAP is a XML based messaging protocol -- it does not care
   what kind of higher software layer is using it. However, a higher
   layer software like "Apache SOAP" should support "value type".
   The current problem is arising because, in my opinion, SOAP
   marshalling is not utilizing value-type inheritance and associated
   serialization.

   In other words, my objection was against Apache SOAP and not
   against SOAP. To elaborate more, initially Apache SOAP appears
   to support objects and then gradually it breaks down as abstraction
   and OO principle is pushed more and more. I know there are so many
interop
   problems regarding value type proposition in SOAP -- in that case
   Apache SOAP should clearly state its limitations as a tool for
   distributed OO programming. It created the initial illuision of
distributed
   OO programming but could not support it in its full glory.

Regarding your second question, I do not have a clear choice of technology
as a client/server or peer/peer system builder. From a system building
mindset
I would like to have CORBA/EJB -- but these technologies fail from open
internet
based service oriented mindset. So it is a mixed bag -- I can NOT state that
in
my work SOAP is replacing CORBA/EJB in MANY areas. There are so many
distributed system
programming issue if SOAP based RPC implementation is used 100%. One example
is the current discussion on parameter variance. SOAP has created
possibilities
for EAI but that does not mean necessary simplification in distributed
programming. 

I will conclude by totally agreeing with your last paragraph -- the scope of
application of SOAP is not clear to some. If one likes transparency at a
distributed OO programming level use EJB/CORBA.

Soumen Sarkar.

-Original Message-
From: Scott Nichol [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 9:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Confusing issue on Maps


Soumen,

I am not a CORBA expert.  When calling a method on a remote object, is the
IDL for the method used to determine how to marshal the parameters, or is an
instance of a type in a particular language always marshalled the same way?

Something that distinguishes SOAP from, say, RMI is that there is no
standard way to reflect the fact that an "object" may implement multiple
interfaces.  For example, if I have a class that implements 4 interfaces,
there is no standard way to marshal this in SOAP such that the unmarshalling
side understands there are 4 interfaces that it could choose to "cast" to if
it wants.  This creates the issue of how to serialize such a class in a way
that the receiver will understand.  I haven't really given it much thought,
but this may just be one of a class of issues created by the lack of SOAP
language bindings.

I am curious: are you still doing a lot of CORBA work, or are you replacing
some of your CORBA-based implementations with SOAP?  Although I like SOAP,
in some situations I think it is being mis-used where a more robust
distributed object system is more appropriate.

Scott Nichol

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 11:39 PM
Subject: RE: Confusing issue on Maps


> The idea that "Apache SOAP forces you to be
> explicit about type" is a barrier in good system design.
> This breaks abstraction. I should be able to use a serializer
> for HashMap class where a serializer for Map is expected. Some
> runtime interaction causes search for Map serializer. If there
> is one -- good, use it. If there is none for Map, but one for
> HashMap -- ok use it.
>
> I would not allow such behavior in my O-O program -- "Liskov
> Substitution principle is lost". Somewhere in Apache serialization
> design this OO principle is lost.
>
> Just my opinion, I could be wrong on design philosophy.
> In CORBA such issues are not there -- all the time I deal
> with OO programming language types whose semantics extend
> to wireline protocol (via code generation and inheritance).
> I am having problem to understand why Apache SOAP would
> not allow such facility to OO programnmers -- why the
> abstraction is suddenly breaking (and discussion
> taking place on serilizers).
>
> Soumen Sarkar.
>
> -Original Message-
> From: Scott Nichol [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 01, 2002 8:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Confusing issue on Maps
>
>
>
> - Original Message -
> From: "Niclas Hedhman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 01, 2002 10:26 PM
> Subject: Re: Confusing issue on Maps
>
>
> > On Tuesday 02 July 2002 10:00, Scott Nichol wrote:
> > > It is "inherent", but only for an exact match of the type Map.  When
the
> > > Parameter instance is created, the type specified there is used to
> > > determine the 

Re: Confusing issue on Maps

[Niclas Hedhman]

On Tuesday 02 July 2002 13:36, [EMAIL PROTECTED] wrote:
> I will conclude by totally agreeing with your last paragraph -- the scope
> of application of SOAP is not clear to some. If one likes transparency at a
> distributed OO programming level use EJB/CORBA.

There are "distributed concerns" that I have to live with, almost dictating 
the use of SOAP over HTTP, or at least XXX over HTTP. 
Firewalls!!! 

SOAP offered a nice middle ground.

HOWEVER, calling it Simple OBJECT Access Protocol is to me a bit 
overstatement, or I am missing something rudimentarily important (passing a 
object reference) for that claim.

Niclas

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Sample application using soap

[Sridhar]

Hi ,
 
I would like to first start with a sample soap 
application, can anybody guide me throught the process
 
what do i need to downl load and where do i get the 
examples??
 
Best Regards,
Sridha