Re: [sca-assembly] Re: [ASSEMBLY-249]: Need some notion of "callback"address in conjunction with eventing

Hi Mike,

    

    It is possible we're vehemently agreeing on many points.  Which
    should make this an interesting discussion....

    

    On 11/4/10 9:11 AM, Mike Edwards wrote:
    
      

      Folks,
      

      

      This message from Eric starts to
        get
        into one of the things that Danny raised on he call earlier this
        week,
        namely the
      

      inability of SCA to model the
        various
        messaging patterns describable in WSDL.
      

      

      I DISAGREE that this is the case,
        and
        I will describe how SCA can deal with these cases.
      

      

      > * message out, maybe message back

          > * message out, N messages back

          > * message out *, message back
      

      

      Currently, SCA can do ALL of these using
          references
          & services, using Callbacks.
      

    
    

    I agree, to the extent that you're talking about a single consumer
    at the destination.  Concretely mapping this to JMS (or email), all
    I know is that I send messages to a destination, and I don't know if
    I get a "message" back at all, whether I get five "messages" back,
    or just one, and I further don't know if those "messages" will come
    from the same source.

    

    
      

      Where a service has both an interface AND a
          callback
          interface, then it is saying:
      

      

      - for any forward invocation of the service
      

      -- there may be 0, 1 or many invocations of any
          one
          of the operations in the callback
      

         interface (which can also be read as
          "response messages")
      

      - the invocation of an operation on the
          callback interface
          can occur in response to one forward invocation
      

      -- or to some sequence of multiple forward
          invocations
    

    Yes, all true.  The way I read it, you've assumed a single
    "responder", whereas I have not.

    

    I perceive an important semantic distinction between "here's a
    message", and "invoke particular operation", even if they're called
    with the same data.  Eventing systems move data, whereas "services"
    systems perform actions based on parameters.  I think they align
    about as much as REST does with SOAP.  You can accomplish the same
    ends with both, but with REST you think primarily about resources,
    representations, and state, whereas with SOAP you think about verbs
    and parameters.  You can end up in radically different places, with
    radically different architectural implications.  In my head at
    least, that analogous distinction extends to messaging/eventing vs.
    web-services/SOAP.

    

    
      

      

          > * message out, message back to different component

        
      

      - this is supported through an override of the
          callback
          binding HOWEVER this is then rightly an aspect
      

      of the configuration of the ASSEMBLY and not
          the result
          of some individual implementation artifact
      

      deciding on the wiring - ie there is no way
          that the
          "client" component should itself be dictating
      

      the target for the response - that MUST be part
          of
          the composition/assembly.
      

    
    

    I agree completely.

    

    
      

      

      Now, I think the real debate here is whether
          "replyTo"
          has **ANY** place in the style of Event Processing
      

      that the SCA spec tries to describe.
      

    
    

    Looking forward in your email, you through out a notion of
    "relatesTo".  That *exactly* what I'm trying to get at with this
    issue.

    

    In certain circumstances, the "relatesTo" meta-data exists as part
    of the application-defined payload of a message, and that's probably
    unavoidable.  I don't want to aim to boil the ocean, as it were.

    

    I'd like however, if the binding can handle the "relatesTo" notion
    whenever it makes sense.  That raises exactly the question I'm
    trying to get at - how does the binding even *know* that it is
    supposed to manufacture a unique identifier so that a subsequently
    delivered message can be correlated via some notion of "relatesTo"? 
    When that subsequent message does arrive, how does the binding layer
    even know to associate it with whatever state it might have stored
    earlier?  How did the first, second, or third consumer know where to
    send the "relatesTo" information?

    

    How can the consuming binding of a message receive the necessary
    information from the incoming message and stash it, such that when
    the consumer then produces a message that relates to the originally
    received message, it will work?  The code calling the producer must
    either get at the "relatesTo" information, or tell the producer it's
    invoking to look up that previously saved state....

    

    
      

      The real question that Eric & Danny need to
          address
          is how an SCA event producer can make **any** assumption
      

      that the receiving component actually produces
          any
          kind of response message.  A subsidiary question is whether
      

      the event producer can also make some
          assumption that
          the receiving component will **only** send some message
      

      back to the event producer and nowhere else.
      

    
    I don't think I've made either assumption.  The only assumption I
    want to make is that an assembler can *choose* to do so with event
    producers and consumers that declare that they have an
    implementation that leverages the notion of "relatesTo" or
    "replyTo".

    

    
      

      I think that our current model of event
          processing
          is simply more loosely coupled than this.  If an event
      

      producer anticipates that some new events may
          be generated
          as a result of some events that it produces, then
      

      I would say that the component with the
          producer should
          also have a consumer for that type (or types) of event.
      

    
    I can think of use-cases where that doesn't work.  For example,
    assume I have a component A that produces messages on some global
    domain channel //foo.  At some point, some set of components show up
    in the system, and start receiving messages on //foo, and perhaps
    some of those components (call them B, C, D) start sending
    "relatesTo" information about messages originally sent to //foo.

    

    How can component A catch these "relatesTo" messages?  Option (1) -
    listen to a predetermined channel //bar (or //foo?) where those
    messages are expected to be sent.  Fails if the assembler doesn't
    wire producers on B, C, and D properly, and unfortunately, this key
    bit of information *isn't* in the model.  Option (2) - A consumes on
    the default domain channel "//".  Problematic in that hosting
    environment of A, if not A itself now sees far more messages than it
    needs to, in order to find the ones it does want.  Option (3) - as
    part of the originally produced message, send an indication of where
    the "relatesTo" messages ought to be sent.  This last approach works
    even if A, B, C, and D are deployed in different composites and at
    different times.

    

    
      

      It is then up to the assembler to decide to
          connect
          both the producer and the consumer separately to appropriate
      

      channels - similarly for any "receiving"
          component's consumer & producer.
      

    
    

    I absolutely agree that the actual choice of how to handle
    "relatesTo" messages should be addressed by the assembler.  I'm just
    noting that by not supporting the notion of "replyTo", we've taken
      away one option for loosely coupling.

    

    
      

      Any "correlation" needed between an initial
          event and some future "response" event should be managed
          through
      

      some aspect of the response event (eg a
          "relatesTo"
          field).
      

    
    

    Indeed yes, if we choose not to model these details, then SCA users
    will need to force such correlation information into the
    application/"business" layer, rather than letting it be handled at
    the binding layer.  Or they'll choose a vendor implementation that
    extends SCA to enable some amount of correlation to be done at the
    binding layer.

    
      

      

      My other reaction to this material is to say
          "if
          you want a response, use services/references, not event
          processing"
      

    
    

    I understand that reaction.  I can see how what I'm saying feels
    like it falls into the category of "if all you have is a
    hammer...".  But I think what I've offered above makes what I'm
    arguing for different in several ways:

    

    1) Eventing is about moving data, not invoking operations, which I
    see as a key semantic difference

    2) I'm not assuming a single "responder", nor a single message back,
    nor a response that comes back even to where it started from.  We're
    talking about choreographed message exchanges, rather than
    individual message exchanges.  Trying to model this with WSDL, or
    even with two WSDLs, is an effort in futility.  Even worse, trying
    to pretend that WSDL captures these choreographies obscures the fact
    that the actual message flows aren't doing the standard
    request/reply exchanges that WSDL typically models.

    3) By not supporting some model notion of "relatesTo"/"replyTo",
    end-user applications will be forced to move such data into event
    messages, mixing transport and business data unnecessarily, rather
    than having the binding take care of it.

    4) By not offering some way of indicating a "reply"
    destination, that moves a tight coupling elsewhere in the system -
    in the form of assumed knowledge about where those events will be
    sent, or assumed knowledge about the types of events will be sent,
    or both.  Or you build in unnecessary inefficiencies.

    

    
      

      

      As to the question of why the various protocols
          listed
          below have "replyTo" - I say it is because those protocols
          have
      

      to be able to deal with request/response
          message patterns
          of the type listed above - the current SCA event processing
      

      model AIN'T REQUEST/RESPONSE.  It is *much*
          more
          loose coupled than that...
    

    As I point out in #4 above, I think the association of request/reply
    with tight coupling is a mental trap of sorts.  Just because I've
    indicated a reply to address, doesn't mean that I've tightly coupled
    anything.  Rather, I've provided a means for late binding.  The
    world of HTML over HTTP is anything but tightly coupled, and it is
    built entirely on a request/response paradigm.  Some uses of HTML
    over HTTP are tightly coupled, but that just demonstrates that you
    can abuse any system.  I think I can assemble some fairly
    interesting message choreographies that will leverage a "replyTo"
    notion, but that in no way implies that the components involved are
    tightly coupled.

    

    I, for one, question why JMS singled out "JMSReplyTo" as the only
    way to send a Destination to a recipient.  It ought to have been
    more open ended than it is.  WS-Addressing doesn't repeat this
    mistake.  But generically, the ability of the event producer to
    indicate one or more interesting "Destinations" for sending
    follow-on messages seems like a way to further decouple systems, as
    it saves the recipient of those messages from having to
    pre-emptively "wire" to those destinations.

    

    -Eric.

    
      

      

      

      

      

        Yours,  Mike.

        

        Strategist - Emerging Technologies, SCA & SDO.

        Co Chair OASIS SCA Assembly TC.

        IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great
        Britain.

        Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

        Email:  
      

      

      Eric Johnson <> wrote on
          01/11/2010
          20:57:15:

          

          > [image removed] 
      

      > 

          > Re: [sca-assembly] NEW ISSUE: Need some notion of
          "callback"
          address

          > in conjunction with eventing
      

      > 

          > Eric Johnson 
      

      > 

          > to:
      

      > 

          > ashok.malhotra
      

      > 

          > 01/11/2010 21:38
      

      > 

          > Cc:
      

      > 

          > Martin Chapman, Anish Karmarkar, sca-assembly
      

      > 

          > Hi Ashok,

          > 

          > Just about every "broadcasting" eventing system that I
          can
          think of 

          > supports some notion of "reply-to"

          > 

          > JMS: JMSReplyTo

          > SOAP WS: WS-Addressing ReplyTo (I admit this is a little
          bit of a
          stretch)

          > AMQP: reply-to (I think - I'm not very familiar with
          this)

          > UDP: source port number

          > PGM: (piggy-backing on UDP, it looks like)

          > TIBCO's Rendevous: (yes - don't know the details)

          > Email: "Reply-To"

          > 

          > ... : ??? (anyone know anything about Apple's Bonjour?)

          > 

          > Perhaps we could come up with a more complete list of
          this "broadcast"
          

          > mechanisms, and what they support?

          > 

          > In any case, the notion of using services and references
          doesn't even
          

          > come close to mapping on to various cases that you might
          relate to
          

          > eventing.  Services and references are tightly tied to
          the 

          > interoperability and known semantics of WSDL 1.1, whereas
          eventing
          might 

          > use a whole bunch of messaging patterns that you might
          not even be
          able 

          > to define in WSDL:

          > 

          > * message out, maybe message back

          > * message out, N messages back

          > * message out *, message back

          > * message out, message back to different component

          > 

          > All of these might take advantage of a "reply to"
          capability
          that has 

          > little or nothing to do with the request/reply semantics
          associated
          with 

          > services and references.  Also, the message back might
          effectively
          be 

          > "any" - there might not be a specific "response"
          message with a single 

          > specific type.

          > 

          > This question does bring me back to one question that
          I've been raising
          

          > for a while.  What bindings do we anticipate people using
          with
          SCA 

          > Eventing, and how do we think they're going to be used?
           Absent
          that 

          > information, it strikes me as very difficult to address
          questions
          like 

          > this one.

          > 

          > As to whether we open this issue, since all the existing
          transports
          I 

          > mentioned above support the functionality, I think
          closing it with
          no 

          > action would be premature. Yet, I agree that we may need
          much discussion
          

          > to establish what this "reply to" notion means, and maybe
          we won't get 

          > there.

          > 

          > -Eric.

          >