[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ISSUE-227 - Promotion of consumers and producersundermines composability
Switching to internet style replies...inline tagged with <dab> </dab> Dave Booz STSM, BPM and SCA Architecture Co-Chair OASIS SCA-Policy TC and SCA-J TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com Eric Johnson <eric@tibco.com> wrote on 04/09/2010 06:24:34 PM: > [image removed] > > Re: [sca-assembly] ISSUE-227 - Promotion of consumers and producers > undermines composability > > Eric Johnson > > to: > > David Booz > > 04/09/2010 06:25 PM > > Cc: > > sca-assembly > > Hi Dave, > > Thanks for the questions. Let me try at responses. > > I struggled with numerous ways to best describe this problem, > because there are several aspects to it. I tried to focus in on a > particular perspective but it was tricky to do that without > presupposing a particular solution. > > On 04/09/2010 01:24 PM, David Booz wrote: > Hi Eric, > >> I'm not quite following the argument so maybe we can clarify in email >> before the telecon. I'm not seeing the distinction that you're trying to >> draw. I can't tell if you're pushing on a problem in the vertical >> composition case (promotion) or horizontal composition (within a >> composite). > > >>> communication needs are exposed at the boundary of a composite > > >> Not quite. Components in the Domain are wired together (services and >> references), across composite boundaries, without the use of promotion. >> Promotion (services and references) is really about exposing the >> configurable aspects of a composite that you wish to use as a component >> implementation. If your composite is not a component implementation then >> there's not much use for service/reference promotion. I think the same is >> true for consumers and producers. > > > I conceptualize the "Domain" as just another composite with some > extra bits thrown in. Perhaps I've grossly mischaracterized the > domain notion, but at least that's where my brain starts. And as > such, I still conceptualize that there are connection endpoints that > I expose at the edge of the domain, because they're communicating > with processes that lie outside the domain. > <dab> Yes, this is true but the Assembly spec provides no meaning to Domain level services and references. </dab> > The above phrase about communication at the boundary of a composite > was an informal way of talking about a specific case of what happens > with a component type, although useful because we can readily > picture interior pieces of a composite. In that regard, I don't > view a "composite" implementation of a component and a Java > implementation differently. To pick on the Java example, in the SCA > world, a Java component should be communicating to the outside world > via exposed services and references, rather than, behind the scenes, > opening up port 80 and doing its own thing. Likewise with > "consumers" and "producers". > <dab> Ok, so we agree that an SCA component implementation should communicate with the outside world via a binding, but promotion is not necessary to use a binding, nor is it always desireable. I believe there will be cases (corner cases) where the component implementation wants to use a binding to talk to the outside WITHOUT exposing that binding for configuration in the vertical composition model (i.e., it is not promoted). </dab> > If you want to talk about the Java case instead, I'm arguing for the > notion that a Java component that wishes to communicate via > something like a JMS Topic should indicate that it wants a > particular destination (a.k.a. "channel" or JMS Destination), and > describe what it is doing on that destination (listening, sending, > or listening and sending), not that it is providing a particular > "consumer" or "provider", which happen to be pointing at the same "target". <dab> Hmmm, is your concern related to the perceived usefulness of bindings on consumers/providers in light of channels? Or the perceived usefulness of consumers/producers themselves? </dab> > > >>> In the case of producers, consumers, and channels, not only can bindings >>> be applied, but also "targets", which then either hide endpoints within a >>> composite, or expose them globally as part of the "global domain." > >> The same thing happens inside a composite with services and references. A >> component service that is wired-to (by a reference) and not promoted is an >> endpoint that is hidden within the composite. Likewise, in the Domain >> (which is a composite) a component service is globally visible even if it >> is already wired-to by another component in the Domain. In this case it is >> not hidden...but that's because the Domain is treated as a composite. It >> is true however that a component reference cannot target a Domain level >> service unless that component reference is also in the Domain. Perhaps >> it's this last bit that you want to make consistent in the event model? > > > I think we're agreeing here. Let me state it a different way. In > the current draft, producers and consumers can define "targets" that > point to "global domain channels." In effect, this creates a third > unique way of "wiring" communications endpoints - rather than simply > reusing the "binding" notion we already have. In concrete > implementation terms, a target value can point to a global domain > channel that maps to a particular JMS Destination (for example). If > that's what you want to do, why not simply use a concrete > binding.jms element, or a new equivalent for pub/sub > (tibco:binding.pubsub?), which is what you'd do for the more old- > fashioned notions of services and references. > <dab> If you know you wanted JMS, then you would probably use a binding. If your messaging system is implemented by a plethora of technologies, then a binding will be difficult. I've actually looked at a channel as the moral equivalent of binding.sca for consumers and producers. Wiring binding.sca doesn't even require a <binding> configuration, all you need is the target. With events, there is no target so you need to connect yourself to something else; currently it's called a channel. </dab> > Further, in the case of specifying targets in this way, if the > component is wrapped inside of a composite that is wrapped by a > composite which is wrapped by a composite, any one of those > intervening composites might have something to say about the > communications channel that the innermost component chose (depending > on how far out the notion of producing and consuming gets pushed) - > but at the moment, the "target" notion steals away this flexibility, > because the innermost component can "jump" across all of those > layers and directly point at a global domain channel. That's not > readily composed with other components at that point, because > components buried ten levels deep can now interfere with global > domains in hidden ways. <dab> Right. This is what I meant by breaking encapsulation. But if your Domain channel is your "system bus" then this concept gives you some interesting options for connecting additional components into the system. </dab> > > >>> target channel references can be to a domain channel, thus undermining >>> composability > >> This point I'm clear on, so I'll just make a comment. I prefer to think of >> it as breaking encapsulation, but the net effect is the same given the >> comparison to service and references. The Domain channel is an interesting >> beast because you can imagine configuring your system (or defaulting your >> authoring tools) such that ALL events flow through it, which makes it easy >> to add new consumers who can pick up any event they want from anywhere in >> the vertical composition without needing to promote producers just to >> enable visibility of the events. It really raises the question of whether >> or not we should have something similar for the ref->service model. This >> was a hotly debated topic in the past, one in which I was only an observer >> so there are others who will probably jump in here. > > > Agreed. This strikes me as a particular binding, as I mentioned > above. TIBCO's customers have a long history of doing messaging > arranged around messaging targets - "subject based addressing", to > pick a phrase at random ;-) . JMS continues this tradition by > providing destinations that can have some "path" structure to them - > so this isn't specific to TIBCO - based on JNDI lookup. This > pattern presents challenges - how do you manage the "subject" space? > With SCA's composibility, I can now imagine that the path for the > "subject/destination" derives directly from the logical path > associated with a composite, and then the unpromoted component type > channels (Destinations) are scoped within the name of the > surrounding composite, however nested that might be. So SCA can > actually solve two customer problems at the same time - useful > abstractions for messaging/eventing, and a way to manage the address > space for pub/sub. That model only works, though, if you are > promoting the channels, not the consumers and producers. > <dab> ...interesting...have to think about this. </dab> > If a particularly user of SCA wants the notion of a single global > channel (JMS Destination) that has all events flowing on it, I see > two ways via promoting channels: > Promote all of the channels from all of the component types all the > way through all the intervening composites out to the edges of the > components deployed at the domain level - and then wire them all to > the same thing. > Use the binding notion we already have to bind to that global > channel (JMS Destination). > There's no need to introduce a new notion of "target". <dab> I'll have to read your proposal to understand this better. <dab> > > >>> Instead of promoting consumers and producers, promote channels. Move >>> the filter and eventType information on consumers and producers into the >>> channel. > >> What does it mean to promote a channel? Does it mean that the consumer and >> producer aspect of the channel are promoted either together or somehow >> jointly? > > Yes. I submit the following example for consideration. Imagine a > composite that contains two components. Again to be concrete - Java > component A listens in on a channel (JMS Topic), and another Java > component B sends on the same channel (JMS Topic), where both > components expect that other producers and consumers somewhere in > the SCA environment will also publish and listen to that same > channel (JMS Topic). If you only promote the "consumer" to indicate > that component A is listening on the channel, then you've not > promoted the key detail that the composite is also producing on the > same channel/JMS Topic. Or, you could imagine swapping the problem, > and only promote the producer, even though the consumer is still > also listening. Either way is misleading. The two have to be > promoted together. The most obvious way I see of doing that is to > call a spade a spade, and model the abstraction of the > communications destination, the JMS Topic. >> Is it different from allowing a composite consumer (and provider >> on the other end) to point to a channel as promoting the consumer aspect of >> the channel? My mental model of a channel is that it's a builtin >> implementation type, which is probably getting in my way of understanding >> what you're pushing on. > > > If you think of a channel as an implementation type, I think that is > possibly a mental trap. The wires going into and out of it don't > mean the same thing as other SCA wires. > > You've perhaps hit upon another of the concerns that I have raised > (not formulated as an issue yet, but I will) - I think it will be > very useful for everyone if we can talk in very specific concrete > terms about possible implementations, including details like how a > binding might work, and specifically what it is - JMS, Apple's > Bonjour, TCP/IP multicast, AMQP, or TIBCO's Rendevous, for example. > Although we like to claim that SCA is independent of the "bindings" > that make it possible, we all have a pretty good idea of how it all > maps down to SOAP/HTTP, and how certain policy intents and message > exchanges can be mapped onto that base, so we're all able to assess > it in that context. > > Absent a discussion about which bindings make sense for "channels", > it will be very difficult for us to assess the correlation of our > particular model constructs - (producers, consumers and?) channels - > and whether they actually make sense. At least, that's my take. > <dab> There's a few WS-* specs which would work for consumer/producer bindings, WS-Notification and WS-Eventing, if I've got the names right. </dab> > Just to give you an example, the WS-* world has constructed all > sorts of notions, such as WS-RM and WS-Addressing, that it turns out > just don't make sense when you start thinking about carrying SOAP > over JMS. All the members of the SOAP/JMS working group poked > around their respective companies asking for specific customers that > would have a use for either of these in the context of JMS, and the > response was deafening silence. <dab> Don't get me started on WS_Addressing... </dab> > WS-Addressing serves two roles - > and at least one role - that of defining EPRs, is completely > unnecessary, because the JMS client already gets to specify the > response destination, and further, the response is already > "asynchronous" in the way that HTTP replies are not, thus mooting > the primary use cases. The message addressing properties of WS- > Addressing are possibly relevant, but at some point you can simply > slip those into the SOAP message body. And WS-RM is mostly moot, > because you can simply request reliability at the transport layer, > and it will be much more efficient than pushing the same problem > into the SOAP stack. > > So if we don't have a particular binding defined that specifically > supports pub/sub, then I'm certain we will not get the specification > of eventing done correctly. But I digress - as I indicated, that's > another issue I need to raise. > > I plan to submit a revised document with a partial proposal to the > working group on Monday. I didn't submit it with the issue I > raised, because I am waiting to hear back from other TIBCO folks as > to whether I'm completely insane (so far the answer seems to be > "no"). So hopefully that concrete form will further aid the discussion. > > -Eric. > > thanks > > Dave Booz > STSM, BPM and SCA Architecture > Co-Chair OASIS SCA-Policy TC and SCA-J TC > "Distributed objects first, then world hunger" > Poughkeepsie, NY (845)-435-6093 or 8-295-6093 > e-mail:booz@us.ibm.com > > > |------------> > | From: | > |------------> > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Mike Edwards <mike_edwards@uk.ibm.com> | > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | To: | > |------------> > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |"OASIS Assembly" <sca-assembly@lists.oasis-open.org> | > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Date: | > |------------> > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |04/09/2010 04:19 AM | > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Subject: | > |------------> > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |[sca-assembly] Fw: [sca-assembly-comment] NEW ISSUE: (1.2) > Promotion of consumers and producers undermines composability | > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > > > Folks, > > Forwarding to the main sca-assembly TC list.... > > 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: mike_edwards@uk.ibm.com > ----- Forwarded by Mike Edwards/UK/IBM on 09/04/2010 09:18 ----- > > From: Eric Johnson <eric@tibco.com> > > > To: sca-assembly-comment@lists.oasis-open.org > > Date: 08/04/2010 18:18 > > > Subje [sca-assembly-comment] NEW ISSUE: (1.2) Promotion of consumers and > ct: producers undermines composability > > > > > > > Target: sca-assembly-1.2-spec-wd01.doc > > Title: Promotion of SCA consumers and producers undermines composibility > > Description: > > In the assembly 1.2 WD 01, consumers and producers are identified as part > of the "component type" of a component, whereas "channels" are limited in > scope to the boundaries of a composite. This is contrary to the rest of > SCA, where the indication of the communication between components surfaces > in the component type, currently as a service or reference. When needed, > services or references can establish concrete bindings, but otherwise > communication needs are exposed at the boundary of a composite. In the > case of producers, consumers, and channels, not only can bindings be > applied, but also "targets", which then either hide endpoints within a > composite, or expose them globally as part of the "global domain." > > This makes composition of applications using eventing more difficult. > > Further, although producers and consumers can refer to the same target, > this is an awkward way for these two constructs to establish that they > intend to operate on the same "destination". When building a composite the > composite developer may wish for one component to produce for a channel, > and a different component to publish on the same channel, and then promote > the combination of producer and consumer. If the developer only promotes > the consumer, or only promotes the publisher, that would be misleading to > the composites using that component. Perhaps it is even an error. > > Here, then, are two problems: > "target" channel references are a weak way to couple the use of the > same destination. > target channel references can be to a domain channel, thus > undermining composability - either by collisions in the naming of > target channels, or by forcing special knowledge of which channels > are used where. > Proposal: > > Instead of promoting consumers and producers, promote channels. Move the > filter and eventType information on consumers and producers into the > channel. > > -Eric > > > > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]