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 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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
