Re: [sca-assembly] ISSUE-227 - Promotion of consumers and producersundermines composability

[Eric Johnson <eric@tibco.com>]

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:

OFAEC6D253.CEF051DB-ON85257700.006A7996-85257700.00701DEC@us.ibm.com" type="cite">

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.

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".

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".

OFAEC6D253.CEF051DB-ON85257700.006A7996-85257700.00701DEC@us.ibm.com" type="cite">

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.

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.

OFAEC6D253.CEF051DB-ON85257700.006A7996-85257700.00701DEC@us.ibm.com" type="cite">

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.

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".

OFAEC6D253.CEF051DB-ON85257700.006A7996-85257700.00701DEC@us.ibm.com" type="cite">

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.

OFAEC6D253.CEF051DB-ON85257700.006A7996-85257700.00701DEC@us.ibm.com" type="cite">

  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. 

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.  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.

OFAEC6D253.CEF051DB-ON85257700.006A7996-85257700.00701DEC@us.ibm.com" type="cite">

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