Announcement Announcement Module
Collapse
No announcement yet.
My two cents Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • My two cents

    I went to a New England Java Users Group meeting tonight where Mark Fisher presented on Spring Integration. Aside from the presentation, I haven't used S.I. before, though I've used Mule and am starting to use JBoss ESB lately too. Given that I haven't used S.I., my feedback might not be worth much, but I want to offer it any way given that S.I. hasn't been released quite yet and so this is a critical time for feedback.

    Wether S.I. is to be considered an ESB or not ... in any case, it basically competes with ESBs and ESB-like things. And so, it can learn a lot from strengths and shortcomings of those competitors. I already like a lot of what I see in S.I. compared to Mule. In particular, I was always annoyed that Mule forces the UMO concept with inbound & outbound routers, even when the scenario presented is just a chain of things that happen with no "real" central component (i.e. a Bridge UMO is used). In this case, S.I. (and JBoss ESB) are better, IMO. I also like the simplicity of the interfaces in S.I. (compared to both Mule & JBoss ESB). I haven't looked at your type coercion / transformation stuff but Mule did a good job in that department; not so much in JBoss ESB.

    Since you don't have a release 1 yet, take care of important issues that are likely to have ramifications across the API if no care is taken now. For example, JCA transaction support, streamed message bodies, type information for the body, automatic transformation/coercion of message body types to that needed. Streaming in Mule seems to me like an afterthought.

    Minutia: I'm not sure if there's much point to splitting MessageHeader from Message and in extending Message with subclasses. One class is simpler.

    And finally, there is one feature that I'm hoping to see in ESBs. In JBoss Messaging, they have a really well done JMS bridge that handles several different QoS levels, plus message batching. It's general purpose, not JBoss messaging specific. The issues that the bridge has to deal with are similar to those that a well done ESB should handle. I submitted a feature-request for JBoss ESB that I hope is of interest here: http://jira.jboss.org/jira/browse/JBESB-1629
    I've seen an example on S.I. where two JMS destinations are tied together. That is basically a poor-man's implementation, whereas the JBoss message bridge is the robust implementation that's probably perfect. See links on the issue I submitted for interesting references to this matter.

  • #2
    Can you be more specific on the functionality you're seeking?

    In my opinion what is missing from spring integration is support to directly plug a source adapter into a target adapter without a channel in between. In all other respects I think the implementation is a lot more elegant than the Bridge that you're referring to. Of course this doesn't mean that it is functionally complete, so it will be interesting to get the requirements on the table.

    What I particularly disliked about the org.jboss.jms.server.bridge.Bridge is that it glues all the concerns together (transactions, lookups, source, target ...). My hope is that with spring integration it will remain possible to plug the different elements together. (use similar components to build a jms -> ws bridge).

    Comment


    • #3
      The reason we at our shop choose SI instead of using Mule, or JBoss ESB, or the one from Apache or other one of the several similar tools out there, Restlet including, was that we don't look as SI as being a ESB. For us to use a ESB seems like to put a elephant in a porcelain store.

      SI is simple enough and easily extensible enough. I hope it keeps being like this, instead of trying to be a "one size fit all" kind of solution, that was what, in my opinion, turns ESB and things like SOAP and all the damn WS-* thingies a very wrong approach and a waste of time and money in systems integration.

      Comment


      • #4
        iwein,
        This is best explained in a what-if scenario. Lets say we've got a queue that's inbound to S.I., and we have a set of things we do to the message; perhaps we send it off to another queue when we're done or not; whatever. I suspect that the current implementation for this gives a QOS_AT_MOST_ONCE level of service which kind of sucks. In other words, if something were to go wrong in spring or if an outgoing queue were down, then the message is lost and won't be resent. To support QOS_DUPLICATES_OK (ideal for most needs), S.I. needs to set the inbound queue to CLIENT_ACKNOWLEDGE, then the bus needs to determine when the message processing is done in the bus -- at which point it acknowledges the message. To support QOS_ONCE_AND_ONLY_ONCE, basically, the source JMS and target JMS need to participate in a combined transaction, possibly involving XA. That's out of my expertise so I won't elaborate on that.

        These scenarios are explained a bit more in the JBoss forum thread I referred to in that JIRA issue.

        My reference to the JBoss Messaging Bridge is only to call-out QoS issues, I don't mean to suggest that the same actual message bridge exist similarly for S.I.; not at all.

        I like your suggestion about being able to directly tie adapters together. In addition, I think it would be nice to "wire" adapters together with channels being implicit. That's the pain point IMO, not so much that they exist.

        Comment


        • #5
          amsmota, I think that an ESB doesn't have to be a heavyweight elephant. S.I. is lightweight, case in point -- and that is its strength and I hope it stays that way. In saying that this or that is an ESB or not should not be a reflection on heavyweight/lightweightness.

          Comment


          • #6
            Originally posted by dsmiley View Post
            I think that an ESB doesn't have to be a heavyweight elephant.
            Well, an ESB doesn't have to be heavyweight, but they usually are... At least all that I evaluated were, and thus a overkill form what we need. But there's no point in discuss that issue here, of course, it was just a remark.

            Nevertheless my point was to stress out the benefits of SI being simple and my wish that it stays that way.

            Comment

            Working...
            X