Roll call 15/18 = 83% Quorate
Resolution: Minutes of 2011-01-18 approved w/o
Action: id=2010-09-22-8 status=pending owner="EricJ" produce new proposal for ASSEMBLY-227
Action: id=2011-01-04-1 status=done Johnson in absentia to create a proposal for the resolution of Assembly-239
Proposal for ASSEMBLY-239 completed & waiting for comments
Have provided comments - need wider debate
Action: id=2011-01-04-2 status=pending Edwards to write a new proposal for the resolution of Assembly-246 along the lines contained
Waiting for new draft - now available
Action: id=2011-01-18-1 status=done Edwards to take the appropriate steps with TC-Admin to accomplish the progression and review of
OASIS Admin has ack'd
Robin is ctahcing up for Mary - Also some questions regarding ref's
Action: id=2011-01-18-2 status=done Johnson to propose more concretely what the different roles of global vs local channels might
Volunteers to help out here - needs some guidance
LOA request from Bob Freund
Cannot grant from today - need 1 weeks notice
No objections - LOA approved from 2011-02-01 tru 2011-02-22
OASIS Admin working on this (see above)
AnishK describes work done - notes that 1.2 needs bringing in line with 1.1 (CSD07)
All issues/comments/notes resolved/removed?
One remains - related to text added at F2F - some questions regarding what should have been added
...Will raise new issue in JIRA
Open Issues 1.1
Open Issues 1.2
E-mail from several TC members
Disconnect between different views of how channels used
aren't we moving away from the main issue at hand, which is whether there is a need for auto-wire. I understand that there
are some related issues, but the current discussion is about getting rid (or problems wrt) global channels -- which is a very
what issue are we talking about, this isnt about autowire
why are components at a domain level connected to a global channel different from coponents in a composite connected to a
ihmo there is no difference
EricJ gives detailed argument about differences between global and local channel usage
Noted some minor issues (connection to non-existant channels, "/" in names. etc)
...agreed that some items not fully thought through
...most importantly notion of "topic"
...can(will) use global channels to connect to external JMS
...also for attachment of policy
Private channel (proper name no local) not intended to connect to external JMS
Not how things currently defined - can be used to external JMS
Never viewed private channels that way - always as local
...whether channel is bound to external JMS doesn't limit other eternal producer/consumers
Autowire can't be reliably determined
Channels all have same semantics - only about visibility
...no difference between global/local channels as far as capabilities - only visibility
...e.g. child can't access parent channels
...Don't see how the current discussion relates to autowire
Line 2815 says..
Channels within a composite used as an implementation are private to the components within that composite. These private
channels can only be the targets for producers existing within the same composite as the channel. Private channels can only
be sources for consumers existing withing the same composite as the channel. An SCA runtime MAY support the use of private
Seems current proposal is heading in a different direction than currently defined
It seems very strange to have these sentences and yet also allow these channels to be bound to external JMS topics
The intent clearly is to keep the comms private to the composite
...that is separate debate - currently only about visibility of channels
peter, i read that in the context of SCA -- it is not available to the components outside the composite -- in that sense it
is private to the composite. The fact that there are channel bindings imply that any channel can be bound to an existing pub-sub
peter, if this causes confusion, i think we should change the wordings to replace private with local -- I take back what I
said on the call -- the spec, obviously, does use the word 'private'
Agreed this isn't autowire - but decided that these issues need addressing before others make sense
...seems that view of channel varies dependig on top-down vs bottom-up design
...this should not be the case - should look same no matter how desgin is done.
sounds like a new issue that needs to be raised: change concept of global channel
Not really trying to go in a new direction - pointing out that lots of things are fully defined
anish, I'm arguing that we used the word "private" for a reason.. it is to allow the event flow to be encapsulated within
the composite. It's counterintuitive to have something that does that, but which also allows events to flow in and out in
a completely unmodelled fashion. Suppose I have two composites with two different private channels.. if I bind them to the
same JMS destination then events will flow between them. Even if they are bound to different JMS destinations events might
flow betweeh them, because who knows what kind of JMS hook up is going on behind the scenes. It seems to me that binding to
externally visible JMS destinations is an important concept, but needs to be kept separate from this private channel idea
Not making any progress on this - we need to move forward.
I am happy with binding global channels to JMS topics (argument is that these JMS things are outside the assembly and therefore
global to it). Are there some use cases that this fails to support?
...same points being made again and again
Agree need to restict to issues being discussed - if there are broader issues then address separately
Can see that autowire simplifies some things but fraught with problems
peter, we (oracle) dont want events encapulated within a composite otherwise the sce runtime will have to police these private
channels and not allow messages to escape
peter, i don't have a problem with the model you are proposing, but what we have now, we allow bindings on global as well
as local channels
if we want to change that we should talk about it
that's why the spec says private channels are RFC 2119 OPTIONAL
i think we are forgetting what the spec says
I think bindings on Global channels are fine and I don't see a problem with them
mikeE, i believe peter does not like bindings on local channels
I would prefer local channels to use bindings (if any) which are non-specific - ie like <binding.jms/> which simply says "use
JMS for the protocol, but with "private" locally created resources like Queues or Topics that are left to the runtime to allocate
- we have that situation for use of jms in services / references
i don't have a problem with that. the issue is once you use JMS, you cannot necessarily guarantee that noone else outside
of SCA is participating -- which I'm ok with, but peter seems to think that this is a bad idea
true, unless you secure the JMS resources in some way
same is true of almost any other protocol that you might use
it is up to the SCA runtime to determine the level of assurance that it will provide
+1 to that. I'm of the opinion that we can only talk about what happens in the SCA domain/components/composites
if the deployer/system does any bridging, all bets are off wrt what events are produced, by whom and who sees them
I agree with one exception - if there are Filters expressed then they should be honoured by however the Channel is implemented
by the SCA runtime
which ain't really an exception - its a demand on the SCA runtime implementation
I think that if the assembly says that only certain Event types pass, that should really be the case...
i agree -- that would be part of the SCA contract
wrt sca components
Martin - do you have the roll please?
Schreiber diagnostics output
[Delete this section before publishing the minutes]
final validation: Date not specified, the date '2011-01-25' was assumed
final validation: Title not specified, default title 'Oasis SCA-Assembly Teleconference...' was assumed
final validation: Chair not specified, default chair was assumed
statistics: Schreiber found 115 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 3: s/1./agenda: 1.
edits: Line 31: s/bojections/objections/
edits: Line 92: s/work/word/
edit-substitute: command on line 3 succeeded, changed line 1 from '1.' to 'agenda: 1.'
command-scribe: Line 2: Scribe 'Eric Wells' is recognized by use of the nick 'EricW'
command-scribe: Line 2: EricW's nick 'EricW' has been selected
edit-delete: Line 3 was deleted
edit-substitute: command on line 31 succeeded, changed line 30 from 'bojections' to 'objections'
edit-delete: Line 31 was deleted
citation-detection-scribed: Line 34: Check for possible unrecognized nick '1.2 Assembly spec draft'
citation-detection-scribed: Line 44: Check for possible unrecognized nick 'ASSEMBLY-250'
citation-detection-scribed: Line 49: Check for possible unrecognized nick 'Latest discussion'
edit-substitute: command on line 92 succeeded, changed line 90 from 'work' to 'word'
edit-delete: Line 92 was deleted
citation-detection-scribed: Line 137: Check for possible unrecognized nick 'COB 9'
system: Transformer: SAXON 184.108.40.206
[End of Schreiber diagnostic output]