Samisa, In short, we would like need to attach a part of the first response to the second request, without worrying about reconstructing it. After attaching, we may optionally need to edit what we attached. Then perhaps we would need the same part of the first response + another part of the second response to construct the third request. And, this model in some form, would be used more than 10% of the time if we are talking about real world scenarios that involve conversation between client/server.
But, In addition to that, the simple serialize/deserialize deep_copy and a simple shallow copy would do if we are going to address the generic case. If someone demands performance, that is lesser than 10%, I believe. However, if we are aiming at a long term solution, where we can do some real research by playing with axiom on a separate trunk, I guess that Bill's approach is much better. If we are aiming at a short term fix, if for instance we are aiming at restructuring AXIOM for 2.x.x, Bill's solution is just an additional overhead to solving the existing issues. Regards, Senaka > Samisa, I can't speak directly to Kasun's use case, but I can describe > what prompted me to need a tree copy and/or clone method. The generated > adb stubs return an object of wsdl type any to the app as a node tree, > detached from the response message. They also accept an object of wsdl > type any as a node tree, to be attached to the request message. In each > case, the interface has ownership of the object, and frees the object when > the interface object is freed. So the get accessor method to the object > returns a pointer to the object tree but does not transfer ownership. The > set accessor method accepts a pointer to the object tree and takes > ownership of it. > > You are correct that cloning alone would be used in a routing app. But > imagine that the app receives an object from the service, modifies it, and > sends the app back to the service. To be able to free the response > interface object after processing the response, the app needs the ability > to copy or clone the object to be able to late use it. After modifying > the object, the app would then pass the object back to the service in a > later request. If the app needs the ability to pass the object to the > service while retaining a copy of it for later processing, it needs a copy > or clone operation again as the service will discard the version that was > sent when the request interface object was freed. With a copy or a clone > one can achieve the same result in different ways; a copy that allows one > to configure what is copied lets the code add what it needs to a reduced > tree, whereas a clone allows one to later remove or modify what is > unneeded from the cloned tree. > > Were the generated adb interface different, the requirement for a copy > would be reduced. Say the adb interface provided an accessor method, get, > that transferred ownership of the tree to the client app, and that the set > method accepted a pointer to the object to be passed without freeing the > tree when the request interface object was freed. Then these copies would > be eliminated, but the free of the tree after sending a request would now > be the responsibility of the client app. One would need a copy method > only if the original object was a template for generating multiple > objects. > > This may be very application specific, and I don't know how general the > need is. I do know that I encountered it, and it sounds like Kasun has a > very similar requirement. When I encountered it and found no suitable > method present, I wrote one that met my needs. But this requirement may > be common enough to warrant inclusion. > > I'm pretty sure you are correct, there is little need for this inside the > SOAP engine. The need is driven more by the interface to axiom, at least > with the adb classes. Kasun's issue with detach losing namespace > references and the tree becoming invalid arises, of course, in the context > of the adb classes detaching the object from the SOAP response message, > and so can arise for anyone using the service/client interface even > without the adb classes. > > Whether addressing this involves a significant architecture change depends > on the implementation. One can implement a copy method with options for > what is copied using the current interfaces, it just requires a bit of > research into the intricacies of axiom_node and its friends. A clone by > way of serializing and deserializing the structure I think uses builder > interfaces that are not public and would need to be included, but does not > involve an architecture change. Certainly a copy-on-write clone algorithm > does involve some pervasive changes, but such an algorithm has other > problems as well, already discussed. > > Bill > > -----Original Message----- > From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] > Sent: Saturday, February 16, 2008 10:33 PM > To: Apache AXIS C Developers List > Subject: Re: Issue in using 'detach' for cloning > > Kasun Indrasiri wrote: >> >> Hi all, >> >> I think, through out this thread there are various possible >> implementations were discussed with their pros and cons. I agreed with >> Senaka that the clone method should not be the 'best' or 'fast' one. >> And also Bill's ref count based implementation would suit where we may >> have to explicitly worry about the performance (and lazy coping also >> got its own pros and cons.) >> So, as Bill suggested earlier we can have several clone methods where >> user can select the method according to his preference. We can >> basically have one method for Shallow copy with ref counts and another >> with the normal serialize/desterilize approach. (and the lazy coping >> approach is also possible). Anyway it's a good move to implement these >> stuff with out affecting the existing axiom. > > IMHO, cloning is not a use case that we really need for a SOAP engine. > If you are trying to use the same XML over and over again, passing it > here and there, without modification, you are really routing stuff and > not doing that many business logic processing. > I am still trying to figure out why would one want to detach and attach > a node in a module or a service. If the use case is less than 10%, I do > not think it is a good idea to major changes to the current AXIOM > implementation that works. > > Samisa... > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
