[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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: OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite"> 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. OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite"> 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. OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite"> I agree completely. OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite"> 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.... OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite">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". OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite">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. OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite"> 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. OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite"> 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. OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite"> 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. OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite"> 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. OF64D5243A.D5CCB758-ON802577D1.005642AC-802577D1.005886CD@uk.ibm.com" type="cite"> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]