> 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.
I am curious: how did Apache SOAP create "the initial illuision of distributed OO programming but could not support it in its full glory"? When I started with Apache SOAP, it was because it implemented a pretty large subset of the SOAP 1.1 specification. Since SOAP is not a distributed OO programming specification, I did not expect Apache SOAP to support distributed OO programming. I mostly got what I expected: RPC over HTTP with marshalling to and from XML as defined by the SOAP specification. And, I actually liked the fact that Apache SOAP did not attempt to stray far from the specification, so that it interoperated well with other implementations. If used, the additional capabilities you desire would cause interoperation nightmares. Ironically, it seems I liked Apache SOAP for the same reasons you did not. > > 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. My perspective is that I build distributed applications using RMI (and a sprinkling of CORBA to cross language boundaries). I expose coarse-grained APIs for those applications using SOAP, which effectively means that SOAP is used for "real-time" EAI (as opposed to the "batch" EAI I still do with daily file transfers). SOAP, as defined by its specification, simply does not have the capabilities to displace RMI/CORBA/DCOM (or even DCE RPC or ONC RPC). > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
