You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@xml.apache.org by pa...@us.ibm.com on 2000/08/29 20:59:17 UTC
Suggestion for feature
Hello all,
Being new to this area, I hope this is the right place to suggest a feature
for the Apache SOAP package (if it isn't please direct me to a better one,
thanks).
After playing with the soap engine for a bit, it occurred to me that a very
useful feature would be the ability to register one or more "filters" with
the engine that are evoked when messages comes into or leaves the soap
engine (that is to say when the soap xml is received or about to be shipped
off -- first and last point of control).
Or put another way, I'd love to see an interface for receiving notice when
something comes into or goes out of the soap servlet/jsp (registered
separately). Ideally such a filter would also have the ability to change
the messages that come in or go out of the engine before passing it onto
the engine itself in addition to the option of doing nothing. Such a hook
would be very useful for debugging and analysis (since no tunnel would then
be needed to see the messages, and they could be redirected to other
systems etc.), logging, and perhaps in some cases transformations or
substitutions of the whole or even part of the message coming in or going
out of the engine.
Just some thoughts
Mike Paolini
IBM Emerging Tech.
----------------------------------------------------------------------------------------------------------------------------------
"A doctor can bury his mistakes, an architect can only advise his client to
plant vines...." -Frank Lloyd Wright
Internet ID: paolini@us.ibm.com
IBM Internal e-mail ID: PAOLINI/Austin/IBM
Re: Suggestion for feature
Posted by Vahe Amirbekyan <av...@techone.com>.
Hi,
> I am just curious about one thing: what kind of transformations do you
> do to the input ?
The transformers can be as usefuls as filters are in CORBA, or even more
:). Suppose you are sending the same data to several destinations in B2B
application, you might want to make some changes in the data you want to
send depending on the specific target. Actually we used quite simple
XSLTs to test the tansformers mechanism. The potential benefits have yet
to be confirmed in a real-life application.
...Once again - we can apply transformers to selected messages based on
the following criteria:
- whether it is IN or OUT message
- target object(s)
- target method(s)
- specific document type
In the first three cases regex selection is used to identify the
specific transformers chain.
>
> I am also wondering if your stuff could not be used to increase
> interoperability between Apache-SOAP and MS-SOAP. I don't know if it is
> possible to have a XSLT transformation to convert a MS-SOAP request into
> a Apache-SOAP request.
This should be doable by using the transformers mechanism, in that case
we would have to define _per-doctype_ transformers in the RPCRouter,
which will be applied to all MS-SOAP incoming requests... As to the back
Apache2MS transformation, we would probably need to either expect MS to
handle SOAP requests in a similar way than we do (in that case we just
send Apache-SOAP reply back), or create some adiional frmework which
will register all calls coming from MS and apply appropriate Apache2MS
transformer to their replies... IMHO
What do you guys think?
Bye, Vahe
>
> What do you guys think ?
>
> Jean-Noel
>
> Vahe Amirbekyan wrote:
> >
> > Salut Jean-Noel,
> >
> > > First of all, sorry for answering you so late. I saw your e-mail but did
> > > not have time to answer it sooner.
> >
> > It's OK, we all are kind of busy, and not only with the SOAP ;)
> >
> > > I think your work is VERY interesting and is going in the right
> > > direction.
> > >
> >
> > Thanks for encouraging words.
> >
> > > I will just put quickly my remarks/questions:
> > >
> > > I like your concept of XML Transformers. From what I understand, it is
> > > just based on XSLT. I am wondering if you could give some examples of
> > > usage of those transformers. Further, how do you apply them ? Do you
> > > serialize first in memory (standard Apache-SOAP serializer) and then
> > > apply the XSLT transformations ?
> >
> > We defined a special interface - Transformer for all classes who perform
> > XML->XML transformation. Plus we defined TransformerChain class which
> > links all Transformer objects into a chain. I'm attaching the generated
> > Javadoc, not very rich one, but hopefully can shed some light on the
> > issue...
> >
> > As I mentioned, we enhanced DeploymentDescriptorby putting there the
> > transformations declaration (naturally, I had to add a similar stuff as
> > it is with TypeMappings - a class and its serializer). The declaration
> > is stored in the *.ds file. When ServiceManager loads the DD's
> > hashtable, it also those declarations and loads the cache of
> > transformers, i.e. a hashtable with '[IN|OUT]_[targetID|methodID] as
> > keys and pre-built transformation chains (which it builds eagerly) as
> > values. A similar process takes place on the client side, but since we
> > generate clients (SOAP proxies) we can insert the code of transformers
> > creation and use in the client code directly.
> >
> > We subclassed the Envelope, Call and Response classes, so that they make
> > use of pre-built transformer chains. The Envelope has an additional
> > transformer chain attribute, which is applied before the Envelope is
> > unmarshalled and after it is marshalled. This Envelope is used to send
> > SOAP messages across the net. E.g. our Call has attributes and get/set
> > operations for transformer chains designated for incoming and outgoing
> > invocations, which it uses to initialize the Envelops: it overloads
> > buildEnvelope() and invoke() operations to send the messages using our
> > subclassed Envelope.
> >
> > Sorry, I suppose my explanation is not that clear, huh? I'll try to send
> > next time the javadoc and also maybe the code sample...
> >
> > > I think your addition to the deployment descriptor should be taken into
> > > account in the new architecture. It would be interesting if you can give
> > > us more information on it.
> >
> > I used IBM's alphaWorks open source regex package
> > (http://www.alphaworks.ibm.com/aw.nsf/techmain/F81E7D23B1C01F1A8825690E000161D7?OpenDocument)
> > in our (again tweaked) Service Manager. Actually, this wasn't much
> > problem since it just instead of
> > dd = (DeploymentDescriptor) dds.get/put (id);
> > uses
> > dd = (DeploymentDescriptor) dds.get/put (new REStringKey(id));
> > where REStringKey is a string-wrapping class which overloads equals()
> > and hashCode() functions.
> >
> > > I am really looking forward your contribution to the Apache-SOAP
> > > project. I think your work can interest a lot of people. I did not
> > > really mention your Locator related stuff because I did not really dug
> > > into this piece, but I seems interesting as well.
> >
> > Locator is just some more sophisticated class loader. We use it in our
> > RPCRouterServlet instead of Class.newInstance() used in Apache-SOAP. The
> > use of Locator makes it possible to operate with URN - in the similar
> > way like CORBA's IOR. In the Locator we enhanced the classic Chain of
> > Responsibility pattern to make it really flexible and pluginable.
> > Currently I am working on a paper describing the final design of the
> > Locator...
> >
> > Currently our RPCRouter performs the following steps (I'm reusing a text
> > I produced for some other occasion :):
> >
> > 1. get the XML (envelope containing the call)
> > 2. parse the XML and get the DOM
> > 3. see if there's a DocType-based transformation declared (in a
> > separate *.ini file), if yes - invoke the transformers. As a result we'd
> > get SOAP-compliant XML
> > 4. get the target URI from the DOM tree (this is required since we
> > want
> > to retrieve DD and transformers information _before_ the unmarshalling)
> > 5. query service manager about the Deployment Descriptor for the
> > target
> > object using the target URI (regular expression-based comparison takes
> > place!)
> > 6. using the returned DD get information about incoming
> > transformers
> > 7. find the chain of transformers (created when the
> > DeploymentDescriptors were read from the storage)
> > 8. invoke static TransformableEnvelope.unmarshall(transformers
> > chain) to
> > get the Envelope (the XML will be processed by the transformers)
> > 9. invoke static Call.extractFromEnvelope() to get the Call
> > 10. using the DD get the list of supported methods and compares
> > to the actual method call (call validation)
> > 11. bind to Locator chain
> > 12. invoke Locator.getObjectWithName(target URI) to get reference to
> > the
> > target object
> > 13. use reflection to invoke the operation on the target object
> > 14. using the returned DD get information about outgoing
> > transformers
> > 15. find/create the chain of transformers
> > 16. build the TransformingResponse object
> > 17. send the response
> > a. build the TransformableEnvelope by invoking
> > buildEnvelope () on the
> > TransformingResponse object
> > b. marshal the TransformableEnvelope into out (the outgoing
> > XML will be
> > processed by transformers prior to sending)
> >
> >
> > > Question: When can we play with your stuff ? :-)
> >
> > The primary problem here is that some of our code is not yet ready for
> > exposure o the World :), so we would have to make some
> > selection/separation, which is not that easy. Hopefully I'll manage to
> > send the transformers stuff - which is not strictly related to the SOAP
> > (I mean the classes I sent javadoc about). Further, as I have your
> > comments/suggestions and as we manage to put everything into better
> > order, I'll send more.
> >
> > Looking forward to see your feedback, Vahe
> >
> > >
> > > Best regards,
> > > Jean-Noel
> > >
> > > Vahe Amirbekyan wrote:
> > > >
> > > > Hi,
> > > >
> > > > Actually we've implemented a similar mechanism in our current Enterprise
> > > > Application Integration project. Probably I should tell more about the
> > > > Project...
> > > >
> > > > At the heart of the project is the compiler which takes the business
> > > > model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> > > > SOAP (SOAP proxies) for the client side (for cases when our application
> > > > uses SOAP to communicate remote/external objects) and/or (2) XML
> > > > Deployment Descriptors for the server side (if our objects serve to
> > > > remote/external clients via SOAP). Our application (which n.b. is also
> > > > generated from the business model) is based on EJB. In some sense the
> > > > compiler's functionality is similar to those of NASSL toolkit.
> > > >
> > > > Now, in order to make the generated SOAP-based application more
> > > > scalable, flexible, usable in real life situations etc. we have also
> > > > extended Apache (former IBM) SOAP. Here are brief descriptions of some
> > > > of the new features we have introduced:
> > > >
> > > > - XML Transformers. We added something like CORBA filters to both ends
> > > > of SOAP interaction. Transformers can be applied on the client side to
> > > > outgoing requests (XML is transformed before it is sent to server),
> > > > incoming replies (transformed before it is parsed) or on the server side
> > > > - for incoming requests (before XML is parsed) and outgoing replies
> > > > (before XML is sent). Currently only one type of transformers -
> > > > XSL-based - are implemented, but you can plug in any kind of XML->XML
> > > > transformer. Transformers can be joined in chains. They can be declared
> > > > to be applied per class (for all methods of the class) and/or per
> > > > particular method of the class. For clients the transformers are created
> > > > in the SOAP proxy object and may be applied for each calls propagated to
> > > > the server. For servers we have added transformers declaration to the
> > > > Deployment Descriptor. Basically the transformer declaration declares
> > > > the id of the entity it should be applied to (class name or method
> > > > name), type (IN or OUT) and URI of the transformation declaration (name
> > > > of XSL file). Also on the server side we are going to introduce
> > > > document-kind-specific transformation, that is transformers applied not
> > > > on per-target basis but per XML's doctype. Thus the server would be able
> > > > to receive any kind of XML messages - not only SOAP ones.
> > > >
> > > > - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> > > > graphs of objects represented as trees of hashtables, vectors,
> > > > enumerations, and object references (see the next entry).
> > > >
> > > > - Locator/URN Generator. We use Unified Resource Name (URN) format for
> > > > our objects' identifiers/references -
> > > > "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> > > > being independent from the SOAP) is used to locate an individual object
> > > > having its URN. Locator is primarily used to reference EJBs, but its
> > > > design allows us to easily extend it to any kind of objects. We
> > > > introduced Locator in RPCRouter in the place of "simple" class loading.
> > > > URN based object references are used in the client-side SOAP proxies as
> > > > handles to remote objects and to set target objects in outgoing calls.
> > > > The references can be passed from server to the client as a result of an
> > > > operation invocations, and on the client side a new SOAP proxy is then
> > > > created/initialized with this reference.
> > > >
> > > > - Regular expression-based matching. Instead of simple string-based
> > > > matching on the server side during Deployment Descriptor querying
> > > > (ServiceManager uses hashtable to store DDs using the target object id
> > > > as a key) we use regular expression based matching. Thus one deployment
> > > > descriptor may be used to describe a set of target objects, which seems
> > > > to be more scalable solution.
> > > >
> > > > We actually were planning to contribute some of our code to the
> > > > Development Group, but first we have to identify the individual parts of
> > > > our extensions that can be introduced independently. I wonder if you
> > > > find it interesting.
> >
> > --
> > (\______________________________________________________/)
> > __|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
> > (___o) tel: (510) 729 6750 ext.375 (o___)
> > (__o) mailto:vahe@techone.com (o__)
> > (__o) http://www.techone.com (o__)
> > (_o)____________________________________________________(o_)
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:vahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Vahe Amirbekyan <av...@techone.com>.
Hi,
> I am just curious about one thing: what kind of transformations do you
> do to the input ?
The transformers can be as usefuls as filters are in CORBA, or even more
:). Suppose you are sending the same data to several destinations in B2B
application, you might want to make some changes in the data you want to
send depending on the specific target. Actually we used quite simple
XSLTs to test the tansformers mechanism. The potential benefits have yet
to be confirmed in a real-life application.
...Once again - we can apply transformers to selected messages based on
the following criteria:
- whether it is IN or OUT message
- target object(s)
- target method(s)
- specific document type
In the first three cases regex selection is used to identify the
specific transformers chain.
>
> I am also wondering if your stuff could not be used to increase
> interoperability between Apache-SOAP and MS-SOAP. I don't know if it is
> possible to have a XSLT transformation to convert a MS-SOAP request into
> a Apache-SOAP request.
This should be doable by using the transformers mechanism, in that case
we would have to define _per-doctype_ transformers in the RPCRouter,
which will be applied to all MS-SOAP incoming requests... As to the back
Apache2MS transformation, we would probably need to either expect MS to
handle SOAP requests in a similar way than we do (in that case we just
send Apache-SOAP reply back), or create some adiional frmework which
will register all calls coming from MS and apply appropriate Apache2MS
transformer to their replies... IMHO
What do you guys think?
Bye, Vahe
>
> What do you guys think ?
>
> Jean-Noel
>
> Vahe Amirbekyan wrote:
> >
> > Salut Jean-Noel,
> >
> > > First of all, sorry for answering you so late. I saw your e-mail but did
> > > not have time to answer it sooner.
> >
> > It's OK, we all are kind of busy, and not only with the SOAP ;)
> >
> > > I think your work is VERY interesting and is going in the right
> > > direction.
> > >
> >
> > Thanks for encouraging words.
> >
> > > I will just put quickly my remarks/questions:
> > >
> > > I like your concept of XML Transformers. From what I understand, it is
> > > just based on XSLT. I am wondering if you could give some examples of
> > > usage of those transformers. Further, how do you apply them ? Do you
> > > serialize first in memory (standard Apache-SOAP serializer) and then
> > > apply the XSLT transformations ?
> >
> > We defined a special interface - Transformer for all classes who perform
> > XML->XML transformation. Plus we defined TransformerChain class which
> > links all Transformer objects into a chain. I'm attaching the generated
> > Javadoc, not very rich one, but hopefully can shed some light on the
> > issue...
> >
> > As I mentioned, we enhanced DeploymentDescriptorby putting there the
> > transformations declaration (naturally, I had to add a similar stuff as
> > it is with TypeMappings - a class and its serializer). The declaration
> > is stored in the *.ds file. When ServiceManager loads the DD's
> > hashtable, it also those declarations and loads the cache of
> > transformers, i.e. a hashtable with '[IN|OUT]_[targetID|methodID] as
> > keys and pre-built transformation chains (which it builds eagerly) as
> > values. A similar process takes place on the client side, but since we
> > generate clients (SOAP proxies) we can insert the code of transformers
> > creation and use in the client code directly.
> >
> > We subclassed the Envelope, Call and Response classes, so that they make
> > use of pre-built transformer chains. The Envelope has an additional
> > transformer chain attribute, which is applied before the Envelope is
> > unmarshalled and after it is marshalled. This Envelope is used to send
> > SOAP messages across the net. E.g. our Call has attributes and get/set
> > operations for transformer chains designated for incoming and outgoing
> > invocations, which it uses to initialize the Envelops: it overloads
> > buildEnvelope() and invoke() operations to send the messages using our
> > subclassed Envelope.
> >
> > Sorry, I suppose my explanation is not that clear, huh? I'll try to send
> > next time the javadoc and also maybe the code sample...
> >
> > > I think your addition to the deployment descriptor should be taken into
> > > account in the new architecture. It would be interesting if you can give
> > > us more information on it.
> >
> > I used IBM's alphaWorks open source regex package
> > (http://www.alphaworks.ibm.com/aw.nsf/techmain/F81E7D23B1C01F1A8825690E000161D7?OpenDocument)
> > in our (again tweaked) Service Manager. Actually, this wasn't much
> > problem since it just instead of
> > dd = (DeploymentDescriptor) dds.get/put (id);
> > uses
> > dd = (DeploymentDescriptor) dds.get/put (new REStringKey(id));
> > where REStringKey is a string-wrapping class which overloads equals()
> > and hashCode() functions.
> >
> > > I am really looking forward your contribution to the Apache-SOAP
> > > project. I think your work can interest a lot of people. I did not
> > > really mention your Locator related stuff because I did not really dug
> > > into this piece, but I seems interesting as well.
> >
> > Locator is just some more sophisticated class loader. We use it in our
> > RPCRouterServlet instead of Class.newInstance() used in Apache-SOAP. The
> > use of Locator makes it possible to operate with URN - in the similar
> > way like CORBA's IOR. In the Locator we enhanced the classic Chain of
> > Responsibility pattern to make it really flexible and pluginable.
> > Currently I am working on a paper describing the final design of the
> > Locator...
> >
> > Currently our RPCRouter performs the following steps (I'm reusing a text
> > I produced for some other occasion :):
> >
> > 1. get the XML (envelope containing the call)
> > 2. parse the XML and get the DOM
> > 3. see if there's a DocType-based transformation declared (in a
> > separate *.ini file), if yes - invoke the transformers. As a result we'd
> > get SOAP-compliant XML
> > 4. get the target URI from the DOM tree (this is required since we
> > want
> > to retrieve DD and transformers information _before_ the unmarshalling)
> > 5. query service manager about the Deployment Descriptor for the
> > target
> > object using the target URI (regular expression-based comparison takes
> > place!)
> > 6. using the returned DD get information about incoming
> > transformers
> > 7. find the chain of transformers (created when the
> > DeploymentDescriptors were read from the storage)
> > 8. invoke static TransformableEnvelope.unmarshall(transformers
> > chain) to
> > get the Envelope (the XML will be processed by the transformers)
> > 9. invoke static Call.extractFromEnvelope() to get the Call
> > 10. using the DD get the list of supported methods and compares
> > to the actual method call (call validation)
> > 11. bind to Locator chain
> > 12. invoke Locator.getObjectWithName(target URI) to get reference to
> > the
> > target object
> > 13. use reflection to invoke the operation on the target object
> > 14. using the returned DD get information about outgoing
> > transformers
> > 15. find/create the chain of transformers
> > 16. build the TransformingResponse object
> > 17. send the response
> > a. build the TransformableEnvelope by invoking
> > buildEnvelope () on the
> > TransformingResponse object
> > b. marshal the TransformableEnvelope into out (the outgoing
> > XML will be
> > processed by transformers prior to sending)
> >
> >
> > > Question: When can we play with your stuff ? :-)
> >
> > The primary problem here is that some of our code is not yet ready for
> > exposure o the World :), so we would have to make some
> > selection/separation, which is not that easy. Hopefully I'll manage to
> > send the transformers stuff - which is not strictly related to the SOAP
> > (I mean the classes I sent javadoc about). Further, as I have your
> > comments/suggestions and as we manage to put everything into better
> > order, I'll send more.
> >
> > Looking forward to see your feedback, Vahe
> >
> > >
> > > Best regards,
> > > Jean-Noel
> > >
> > > Vahe Amirbekyan wrote:
> > > >
> > > > Hi,
> > > >
> > > > Actually we've implemented a similar mechanism in our current Enterprise
> > > > Application Integration project. Probably I should tell more about the
> > > > Project...
> > > >
> > > > At the heart of the project is the compiler which takes the business
> > > > model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> > > > SOAP (SOAP proxies) for the client side (for cases when our application
> > > > uses SOAP to communicate remote/external objects) and/or (2) XML
> > > > Deployment Descriptors for the server side (if our objects serve to
> > > > remote/external clients via SOAP). Our application (which n.b. is also
> > > > generated from the business model) is based on EJB. In some sense the
> > > > compiler's functionality is similar to those of NASSL toolkit.
> > > >
> > > > Now, in order to make the generated SOAP-based application more
> > > > scalable, flexible, usable in real life situations etc. we have also
> > > > extended Apache (former IBM) SOAP. Here are brief descriptions of some
> > > > of the new features we have introduced:
> > > >
> > > > - XML Transformers. We added something like CORBA filters to both ends
> > > > of SOAP interaction. Transformers can be applied on the client side to
> > > > outgoing requests (XML is transformed before it is sent to server),
> > > > incoming replies (transformed before it is parsed) or on the server side
> > > > - for incoming requests (before XML is parsed) and outgoing replies
> > > > (before XML is sent). Currently only one type of transformers -
> > > > XSL-based - are implemented, but you can plug in any kind of XML->XML
> > > > transformer. Transformers can be joined in chains. They can be declared
> > > > to be applied per class (for all methods of the class) and/or per
> > > > particular method of the class. For clients the transformers are created
> > > > in the SOAP proxy object and may be applied for each calls propagated to
> > > > the server. For servers we have added transformers declaration to the
> > > > Deployment Descriptor. Basically the transformer declaration declares
> > > > the id of the entity it should be applied to (class name or method
> > > > name), type (IN or OUT) and URI of the transformation declaration (name
> > > > of XSL file). Also on the server side we are going to introduce
> > > > document-kind-specific transformation, that is transformers applied not
> > > > on per-target basis but per XML's doctype. Thus the server would be able
> > > > to receive any kind of XML messages - not only SOAP ones.
> > > >
> > > > - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> > > > graphs of objects represented as trees of hashtables, vectors,
> > > > enumerations, and object references (see the next entry).
> > > >
> > > > - Locator/URN Generator. We use Unified Resource Name (URN) format for
> > > > our objects' identifiers/references -
> > > > "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> > > > being independent from the SOAP) is used to locate an individual object
> > > > having its URN. Locator is primarily used to reference EJBs, but its
> > > > design allows us to easily extend it to any kind of objects. We
> > > > introduced Locator in RPCRouter in the place of "simple" class loading.
> > > > URN based object references are used in the client-side SOAP proxies as
> > > > handles to remote objects and to set target objects in outgoing calls.
> > > > The references can be passed from server to the client as a result of an
> > > > operation invocations, and on the client side a new SOAP proxy is then
> > > > created/initialized with this reference.
> > > >
> > > > - Regular expression-based matching. Instead of simple string-based
> > > > matching on the server side during Deployment Descriptor querying
> > > > (ServiceManager uses hashtable to store DDs using the target object id
> > > > as a key) we use regular expression based matching. Thus one deployment
> > > > descriptor may be used to describe a set of target objects, which seems
> > > > to be more scalable solution.
> > > >
> > > > We actually were planning to contribute some of our code to the
> > > > Development Group, but first we have to identify the individual parts of
> > > > our extensions that can be introduced independently. I wonder if you
> > > > find it interesting.
> >
> > --
> > (\______________________________________________________/)
> > __|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
> > (___o) tel: (510) 729 6750 ext.375 (o___)
> > (__o) mailto:vahe@techone.com (o__)
> > (__o) http://www.techone.com (o__)
> > (_o)____________________________________________________(o_)
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:vahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Jean-Noel Gadreau <jn...@activcard.com>.
I am just curious about one thing: what kind of transformations do you
do to the input ?
I am also wondering if your stuff could not be used to increase
interoperability between Apache-SOAP and MS-SOAP. I don't know if it is
possible to have a XSLT transformation to convert a MS-SOAP request into
a Apache-SOAP request.
What do you guys think ?
Jean-Noel
Vahe Amirbekyan wrote:
>
> Salut Jean-Noel,
>
> > First of all, sorry for answering you so late. I saw your e-mail but did
> > not have time to answer it sooner.
>
> It's OK, we all are kind of busy, and not only with the SOAP ;)
>
> > I think your work is VERY interesting and is going in the right
> > direction.
> >
>
> Thanks for encouraging words.
>
> > I will just put quickly my remarks/questions:
> >
> > I like your concept of XML Transformers. From what I understand, it is
> > just based on XSLT. I am wondering if you could give some examples of
> > usage of those transformers. Further, how do you apply them ? Do you
> > serialize first in memory (standard Apache-SOAP serializer) and then
> > apply the XSLT transformations ?
>
> We defined a special interface - Transformer for all classes who perform
> XML->XML transformation. Plus we defined TransformerChain class which
> links all Transformer objects into a chain. I'm attaching the generated
> Javadoc, not very rich one, but hopefully can shed some light on the
> issue...
>
> As I mentioned, we enhanced DeploymentDescriptorby putting there the
> transformations declaration (naturally, I had to add a similar stuff as
> it is with TypeMappings - a class and its serializer). The declaration
> is stored in the *.ds file. When ServiceManager loads the DD's
> hashtable, it also those declarations and loads the cache of
> transformers, i.e. a hashtable with '[IN|OUT]_[targetID|methodID] as
> keys and pre-built transformation chains (which it builds eagerly) as
> values. A similar process takes place on the client side, but since we
> generate clients (SOAP proxies) we can insert the code of transformers
> creation and use in the client code directly.
>
> We subclassed the Envelope, Call and Response classes, so that they make
> use of pre-built transformer chains. The Envelope has an additional
> transformer chain attribute, which is applied before the Envelope is
> unmarshalled and after it is marshalled. This Envelope is used to send
> SOAP messages across the net. E.g. our Call has attributes and get/set
> operations for transformer chains designated for incoming and outgoing
> invocations, which it uses to initialize the Envelops: it overloads
> buildEnvelope() and invoke() operations to send the messages using our
> subclassed Envelope.
>
> Sorry, I suppose my explanation is not that clear, huh? I'll try to send
> next time the javadoc and also maybe the code sample...
>
> > I think your addition to the deployment descriptor should be taken into
> > account in the new architecture. It would be interesting if you can give
> > us more information on it.
>
> I used IBM's alphaWorks open source regex package
> (http://www.alphaworks.ibm.com/aw.nsf/techmain/F81E7D23B1C01F1A8825690E000161D7?OpenDocument)
> in our (again tweaked) Service Manager. Actually, this wasn't much
> problem since it just instead of
> dd = (DeploymentDescriptor) dds.get/put (id);
> uses
> dd = (DeploymentDescriptor) dds.get/put (new REStringKey(id));
> where REStringKey is a string-wrapping class which overloads equals()
> and hashCode() functions.
>
> > I am really looking forward your contribution to the Apache-SOAP
> > project. I think your work can interest a lot of people. I did not
> > really mention your Locator related stuff because I did not really dug
> > into this piece, but I seems interesting as well.
>
> Locator is just some more sophisticated class loader. We use it in our
> RPCRouterServlet instead of Class.newInstance() used in Apache-SOAP. The
> use of Locator makes it possible to operate with URN - in the similar
> way like CORBA's IOR. In the Locator we enhanced the classic Chain of
> Responsibility pattern to make it really flexible and pluginable.
> Currently I am working on a paper describing the final design of the
> Locator...
>
> Currently our RPCRouter performs the following steps (I'm reusing a text
> I produced for some other occasion :):
>
> 1. get the XML (envelope containing the call)
> 2. parse the XML and get the DOM
> 3. see if there's a DocType-based transformation declared (in a
> separate *.ini file), if yes - invoke the transformers. As a result we'd
> get SOAP-compliant XML
> 4. get the target URI from the DOM tree (this is required since we
> want
> to retrieve DD and transformers information _before_ the unmarshalling)
> 5. query service manager about the Deployment Descriptor for the
> target
> object using the target URI (regular expression-based comparison takes
> place!)
> 6. using the returned DD get information about incoming
> transformers
> 7. find the chain of transformers (created when the
> DeploymentDescriptors were read from the storage)
> 8. invoke static TransformableEnvelope.unmarshall(transformers
> chain) to
> get the Envelope (the XML will be processed by the transformers)
> 9. invoke static Call.extractFromEnvelope() to get the Call
> 10. using the DD get the list of supported methods and compares
> to the actual method call (call validation)
> 11. bind to Locator chain
> 12. invoke Locator.getObjectWithName(target URI) to get reference to
> the
> target object
> 13. use reflection to invoke the operation on the target object
> 14. using the returned DD get information about outgoing
> transformers
> 15. find/create the chain of transformers
> 16. build the TransformingResponse object
> 17. send the response
> a. build the TransformableEnvelope by invoking
> buildEnvelope () on the
> TransformingResponse object
> b. marshal the TransformableEnvelope into out (the outgoing
> XML will be
> processed by transformers prior to sending)
>
>
> > Question: When can we play with your stuff ? :-)
>
> The primary problem here is that some of our code is not yet ready for
> exposure o the World :), so we would have to make some
> selection/separation, which is not that easy. Hopefully I'll manage to
> send the transformers stuff - which is not strictly related to the SOAP
> (I mean the classes I sent javadoc about). Further, as I have your
> comments/suggestions and as we manage to put everything into better
> order, I'll send more.
>
> Looking forward to see your feedback, Vahe
>
> >
> > Best regards,
> > Jean-Noel
> >
> > Vahe Amirbekyan wrote:
> > >
> > > Hi,
> > >
> > > Actually we've implemented a similar mechanism in our current Enterprise
> > > Application Integration project. Probably I should tell more about the
> > > Project...
> > >
> > > At the heart of the project is the compiler which takes the business
> > > model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> > > SOAP (SOAP proxies) for the client side (for cases when our application
> > > uses SOAP to communicate remote/external objects) and/or (2) XML
> > > Deployment Descriptors for the server side (if our objects serve to
> > > remote/external clients via SOAP). Our application (which n.b. is also
> > > generated from the business model) is based on EJB. In some sense the
> > > compiler's functionality is similar to those of NASSL toolkit.
> > >
> > > Now, in order to make the generated SOAP-based application more
> > > scalable, flexible, usable in real life situations etc. we have also
> > > extended Apache (former IBM) SOAP. Here are brief descriptions of some
> > > of the new features we have introduced:
> > >
> > > - XML Transformers. We added something like CORBA filters to both ends
> > > of SOAP interaction. Transformers can be applied on the client side to
> > > outgoing requests (XML is transformed before it is sent to server),
> > > incoming replies (transformed before it is parsed) or on the server side
> > > - for incoming requests (before XML is parsed) and outgoing replies
> > > (before XML is sent). Currently only one type of transformers -
> > > XSL-based - are implemented, but you can plug in any kind of XML->XML
> > > transformer. Transformers can be joined in chains. They can be declared
> > > to be applied per class (for all methods of the class) and/or per
> > > particular method of the class. For clients the transformers are created
> > > in the SOAP proxy object and may be applied for each calls propagated to
> > > the server. For servers we have added transformers declaration to the
> > > Deployment Descriptor. Basically the transformer declaration declares
> > > the id of the entity it should be applied to (class name or method
> > > name), type (IN or OUT) and URI of the transformation declaration (name
> > > of XSL file). Also on the server side we are going to introduce
> > > document-kind-specific transformation, that is transformers applied not
> > > on per-target basis but per XML's doctype. Thus the server would be able
> > > to receive any kind of XML messages - not only SOAP ones.
> > >
> > > - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> > > graphs of objects represented as trees of hashtables, vectors,
> > > enumerations, and object references (see the next entry).
> > >
> > > - Locator/URN Generator. We use Unified Resource Name (URN) format for
> > > our objects' identifiers/references -
> > > "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> > > being independent from the SOAP) is used to locate an individual object
> > > having its URN. Locator is primarily used to reference EJBs, but its
> > > design allows us to easily extend it to any kind of objects. We
> > > introduced Locator in RPCRouter in the place of "simple" class loading.
> > > URN based object references are used in the client-side SOAP proxies as
> > > handles to remote objects and to set target objects in outgoing calls.
> > > The references can be passed from server to the client as a result of an
> > > operation invocations, and on the client side a new SOAP proxy is then
> > > created/initialized with this reference.
> > >
> > > - Regular expression-based matching. Instead of simple string-based
> > > matching on the server side during Deployment Descriptor querying
> > > (ServiceManager uses hashtable to store DDs using the target object id
> > > as a key) we use regular expression based matching. Thus one deployment
> > > descriptor may be used to describe a set of target objects, which seems
> > > to be more scalable solution.
> > >
> > > We actually were planning to contribute some of our code to the
> > > Development Group, but first we have to identify the individual parts of
> > > our extensions that can be introduced independently. I wonder if you
> > > find it interesting.
>
> --
> (\______________________________________________________/)
> __|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
> (___o) tel: (510) 729 6750 ext.375 (o___)
> (__o) mailto:vahe@techone.com (o__)
> (__o) http://www.techone.com (o__)
> (_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Jean-Noel Gadreau <jn...@activcard.com>.
I am just curious about one thing: what kind of transformations do you
do to the input ?
I am also wondering if your stuff could not be used to increase
interoperability between Apache-SOAP and MS-SOAP. I don't know if it is
possible to have a XSLT transformation to convert a MS-SOAP request into
a Apache-SOAP request.
What do you guys think ?
Jean-Noel
Vahe Amirbekyan wrote:
>
> Salut Jean-Noel,
>
> > First of all, sorry for answering you so late. I saw your e-mail but did
> > not have time to answer it sooner.
>
> It's OK, we all are kind of busy, and not only with the SOAP ;)
>
> > I think your work is VERY interesting and is going in the right
> > direction.
> >
>
> Thanks for encouraging words.
>
> > I will just put quickly my remarks/questions:
> >
> > I like your concept of XML Transformers. From what I understand, it is
> > just based on XSLT. I am wondering if you could give some examples of
> > usage of those transformers. Further, how do you apply them ? Do you
> > serialize first in memory (standard Apache-SOAP serializer) and then
> > apply the XSLT transformations ?
>
> We defined a special interface - Transformer for all classes who perform
> XML->XML transformation. Plus we defined TransformerChain class which
> links all Transformer objects into a chain. I'm attaching the generated
> Javadoc, not very rich one, but hopefully can shed some light on the
> issue...
>
> As I mentioned, we enhanced DeploymentDescriptorby putting there the
> transformations declaration (naturally, I had to add a similar stuff as
> it is with TypeMappings - a class and its serializer). The declaration
> is stored in the *.ds file. When ServiceManager loads the DD's
> hashtable, it also those declarations and loads the cache of
> transformers, i.e. a hashtable with '[IN|OUT]_[targetID|methodID] as
> keys and pre-built transformation chains (which it builds eagerly) as
> values. A similar process takes place on the client side, but since we
> generate clients (SOAP proxies) we can insert the code of transformers
> creation and use in the client code directly.
>
> We subclassed the Envelope, Call and Response classes, so that they make
> use of pre-built transformer chains. The Envelope has an additional
> transformer chain attribute, which is applied before the Envelope is
> unmarshalled and after it is marshalled. This Envelope is used to send
> SOAP messages across the net. E.g. our Call has attributes and get/set
> operations for transformer chains designated for incoming and outgoing
> invocations, which it uses to initialize the Envelops: it overloads
> buildEnvelope() and invoke() operations to send the messages using our
> subclassed Envelope.
>
> Sorry, I suppose my explanation is not that clear, huh? I'll try to send
> next time the javadoc and also maybe the code sample...
>
> > I think your addition to the deployment descriptor should be taken into
> > account in the new architecture. It would be interesting if you can give
> > us more information on it.
>
> I used IBM's alphaWorks open source regex package
> (http://www.alphaworks.ibm.com/aw.nsf/techmain/F81E7D23B1C01F1A8825690E000161D7?OpenDocument)
> in our (again tweaked) Service Manager. Actually, this wasn't much
> problem since it just instead of
> dd = (DeploymentDescriptor) dds.get/put (id);
> uses
> dd = (DeploymentDescriptor) dds.get/put (new REStringKey(id));
> where REStringKey is a string-wrapping class which overloads equals()
> and hashCode() functions.
>
> > I am really looking forward your contribution to the Apache-SOAP
> > project. I think your work can interest a lot of people. I did not
> > really mention your Locator related stuff because I did not really dug
> > into this piece, but I seems interesting as well.
>
> Locator is just some more sophisticated class loader. We use it in our
> RPCRouterServlet instead of Class.newInstance() used in Apache-SOAP. The
> use of Locator makes it possible to operate with URN - in the similar
> way like CORBA's IOR. In the Locator we enhanced the classic Chain of
> Responsibility pattern to make it really flexible and pluginable.
> Currently I am working on a paper describing the final design of the
> Locator...
>
> Currently our RPCRouter performs the following steps (I'm reusing a text
> I produced for some other occasion :):
>
> 1. get the XML (envelope containing the call)
> 2. parse the XML and get the DOM
> 3. see if there's a DocType-based transformation declared (in a
> separate *.ini file), if yes - invoke the transformers. As a result we'd
> get SOAP-compliant XML
> 4. get the target URI from the DOM tree (this is required since we
> want
> to retrieve DD and transformers information _before_ the unmarshalling)
> 5. query service manager about the Deployment Descriptor for the
> target
> object using the target URI (regular expression-based comparison takes
> place!)
> 6. using the returned DD get information about incoming
> transformers
> 7. find the chain of transformers (created when the
> DeploymentDescriptors were read from the storage)
> 8. invoke static TransformableEnvelope.unmarshall(transformers
> chain) to
> get the Envelope (the XML will be processed by the transformers)
> 9. invoke static Call.extractFromEnvelope() to get the Call
> 10. using the DD get the list of supported methods and compares
> to the actual method call (call validation)
> 11. bind to Locator chain
> 12. invoke Locator.getObjectWithName(target URI) to get reference to
> the
> target object
> 13. use reflection to invoke the operation on the target object
> 14. using the returned DD get information about outgoing
> transformers
> 15. find/create the chain of transformers
> 16. build the TransformingResponse object
> 17. send the response
> a. build the TransformableEnvelope by invoking
> buildEnvelope () on the
> TransformingResponse object
> b. marshal the TransformableEnvelope into out (the outgoing
> XML will be
> processed by transformers prior to sending)
>
>
> > Question: When can we play with your stuff ? :-)
>
> The primary problem here is that some of our code is not yet ready for
> exposure o the World :), so we would have to make some
> selection/separation, which is not that easy. Hopefully I'll manage to
> send the transformers stuff - which is not strictly related to the SOAP
> (I mean the classes I sent javadoc about). Further, as I have your
> comments/suggestions and as we manage to put everything into better
> order, I'll send more.
>
> Looking forward to see your feedback, Vahe
>
> >
> > Best regards,
> > Jean-Noel
> >
> > Vahe Amirbekyan wrote:
> > >
> > > Hi,
> > >
> > > Actually we've implemented a similar mechanism in our current Enterprise
> > > Application Integration project. Probably I should tell more about the
> > > Project...
> > >
> > > At the heart of the project is the compiler which takes the business
> > > model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> > > SOAP (SOAP proxies) for the client side (for cases when our application
> > > uses SOAP to communicate remote/external objects) and/or (2) XML
> > > Deployment Descriptors for the server side (if our objects serve to
> > > remote/external clients via SOAP). Our application (which n.b. is also
> > > generated from the business model) is based on EJB. In some sense the
> > > compiler's functionality is similar to those of NASSL toolkit.
> > >
> > > Now, in order to make the generated SOAP-based application more
> > > scalable, flexible, usable in real life situations etc. we have also
> > > extended Apache (former IBM) SOAP. Here are brief descriptions of some
> > > of the new features we have introduced:
> > >
> > > - XML Transformers. We added something like CORBA filters to both ends
> > > of SOAP interaction. Transformers can be applied on the client side to
> > > outgoing requests (XML is transformed before it is sent to server),
> > > incoming replies (transformed before it is parsed) or on the server side
> > > - for incoming requests (before XML is parsed) and outgoing replies
> > > (before XML is sent). Currently only one type of transformers -
> > > XSL-based - are implemented, but you can plug in any kind of XML->XML
> > > transformer. Transformers can be joined in chains. They can be declared
> > > to be applied per class (for all methods of the class) and/or per
> > > particular method of the class. For clients the transformers are created
> > > in the SOAP proxy object and may be applied for each calls propagated to
> > > the server. For servers we have added transformers declaration to the
> > > Deployment Descriptor. Basically the transformer declaration declares
> > > the id of the entity it should be applied to (class name or method
> > > name), type (IN or OUT) and URI of the transformation declaration (name
> > > of XSL file). Also on the server side we are going to introduce
> > > document-kind-specific transformation, that is transformers applied not
> > > on per-target basis but per XML's doctype. Thus the server would be able
> > > to receive any kind of XML messages - not only SOAP ones.
> > >
> > > - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> > > graphs of objects represented as trees of hashtables, vectors,
> > > enumerations, and object references (see the next entry).
> > >
> > > - Locator/URN Generator. We use Unified Resource Name (URN) format for
> > > our objects' identifiers/references -
> > > "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> > > being independent from the SOAP) is used to locate an individual object
> > > having its URN. Locator is primarily used to reference EJBs, but its
> > > design allows us to easily extend it to any kind of objects. We
> > > introduced Locator in RPCRouter in the place of "simple" class loading.
> > > URN based object references are used in the client-side SOAP proxies as
> > > handles to remote objects and to set target objects in outgoing calls.
> > > The references can be passed from server to the client as a result of an
> > > operation invocations, and on the client side a new SOAP proxy is then
> > > created/initialized with this reference.
> > >
> > > - Regular expression-based matching. Instead of simple string-based
> > > matching on the server side during Deployment Descriptor querying
> > > (ServiceManager uses hashtable to store DDs using the target object id
> > > as a key) we use regular expression based matching. Thus one deployment
> > > descriptor may be used to describe a set of target objects, which seems
> > > to be more scalable solution.
> > >
> > > We actually were planning to contribute some of our code to the
> > > Development Group, but first we have to identify the individual parts of
> > > our extensions that can be introduced independently. I wonder if you
> > > find it interesting.
>
> --
> (\______________________________________________________/)
> __|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
> (___o) tel: (510) 729 6750 ext.375 (o___)
> (__o) mailto:vahe@techone.com (o__)
> (__o) http://www.techone.com (o__)
> (_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Vahe Amirbekyan <av...@techone.com>.
Salut Jean-Noel,
> First of all, sorry for answering you so late. I saw your e-mail but did
> not have time to answer it sooner.
It's OK, we all are kind of busy, and not only with the SOAP ;)
> I think your work is VERY interesting and is going in the right
> direction.
>
Thanks for encouraging words.
> I will just put quickly my remarks/questions:
>
> I like your concept of XML Transformers. From what I understand, it is
> just based on XSLT. I am wondering if you could give some examples of
> usage of those transformers. Further, how do you apply them ? Do you
> serialize first in memory (standard Apache-SOAP serializer) and then
> apply the XSLT transformations ?
We defined a special interface - Transformer for all classes who perform
XML->XML transformation. Plus we defined TransformerChain class which
links all Transformer objects into a chain. I'm attaching the generated
Javadoc, not very rich one, but hopefully can shed some light on the
issue...
As I mentioned, we enhanced DeploymentDescriptorby putting there the
transformations declaration (naturally, I had to add a similar stuff as
it is with TypeMappings - a class and its serializer). The declaration
is stored in the *.ds file. When ServiceManager loads the DD's
hashtable, it also those declarations and loads the cache of
transformers, i.e. a hashtable with '[IN|OUT]_[targetID|methodID] as
keys and pre-built transformation chains (which it builds eagerly) as
values. A similar process takes place on the client side, but since we
generate clients (SOAP proxies) we can insert the code of transformers
creation and use in the client code directly.
We subclassed the Envelope, Call and Response classes, so that they make
use of pre-built transformer chains. The Envelope has an additional
transformer chain attribute, which is applied before the Envelope is
unmarshalled and after it is marshalled. This Envelope is used to send
SOAP messages across the net. E.g. our Call has attributes and get/set
operations for transformer chains designated for incoming and outgoing
invocations, which it uses to initialize the Envelops: it overloads
buildEnvelope() and invoke() operations to send the messages using our
subclassed Envelope.
Sorry, I suppose my explanation is not that clear, huh? I'll try to send
next time the javadoc and also maybe the code sample...
> I think your addition to the deployment descriptor should be taken into
> account in the new architecture. It would be interesting if you can give
> us more information on it.
I used IBM's alphaWorks open source regex package
(http://www.alphaworks.ibm.com/aw.nsf/techmain/F81E7D23B1C01F1A8825690E000161D7?OpenDocument)
in our (again tweaked) Service Manager. Actually, this wasn't much
problem since it just instead of
dd = (DeploymentDescriptor) dds.get/put (id);
uses
dd = (DeploymentDescriptor) dds.get/put (new REStringKey(id));
where REStringKey is a string-wrapping class which overloads equals()
and hashCode() functions.
> I am really looking forward your contribution to the Apache-SOAP
> project. I think your work can interest a lot of people. I did not
> really mention your Locator related stuff because I did not really dug
> into this piece, but I seems interesting as well.
Locator is just some more sophisticated class loader. We use it in our
RPCRouterServlet instead of Class.newInstance() used in Apache-SOAP. The
use of Locator makes it possible to operate with URN - in the similar
way like CORBA's IOR. In the Locator we enhanced the classic Chain of
Responsibility pattern to make it really flexible and pluginable.
Currently I am working on a paper describing the final design of the
Locator...
Currently our RPCRouter performs the following steps (I'm reusing a text
I produced for some other occasion :):
1. get the XML (envelope containing the call)
2. parse the XML and get the DOM
3. see if there's a DocType-based transformation declared (in a
separate *.ini file), if yes - invoke the transformers. As a result we'd
get SOAP-compliant XML
4. get the target URI from the DOM tree (this is required since we
want
to retrieve DD and transformers information _before_ the unmarshalling)
5. query service manager about the Deployment Descriptor for the
target
object using the target URI (regular expression-based comparison takes
place!)
6. using the returned DD get information about incoming
transformers
7. find the chain of transformers (created when the
DeploymentDescriptors were read from the storage)
8. invoke static TransformableEnvelope.unmarshall(transformers
chain) to
get the Envelope (the XML will be processed by the transformers)
9. invoke static Call.extractFromEnvelope() to get the Call
10. using the DD get the list of supported methods and compares
to the actual method call (call validation)
11. bind to Locator chain
12. invoke Locator.getObjectWithName(target URI) to get reference to
the
target object
13. use reflection to invoke the operation on the target object
14. using the returned DD get information about outgoing
transformers
15. find/create the chain of transformers
16. build the TransformingResponse object
17. send the response
a. build the TransformableEnvelope by invoking
buildEnvelope () on the
TransformingResponse object
b. marshal the TransformableEnvelope into out (the outgoing
XML will be
processed by transformers prior to sending)
> Question: When can we play with your stuff ? :-)
The primary problem here is that some of our code is not yet ready for
exposure o the World :), so we would have to make some
selection/separation, which is not that easy. Hopefully I'll manage to
send the transformers stuff - which is not strictly related to the SOAP
(I mean the classes I sent javadoc about). Further, as I have your
comments/suggestions and as we manage to put everything into better
order, I'll send more.
Looking forward to see your feedback, Vahe
>
> Best regards,
> Jean-Noel
>
> Vahe Amirbekyan wrote:
> >
> > Hi,
> >
> > Actually we've implemented a similar mechanism in our current Enterprise
> > Application Integration project. Probably I should tell more about the
> > Project...
> >
> > At the heart of the project is the compiler which takes the business
> > model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> > SOAP (SOAP proxies) for the client side (for cases when our application
> > uses SOAP to communicate remote/external objects) and/or (2) XML
> > Deployment Descriptors for the server side (if our objects serve to
> > remote/external clients via SOAP). Our application (which n.b. is also
> > generated from the business model) is based on EJB. In some sense the
> > compiler's functionality is similar to those of NASSL toolkit.
> >
> > Now, in order to make the generated SOAP-based application more
> > scalable, flexible, usable in real life situations etc. we have also
> > extended Apache (former IBM) SOAP. Here are brief descriptions of some
> > of the new features we have introduced:
> >
> > - XML Transformers. We added something like CORBA filters to both ends
> > of SOAP interaction. Transformers can be applied on the client side to
> > outgoing requests (XML is transformed before it is sent to server),
> > incoming replies (transformed before it is parsed) or on the server side
> > - for incoming requests (before XML is parsed) and outgoing replies
> > (before XML is sent). Currently only one type of transformers -
> > XSL-based - are implemented, but you can plug in any kind of XML->XML
> > transformer. Transformers can be joined in chains. They can be declared
> > to be applied per class (for all methods of the class) and/or per
> > particular method of the class. For clients the transformers are created
> > in the SOAP proxy object and may be applied for each calls propagated to
> > the server. For servers we have added transformers declaration to the
> > Deployment Descriptor. Basically the transformer declaration declares
> > the id of the entity it should be applied to (class name or method
> > name), type (IN or OUT) and URI of the transformation declaration (name
> > of XSL file). Also on the server side we are going to introduce
> > document-kind-specific transformation, that is transformers applied not
> > on per-target basis but per XML's doctype. Thus the server would be able
> > to receive any kind of XML messages - not only SOAP ones.
> >
> > - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> > graphs of objects represented as trees of hashtables, vectors,
> > enumerations, and object references (see the next entry).
> >
> > - Locator/URN Generator. We use Unified Resource Name (URN) format for
> > our objects' identifiers/references -
> > "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> > being independent from the SOAP) is used to locate an individual object
> > having its URN. Locator is primarily used to reference EJBs, but its
> > design allows us to easily extend it to any kind of objects. We
> > introduced Locator in RPCRouter in the place of "simple" class loading.
> > URN based object references are used in the client-side SOAP proxies as
> > handles to remote objects and to set target objects in outgoing calls.
> > The references can be passed from server to the client as a result of an
> > operation invocations, and on the client side a new SOAP proxy is then
> > created/initialized with this reference.
> >
> > - Regular expression-based matching. Instead of simple string-based
> > matching on the server side during Deployment Descriptor querying
> > (ServiceManager uses hashtable to store DDs using the target object id
> > as a key) we use regular expression based matching. Thus one deployment
> > descriptor may be used to describe a set of target objects, which seems
> > to be more scalable solution.
> >
> > We actually were planning to contribute some of our code to the
> > Development Group, but first we have to identify the individual parts of
> > our extensions that can be introduced independently. I wonder if you
> > find it interesting.
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:vahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Vahe Amirbekyan <av...@techone.com>.
Sorry, I forgot to attach the javadoc
Vahe
Jean-Noel Gadreau wrote:
>
> Hi Vahe.
>
> First of all, sorry for answering you so late. I saw your e-mail but did
> not have time to answer it sooner.
>
> I think your work is VERY interesting and is going in the right
> direction.
>
> I will just put quickly my remarks/questions:
>
> I like your concept of XML Transformers. From what I understand, it is
> just based on XSLT. I am wondering if you could give some examples of
> usage of those transformers. Further, how do you apply them ? Do you
> serialize first in memory (standard Apache-SOAP serializer) and then
> apply the XSLT transformations ?
>
> I think your addition to the deployment descriptor should be taken into
> account in the new architecture. It would be interesting if you can give
> us more information on it.
>
> I am really looking forward your contribution to the Apache-SOAP
> project. I think your work can interest a lot of people. I did not
> really mention your Locator related stuff because I did not really dug
> into this piece, but I seems interesting as well.
>
> Question: When can we play with your stuff ? :-)
>
> Best regards,
> Jean-Noel
>
> Vahe Amirbekyan wrote:
> >
> > Hi,
> >
> > Actually we've implemented a similar mechanism in our current Enterprise
> > Application Integration project. Probably I should tell more about the
> > Project...
> >
> > At the heart of the project is the compiler which takes the business
> > model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> > SOAP (SOAP proxies) for the client side (for cases when our application
> > uses SOAP to communicate remote/external objects) and/or (2) XML
> > Deployment Descriptors for the server side (if our objects serve to
> > remote/external clients via SOAP). Our application (which n.b. is also
> > generated from the business model) is based on EJB. In some sense the
> > compiler's functionality is similar to those of NASSL toolkit.
> >
> > Now, in order to make the generated SOAP-based application more
> > scalable, flexible, usable in real life situations etc. we have also
> > extended Apache (former IBM) SOAP. Here are brief descriptions of some
> > of the new features we have introduced:
> >
> > - XML Transformers. We added something like CORBA filters to both ends
> > of SOAP interaction. Transformers can be applied on the client side to
> > outgoing requests (XML is transformed before it is sent to server),
> > incoming replies (transformed before it is parsed) or on the server side
> > - for incoming requests (before XML is parsed) and outgoing replies
> > (before XML is sent). Currently only one type of transformers -
> > XSL-based - are implemented, but you can plug in any kind of XML->XML
> > transformer. Transformers can be joined in chains. They can be declared
> > to be applied per class (for all methods of the class) and/or per
> > particular method of the class. For clients the transformers are created
> > in the SOAP proxy object and may be applied for each calls propagated to
> > the server. For servers we have added transformers declaration to the
> > Deployment Descriptor. Basically the transformer declaration declares
> > the id of the entity it should be applied to (class name or method
> > name), type (IN or OUT) and URI of the transformation declaration (name
> > of XSL file). Also on the server side we are going to introduce
> > document-kind-specific transformation, that is transformers applied not
> > on per-target basis but per XML's doctype. Thus the server would be able
> > to receive any kind of XML messages - not only SOAP ones.
> >
> > - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> > graphs of objects represented as trees of hashtables, vectors,
> > enumerations, and object references (see the next entry).
> >
> > - Locator/URN Generator. We use Unified Resource Name (URN) format for
> > our objects' identifiers/references -
> > "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> > being independent from the SOAP) is used to locate an individual object
> > having its URN. Locator is primarily used to reference EJBs, but its
> > design allows us to easily extend it to any kind of objects. We
> > introduced Locator in RPCRouter in the place of "simple" class loading.
> > URN based object references are used in the client-side SOAP proxies as
> > handles to remote objects and to set target objects in outgoing calls.
> > The references can be passed from server to the client as a result of an
> > operation invocations, and on the client side a new SOAP proxy is then
> > created/initialized with this reference.
> >
> > - Regular expression-based matching. Instead of simple string-based
> > matching on the server side during Deployment Descriptor querying
> > (ServiceManager uses hashtable to store DDs using the target object id
> > as a key) we use regular expression based matching. Thus one deployment
> > descriptor may be used to describe a set of target objects, which seems
> > to be more scalable solution.
> >
> > We actually were planning to contribute some of our code to the
> > Development Group, but first we have to identify the individual parts of
> > our extensions that can be introduced independently. I wonder if you
> > find it interesting.
> >
> > With the best regards, Vahe Amirbekyan
> >
> > > Being new to this area, I hope this is the right place to suggest a
> > feature
> > > for the Apache SOAP package (if it isn't please direct me to a better
> > one,
> > > thanks).
> > >
> > > After playing with the soap engine for a bit, it occurred to me that a
> > very
> > > useful feature would be the ability to register one or more "filters"
> > with
> > > the engine that are evoked when messages comes into or leaves the soap
> > > engine (that is to say when the soap xml is received or about to be
> > shipped
> > > off -- first and last point of control).
> > >
> > > Or put another way, I'd love to see an interface for receiving notice
> > when
> > > something comes into or goes out of the soap servlet/jsp (registered
> > > separately). Ideally such a filter would also have the ability to
> > change
> > > the messages that come in or go out of the engine before passing it
> > onto
> > > the engine itself in addition to the option of doing nothing. Such a
> > hook
> > > would be very useful for debugging and analysis (since no tunnel would
> > then
> > > be needed to see the messages, and they could be redirected to other
> > > systems etc.), logging, and perhaps in some cases transformations or
> > > substitutions of the whole or even part of the message coming in or
> > going
> > > out of the engine.
> > >
> > > Just some thoughts
> > > Mike Paolini
> > > IBM Emerging Tech.
> > >
> > >
> > ------------------------------------------------------------------------
> > ----------------------------------------------------------
> > >
> > > "A doctor can bury his mistakes, an architect can only advise his
> > client to
> > > plant vines...." -Frank Lloyd Wright
> > >
> > > Internet ID: paolini@us.ibm.com
> > > IBM Internal e-mail ID: PAOLINI/Austin/IBM
> >
> > --
> > (\______________________________________________________/)
> > __|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
> > (___o) tel: (510) 729 6750 ext.375 (o___)
> > (__o) mailto:vahe@techone.com (o__)
> > (__o) http://www.techone.com (o__)
> > (_o)____________________________________________________(o_)
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:vahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Vahe Amirbekyan <av...@techone.com>.
Sorry, I forgot to attach the javadoc
Vahe
Jean-Noel Gadreau wrote:
>
> Hi Vahe.
>
> First of all, sorry for answering you so late. I saw your e-mail but did
> not have time to answer it sooner.
>
> I think your work is VERY interesting and is going in the right
> direction.
>
> I will just put quickly my remarks/questions:
>
> I like your concept of XML Transformers. From what I understand, it is
> just based on XSLT. I am wondering if you could give some examples of
> usage of those transformers. Further, how do you apply them ? Do you
> serialize first in memory (standard Apache-SOAP serializer) and then
> apply the XSLT transformations ?
>
> I think your addition to the deployment descriptor should be taken into
> account in the new architecture. It would be interesting if you can give
> us more information on it.
>
> I am really looking forward your contribution to the Apache-SOAP
> project. I think your work can interest a lot of people. I did not
> really mention your Locator related stuff because I did not really dug
> into this piece, but I seems interesting as well.
>
> Question: When can we play with your stuff ? :-)
>
> Best regards,
> Jean-Noel
>
> Vahe Amirbekyan wrote:
> >
> > Hi,
> >
> > Actually we've implemented a similar mechanism in our current Enterprise
> > Application Integration project. Probably I should tell more about the
> > Project...
> >
> > At the heart of the project is the compiler which takes the business
> > model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> > SOAP (SOAP proxies) for the client side (for cases when our application
> > uses SOAP to communicate remote/external objects) and/or (2) XML
> > Deployment Descriptors for the server side (if our objects serve to
> > remote/external clients via SOAP). Our application (which n.b. is also
> > generated from the business model) is based on EJB. In some sense the
> > compiler's functionality is similar to those of NASSL toolkit.
> >
> > Now, in order to make the generated SOAP-based application more
> > scalable, flexible, usable in real life situations etc. we have also
> > extended Apache (former IBM) SOAP. Here are brief descriptions of some
> > of the new features we have introduced:
> >
> > - XML Transformers. We added something like CORBA filters to both ends
> > of SOAP interaction. Transformers can be applied on the client side to
> > outgoing requests (XML is transformed before it is sent to server),
> > incoming replies (transformed before it is parsed) or on the server side
> > - for incoming requests (before XML is parsed) and outgoing replies
> > (before XML is sent). Currently only one type of transformers -
> > XSL-based - are implemented, but you can plug in any kind of XML->XML
> > transformer. Transformers can be joined in chains. They can be declared
> > to be applied per class (for all methods of the class) and/or per
> > particular method of the class. For clients the transformers are created
> > in the SOAP proxy object and may be applied for each calls propagated to
> > the server. For servers we have added transformers declaration to the
> > Deployment Descriptor. Basically the transformer declaration declares
> > the id of the entity it should be applied to (class name or method
> > name), type (IN or OUT) and URI of the transformation declaration (name
> > of XSL file). Also on the server side we are going to introduce
> > document-kind-specific transformation, that is transformers applied not
> > on per-target basis but per XML's doctype. Thus the server would be able
> > to receive any kind of XML messages - not only SOAP ones.
> >
> > - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> > graphs of objects represented as trees of hashtables, vectors,
> > enumerations, and object references (see the next entry).
> >
> > - Locator/URN Generator. We use Unified Resource Name (URN) format for
> > our objects' identifiers/references -
> > "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> > being independent from the SOAP) is used to locate an individual object
> > having its URN. Locator is primarily used to reference EJBs, but its
> > design allows us to easily extend it to any kind of objects. We
> > introduced Locator in RPCRouter in the place of "simple" class loading.
> > URN based object references are used in the client-side SOAP proxies as
> > handles to remote objects and to set target objects in outgoing calls.
> > The references can be passed from server to the client as a result of an
> > operation invocations, and on the client side a new SOAP proxy is then
> > created/initialized with this reference.
> >
> > - Regular expression-based matching. Instead of simple string-based
> > matching on the server side during Deployment Descriptor querying
> > (ServiceManager uses hashtable to store DDs using the target object id
> > as a key) we use regular expression based matching. Thus one deployment
> > descriptor may be used to describe a set of target objects, which seems
> > to be more scalable solution.
> >
> > We actually were planning to contribute some of our code to the
> > Development Group, but first we have to identify the individual parts of
> > our extensions that can be introduced independently. I wonder if you
> > find it interesting.
> >
> > With the best regards, Vahe Amirbekyan
> >
> > > Being new to this area, I hope this is the right place to suggest a
> > feature
> > > for the Apache SOAP package (if it isn't please direct me to a better
> > one,
> > > thanks).
> > >
> > > After playing with the soap engine for a bit, it occurred to me that a
> > very
> > > useful feature would be the ability to register one or more "filters"
> > with
> > > the engine that are evoked when messages comes into or leaves the soap
> > > engine (that is to say when the soap xml is received or about to be
> > shipped
> > > off -- first and last point of control).
> > >
> > > Or put another way, I'd love to see an interface for receiving notice
> > when
> > > something comes into or goes out of the soap servlet/jsp (registered
> > > separately). Ideally such a filter would also have the ability to
> > change
> > > the messages that come in or go out of the engine before passing it
> > onto
> > > the engine itself in addition to the option of doing nothing. Such a
> > hook
> > > would be very useful for debugging and analysis (since no tunnel would
> > then
> > > be needed to see the messages, and they could be redirected to other
> > > systems etc.), logging, and perhaps in some cases transformations or
> > > substitutions of the whole or even part of the message coming in or
> > going
> > > out of the engine.
> > >
> > > Just some thoughts
> > > Mike Paolini
> > > IBM Emerging Tech.
> > >
> > >
> > ------------------------------------------------------------------------
> > ----------------------------------------------------------
> > >
> > > "A doctor can bury his mistakes, an architect can only advise his
> > client to
> > > plant vines...." -Frank Lloyd Wright
> > >
> > > Internet ID: paolini@us.ibm.com
> > > IBM Internal e-mail ID: PAOLINI/Austin/IBM
> >
> > --
> > (\______________________________________________________/)
> > __|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
> > (___o) tel: (510) 729 6750 ext.375 (o___)
> > (__o) mailto:vahe@techone.com (o__)
> > (__o) http://www.techone.com (o__)
> > (_o)____________________________________________________(o_)
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:vahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Vahe Amirbekyan <av...@techone.com>.
Salut Jean-Noel,
> First of all, sorry for answering you so late. I saw your e-mail but did
> not have time to answer it sooner.
It's OK, we all are kind of busy, and not only with the SOAP ;)
> I think your work is VERY interesting and is going in the right
> direction.
>
Thanks for encouraging words.
> I will just put quickly my remarks/questions:
>
> I like your concept of XML Transformers. From what I understand, it is
> just based on XSLT. I am wondering if you could give some examples of
> usage of those transformers. Further, how do you apply them ? Do you
> serialize first in memory (standard Apache-SOAP serializer) and then
> apply the XSLT transformations ?
We defined a special interface - Transformer for all classes who perform
XML->XML transformation. Plus we defined TransformerChain class which
links all Transformer objects into a chain. I'm attaching the generated
Javadoc, not very rich one, but hopefully can shed some light on the
issue...
As I mentioned, we enhanced DeploymentDescriptorby putting there the
transformations declaration (naturally, I had to add a similar stuff as
it is with TypeMappings - a class and its serializer). The declaration
is stored in the *.ds file. When ServiceManager loads the DD's
hashtable, it also those declarations and loads the cache of
transformers, i.e. a hashtable with '[IN|OUT]_[targetID|methodID] as
keys and pre-built transformation chains (which it builds eagerly) as
values. A similar process takes place on the client side, but since we
generate clients (SOAP proxies) we can insert the code of transformers
creation and use in the client code directly.
We subclassed the Envelope, Call and Response classes, so that they make
use of pre-built transformer chains. The Envelope has an additional
transformer chain attribute, which is applied before the Envelope is
unmarshalled and after it is marshalled. This Envelope is used to send
SOAP messages across the net. E.g. our Call has attributes and get/set
operations for transformer chains designated for incoming and outgoing
invocations, which it uses to initialize the Envelops: it overloads
buildEnvelope() and invoke() operations to send the messages using our
subclassed Envelope.
Sorry, I suppose my explanation is not that clear, huh? I'll try to send
next time the javadoc and also maybe the code sample...
> I think your addition to the deployment descriptor should be taken into
> account in the new architecture. It would be interesting if you can give
> us more information on it.
I used IBM's alphaWorks open source regex package
(http://www.alphaworks.ibm.com/aw.nsf/techmain/F81E7D23B1C01F1A8825690E000161D7?OpenDocument)
in our (again tweaked) Service Manager. Actually, this wasn't much
problem since it just instead of
dd = (DeploymentDescriptor) dds.get/put (id);
uses
dd = (DeploymentDescriptor) dds.get/put (new REStringKey(id));
where REStringKey is a string-wrapping class which overloads equals()
and hashCode() functions.
> I am really looking forward your contribution to the Apache-SOAP
> project. I think your work can interest a lot of people. I did not
> really mention your Locator related stuff because I did not really dug
> into this piece, but I seems interesting as well.
Locator is just some more sophisticated class loader. We use it in our
RPCRouterServlet instead of Class.newInstance() used in Apache-SOAP. The
use of Locator makes it possible to operate with URN - in the similar
way like CORBA's IOR. In the Locator we enhanced the classic Chain of
Responsibility pattern to make it really flexible and pluginable.
Currently I am working on a paper describing the final design of the
Locator...
Currently our RPCRouter performs the following steps (I'm reusing a text
I produced for some other occasion :):
1. get the XML (envelope containing the call)
2. parse the XML and get the DOM
3. see if there's a DocType-based transformation declared (in a
separate *.ini file), if yes - invoke the transformers. As a result we'd
get SOAP-compliant XML
4. get the target URI from the DOM tree (this is required since we
want
to retrieve DD and transformers information _before_ the unmarshalling)
5. query service manager about the Deployment Descriptor for the
target
object using the target URI (regular expression-based comparison takes
place!)
6. using the returned DD get information about incoming
transformers
7. find the chain of transformers (created when the
DeploymentDescriptors were read from the storage)
8. invoke static TransformableEnvelope.unmarshall(transformers
chain) to
get the Envelope (the XML will be processed by the transformers)
9. invoke static Call.extractFromEnvelope() to get the Call
10. using the DD get the list of supported methods and compares
to the actual method call (call validation)
11. bind to Locator chain
12. invoke Locator.getObjectWithName(target URI) to get reference to
the
target object
13. use reflection to invoke the operation on the target object
14. using the returned DD get information about outgoing
transformers
15. find/create the chain of transformers
16. build the TransformingResponse object
17. send the response
a. build the TransformableEnvelope by invoking
buildEnvelope () on the
TransformingResponse object
b. marshal the TransformableEnvelope into out (the outgoing
XML will be
processed by transformers prior to sending)
> Question: When can we play with your stuff ? :-)
The primary problem here is that some of our code is not yet ready for
exposure o the World :), so we would have to make some
selection/separation, which is not that easy. Hopefully I'll manage to
send the transformers stuff - which is not strictly related to the SOAP
(I mean the classes I sent javadoc about). Further, as I have your
comments/suggestions and as we manage to put everything into better
order, I'll send more.
Looking forward to see your feedback, Vahe
>
> Best regards,
> Jean-Noel
>
> Vahe Amirbekyan wrote:
> >
> > Hi,
> >
> > Actually we've implemented a similar mechanism in our current Enterprise
> > Application Integration project. Probably I should tell more about the
> > Project...
> >
> > At the heart of the project is the compiler which takes the business
> > model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> > SOAP (SOAP proxies) for the client side (for cases when our application
> > uses SOAP to communicate remote/external objects) and/or (2) XML
> > Deployment Descriptors for the server side (if our objects serve to
> > remote/external clients via SOAP). Our application (which n.b. is also
> > generated from the business model) is based on EJB. In some sense the
> > compiler's functionality is similar to those of NASSL toolkit.
> >
> > Now, in order to make the generated SOAP-based application more
> > scalable, flexible, usable in real life situations etc. we have also
> > extended Apache (former IBM) SOAP. Here are brief descriptions of some
> > of the new features we have introduced:
> >
> > - XML Transformers. We added something like CORBA filters to both ends
> > of SOAP interaction. Transformers can be applied on the client side to
> > outgoing requests (XML is transformed before it is sent to server),
> > incoming replies (transformed before it is parsed) or on the server side
> > - for incoming requests (before XML is parsed) and outgoing replies
> > (before XML is sent). Currently only one type of transformers -
> > XSL-based - are implemented, but you can plug in any kind of XML->XML
> > transformer. Transformers can be joined in chains. They can be declared
> > to be applied per class (for all methods of the class) and/or per
> > particular method of the class. For clients the transformers are created
> > in the SOAP proxy object and may be applied for each calls propagated to
> > the server. For servers we have added transformers declaration to the
> > Deployment Descriptor. Basically the transformer declaration declares
> > the id of the entity it should be applied to (class name or method
> > name), type (IN or OUT) and URI of the transformation declaration (name
> > of XSL file). Also on the server side we are going to introduce
> > document-kind-specific transformation, that is transformers applied not
> > on per-target basis but per XML's doctype. Thus the server would be able
> > to receive any kind of XML messages - not only SOAP ones.
> >
> > - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> > graphs of objects represented as trees of hashtables, vectors,
> > enumerations, and object references (see the next entry).
> >
> > - Locator/URN Generator. We use Unified Resource Name (URN) format for
> > our objects' identifiers/references -
> > "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> > being independent from the SOAP) is used to locate an individual object
> > having its URN. Locator is primarily used to reference EJBs, but its
> > design allows us to easily extend it to any kind of objects. We
> > introduced Locator in RPCRouter in the place of "simple" class loading.
> > URN based object references are used in the client-side SOAP proxies as
> > handles to remote objects and to set target objects in outgoing calls.
> > The references can be passed from server to the client as a result of an
> > operation invocations, and on the client side a new SOAP proxy is then
> > created/initialized with this reference.
> >
> > - Regular expression-based matching. Instead of simple string-based
> > matching on the server side during Deployment Descriptor querying
> > (ServiceManager uses hashtable to store DDs using the target object id
> > as a key) we use regular expression based matching. Thus one deployment
> > descriptor may be used to describe a set of target objects, which seems
> > to be more scalable solution.
> >
> > We actually were planning to contribute some of our code to the
> > Development Group, but first we have to identify the individual parts of
> > our extensions that can be introduced independently. I wonder if you
> > find it interesting.
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:vahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Jean-Noel Gadreau <jn...@activcard.com>.
Hi Vahe.
First of all, sorry for answering you so late. I saw your e-mail but did
not have time to answer it sooner.
I think your work is VERY interesting and is going in the right
direction.
I will just put quickly my remarks/questions:
I like your concept of XML Transformers. From what I understand, it is
just based on XSLT. I am wondering if you could give some examples of
usage of those transformers. Further, how do you apply them ? Do you
serialize first in memory (standard Apache-SOAP serializer) and then
apply the XSLT transformations ?
I think your addition to the deployment descriptor should be taken into
account in the new architecture. It would be interesting if you can give
us more information on it.
I am really looking forward your contribution to the Apache-SOAP
project. I think your work can interest a lot of people. I did not
really mention your Locator related stuff because I did not really dug
into this piece, but I seems interesting as well.
Question: When can we play with your stuff ? :-)
Best regards,
Jean-Noel
Vahe Amirbekyan wrote:
>
> Hi,
>
> Actually we've implemented a similar mechanism in our current Enterprise
> Application Integration project. Probably I should tell more about the
> Project...
>
> At the heart of the project is the compiler which takes the business
> model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> SOAP (SOAP proxies) for the client side (for cases when our application
> uses SOAP to communicate remote/external objects) and/or (2) XML
> Deployment Descriptors for the server side (if our objects serve to
> remote/external clients via SOAP). Our application (which n.b. is also
> generated from the business model) is based on EJB. In some sense the
> compiler's functionality is similar to those of NASSL toolkit.
>
> Now, in order to make the generated SOAP-based application more
> scalable, flexible, usable in real life situations etc. we have also
> extended Apache (former IBM) SOAP. Here are brief descriptions of some
> of the new features we have introduced:
>
> - XML Transformers. We added something like CORBA filters to both ends
> of SOAP interaction. Transformers can be applied on the client side to
> outgoing requests (XML is transformed before it is sent to server),
> incoming replies (transformed before it is parsed) or on the server side
> - for incoming requests (before XML is parsed) and outgoing replies
> (before XML is sent). Currently only one type of transformers -
> XSL-based - are implemented, but you can plug in any kind of XML->XML
> transformer. Transformers can be joined in chains. They can be declared
> to be applied per class (for all methods of the class) and/or per
> particular method of the class. For clients the transformers are created
> in the SOAP proxy object and may be applied for each calls propagated to
> the server. For servers we have added transformers declaration to the
> Deployment Descriptor. Basically the transformer declaration declares
> the id of the entity it should be applied to (class name or method
> name), type (IN or OUT) and URI of the transformation declaration (name
> of XSL file). Also on the server side we are going to introduce
> document-kind-specific transformation, that is transformers applied not
> on per-target basis but per XML's doctype. Thus the server would be able
> to receive any kind of XML messages - not only SOAP ones.
>
> - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> graphs of objects represented as trees of hashtables, vectors,
> enumerations, and object references (see the next entry).
>
> - Locator/URN Generator. We use Unified Resource Name (URN) format for
> our objects' identifiers/references -
> "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> being independent from the SOAP) is used to locate an individual object
> having its URN. Locator is primarily used to reference EJBs, but its
> design allows us to easily extend it to any kind of objects. We
> introduced Locator in RPCRouter in the place of "simple" class loading.
> URN based object references are used in the client-side SOAP proxies as
> handles to remote objects and to set target objects in outgoing calls.
> The references can be passed from server to the client as a result of an
> operation invocations, and on the client side a new SOAP proxy is then
> created/initialized with this reference.
>
> - Regular expression-based matching. Instead of simple string-based
> matching on the server side during Deployment Descriptor querying
> (ServiceManager uses hashtable to store DDs using the target object id
> as a key) we use regular expression based matching. Thus one deployment
> descriptor may be used to describe a set of target objects, which seems
> to be more scalable solution.
>
> We actually were planning to contribute some of our code to the
> Development Group, but first we have to identify the individual parts of
> our extensions that can be introduced independently. I wonder if you
> find it interesting.
>
> With the best regards, Vahe Amirbekyan
>
> > Being new to this area, I hope this is the right place to suggest a
> feature
> > for the Apache SOAP package (if it isn't please direct me to a better
> one,
> > thanks).
> >
> > After playing with the soap engine for a bit, it occurred to me that a
> very
> > useful feature would be the ability to register one or more "filters"
> with
> > the engine that are evoked when messages comes into or leaves the soap
> > engine (that is to say when the soap xml is received or about to be
> shipped
> > off -- first and last point of control).
> >
> > Or put another way, I'd love to see an interface for receiving notice
> when
> > something comes into or goes out of the soap servlet/jsp (registered
> > separately). Ideally such a filter would also have the ability to
> change
> > the messages that come in or go out of the engine before passing it
> onto
> > the engine itself in addition to the option of doing nothing. Such a
> hook
> > would be very useful for debugging and analysis (since no tunnel would
> then
> > be needed to see the messages, and they could be redirected to other
> > systems etc.), logging, and perhaps in some cases transformations or
> > substitutions of the whole or even part of the message coming in or
> going
> > out of the engine.
> >
> > Just some thoughts
> > Mike Paolini
> > IBM Emerging Tech.
> >
> >
> ------------------------------------------------------------------------
> ----------------------------------------------------------
> >
> > "A doctor can bury his mistakes, an architect can only advise his
> client to
> > plant vines...." -Frank Lloyd Wright
> >
> > Internet ID: paolini@us.ibm.com
> > IBM Internal e-mail ID: PAOLINI/Austin/IBM
>
> --
> (\______________________________________________________/)
> __|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
> (___o) tel: (510) 729 6750 ext.375 (o___)
> (__o) mailto:vahe@techone.com (o__)
> (__o) http://www.techone.com (o__)
> (_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Jean-Noel Gadreau <jn...@activcard.com>.
Hi Vahe.
First of all, sorry for answering you so late. I saw your e-mail but did
not have time to answer it sooner.
I think your work is VERY interesting and is going in the right
direction.
I will just put quickly my remarks/questions:
I like your concept of XML Transformers. From what I understand, it is
just based on XSLT. I am wondering if you could give some examples of
usage of those transformers. Further, how do you apply them ? Do you
serialize first in memory (standard Apache-SOAP serializer) and then
apply the XSLT transformations ?
I think your addition to the deployment descriptor should be taken into
account in the new architecture. It would be interesting if you can give
us more information on it.
I am really looking forward your contribution to the Apache-SOAP
project. I think your work can interest a lot of people. I did not
really mention your Locator related stuff because I did not really dug
into this piece, but I seems interesting as well.
Question: When can we play with your stuff ? :-)
Best regards,
Jean-Noel
Vahe Amirbekyan wrote:
>
> Hi,
>
> Actually we've implemented a similar mechanism in our current Enterprise
> Application Integration project. Probably I should tell more about the
> Project...
>
> At the heart of the project is the compiler which takes the business
> model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
> SOAP (SOAP proxies) for the client side (for cases when our application
> uses SOAP to communicate remote/external objects) and/or (2) XML
> Deployment Descriptors for the server side (if our objects serve to
> remote/external clients via SOAP). Our application (which n.b. is also
> generated from the business model) is based on EJB. In some sense the
> compiler's functionality is similar to those of NASSL toolkit.
>
> Now, in order to make the generated SOAP-based application more
> scalable, flexible, usable in real life situations etc. we have also
> extended Apache (former IBM) SOAP. Here are brief descriptions of some
> of the new features we have introduced:
>
> - XML Transformers. We added something like CORBA filters to both ends
> of SOAP interaction. Transformers can be applied on the client side to
> outgoing requests (XML is transformed before it is sent to server),
> incoming replies (transformed before it is parsed) or on the server side
> - for incoming requests (before XML is parsed) and outgoing replies
> (before XML is sent). Currently only one type of transformers -
> XSL-based - are implemented, but you can plug in any kind of XML->XML
> transformer. Transformers can be joined in chains. They can be declared
> to be applied per class (for all methods of the class) and/or per
> particular method of the class. For clients the transformers are created
> in the SOAP proxy object and may be applied for each calls propagated to
> the server. For servers we have added transformers declaration to the
> Deployment Descriptor. Basically the transformer declaration declares
> the id of the entity it should be applied to (class name or method
> name), type (IN or OUT) and URI of the transformation declaration (name
> of XSL file). Also on the server side we are going to introduce
> document-kind-specific transformation, that is transformers applied not
> on per-target basis but per XML's doctype. Thus the server would be able
> to receive any kind of XML messages - not only SOAP ones.
>
> - (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
> graphs of objects represented as trees of hashtables, vectors,
> enumerations, and object references (see the next entry).
>
> - Locator/URN Generator. We use Unified Resource Name (URN) format for
> our objects' identifiers/references -
> "urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
> being independent from the SOAP) is used to locate an individual object
> having its URN. Locator is primarily used to reference EJBs, but its
> design allows us to easily extend it to any kind of objects. We
> introduced Locator in RPCRouter in the place of "simple" class loading.
> URN based object references are used in the client-side SOAP proxies as
> handles to remote objects and to set target objects in outgoing calls.
> The references can be passed from server to the client as a result of an
> operation invocations, and on the client side a new SOAP proxy is then
> created/initialized with this reference.
>
> - Regular expression-based matching. Instead of simple string-based
> matching on the server side during Deployment Descriptor querying
> (ServiceManager uses hashtable to store DDs using the target object id
> as a key) we use regular expression based matching. Thus one deployment
> descriptor may be used to describe a set of target objects, which seems
> to be more scalable solution.
>
> We actually were planning to contribute some of our code to the
> Development Group, but first we have to identify the individual parts of
> our extensions that can be introduced independently. I wonder if you
> find it interesting.
>
> With the best regards, Vahe Amirbekyan
>
> > Being new to this area, I hope this is the right place to suggest a
> feature
> > for the Apache SOAP package (if it isn't please direct me to a better
> one,
> > thanks).
> >
> > After playing with the soap engine for a bit, it occurred to me that a
> very
> > useful feature would be the ability to register one or more "filters"
> with
> > the engine that are evoked when messages comes into or leaves the soap
> > engine (that is to say when the soap xml is received or about to be
> shipped
> > off -- first and last point of control).
> >
> > Or put another way, I'd love to see an interface for receiving notice
> when
> > something comes into or goes out of the soap servlet/jsp (registered
> > separately). Ideally such a filter would also have the ability to
> change
> > the messages that come in or go out of the engine before passing it
> onto
> > the engine itself in addition to the option of doing nothing. Such a
> hook
> > would be very useful for debugging and analysis (since no tunnel would
> then
> > be needed to see the messages, and they could be redirected to other
> > systems etc.), logging, and perhaps in some cases transformations or
> > substitutions of the whole or even part of the message coming in or
> going
> > out of the engine.
> >
> > Just some thoughts
> > Mike Paolini
> > IBM Emerging Tech.
> >
> >
> ------------------------------------------------------------------------
> ----------------------------------------------------------
> >
> > "A doctor can bury his mistakes, an architect can only advise his
> client to
> > plant vines...." -Frank Lloyd Wright
> >
> > Internet ID: paolini@us.ibm.com
> > IBM Internal e-mail ID: PAOLINI/Austin/IBM
>
> --
> (\______________________________________________________/)
> __|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
> (___o) tel: (510) 729 6750 ext.375 (o___)
> (__o) mailto:vahe@techone.com (o__)
> (__o) http://www.techone.com (o__)
> (_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Vahe Amirbekyan <av...@techone.com>.
Hi,
Actually we've implemented a similar mechanism in our current Enterprise
Application Integration project. Probably I should tell more about the
Project...
At the heart of the project is the compiler which takes the business
model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
SOAP (SOAP proxies) for the client side (for cases when our application
uses SOAP to communicate remote/external objects) and/or (2) XML
Deployment Descriptors for the server side (if our objects serve to
remote/external clients via SOAP). Our application (which n.b. is also
generated from the business model) is based on EJB. In some sense the
compiler's functionality is similar to those of NASSL toolkit.
Now, in order to make the generated SOAP-based application more
scalable, flexible, usable in real life situations etc. we have also
extended Apache (former IBM) SOAP. Here are brief descriptions of some
of the new features we have introduced:
- XML Transformers. We added something like CORBA filters to both ends
of SOAP interaction. Transformers can be applied on the client side to
outgoing requests (XML is transformed before it is sent to server),
incoming replies (transformed before it is parsed) or on the server side
- for incoming requests (before XML is parsed) and outgoing replies
(before XML is sent). Currently only one type of transformers -
XSL-based - are implemented, but you can plug in any kind of XML->XML
transformer. Transformers can be joined in chains. They can be declared
to be applied per class (for all methods of the class) and/or per
particular method of the class. For clients the transformers are created
in the SOAP proxy object and may be applied for each calls propagated to
the server. For servers we have added transformers declaration to the
Deployment Descriptor. Basically the transformer declaration declares
the id of the entity it should be applied to (class name or method
name), type (IN or OUT) and URI of the transformation declaration (name
of XSL file). Also on the server side we are going to introduce
document-kind-specific transformation, that is transformers applied not
on per-target basis but per XML's doctype. Thus the server would be able
to receive any kind of XML messages - not only SOAP ones.
- (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
graphs of objects represented as trees of hashtables, vectors,
enumerations, and object references (see the next entry).
- Locator/URN Generator. We use Unified Resource Name (URN) format for
our objects' identifiers/references -
"urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
being independent from the SOAP) is used to locate an individual object
having its URN. Locator is primarily used to reference EJBs, but its
design allows us to easily extend it to any kind of objects. We
introduced Locator in RPCRouter in the place of "simple" class loading.
URN based object references are used in the client-side SOAP proxies as
handles to remote objects and to set target objects in outgoing calls.
The references can be passed from server to the client as a result of an
operation invocations, and on the client side a new SOAP proxy is then
created/initialized with this reference.
- Regular expression-based matching. Instead of simple string-based
matching on the server side during Deployment Descriptor querying
(ServiceManager uses hashtable to store DDs using the target object id
as a key) we use regular expression based matching. Thus one deployment
descriptor may be used to describe a set of target objects, which seems
to be more scalable solution.
We actually were planning to contribute some of our code to the
Development Group, but first we have to identify the individual parts of
our extensions that can be introduced independently. I wonder if you
find it interesting.
With the best regards, Vahe Amirbekyan
> Being new to this area, I hope this is the right place to suggest a feature
> for the Apache SOAP package (if it isn't please direct me to a better one,
> thanks).
>
> After playing with the soap engine for a bit, it occurred to me that a very
> useful feature would be the ability to register one or more "filters" with
> the engine that are evoked when messages comes into or leaves the soap
> engine (that is to say when the soap xml is received or about to be shipped
> off -- first and last point of control).
>
> Or put another way, I'd love to see an interface for receiving notice when
> something comes into or goes out of the soap servlet/jsp (registered
> separately). Ideally such a filter would also have the ability to change
> the messages that come in or go out of the engine before passing it onto
> the engine itself in addition to the option of doing nothing. Such a hook
> would be very useful for debugging and analysis (since no tunnel would then
> be needed to see the messages, and they could be redirected to other
> systems etc.), logging, and perhaps in some cases transformations or
> substitutions of the whole or even part of the message coming in or going
> out of the engine.
>
> Just some thoughts
> Mike Paolini
> IBM Emerging Tech.
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
> "A doctor can bury his mistakes, an architect can only advise his client to
> plant vines...." -Frank Lloyd Wright
>
> Internet ID: paolini@us.ibm.com
> IBM Internal e-mail ID: PAOLINI/Austin/IBM
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:vahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)
Re: Suggestion for feature
Posted by Vahe Amirbekyan <av...@techone.com>.
Hi,
Actually we've implemented a similar mechanism in our current Enterprise
Application Integration project. Probably I should tell more about the
Project...
At the heart of the project is the compiler which takes the business
model (Rational Rose *.mdl file) and generates (1) Java classes wrapping
SOAP (SOAP proxies) for the client side (for cases when our application
uses SOAP to communicate remote/external objects) and/or (2) XML
Deployment Descriptors for the server side (if our objects serve to
remote/external clients via SOAP). Our application (which n.b. is also
generated from the business model) is based on EJB. In some sense the
compiler's functionality is similar to those of NASSL toolkit.
Now, in order to make the generated SOAP-based application more
scalable, flexible, usable in real life situations etc. we have also
extended Apache (former IBM) SOAP. Here are brief descriptions of some
of the new features we have introduced:
- XML Transformers. We added something like CORBA filters to both ends
of SOAP interaction. Transformers can be applied on the client side to
outgoing requests (XML is transformed before it is sent to server),
incoming replies (transformed before it is parsed) or on the server side
- for incoming requests (before XML is parsed) and outgoing replies
(before XML is sent). Currently only one type of transformers -
XSL-based - are implemented, but you can plug in any kind of XML->XML
transformer. Transformers can be joined in chains. They can be declared
to be applied per class (for all methods of the class) and/or per
particular method of the class. For clients the transformers are created
in the SOAP proxy object and may be applied for each calls propagated to
the server. For servers we have added transformers declaration to the
Deployment Descriptor. Basically the transformer declaration declares
the id of the entity it should be applied to (class name or method
name), type (IN or OUT) and URI of the transformation declaration (name
of XSL file). Also on the server side we are going to introduce
document-kind-specific transformation, that is transformers applied not
on per-target basis but per XML's doctype. Thus the server would be able
to receive any kind of XML messages - not only SOAP ones.
- (De)Serializers. We've introduced (de)serializers for EJBs (by-value),
graphs of objects represented as trees of hashtables, vectors,
enumerations, and object references (see the next entry).
- Locator/URN Generator. We use Unified Resource Name (URN) format for
our objects' identifiers/references -
"urn:namespace:[protocol:]typename[@key]". The Locator framework (itself
being independent from the SOAP) is used to locate an individual object
having its URN. Locator is primarily used to reference EJBs, but its
design allows us to easily extend it to any kind of objects. We
introduced Locator in RPCRouter in the place of "simple" class loading.
URN based object references are used in the client-side SOAP proxies as
handles to remote objects and to set target objects in outgoing calls.
The references can be passed from server to the client as a result of an
operation invocations, and on the client side a new SOAP proxy is then
created/initialized with this reference.
- Regular expression-based matching. Instead of simple string-based
matching on the server side during Deployment Descriptor querying
(ServiceManager uses hashtable to store DDs using the target object id
as a key) we use regular expression based matching. Thus one deployment
descriptor may be used to describe a set of target objects, which seems
to be more scalable solution.
We actually were planning to contribute some of our code to the
Development Group, but first we have to identify the individual parts of
our extensions that can be introduced independently. I wonder if you
find it interesting.
With the best regards, Vahe Amirbekyan
> Being new to this area, I hope this is the right place to suggest a feature
> for the Apache SOAP package (if it isn't please direct me to a better one,
> thanks).
>
> After playing with the soap engine for a bit, it occurred to me that a very
> useful feature would be the ability to register one or more "filters" with
> the engine that are evoked when messages comes into or leaves the soap
> engine (that is to say when the soap xml is received or about to be shipped
> off -- first and last point of control).
>
> Or put another way, I'd love to see an interface for receiving notice when
> something comes into or goes out of the soap servlet/jsp (registered
> separately). Ideally such a filter would also have the ability to change
> the messages that come in or go out of the engine before passing it onto
> the engine itself in addition to the option of doing nothing. Such a hook
> would be very useful for debugging and analysis (since no tunnel would then
> be needed to see the messages, and they could be redirected to other
> systems etc.), logging, and perhaps in some cases transformations or
> substitutions of the whole or even part of the message coming in or going
> out of the engine.
>
> Just some thoughts
> Mike Paolini
> IBM Emerging Tech.
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
> "A doctor can bury his mistakes, an architect can only advise his client to
> plant vines...." -Frank Lloyd Wright
>
> Internet ID: paolini@us.ibm.com
> IBM Internal e-mail ID: PAOLINI/Austin/IBM
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:vahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)