The code must have some way to understand how to represent a Java class in XML, and how to create an instance of a Java class from XML. The Apache SOAP way of doing this is pretty reasonable, and is similar to what Microsoft implemented in the SOAP Toolkit V2. On the serialization side, it might have been nice to have BeanSerializer used as the default if no serializer is specified, but it is a little more difficult to know what would be appropriate for the de-serializer to do when confronted with an unmapped type. It could search the classpath for the first class matching the element type, but that is not always what is desired. It could create a Bean for each unmapped type, but that would just provide a bag of wrapped data, not a class with the semantics of some entity in the application domain as might be desired. I guess it would provide some kind of default, though.
Scott ----- Original Message ----- From: "soap vamsi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, April 22, 2002 6:52 AM Subject: serializers/deserializers > Why do i need different serializers and deserializers to marshall > and unmarshall a message? > Why do have to specify the a serializer/deserialzer of my choice > when i pass an user created type as a parameter to an rpc? > Thanx in advance > vamsi > _________________________________________________________ > Click below to visit monsterindia.com and review jobs in India or > Abroad > http://monsterindia.rediff.com/jobs > >
