Minutes
Opening
MikeE:
Does anything need to be added (or moved) to accomodate?
ASSEMBLY-227 purposely split to allow consideration
Anish:
Will send proposal for ASSEMBLY-238 later today.
Swap ASSEMBLY-238 & ASSEMBLY-235
Anish:
Also have presentation (15min) from discussion on OSOA Event handling
Add Anish's presentation at 11:00AM today
No comments - no objections
Resolution: Minutes of 20100914 approved w/o
MikeE:
Notes there have been no comments so far on Implementation Type & Test Adaption PR docs
ASSEMBLY-227: Promotion of consumers and producers undermines composability
Agreement to "restate the problem" and summarize
EricJ:
Issue is really about composability
...details of what is wired to what is hidden
...sometimes need to expose these details
EricJ:
Problem is then how to represent the intended wiring of the composite
...not so much of a problem with global channels, but not the best solution
MartinC:
Global channel;s not part of the solution really - How can we solv the issue WITHOUT using global channels
EricJ:
Illustrates original proposal on whiteboard
..."local" channel is exposed in composite by promotion
MikeE:
How does developer of composite know how a USER of the composite is going to use it?
...developer can't really know how composite is used
DannyV:
When local channel is used currently upper layers cannot see channel.
MartinC:
Essentially it is a problem of "joint promotion"
...if produer A is promoted then consumer B should also be promoted
EricJ:
Describes an "Event Log" type use case where producers (& consumers) at various levels want to write events to log
MikeE:
Argues that this use case should use global channel
Anish:
Can't see how (in general case) you can determine how things are connected without looking inside composites
...(gives example from EricJ's document)
EricJ:
Situation is similar to service/reference - same problem don't know if service is the one we want
Anish:
Difficulty in using global channels is "name conflict" - two or more composites that both want a global "log channel"
...maybe this is a different issue
PeterN:
Probably do need better name management on global chanels - another issue
PeterN:
Things shouldn't change semantics when promoted - if producer/connsumere is promoted then shouldn't have to worry about if
they are connected within a composite
MartinC:
Naming is separate issue but needs to be raised
...what is needed is to be able to group the promotion of producers & consumres
<Peter Niblett>
what i was trying to say is that the issue here occurs when you promote both a producer and a consumer AND the composite only
works properly if they are connected together AND you want the composite to work both standalone and in an assembly where
they may be connected externally
MartinC:
Like deferring connection to higher level because we don't know at current level
...What you're saying is "when A & B are connected then connect them to the same channel"
DannyV:
Local channels also need ability to say producer/consuer MUST NOT be connected (to avoid looping issues)
PeterN:
Want composite to work "standalone" but also work when used in other composites
MartinC:
Don't fully understand looping issue - not connecting channels, just the endpoints
...its up to producer/comsumer if event is placed back onto channel
PeterN:
Would not accept a proposal that prevented individual promotion of producres/consumers
MartinC:
Suggestion is to add ability group producers/consumers for promotion
<Peter Niblett>
Two basic principles 1. need to preserve the ability to promote a singular producer of consumer. That is so that I can have
a composite implementation of something that looks like a simple producer to the next layer up (likewise consumer).
<Peter Niblett>
2. There should not be any extra external features of a composite that don't apply to a simple component... e.g. if we postulate
some kind of grouped producer/consumer on a composite we have to permit (and rationalise the purpose of) that kind of construct
on a simple component
<Peter Niblett>
continuing on 2, a composite is not a channel
DannyV:
Composites can have communication internally that may be oveerridden by channel
...e.g. AJAX web component - works standalone, but uses channel in SCA when promoted
PeterN:
Describes options listed above
...result of composing components should be anothr component
15 min break - resume 11:00AM PST
<Peter Niblett>
I have posted a suggestion to the list
<Mike Edwards>
if you'd like to speak Peter, you're welcome
MikeE:
Reviews proposal originaly sent 22-Jun-10:
<Peter Niblett>
My Option 2 was to use an indirect reference, of the form
source ="/SCA/ChannelA"/
The /SCA/ or some similar syntax indicates that it is a reference to some external channel.
An assembler can then define a local channel at a higher level called Channel A with a flag to say it should be visible from
components inside nested composites.
<Peter Niblett>
That way they get to redirect the channels used by their internal components
<Peter Niblett>
The issue of whether this reference needs to appear in the composite component type is a separate one in my opinion
<Peter Niblett>
s /External/Non-local/
<EricW1>
MikeE: "Virtual" channel inside composite, property points to higher level channel
<EricW1>
Ashok: What if composite is not used in higher level - how is internal channel connected?
MikeE:
Can be set with default
...could be local or global channel
<Peter Niblett>
so maybe you don't have a special syntax. All domain channels can be respecified by a composite assembler
<Peter Niblett>
and if you haven't respecified it drops through to be a real domain channel
PeterN:
Problem with global channel is there's no indication of the dependency of the producers/consumers
<Peter Niblett>
if you think I am talking nonsense there's easier ways to stop me
...just connect all things that need "fire alarm" events to the "fire alarm" channel
PeterN:
The problem then is knowing the correct name and if it changes
MikeE:
Default for rediretable channel is a property that is both inspectable and overridable
(refer to above E-mail from Mike for detail)
PeterN:
Should be a reference to a channel not a channel
EricJ:
Seems that "channel" is being used in different senses
...Mike seems to mean something different than Peter (and EricJ) by "channel"
<Bryan Aupperle>
Would intents be additive or replacement?
(Also see Anish's proposal above)
DannyV:
Mike's & Eric's seeme similar in use but need some clarification
...why do channels need to be named? They should just exist and be unique via the runtime
...if things are (accidentally) given same name the wouldn't there be "crosstalk"?
DannyV:
If A and B need to communicate within composite then must refer to property, but then what happens if propert is overridden?
EricJ:
Still seems to be different ideas of what a "channel" is
EricJ:
1) Channel has policy, intents, events (produced & received), filters
...2) Channel has a nae, binding
MikeE:
"Channel" is just an identity to allow producers/consumers to refer to it
MartinC:
"Name" of the channel is to allow access to metadata
Discussion on filters and how/where they're applied
EricJ:
Need to know what filters are applied to internal channels at higher levels so that correct substitutions (overrids) can be
made
PeterN:
Channels are a place where producers and consumers can communicate and policies, intents, filters can be applied.
...want a mechanism to be able to replace a local channel with a higher level one
...how do you know what to replace it with unless you look insdie the component
PeterN:
Don't like that simple components and composites look different
Anish:
Seems to be problems with all of the proposals
...we seem to be trying to "recreate" service/reference in publish/subscribe/event environment
...however they don't work the same way.
Intents applied to channel affects ALL producers and consumeres that use the channel
Anish:
The can invalidate lower level connections by applying intents at higher level
...This is a problem with all the proposals
<Peter Niblett>
it seems to me we have two models at the moment. One of them uses local channels and promotion of producers/consumers. This
is a "clean" encapsulation model, like we have for services and references, and the sorts of issue that Anish raises don't
apply. However we also have a model that uses global channels.. and what we have been talking about is extending that global
channel concept
DannyV:
Some implemention details creeping in - seem to be arguing in the abstract and using implementation to justify
Break for lunch - resume 1:30PM PST
<Mike Edwards>
Updated agenda for this afternoon:
EricJ:
Not arguing for WSDL 2.0 but shoulkd allow other than WSDL 1.1 and not require mapping
...could use other interfaces and mapping can produce false mismatches
EricJ:
Also don't want to preclude WSDL 2.0 (should anyone want to do this)
Anish:
Do you want to relax mapping to WSDL 1.1 or WSDL 2.0?
EricJ:
Want to reconsider what it means for interefaces to be compatible
MartinC:
We should not just add another mapping - we should define generic rules to determine compatible
Discussion on issues for "non-interface" services like REST
Ashok:
Interfaces were separated from binding but now want to link them for REST (etc)?
MikeE:
Client & service could be in completely different languages - WSDL 1.1 chose as known "common ground"
...can't be sure with other mappings that compatability can be checked
...only people using same language can be shure interfaces are compatible
Ashok:
Need to determine binding early then describe interface in that language
MartinC:
Necessity for mapping to WSDL 1.1 does not require everything to actually use WSDL for compatibility
JeffE:
But how can you agree on what language to use in a standard way?
...difference is not if it can be done, but if it can be done in a standard way
EricJ:
1) "Remoteable" interfaces may not be expressed as such in SCA due to WSDL mapping
...2) SCA "remotable" interfaces may actually not be compatible
MikeE:
Design was to not place any restrictions on implementations for each end
EricJ:
Need to be able to say things are passed by value and only way currently is to mark then as "remoteable"
...need to separate two features
MikeE:
Allow the opposite - pass by ref in on same mahine for local optimization
EricJ:
So what is being said at present is "pass by value & remoteable" or "pass by ref & non-remoteable"
...but these are separate and should be independantly specifiable
MikeE:
Can do mapping but not necessarily capture all semantics
MikeE:
Would be good to see an example (e.g. Java) to determine what "extra" is needed.
Action: Check spec to see where it may be possible to relax mapping req owner=EricJ
Action: Produce example of two differnet languages using non-WSDL IDL owner=EricJ
15min break resume 3:00PM PDT
Anish:
By allowing bindings on producers/consumers the same problems as previously seen on reference bindings
...Bindings should be on channels not on producers/consumers (but intents allowed on p/c)
MikeE:
But then can't connect consumer to external source of events
Anish:
There would be an exception for external sources (as there is for external references)
...so if a consumer has a source attribute (channel) then there can be no biding for the consumer
...conversely a consmuer with a binding has no source attribute and connects to an external source
Anish:
In summary it doesn't make sense to specify bindings for producers/consumers that only connect to channels (internal to SCA)
... This raises the question: Do external sources have to be modelled (as channels) in SCA?
Discussion regarding multiple bindings on channel vs single binding
Multiple bindings on channel would require translation of events from one binding to all others
Multiple bindings would not be required, but would have to do translation if supported
Anish:
Can producers/consumers that dont have target/source have binding elements?
MartinC:
That would be equivelent to an "anonymous local channel"
DannyV:
How would that differ from service/reference?
Discussion of possible use case - what does it mean to put a binding on a consumer?
<anish>
Agreed outline for resolving this issue: bindings will be allowed only for channels, producers and consumers cannot have bindings.
Whether multiple bindings are allowed for a channel will be raised as a separate issue.
MartinC:
IF there are multipe bindings on channel producers/consumers need to be able to select which
(This is currently possible using source/JMS, etc)
Motion: Remove the binding sub-elements from producers and consumers m=Anish s=Danny
No further discussion - no objections
Resolution: Remove the binding sub-elements from producers and consumers
Action: Produce concrete proposal for ASSEMBLY-241 based on directional resolution in F2F minutes owner=Anish
Action: Raise new issue regarding multiple bindings on channels owner=Anish status=done
ASSEMBLY-227 Revisited
Anish:
Intended only as illustration of use cases and some customers perspectives
...not intended as an "example" or "recommended" implementation
...Five different proposals considered in OSOA - lots of detailed discussion & compromises to reach spec submitted to OASIS
Anish:
One of main motivations was to integrate existing infrastructure into SCA
...(non)requirements just what we've found from our expereience
...channels not scoped to SCA only - external producers/consumers as well as internal
Anish:
Also don't do filtering on channel - on consumer
...filter on SCA channel prvents all consumers from seeinng events
...SCA could either just drop messages that don't fit with channel filter or treat as producer error
Anish:
Customers only used global channels which allowed load-balancing etc
...users hated JMS administration - SCA should avoid if possible
Anish:
This is probably a narrow selection of customers and may not be vaild in general
...Event source/target viewed as global resource - no local channels
...driven by need to optimise implementation
EricJ:
So how are users using global channels?
Anish:
Connections to a channel reflect participation in a community - how that maps to (e.g.) JMS topics is irrelevant
...I.e. there would be "sales" or "accounting" channels which each map to one or more topics
5:39PM PDT Recessed until 8:30AM 23-Sep-10
ASSEMBLY-238: (1.2)
Anish:
Bug in draft doc - EventType type declared twice in schema
...appologies, but haven't had time to produce new draft
PeterN:
Is this related to W3C work?
Anish:
Yes, but they're not finished yet
...we can fix ASSEMBLY-238 then look at W3C have done - not sure it will apply
MikeE:
A substitution group would allow for event type descriptions to be written in event processing language (Java, etc)
Discussion on errors reported in JIRA
Two different things called "EventType" - one used for filtering the other for defining a substitutio group
MartinC:
Should we also consider adopting WS-RA EventType spec?
Action: Raise issue regarding adopting WS-RA Event Type spec owner=MikeE
Ashok:
Doug Davis says this will be in final recommendation spec as IBM and Oracle have agreed to implement
Ashok:
Notes that this is conjecture and can't be relied upon
Detailed discussion on what needs to be fixed
Anish:
Need to fix producer issue also
MikeE:
Similar situation to PolicySet definition
Action: Raise issue to add eventType declarations to "definitions.xml" owner=MikeE
Discussion of how Bindings relate to Consumers, Producers and Channels
Anish:
Summarizes yesterdays discussion
...Bindings will be removed from producer and consumer
...maybe will allow multiple bindings on channel
Ashok:
Need to discuss the default channel - overridable? Can add binding?
<Ashok (Oracle)>
c/overridable/configurable/
<Mike Edwards>
(raised as a result of yesterday's discussions)
Motion: Open ASSEMBLY-242 m=DannyV s=EricJ
No discussion - no objections
Resolution: ASSEMBLY-242 opened w/o
Anish:
Two choices for binding subelements in channel: 0..1 or 0..N
...if the latter then each binding provides an alternative way to "access" the SAME community of events
Binding.sca is assumed unless otherwise specified, in which case it is replaced
Anish:
If we allow multiple bindings we should not require support (only require one binding)
EricJ:
We could turn channels into an extension point so implementers could define there own "multipe bindings"
Anish:
Service and reference are not extension points - think this goes too far
straw poll: In favor of restricting to single binding (without extension)?
MikeE:
Problem with mulltiple bidings is that it more or less requires sending and receiveeing over all protocols
...this is not how it work normally work - one protocol would be used for sending the other(s) for receiveing
...I.E. two (or more) different sematics for multiple bindings
...better to only allow single binding but allow extension of channel
Summary: "base" channel simple with 0..1 bindings
abstract type to allow multiple bindings in <channel.bar> extension (XML substitution group)
<Eric Johnson>
Adopt as a direction for resolving Assembly 242 that we introduce channels as an abstract extension point in the same pattern
as binding and implementation, and that we introduce a channel.sca that allows for at most one binding.
<Eric Johnson>
Adopt as a direction for resolving Assembly 242 that we introduce channels as an abstract extension point in the same pattern
as binding and implementation, that we introduce a channel.sca that allows for at most one binding declaration, and that all
conforming implementations must support channel.sca
Anish:
All implementations would need to support channel.sca
<Eric Johnson>
Eric moves that we adopt as a direction for resolving Assembly 242 that we introduce channels as an abstract extension point
in the same pattern as binding and implementation, that we introduce a channel.sca that allows for at most one binding declaration,
and that all conforming implementations must support channel.sca
Motion: m=EricJ s=AnishK Adopt as a direction for resolving Assembly 242 that we introduce channels as an abstract extension point
in the same pattern as binding and implementation, that we introduce a channel.sca that allows for at most one binding declaration,
and that all conforming implementations must support channel.sca
Danny:
Semantics really should follow service/reference and not be driven by syntax
MartinC:
Don't think they're quite the same - service/reference (parameters) not expected change
...there IS some expectation that event processing does change parameters
EricJ:
Part of proposal for ASSEMBLY-227 would allow producers and consumers to be linked and essential become "definition" of channel
MartinC:
Issues of "multiple binding" has morphed into "are channels extensible?"
...would be better to separate issues and focus on multiple bindings in this discussion
Anish:
In this case channel would need to be concrete not abstract
No support for motion - motion fails
<Eric Johnson>
Need action item: Someone should raise an issue as to whether channels should be extensible.
Action: Raise issue as to whether channels should be extensible owner=EricJ
Anish:
In this case proposal 1 in JIRA would be best way to resolve ASSEMBLY-242
Motion: Resolve ASSEMBLY-242 by changing maxoccurs on binding child element from "unbounded" to "1" (one) m=Anish s=MikeE
Danny:
Support motion but need to allow extensibility for multiple bindings
No further discussion - no objections
Resolution: Resolve ASSEMBLY-242 by changing maxoccurs on binding child element from "unbounded" to "1" (one) w/o
MikeE:
Anything else to discuss at preseent on this topic?
ASSEMBLY-277 Revisited
MartinC:
What is the "little blue box" at the edge of a composite?
EricJ:
Explains current thinking on channels/composability
...channels conceptualized as 1<->1 mapping to JMS topics
MikeE:
Consider model is pub/sub and channels not necessarily best solution
MartinC:
Sees channels as a "named access point"
EricJ:
@target = //destination @source = //destination
...(maybe "../" to reference upper level?)
...reference would need to be part of componentType for visibility
MikeE:
Need to be able to process received events before sending back to same "destination"
Recess for lunch - return 1:00PM
Waiting for Oracle members to return from another call
Resuming - setting up projector
Waiting for anyone on the 'phone - will start at 1:30PM regardless
Ashok:
Reviews presentation
Ashok:
Does policy actually apply to events? Produceres and consumeres decoupled so does policy apply?
Anish:
If spec says nothing about policy then how could it be applied? (##other)
Ashok:
Can default channel be configured with policy? - Yes
...Can binding.ws be used for events? (WSDL porttypes vs Events using EDL)
MikeE:
Yes - use WS-Eventing
Ashok:
Match policy between producers/consumers?
...policy on producers, consumers and channels?
EricJ:
Some may need matching, some only apply to producers, some to consumers
Danny:
What would it mean to put policy on channels if (say) a peer-to-peer implementation? - Nothing to enforce/implement policy
Why would consumer need to have policy?
To ensure both producers & consumeres can handle events (e.g. have correct stack to decrypt)
matching (promoted) policy ensures endpoints can communicate
EricJ:
With multiple recipients in different locations some may not care if message is (e.g.) signed
Anish:
How does this differ from service & reference
Danny:
Policy could be "just" a filter on the consumer
MikeE:
Can interpret policy as either "message must be encrypted" or "software must be able to handle' encryption"
EricJ:
It means different things to attach policy at different points
Danny:
Is policy about assembly or runtime?
...Does policy apply "per message" e.g. consumers only accepting messages with "integrity" and rejecting others
...intent on consumer states what it can/will accept
...intent on producer states what is produced
...intent on channel states what is transmitted
...these are all different things
Discussion of to what extent underlying implementation "shows through" and influences model
e.g. hub/spoke influencing how policy on the channel could be implemented
MartinC:
Probably can't do this in a genereic way - will need to examine policies in each circumstances - its hard to do
MartinC:
Would only work in general if policy ONLY applied to channel
...can policy match between producer/consumer & channel but can't really do end-to-end producere to consumer
Anish:
But some policy will require end-to-end matching
MartinC:
In that case it would have to be proprietary
Anish:
We could just say nothing about policy for events - no schema, nothing
MikeE:
This would be less than useful
EricJ:
Could use "placeholder" schema to allow but not define policy
Ashok:
Auto-import Option
...consumer just imports producer policy and cofigures accordingly
Ashok:
Could also consider this for service/reference
Danny:
Depends on model multiple producers single consumer or single producer multiple consumers
MikeE:
Some policy is "determined" by producer (e.g. this is sensitive data it will be encrypted)
...other determined by consumer (e.g. where did this data originate?)
...hence can't just import producer or consumer - would need to import both and resolve discrepencies
Danny:
We would need to define algorithm for assemblers to define how policy would be imported
...also MANY different use cases that could modify meanings of policy
...requiring policy match would be requiring messages to flow - which may not be the case
Considerable discussion - no specific conclusions
PeterN:
Did we agree that policy for producer/consumer is significantly different from service/reference?
PeterN:
Seem to be assuming pub/sub which is not the case
MartinC:
There's been considerable discussion on how to generalise
Anish:
Explains use case - differences between point-to-point of service/reference and "many-to-many" for producer/consumer
Brief rehash of issues discussed
Danny:
Many more use cases that makes solving things generically very difficult
...Authentication - consumer checks producer - info is placed in message (e.g. token) to authenticate
...Authorization - are event messages deliverd to consumers
...Identity Propogation - propogate, non-propogation, substitute identity
PeterN:
Authorization (and other) applies to both producers and consumers
Brief discussion on what can be specified in current model
Message Encryption & Signing
Ashok:
AtLeastOnce, AtMostOnce, ExactlyOnce, etc - how does JMS support this?
MartinC:
This is point raised eariler - how do we know an event is not a duplicate?
PeterN:
Application can use seq numbers etc.
MartinC:
Exaclty - application logic but not within SCA model
Discussion of requirements for (e.g.) durable consumers
Anish:
Consumers may expect/need two (or more) messages from application POV
...we need to define what is meant by (e.g.) "ExactlyOnce"
Ashok:
Note there are no use cases for transactions
DaveB:
Transactions really too tightly coupled to apply to event model
Danny:
Some policies change meaning depending on implementation model (peer-to-peer, hub/spoke)
...need to consider implications for all uses cases
MikeE:
Need to ensure that there's sufficient metadata to handle both sorts
ASSEMBLY-227 Continued
EricJ:
Resumes discussion of proposed model
EricJ:
Bottom level defines a "logical" channel and its attributes
Danny:
Specifying requirements for a channel that is instanced by the runtime if no other composite provides instance
PeterN:
Missgivings as composite is no longer a component but some sort of hybrid
PeterN:
What is the artifact at the composite border?
Danny:
Atrifact does not implement a channel - says a channel is required (and gives constraints)
Danny explains how Java would implement
Danny:
Composite does NOT implement a channel - states the need to create a channel (between producers/consumers in composite)
MikeE:
Concerned that this doesn't allow intermediate processing of events from producer sent to same channel
Danny:
Can, but don't want to require producer/consumer tied by a global channel - want less restriction
MartinC:
Isn't this just extra syntax to "group" promotion of producers/consumers?
MikeE:
What is being asked for is that at some higher level there IS a single channel that connects producers/consumers
MartinC:
There's no requirement for a single promoted producer to be connected to a channel
...service/reference can be required to be wired
MikeE:
Looks like a constraint (intent) that producr/consumer MUST be connected
Anish:
What about two (or more) consumers treated in same way (connected to same channel)
PeterN:
If producers/consumers could be directly wired then this would work in existing model
Anish:
Set of producrs/consumers provided with sufficient info to connect them at a higher level
...explains "prosumer" "element" that groups connected producers/consumers
<Peter Niblett>
so my suggestion was a) permit producers to be wired directly to consumers (no new syntax is required to do this.. we just
need to remove the sentence that says you can't). Then b) you have a design pattern that says that the assembler of the lower
level composite has to wire the promoted promoted to the promoted consumer
<Peter Niblett>
the promoted producer and consumer are connected via an external wire
<Peter Niblett>
which the higher level user can choose to keep, or rewire
MartinC:
Defines a specified set of producers/consumers as an entity that can be promoted
<MartinC>
sounds like a hack to me
MikeE:
But this doesn't allow parts to be treated as individual producres and consumers(?)
Anish:
Could promote individual producers and consumers
...either exclusively with "prosumer" or inclusively
<Peter Niblett>
This whole problem is caused because we want the producer and consumer to be wired together internally when the composite
is used standalone, but not wired together internally when you want to add an external producer or consumer in a higher composite
<Peter Niblett>
my solution avoids this by making the wire external, so it can be removed (if you want to) without having to look inside the
implementation of the composite
<Dave Booz>
so perhaps in the latter case the composite should be included instead of used as a component
Anish:
Any restriction on the number of channels a "prosumer" could be connected to?
Jeff; Can this be done at present? (Within spec)
EricJ:
No (gave explanation)
Danny:
Either consider as originally proposed as channel reference
...or just view as constraint that producers and consumers must be connected to each other (at least once)
PeterN:
Can I provide a suggested channel that should be used?
...need to avoid problem of two different composites trying to use same channel "name" but that should not be connected
Danny:
Would be preferable to not specify an actual channel at all
Anish:
When group of (e.g.) consumers promoted as group, higher level cannot treat grouped consumers individually
...higher level composite has to treat promoted consumers as a single composite consumer
..."prosumer" should be treaated in same way
...Creator of componet decides how elements can be promoted (for whatever reason)
Danny:
Don't think we should see this as "adding something new" because ALL event processing is new to SCA
...we can add what we like as long as we specify what is being added
MikeE:
Explains objections
...Its not the constraint to connect producer/consumer (which can't be removed at higher level) but the fact the higher level
composite cannot connect additional producer/consumer to promoted entity
...wants something that does not change the existing model but adds a constraint to say "somewhere in the hierarchy A & B are
connected"
MikeE:
Do events HAVE to flow between "prosumer" connected producer/consumer?
...if so then problems with filters which may prveent events being sent/received
Discussion concerning filters on promoted producers/consumers
5:40PM Recessed until Friday AM
<Mike Edwards>
ok, we're in now
Agenda - Day 3
MikeE:
Tying up loose ends
EricJ:
What about W3C Event specs?
Anish; Very simple spec - should be very easy to incoporated if e decidee it's useful
...also we can use their types, but will probably need to define our own elements
Brief discussion on WS-EventType
Sufficient details covered to not require an additionl agenda item
ASSEMBLY-227
MikeE:
Gives summary of yesterdays discussion
PeterN:
Two reasons to compose - 1) to create logical entity 2) for convienience (e.g. NAND logic gates)
DaveB:
Also two methods - 1) by promotion 2) by inclusion
...can't see why TIBCO's use case can't be solved by inclusion
MikeE:
From discussion of details this doesn't seem possible
Dannyv:
Explains use case
...Java logging component (existing prior to SCA maybe Spring)
...want to expose so that it can source and receive events
...internally component achieves logging in various ways depending on type of event (high priority, etc)
PeterN:
Can't see why you would have a component that would need to receive events that it generates
...what you need is an internal wire that dissapears only if the composite is externally connected
DaveB:
If producere & consumer were in different composites then would still need to connect them together
...within a composite it could be the developer, but at the higher level it would be assembler who decides connections
MikeE:
Describes use case where internal & external connection give duplicate messages (a bad thing)
DaveB:
Proposals have some metatdata that ties producers/consumers within a single composite
...but what about the use case where producers and consumers are in different composites?
...we should try to find a solution that applies to general case
Dannyv:
Existing solution would be to use a global channel - BUT that breaks encapsulation
<Dave Booz>
what if channels were defined outside of composites instead of scoped to composites?
...alternatively create a local channel (at the lower level) and then promote - but can't see the channel at higher levels
<Peter Niblett>
I have sympathy with the view that global channels aren't good encapsulation, so I suggested (my original option 2) that
you should be able to remap channel references and associate them with channels that are local to any level of the composition
<Dave Booz>
+1 to Peter's comment
<Peter Niblett>
the minimalist version of this is that I can define a local channel (at some arbitrary level > 1) and give it a set of alias
names. Any components at lower levels that reference one of those aliases get mapped onto that channel. So at my leaf node
if I say target = /myChan and someone at a higher level declares a local channel foo with alias myChan, then the leaf node
will start using myChan. If that local channel foo is removed, it bubbles up to a domain level channel (as today)
MikeE:
Describes proposal with "expectedSource" and "expectedTarget" (exposed in componentType for promotion)
<Peter Niblett>
I proposed this on Wednesday, but people didn't like it. I think they wanted to have a local channel at the leaf level that
acted as a default. But we seem to have stopped talking about that now, so can we look at this proposal again?
...question then is whether runtime ENFORCES connections between "expected" channels or if just hints
PeterN:
Don't understand why this would be needed
MikeE:
From previous discussion there's an orthogonal requirement for the ability to say source/target UST be connected (to channel)
...not necessarily an expectation that anyone is listening or messges are sent/received
...just that it is definitely an error if the source/target is disconnected
<Peter Niblett>
An extension of my original proposal is to make the reference visible in the component type - that addresses the concern about
encapsulation as well
<Peter Niblett>
that reference would be something that doesn't (to my mind) make sense for a singleton component, but I could live with that
Discussion of Mikes poposal
<Danny van der Rijn>
@Peter: 'Reference' or 'Consumer'?
<Peter Niblett>
I meant "channel ref", I forgot there was already something called reference, e.g. the thing that appears as the source/target
of the consumer/producer
<Peter Niblett>
the //Mychan
Anish:
Don't like the idea of cardinality for event processing
...maybe "more than one" is OK , but not happy with upper bounds
MikeE:
Different requirements1) Want to create a closed community - no other connections
...or a "minimal set" and once these connected don't care if there's additional connections
Much detailed argument - scribe failure: can't keep up
MartinC:
Seems to be several orthoganal issues embedded in ASSEMBLY-227 we should try to separate these and raise individual issues
...Allowing 1/2 hour more for 227 and hope to at least get a list of subissues
EricJ:
Explains latest variation (on whiteboard)
<anish>
death by promotion
<anish>
in any sca hierarchy, each channel, producer and consumer get promoted to its own level of irrelevance
Action: owner=EricJ produce new proposal for ASSEMBLY-227
Policy
Ashok:
Summarizes yesterdays discussion
...1) Need policy on events
...2) Most intents apply to events EXCEPT transactions (may need to consider specific applicability to producers/consumers/channels
DannyV:
Actually agreed that implimentations would need policy, but NOT that the spec has to say anything about it
...looks like it could be too complicated for us to produce a useful specification
MikeE:
Should try to see what we can do and "rollback" if it dosn't work
Ashok:
Existing policies: Confidentiality, Authentication, Integrity, Reliability (of messages), Authorization
EricJ:
We should do this in a way that allows us to "fail gracefully" (e.g. not mandate a transport)
MikeE:
Don't see why this would be more difficult than what we did for service/reference
Dannyv:
There may be enough semanic differences between (say) peer-to-peer and hub/spoke to make policies difficult (impossible) to
realize
...Service/reference is constrained by wiring to make situation simpler
Ashok:
These are abstract policies that can be realized in various ways
Dannyv:
But don't want to make policy so abstract it's not useful
Ashok:
continues with "agreements"
... 3) Matching policies: consumer/channel, producer/channel
MikeE:
Matching could be left to Assemblr (if to difficult to automate)
...but preferably do some sort of matching to make life easier
...Also consider "accommodation" - consumer doesn't care how messages are treated (e.g. encryption) but can it accept if produced
...i.e. requires encryption vs can accept encryption
...4) Import of policies (between producers/consumers/channel)
Discussion of "optionality" of policies and how that could apply to different artifacts
(e.g. channel can support encryption, producer may encrypt messages, consuer can decrypt messages)
Implimentation & Test for 1.2
MikeE:
Tuscany guys completely involved with 1.1 no spare capacity for 1.2
General question of how this should be handled
MikeE:
IBM Tuscay will not be in a position to look at 1.2 before Q1 2011 (quite probably later)
Wrap Up
Action: Raise issue WRT cardinality of channels
Action: Add RFC2119 to Event portion of 1.2
Action: Define what a binding needs to support for event processing
Motion: Thanks to Anish for hosting m=EricW s=MartinC
Resolution: Thanks to Anish for hosting w/o
AOB
Meeting adjorned 12:55PM 24-Sep-10
Schreiber diagnostics output
[Delete this section before publishing the minutes]
final validation: Title not specified, default title 'OASIS SCA-Assembly TC...' was assumed
final validation: Chair not specified, default chair was assumed
statistics: Schreiber found 534 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 39: s/og/of/
edits: Line 99: s/Ree/Re/
edits: Line 123: s/conncet/connect/
edits: Line 153: s/cahnnel/channel/
edits: Line 233: s/PST/PDT/
edits: Line 252: s/resolution/resolving/
edits: Line 256: s/sun/sub/
edits: Line 257: s/consumeres/consumers/
edits: Line 272: s/filterig/filtering/
edits: Line 278: s/genereal/general/
edits: Line 291: s/haad/had/
edits: Line 344: s/nor/not/
edits: Line 364: s/JPM/JMS/
edits: Line 384: s/Yesy/Yes/
edits: Line 419: s/Depens/Depends/
edits: Line 430: s/refernce/reference/
edits: Line 466: s/psosed/proposed/
edits: Line 472: s/i no longer/is no longer/
edits: Line 634: s/discussion/argument/
edits: Line 656: s/Summarizs/Summarizes/
command-scribe: Line 5: Since the line number is less than or equal to 20 we will interpret this as a scribename command,
note that the scribe command is deprecated
command-scribe: Line 5: Scribe 'Eric Wells' is recognized by use of the nick 'EricW'
command-scribe: Line 5: EricW's nick 'EricW' has been selected
citation-detection-scribed: Line 19: Check for possible unrecognized nick 'Add Anish's presentation at 11'
citation-detection-scribed: Line 20: Check for possible unrecognized nick 'Minutes from 14-Sep-10'
edit-substitute: command on line 39 succeeded, changed line 38 from 'og' to 'of'
edit-delete: Line 39 was deleted
citation-detection-scribed: Line 97: Check for possible unrecognized nick '15 min break - resume 11'
edit-substitute: command on line 99 succeeded, changed line 98 from 'Ree' to 'Re'
edit-delete: Line 99 was deleted
edit-substitute: command on line 123 succeeded, changed line 121 from 'conncet' to 'connect'
edit-delete: Line 123 was deleted
edit-substitute: command on line 153 succeeded, changed line 147 from 'cahnnel' to 'channel'
edit-delete: Line 153 was deleted
citation-detection-scribed: Line 182: Check for possible unrecognized nick 'Break for lunch - resume 1'
citation-detection-scribed: Line 190: Check for possible unrecognized nick 'Eric's original issue'
edit-substitute: command on line 233 succeeded, changed line 232 from 'PST' to 'PDT'
citation-detection-scribed: Line 232: Check for possible unrecognized nick '15min break resume 3'
edit-delete: Line 233 was deleted
citation-detection-scribed: Line 243: Check for possible unrecognized nick '... This raises the question'
edit-substitute: command on line 252 succeeded, changed line 251 from 'resolution' to 'resolving'
edit-delete: Line 252 was deleted
edit-substitute: command on line 256 succeeded, changed line 255 from 'sun' to 'sub'
edit-substitute: command on line 257 succeeded, changed line 255 from 'consumeres' to 'consumers'
edit-delete: Line 256 was deleted
edit-delete: Line 257 was deleted
citation-detection-scribed: Line 264: Check for possible unrecognized nick 'Direct link'
edit-substitute: command on line 272 succeeded, changed line 271 from 'filterig' to 'filtering'
edit-delete: Line 272 was deleted
edit-substitute: command on line 278 succeeded, changed line 277 from 'genereal' to 'general'
edit-delete: Line 278 was deleted
citation-detection-scribed: Line 284: Check for possible unrecognized nick '5:39PM PDT Recessed until 8'
command-scribe: Line 287: Since the line number is greater than 20 we will not interpret this as the deprecated scribe command
replaced by scribename
edit-substitute: command on line 291 succeeded, changed line 290 from 'haad' to 'had'
edit-delete: Line 291 was deleted
citation-detection-scribed: Line 295: Check for possible unrecognized nick 'JIRA Entry'
citation-detection-scribed: Line 328: Check for possible unrecognized nick 'straw poll'
citation-detection-scribed: Line 334: Check for possible unrecognized nick 'Summary'
edit-substitute: command on line 344 succeeded, changed line 341 from 'nor' to 'not'
edit-delete: Line 344 was deleted
edit-substitute: command on line 364 succeeded, changed line 363 from 'JPM' to 'JMS'
edit-delete: Line 364 was deleted
citation-detection-scribed: Line 371: Check for possible unrecognized nick 'Recess for lunch - return 1'
citation-detection-scribed: Line 375: Check for possible unrecognized nick 'Waiting for anyone on the 'phone - will start
at 1'
edit-substitute: command on line 384 succeeded, changed line 383 from 'Yesy' to 'Yes'
edit-delete: Line 384 was deleted
edit-substitute: command on line 419 succeeded, changed line 418 from 'Depens' to 'Depends'
edit-delete: Line 419 was deleted
edit-substitute: command on line 430 succeeded, changed line 428 from 'refernce' to 'reference'
edit-delete: Line 430 was deleted
edit-substitute: command on line 466 succeeded, changed line 465 from 'psosed' to 'proposed'
edit-delete: Line 466 was deleted
edit-substitute: command on line 472 succeeded, changed line 470 from 'i no longer' to 'is no longer'
edit-delete: Line 472 was deleted
command-scribe: Line 553: Since the line number is greater than 20 we will not interpret this as the deprecated scribe command
replaced by scribename
edit-substitute: command on line 634 succeeded, changed line 633 from 'discussion' to 'argument'
citation-detection-scribed: Line 633: Check for possible unrecognized nick 'Much detailed argument - scribe failure'
edit-delete: Line 634 was deleted
edit-substitute: command on line 656 succeeded, changed line 655 from 'Summarizs' to 'Summarizes'
edit-delete: Line 656 was deleted
citation-detection-scribed: Line 672: Check for possible unrecognized nick '... 3) Matching policies'
citation-detection-scribed: Line 695: Check for possible unrecognized nick 'Meeting adjorned 12'
command-autoroll/oasis: Line 696: Attempting to fetch roll from http://www.oasis-open.org/apps/org/workgroup/sca-assembly/event.php?event_id=28275
command-autoroll/oasis: Line 696: Successfully fetched roll from http://www.oasis-open.org/apps/org/workgroup/sca-assembly/event.php?event_id=28275
system: Transformer: SAXON 9.2.1.2
[End of Schreiber diagnostic output]