Announcement Announcement Module
Collapse
No announcement yet.
Sending a message to multiple endpoints with transforms. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Iwein,

    When you say marius' solution do you mean?

    Originally posted by mbogoevici View Post
    But I'm afraid we moved away from Dave's original issue: this can be solved relatively easy now, by introducing supplemental Endpoints before the e-mail and webservice Targets, which would take charge of the transformation in a MessageHandler - rather than using a MessageTransformer - so the original shared copy is not altered, but rather a new message is created every time. Of course, this should just give some relief until the cloning option will be available.
    Currently I'm running the message through a clone handler in a chain with the transformer handler adapter to get round the problem. If I did the above I wouldn't be using the transformer interface anymore which I want to try to stick with as I have my own oxm,xslt and xpath implementations of it and this seems more consistent with where the next milestone release is going.

    For me doing it either way - either cloning in the pub / sub channel and multi channel routers or having transformers behave more like handlers would work.

    Actually originally I was using a handler to do the transform - but wanted to move to the new standard transformer interface and that's when I hit the problem

    Although immutable messages is the simpler fix, I can see it's more flexible to have the framework distinguish between transformers and handlers.

    Another option would be to put a clone option on the TransformerMessageHandlerAdapter?

    Dave

    Comment


    • #17
      Hi Dave,

      Indeed, the idea is to do transformation on a separate copy. Interface-related, the end goal is to be able to use pojos for transformation/handling, case in which switching from one to the other is a matter of modifying an annotation.

      The Transformer model will definitely undergo changes in the M5, but this snippet from the unit tests should be illustrative:

      Code:
      private static class HandlerWithTransformers {
      
      		@Transformer
      		@Order(-1)
      		public String transformBefore(String input) {
      			return "pre." + input;
      		}
      
      		@Handler
      		@Order(0)
      		public String handle(String input) {
      			return input.toUpperCase();
      		}
      
      		@Transformer
      		@Order(1)
      		public String transformAfter(String input) {
      			return input + ".post";
      		}
      	}
      Unfortunately, there's no namespace equivalent at this time, yet.

      We plan on addressing the issue of cloning messages in a pub-sub scenario before M5.


      Regards,
      Marius

      Comment


      • #18
        Originally posted by david_geary View Post
        Iwein,
        When you say marius' solution do you mean (quote omitted)?
        Yes.
        If I did the above I wouldn't be using the transformer interface anymore which I want to try to stick with as I have my own oxm,xslt and xpath implementations of it and this seems more consistent with where the next milestone release is going.

        For me doing it either way - either cloning in the pub / sub channel and multi channel routers or having transformers behave more like handlers would work.

        Actually originally I was using a handler to do the transform - but wanted to move to the new standard transformer interface and that's when I hit the problem

        Although immutable messages is the simpler fix, I can see it's more flexible to have the framework distinguish between transformers and handlers.
        One of my points was that we could distinguish and offer the option of doing a copy on transform (by adding a return type to the method). The downside that Marius pointed out is that we couldn't be sure of the identity preservation of the message anymore in that scenario.

        One other important point of Marius that I missed is that it doesn't work that way now hence, if you want it to change, you should create an issue for it.

        At the moment we're waiting for Mark to shed his light on this discussion (which will take a until after next week). If you want to move forward on the immutable path you could easily implement MessageHandler first and refactor later (to the better method name). You could also glue with something like...

        Code:
        abstract class ImmutableMessageTransformer implements MessageHandler{..}
        ...which is pretty horrible but very easy to refactor once MessageTransformer is changed (if it ever will be). It's still a bit dodgy, but that means it's good we have this discussion before RC1.
        Last edited by iwein; Jun 17th, 2008, 09:18 AM. Reason: removed horrible code

        Comment


        • #19
          Thanks for the feedback,

          Originally posted by mbogoevici View Post

          Indeed, the idea is to do transformation on a separate copy. Interface-related, the end goal is to be able to use pojos for transformation/handling, case in which switching from one to the other is a matter of modifying an annotation.
          Off topic slightly, but one point to note is that what we are trying to do with spring integration is provide a customisable event publishing mechanism for our product, where we publish event messages with a known (published schema) xml payload on fixed message channels. The integration people will then write custom spring configuration files that get added into the spring context to transform and route the messages to do what ever they need to do.

          Hence we are trying to stay away from custom POJOs (although they may occasionally be necessary) and in particular annotations as we are trying to rely on supplied transformers such as xslt and xpath (eg to pull out a bit of content for emails)

          Hence the namespace support would be important to us (to make it easier for the integration people to configure) whereas the annotation stuff isn't really at present.

          I'm interested to see what the namespace support for transformers / transformers chains will look like. In particular the code you show seems to show the application of pre and post transformers to a message handler. If a pre transformer could be added to message targets also then this could provide a very concise way to make web service calls ie something like

          Code:
          <channel id="eventpublishingchannel" publish-subscribe="true" clone="true"/>
          
          <ws-target id="bpelTarget" 
          		uri="http://localhost:8081/bpel/services/TestService" 
          		channel="eventpublishingchannel"
          		transformer="bpelRequestTransformer"/>
          
          <xslt-transformer id="bpelRequestTransformer" xslFile="C:\bpelRequest.xsl"/>
          In this example the eventpublishingchannel would be the publish subscribe channel with the clone support as already discussed enabling multiple endpoints using the events on this channel.

          The transforms could also be done in the target-endpoint tag.

          Dave

          Comment


          • #20
            David,

            Thanks for your feedback as well - it's very helpful for us. Namespace support is critical from our point of view as well, it's just that it needs to be ready for M5, as M4 had to be released before we had that part ready.

            For target endpoints, it would look something like:

            Code:
            <channel id="eventpublishingchannel" publish-subscribe="true" clone="true"/>
            
            <target-endpoint input-channel="exampleChannel" target="bpelTarget" 
                transformer="bpelRequestTransformer">
                <schedule period="#somePeriod"/>
            </target-endpoint>
            
            <ws-target id="bpelTarget" 
            		uri="http://localhost:8081/bpel/services/TestService" 
            		channel="eventpublishingchannel"/>
            
            <xslt-transformer id="bpelRequestTransformer" xslFile="C:\bpelRequest.xsl"/>
            It's pretty much what you wrote, except that transformers will be placed on the endpoints themselves. Also, if there's more than one transformer per endpoint (i.e. a chain), they could be placed as sub-elements of <*-endpoint/>, the order being relevant in this case.

            Cannot say 100% that this will be the final syntax, but this is by and large how it will look like.

            The intent is for the transformers will be hosted in an endpoint (just like handlers) but, in principle, to operate on the same message (again, besides payload handling it can be a matter of header/envelope manipulation). In the case of a target endpoint, it is just pre-processing, in the case of a source-endpoint, it is just post-processing, and for a handler-endpoint they would provide either pre-processing or postprocessing, depending on their placement relative to the handlers.

            Regards,
            Marius
            Last edited by mbogoevici; Jun 17th, 2008, 12:11 PM. Reason: removed a code tag

            Comment


            • #21
              cloning

              Can someone tell me how this all worked out?
              I'm using spring-integration-1.0.2.SR1

              I have a similar need. I need to essentially "multicast" a message out to many channels. Each of the "many" channels has the need to filter/validate/transform etc.

              I was thinking of using the RecipientListRouter but I believe this thread points me to the Publish Subscribe channel.

              However, the reference documentation in regards to the Publish Subscribe channel says this: "This is most often used for sending Event Messages whose primary role is notification as opposed to Document Messages which are generally intended to be processed by a single consumer"


              Keith

              Comment


              • #22
                Can you create a documentation issue for this? In my opinion we shouldn't document how things are used, we should document what they do and how you could use them. If you rephrase it for us once you understand that would be nice

                Comment

                Working...
                X