R J Scheuerle Jr/Austin/[EMAIL PROTECTED] wrote on 10/26/2006 08:34:24 AM: > Henry said: > <henry> > One of the possible use cases for filter is for checking uniqness of a > piece of data, if this is implemented in using filter, the check and > enforcement can be done during the parsing of the message. This will save > the walking of the OM tree again. > </henry> > > A uniquenes check requires the inspection of the entire message. > If a uniquess check is performed with a handler solution, there are several > undesirable outcomes: > 1) the OM tree will be traversed, which is expensive. > 2) the OM tree will be expanded and cached, which kills performance. > > If a uniquess check is performed with a filter and handler solution: > 1) The filter can inspect the StAX events as they are read. The filter will > not affect the caching of the OM tree. The filter will not pull StAX events. > 2) The filter will store its results on the MessageContext. > > Handlers pull StAX events. > Filters don't pull StAX events. They intercept and propogate StAX events. > > Comments ? Takahide / Henry can you provide more justifications or feedback > for this request ?
Rich, thanks, you have captured the important points and explain it well. > > Rich Scheuerle > IBM Web Services > Apache Axis2 ([EMAIL PROTECTED]) > 512-838-5115 (IBM TL 678-5115) > [image removed] Hyen V Chung/Austin/[EMAIL PROTECTED] > > > Hyen V Chung/Austin/[EMAIL PROTECTED] > 10/25/2006 10:14 PM > > Please respond to > [email protected] > > [image removed] > To > > [image removed] > [email protected] > > [image removed] > cc > > [image removed] > > [image removed] > Subject > > [image removed] > Re: Request for XML Filter (AXIS2-1085) > > [image removed] > > [image removed] > > > R J Scheuerle Jr/Austin/[EMAIL PROTECTED] wrote on 10/25/2006 07:39:03 AM: > > > On Tue, 2006-10-24 at 12:15 -0500, R J Scheuerle Jr wrote: > > > Takahide would like a plugin, which he calls a Filter, which satisfies > > > the following requirements. > > > A) A Filter wraps an input XMLStreamReader and implements an > > > XMLStreamReader. The Filter intercepts each StAX event and can > > > propogate the event. > > > > > > B) A Filter has access to the Axis 2 MessageContext. > > > > These two statements are not consistent: if its a StAX filter its a StAX > > filter - there's no message context involved. If you want the MC then > > the right solution is a handler. > > <noga> I agree about using handler as primary processor. Filter helps > > the handler by doing some process instead of handler. There are some > > processes which is processed more efficiently on StAXEvent than on OM > > tree. Filter will cooperate with handler. So messageContext is need to > > transfer the results of filter's processing to handler. </noga> > > > > > C) A Filter may have access to the Builder so that it can access the > > > OM tree. (This was the BuilderAwareReader code that was > > > added to Axiom as part of WSCOMMONS-76). > > > > Again that doesn't make sense to me - if you want to filter at the OM > > level that's essentially what a handler is. If you want to filter at the > > StAX level I can certainly see it has some value but I'm not convinced > > its of much general value .. the practicalities are going to be very > > hard to just remove some information items at the StAX level. > > <noga> If we winnow or convert some OM element, some attribute value or > > some test value at the OM level, we have to create the OM element which > > will be removed or converted soon. Remove scenario of Filter aims to > > winnow without creating such OM elements. </noga> > > > > > Usages of a Filter: > > > USAGE 1) If this SOAP node is the Ultimate SOAPReceiver, a user > > > provided Filter could remove SOAP Headers that will not be processed > > > by the node. > > > Filtering the headers could increase performance and reduce the memory > > > usage. > > > > If you remove the headers that are not processed at the node then they > > will not be propagated to other nodes; that's incorrect behavior for an > > intermediary. > > > > In any case, that's what handlers are for. > > <noga> I think so too, this example is not good for intermediary</noga> > > > > > USAGE 2) If a QOS handler requires access to certain om nodes, the QOS > > > provider could provide a Filter that caches the location of these > > > nodes as the events are streamed. The end result is that the QOS > > > handler has direct access to the nodes without doing a costly > > > traversal. > > > > ?? Again that seems very fishy to me- you're going to examine each and > > every element that's going thru to identify the one element you care > > about. That means you'll slow everything down .. I don't see how > > navigating the OM tree will be slower in general. > > <noga> If we want to get only one element by using filter, To avoid > > to examne against all element, iFilter shuold disable itself when > > the first target is found. But this scenario is not realistic, > > One of the possible use cases for filter is for checking uniqness of a > piece of data, if this is implemented in using filter, the check and > enforcement can be done during the parsing of the message. This will save > the walking of the OM tree again. > > > > > For example, "Id" attribute can be set on any elements. and it is > > usually used to refer the target element. When we want to get the > > OM element which has the id at handler layer, we can not know where > > the OM element locates in the OM tree. we have to traverse the tree > > to find the element. > > we can make map which returns OM element corresponding specified "Id" > > value on filter layer by using this pick up filter. Then we can access > > to the element directly. I think this is efficient and realistic > scenario </noga> > > > > > > Rich Scheuerle > > IBM Web Services > > Apache Axis2 ([EMAIL PROTECTED]) > > 512-838-5115 (IBM TL 678-5115) > > [image removed] Sanjiva Weerawarana <[EMAIL PROTECTED]> > > > > > > > Sanjiva Weerawarana <[EMAIL PROTECTED]> > > 10/24/2006 06:50 PM > > > > Please respond to > > [email protected] > > > > [image removed] > > To > > > > [image removed] > > [email protected] > > > > [image removed] > > cc > > > > [image removed] > > > > [image removed] > > Subject > > > > [image removed] > > Re: Request for XML Filter (AXIS2-1085) > > > > [image removed] > > > > [image removed] > > > > > > On Tue, 2006-10-24 at 12:15 -0500, R J Scheuerle Jr wrote: > > > Takahide would like a plugin, which he calls a Filter, which satisfies > > > the following requirements. > > > A) A Filter wraps an input XMLStreamReader and implements an > > > XMLStreamReader. The Filter intercepts each StAX event and can > > > propogate the event. > > > > > > B) A Filter has access to the Axis 2 MessageContext. > > > > These two statements are not consistent: if its a StAX filter its a StAX > > filter - there's no message context involved. If you want the MC then > > the right solution is a handler. > > > > > C) A Filter may have access to the Builder so that it can access the > > > OM tree. (This was the BuilderAwareReader code that was > > > added to Axiom as part of WSCOMMONS-76). > > > > Again that doesn't make sense to me - if you want to filter at the OM > > level that's essentially what a handler is. If you want to filter at the > > StAX level I can certainly see it has some value but I'm not convinced > > its of much general value .. the practicalities are going to be very > > hard to just remove some information items at the StAX level. > > > > > Usages of a Filter: > > > USAGE 1) If this SOAP node is the Ultimate SOAPReceiver, a user > > > provided Filter could remove SOAP Headers that will not be processed > > > by the node. > > > Filtering the headers could increase performance and reduce the memory > > > usage. > > > > If you remove the headers that are not processed at the node then they > > will not be propagated to other nodes; that's incorrect behavior for an > > intermediary. > > > > In any case, that's what handlers are for. > > > > > USAGE 2) If a QOS handler requires access to certain om nodes, the QOS > > > provider could provide a Filter that caches the location of these > > > nodes as the events are streamed. The end result is that the QOS > > > handler has direct access to the nodes without doing a costly > > > traversal. > > > > ?? Again that seems very fishy to me- you're going to examine each and > > every element that's going thru to identify the one element you care > > about. That means you'll slow everything down .. I don't see how > > navigating the OM tree will be slower in general. > > > > Sanjiva. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > [image removed] > > > > Thanks, > Henry > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > [image removed] Thanks, Henry --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
