> > Dear All, > > Niclas Hedhman wrote : > > > 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. > > > > I was a bit suprised after reading these messages about OO distributed > programming and SOAP. > > Am I mistaken if I think that sending a java Vector, or Map or Hashmap over > the SOAP wire will not be received well in a .Net client? > > In our system design, SOAP is used for interoperability and the .NET > compatibility is important, so only primitives, and arrays or complex types > of primitives are allowed.
You are correct that .NET will not "natively" handle Vector, Map, etc., but one can provide .NET [de-]serializers for these types, much as one could write DataSet [de-]serializers in Java. I personally would prefer not to do this, but some folks do. > > The OO backend translates its content to these types to communicate to the > other side. > > Am I correct in this matter ? > The O in SOAP was spelling error ? I think the problem was that without the O one is left with SAP, which is already the name of a well-known company ;-). Frankly, I don't think the O belongs. The original Userland XML-RPC name is far more appropriate, I believe. The SOAP name seems to lead some people to think it is a replacement for RMI, CORBA, etc., which it is not. > > Br. > Christophe Herreman. > Scott Nichol -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
