[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Fw: [sca-assembly-comment] NEW ISSUE: (1.2) Promotionof consumers and producers undermines composability
Hi Eric: Re. policies the eventing spec merely carries over what the assembly says about policies on services/references to producers/consumers. I'm not sure this is correct. We need to think some more about policies in the eventing situation. At one time I thought you could apply policies only to producers and consumers could accede to the producers policies or lump it. But there are event models in the database world where there is one producer and one consumer (tell me if IBM stock trades for over $100) and in such cases it does make sense for the consumer and producer to match policies. The problem I see with policies on channels is that the channel can act as an aggregator for events from from several producers, so what policies does it employ?> All the best, Ashok Eric Johnson wrote: > Hi Peter, > > On 05/11/2010 04:24 AM, Peter Niblett wrote: >> >> Eric >> >> I have read your correspondence with Dave Booz, and taken a quick >> look at your revisions. I have a number of things to ask about that, >> but first I would like to understand the issues here. >> >> I think your points relative to the Feb 12 draft can be summarized as >> >> 1. Components within a composite can be directly wired to a >> domain-level channel (see the example in figure 2-6). As Dave points >> out, this can be viewed as breaking encapsulation as there is nothing >> explicit in the component types of components D1 and D2 that tells >> you that this is going on (since you can't reconfigure it when >> assembling the composite). You have to look inside the definitions of >> composites X and Y to see this, and if there is a deep nesting of >> composites you have to look down all the levels. >> >> 2. The mechanism of linking up producing and consuming components >> within a composite, e.g. in the case shown in figure 2-5, is awkward. >> You have to configure the @sources of the consumers and the @targets >> of the producers to point to the same channel > > Not just awkward - it breaks encapsulation. It hides a critical detail. > >> >> 3. At the moment channels are either completely private (scoped only >> within a single composite), or completely global (when they are in >> the domain). There is no mechanism for promoting a channel so that it >> is visible only to a given composite and its subcomponents. >> >> 4. Domain level channels don't seem to be necessary since we could do >> the same thing by binding to JMS topics. > On this last point, you're construing my point as being overly > specific. Any binding could do, not just a JMS binding. UDP, AMQP, > TIBCO Rendevous, Apple's Bonjour are others that I can think of. We > could equally well have an "binding.scaeventing". > > Some additional points: > > 5. Policies assigned to producers and consumers are likely to need > to be the same, or to align. It makes more sense to assign > those policies to a shared concept of a "channel", rather than > treat the producers and consumers as independent. > 6. SCA already has the means to "break encapsulation" by way of a > well understood pattern - bindings. The existing eventing draft > allows "sources"/"targets" that provide an alternate means of > breaking encapsulation without justifying why an alternate means > is necessary. > 7. Channels have bindings, not producers and consumers. Suppose I > have a producer and a consumer in a composite - on both I > "target/source" the same transport destination, but here's a > weirdness - I could put a binding on both, and perhaps it isn't > the same. Does that imply, behind the scenes, that the runtime > has to do automatic bridging from one transport to the other? > That no longer sounds like we're modeling eventing, but modeling > a system in which we hope transport level details can be modeled > as if they don't exist. My gut tells me that hope will be > squashed by an unfriendly reality. > > >> >> Please correct me if this is wrong. >> >> In "defence" of the OSOA spec, what we were trying to do is >> >> a) Allow true decoupling of event-centric components, so that it is >> possible to author a component as a pure consumer and/or producer of >> events without knowing how these components are going to be >> assembled. This means keeping details of the channels out of the >> component types. This is the main motivation for having <producer> >> and <consumer> elements in the component type and for declaring >> filters as part of the consumer (if there's no way a component can >> handle a particular kind of event, it should say so) >> >> b) Allow an assembler - if he/she wishes - to define a tight coupling >> of components so that they can be wired up without "leakage" of >> events outside a composite, and without external events coming into >> the composite uninvited. This is needed when you are modelling event >> processing applications. This is why we have private channels scoped >> within components, as shown in figures 2-4, 2-5 and 2-7. >> >> c) Allow loose binding of components, where producers are not aware >> of the identities of the consumers and vice versa, and where there is >> some kind of global event distribution mechanism (an event bus if you >> will) that spans all application components. This is done by having >> global channels at the domain level >> >> d) Provide an abstraction that allows event distribution to be >> modelled in a protocol neutral fashion. This is the reason for having >> channels in the model at all. > > Again, I maintain, as I stated on the conference call, that my > proposal only adds additional use-cases, it does not remove any. > >> >> Maybe the confusion is caused by accommodating both b) and c) >> simultaneously. >> >> Returning to the points >> >> 1. It is true that you can do this, see figure 2-6, but you don't >> have to. The alternative is to promote the producers and consumers, >> so they do become visible at the next level up and then can be wired >> to a channel (or promoted further) by the person assembling that >> composite. That's what you would do if you were designing libraries >> of reusable nested event processing components. On the other hand if >> you really do have a uniform event bus concept that spans all your >> components, we felt it would be unnecessarily tedious for people to >> have to do this all the time. > > Well, except if my use case is that some of the producers and > consumers from a composite are listening on the same logical > destination, and they want to share that destination outside of the > composite, the only way they can do that is to specify "source" & > "target". At which point, I can no longer compose as freely. > > With the proposal I've submitted, I have added the ability to directly > associate producers and consumers, and model that they share the > underlying transport destination, without having to specifically tie > that to any "target" or "source" for that destination. In other > words, it preserves composability without sacrifice. > > Further, in my proposal, a binding is associated with a channel, not > with an individual producer or consumer, which means that the > additional bullet point #7 above of having to automatically generate a > bridge goes away. Designers would have to intentionally create a > bridge. This strikes me as an important feature. > >> >> 2. I agree that this is awkward. I have always favoured being able to >> wire a producer directly to a consumer (effectively having an >> implicit channel). You should also be able to choose whether you >> establish this by setting @target on the producer or @source on the >> consumer. That same mechanism could be used if you have an explicit >> channel, so you could set the @targets/@sources on the channel to >> point at the producers/consumer (effectively what Eric does in his >> example of figure 2-4) rather than the other way round. > > I think wiring directly is a mistake, and implies a different kind of > transport. I think, if you're talking about producers & consumers, > you want to graphically depict that as wiring via an indirection. The > semantics and behavior of publish/subscribe are dramatically different > from direct point-to-point communications, and shouldn't be confused > by identical/very similar graphics. > > My proposal has a simple unification. Producers and consumers go away > - components always "wire" to channels when they want to > produce/consume. The difference with my proposal is that channels > are either private to the composite, or promoted. > >> >> 3. At the moment we accommodate both use cases (completely private or >> completely global). Intermediate cases sound interesting, but I am >> not sure whether anyone really needs them. Just to be clear on how >> we'd expect things to work at the moment... if you look at figure 2-4 >> you would normally either wire a producer/consumer (the yellow >> triangles) to a channel or promote them. That's what the figure >> shows. You could promote the consumer for component 4, in which case >> it would receive events from the outside AND events from channel A >> (which can only have come from components 1 and 2). One other thing >> one could consider is allowing the input or output of the channel >> (which are in effect producers and consumers themselves) to be >> promoted, to allow events from the outside to go directly into >> channel A without having to go via components 1 or 2, but again I'm >> not sure why that would be useful. > > You've fundamentally hit the nail on the head here, perhaps > unintentionally. The notion of completely private or completely > global simply isn't composable. > > I think it is fair to turn this question around - why /wouldn't/ I > want to abstractly model and promote the channel that my composite > wishes to send and receive on, rather than be forced to early bind to > some notion of a global "source/target" for where those messages are > coming from. The essential value of an abstract concept of channel is > the model of which events are being sent and received over it, not its > name! > >> >> 4. I think modelling the distribution mechanism is a good thing. > > And yet, where do I model a notion of a channel that crosses composite > boundaries, but for which I don't yet have a specific concrete name > for the destination? We model services and references abstractly in > this manner as part of the component type, yet for some reason you > seem to be resistant to including the channel in the component type. > > My take on the above: > > * You agree that it isn't composable (see your #3), so shouldn't > we open the issue? > * For the notion of promoting channels, I don't see any > problems/objections identified above, except that it is > different from promoting producers and consumers. > * My proposal doesn't remove any use cases/functionality, and it > adds composability > > I admit that my proposal is *not* perfect - it needs work on the > artwork, and the policy details probably need more detail, and perhaps > a discussion of channel hopping (channel bridging), but I do think it > adds functionality, and solves problems that the current draft > specifically identifies as areas needing work. > > All of this discussion, I note, is in service of the question: should > we open the issue? Seems like you've acknowledge that the current > approach isn't composable. Further, I've provided an approach that > covers additional use-cases, without taking any away, while > simultaneously solving the problems raised by the issue. So maybe we > don't take my solution, but the issue ought to be opened. > > -Eric. > >> >> >> Regards >> >> Peter Niblett >> IBM Senior Technical Staff Member >> Member of the IBM Academy of Technology >> +44 1962 815055 >> +44 7825 657662 (mobile) >> >> >> >> From: Eric Johnson <eric@tibco.com> >> To: OASIS Assembly <sca-assembly@lists.oasis-open.org> >> Date: 12/04/2010 17:56 >> Subject: Re: [sca-assembly] Fw: [sca-assembly-comment] NEW ISSUE: >> (1.2) Promotion of consumers and producers undermines composability >> >> >> ------------------------------------------------------------------------ >> >> >> >> Follow up.... >> >> I've just posted to the OASIS documents repository a proposal for >> ASSEMBLY-227._ >> __http://www.osoa.org/jira/browse/ASSEMBLY-227_ >> >> I posted in PDF and Word format:_ >> __http://www.oasis-open.org/committees/document.php?document_id=37272__ >> __http://www.oasis-open.org/committees/document.php?document_id=37273_ >> >> These documents are *not* in anything close to final form: >> >> * OpenOffice did a number of things to slightly mangle the word >> document >> * We need new pictures to show the new channel promotion notion. >> I've included my notion of what it would look like below, in >> the hopes that it will help, although I should add that so far >> within TIBCO, I've gotten the some disagreement about the >> proposed artwork. >> * I haven't vetted the schema changes. >> * Obviously this is still a fork of the current spec, based off >> of the copy that Anish started from. >> >> However, before I spent many hours trying to get everything perfect, >> I figured I should at least know whether the intent is even close to >> acceptable to the TC. >> >> -Eric. >> >> P.S. My current conception of a channel might look like - see diamond >> at the bottom edge of the component. >> >> >> >> >> On 04/09/2010 01:19 AM, Mike Edwards wrote: >> >> 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_ <mailto:mike_edwards@uk.ibm.com> >> ----- Forwarded by Mike Edwards/UK/IBM on 09/04/2010 09:18 ----- >> From: Eric Johnson _<eric@tibco.com>_ <mailto:eric@tibco.com> >> To: _sca-assembly-comment@lists.oasis-open.org_ >> <mailto:sca-assembly-comment@lists.oasis-open.org> >> Date: 08/04/2010 18:18 >> Subject: [sca-assembly-comment] NEW ISSUE: (1.2) Promotion of >> consumers and 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/ >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> / >> / >> >> /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/ >> >> >> >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]