Minutes
Opening
Change start time for wednesday and thursday to 8am pacific
Meeting is quorate (13/25 - 52% at present)
Resolution: Minutes of 2009-11-17 approved w/o
Scott describes the TIBCO proposal ...
Eventing related metadata can be handled as mapping of Component in a composite to the ComponentType presented by the implementation
Java methods with void return, or one-way WSDL operations is one way of developers implementing event producers/consumers
Alternative of generic event dispatch methods should also be allowed
Anish:
One of the reasons behind the osoa design was - to indtroduce a decoupling between event producers/consumers whereby there
is no assumption on the event producer about the consumption of the events, its semantics, etc
Martin:
We have seen a need to extend BPEL to support events (as opposed to linking partnerLinks)
TIBCO proposal uses interface element and its extensibility to model event types, filters
Differences of eventing specific binding types
...not all service/reference bindings may be applicable for eventing
...configuration of eventing binding may also be different from service/reference bindings
Peter:
Would not want to have binding configuration determine the semantics of the logical model
...e.g. filters in the bindings
Anish:
Does the application code for an event producer know about the connection with the consumer?
MikeE:
It is far simpler for programmer to have a eventing proxy to code against
Discussion on cardinality
Does cardinality of event producer matter in the developer model or the assembler model?
Optimization of the producer to turn off the event creation if nobody is listening may be a use case, but we are not supporting
that
General consensus that producer cardinality does not make sense in the developer model - details to be sorted out
<Peter Niblett>
..so long as you are permitted to connect a producer to more than one channel
Discussion on bindings for eventing
Anish:
Could we adopt a model similar to service/reference bindings - within a composite, only services are allowed to have bindings?
Scott:
Specifying filters may get tricky
Anish:
How about bindings are limited to channels - and channels mediate if different bindings are used by producer and consumer
Peter:
Developer of a consumer knows about the filters to be applied
...which is completely independent of the binding
...place where filters are specified in the composition should provide the flexibility to the developer to use messaging for
applying filters
Scott:
Application of filters could be optimized and pushed upstream (to the producers) in the eventing world
Point of discussion: Whether consumer developer could trust that filters will always be applied
Next section from TIBCO proposal: Domain Channels
<Peter Niblett>
I would like to congratulate TIBCO on the quality of the audio in the room. I can hear every word and it feels as if I am
really in the meeting - it's an order of magnitude better than other remote meetings that I have attended
<Dave Booz>
yes, +1 from me as well
Similarities between OSOA and TIBCO models
- producers, consumers, channel model elements are similar
a> Use of interface extension point as opposed to list of event type names
b> osoa requires explicit modeling of producer/consumers, tibco model supports mapping of service/reference to consumer/producer
c> Channel transparency - use of domain channel deep in the composite with // convention
d> Binding types - generic vs specific (producerBinding, consumerBinding, channelBinding)
e> Filters - as interface/binding metadata or as an explicit construct?
<Peter Niblett>
+1 to Anish, that's an important question, and I think we do need the canonical filter
Agreement -- Filtering can be expressed by a component developer as well as assembler
...you could apply filters on the body (syntax to be discussed) and also on bindings
Not resolved -- Are component type defined filters a hint or a requirement?
Wiring rules in TIBCO proposal - the channel and producer/consumer would have methods with matching name and signature - portType
name is ignored
these rules do not impose restriction on producer to not produce other events than what is declared
<Peter Niblett>
For the record, the way we ended up in OSOA at the end of the discussion on producer type declarations were
<Peter Niblett>
1 A producer SHOULD only produce event types it has declared
<Peter Niblett>
2.An SCA Runtime MAY reject events of a type from a producer which does not declare that
it produces events of that type
<Peter Niblett>
we noted that a) When the event types produced and consumed are explicitly declared, it may be possible
to avoid the need for runtime event filters on the consumers, providing an optimized path
for the handling of the events.
<Peter Niblett>
b) Because the channel, producer and consumer declarations can include a list of event
types, it is possible to report an error when a producer or a consumer is connected to a channel, where there is no chance
that the produced events will be accepted by the
channel or the consumer will ever get any event.
<anish>
i think the issue is the mismatch between event processing and interfaces. With TIBCO proposal, we'll have to create parallel
bindings for eventing, so binding.wsEventing, binding.jmsEventing etc. If we use WSRA's EDL (and the mapping requirements),
then we can reuse the existing binding
<Mike Edwards>
ok folks we should be restarting in a couple of minutes
Assembly Specification V1.1 completion
Waiting for SCA-Policy - can now progress
Same status as ASSEMBLY-189
Plus small number of other issues against the SPEC that need to be addressed for completion
Several more against the test suite
MikeE:
Aim is to clear out the open issues - Either get a proposal or otherwise dispose of (CNA?)
<Mike Edwards>
Here is a list of the outstanding issues against the spec:
<Mike Edwards>
87
109
132
149
152
175
177
178
192
MartinC:
If there's no changes to normative text then can CNA
<Mike Edwards>
109 has been resolved (Mar 02)
ASSEMBLY-109 actually applied to spec on 03-Mar-09
<Mike Edwards>
87 was also resolved on Mar 02 2009
ASSEMBLY-87 resolved with CNA on 02-Mar-09
ASSEMBLY-101 resolved and applied 03-Mar-09
ASSEMBLY-102 CNA 03-Mar-09
MikeE:
Suggest dealing with Public Review comments later (today)
...other issues opened recently so shold look at these first
ASSEMBLY-175
<Mike Edwards>
Current Schema for Properties does not support value attribute- [ASM50027]
Schema in CD 03 Rev 5 - Appendix A
<anish>
add: <attribute name="value" type="xs:anySimpleType use="optional" />
(discussion regarding use of "value" property/attribute)
DaveB:
Version in SVN depository already has "value" in "PropertyValue"
<Dave Booz>
<complexType name="SCAPropertyBase" mixed="true">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<!-- NOT an extension point; This any exists to accept
the element-based or complex type property
i.e. no element-based extension point under "sca:property" -->
</sequence>
<!-- mixed="true" to handle simple type -->
<attribute name="name" type="NCName" use="required"/>
<attribute name="type" type="QName" use="optional"/>
<attribute name="element" type="QName" use="optional"/>
<attribute name="many" type="boolean" use="optional" default="false"/>
<attribute name="value" type="anySimpleType" use="optional"/>
<attribute name="requires" type="sca:listOfQNames" use="optional"/>
<attribute name="policySets" type="sca:listOfQNames" use="optional"/>
</complexType>
<anish>
<complexType name="SCAPropertyBase" mixed="true">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="4154 unbounded" />
<!-- NOT an extension point; This any exists to accept
the element-based or complex type property
i.e. no element-based extension point under "sca:property" -->
</sequence>
<!-- mixed="true" to handle simple type -->
<attribute name="name" type="NCName" use="required"/>
<attribute name="type" type="QName" use="optional"/>
<attribute name="element" type="QName" use="optional"/>
<attribute name="many" type="boolean" use="optional"
default="false"/>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>
<complexType name="Property" mixed="true">
<complexContent mixed="true">
<extension base="sca:SCAPropertyBase">
<attribute name="mustSupply" type="boolean" use="optional"
default="false"/>
<anyAttribute namespace="##other" processContents="lax"/>
</extension>
<!-- extension defines the place to hold default value -->
<!-- an extension point ; attribute-based only -->
</complexContent>
</complexType>
<complexType name="PropertyValue" mixed="true">
<complexContent mixed="true">
<extension base="sca:SCAPropertyBase">
<attribute name="source" type="string" use="optional"/>
<attribute name="file" type="anyURI" use="optional"/>
</extension>
<!-- an extension point ; attribute-based only -->
</complexContent>
</complexType>
<anish>
<complexType name="SCAPropertyBase" mixed="true">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
<!-- NOT an extension point; This any exists to accept
the element-based or complex type property
i.e. no element-based extension point under "sca:property" -->
</sequence>
<!-- mixed="true" to handle simple type -->
<attribute name="name" type="NCName" use="required"/>
<attribute name="type" type="QName" use="optional"/>
<attribute name="element" type="QName" use="optional"/>
<attribute name="value" type="anySimpleType use="optional"/>
<attribute name="many" type="boolean" use="optional"
default="false"/>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>
<complexType name="Property" mixed="true">
<complexContent mixed="true">
<extension base="sca:SCAPropertyBase">
<attribute name="mustSupply" type="boolean" use="optional"
default="false"/>
<anyAttribute namespace="##other" processContents="lax"/>
</extension>
<!-- extension defines the place to hold default value -->
<!-- an extension point ; attribute-based only -->
</complexContent>
</complexType>
<complexType name="PropertyValue" mixed="true">
<complexContent mixed="true">
<extension base="sca:SCAPropertyBase">
<attribute name="source" type="string" use="optional"/>
<attribute name="file" type="anyURI" use="optional"/>
</extension>
<!-- an extension point ; attribute-based only -->
</complexContent>
</complexType>
MikeE:
Need to carefully check SVN against CD 03 Rev5 for discrepancies
<anish>
<complexType name="SCAPropertyBase" mixed="true">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
<!-- NOT an extension point; This any exists to accept
the element-based or complex type property
i.e. no element-based extension point under "sca:property" -->
</sequence>
<!-- mixed="true" to handle simple type -->
<attribute name="name" type="NCName" use="required"/>
<attribute name="type" type="QName" use="optional"/>
<attribute name="element" type="QName" use="optional"/>
<attribute name="value" type="anySimpleType use="optional"/>
<attribute name="many" type="boolean" use="optional"
default="false"/>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>
<complexType name="Property" mixed="true">
<complexContent mixed="true">
<extension base="sca:SCAPropertyBase">
<attribute name="mustSupply" type="boolean" use="optional"
default="false"/>
</extension>
<!-- extension defines the place to hold default value -->
<!-- an extension point ; attribute-based only -->
</complexContent>
</complexType>
<complexType name="PropertyValue" mixed="true">
<complexContent mixed="true">
<extension base="sca:SCAPropertyBase">
<attribute name="source" type="string" use="optional"/>
<attribute name="file" type="anyURI" use="optional"/>
</extension>
<!-- an extension point ; attribute-based only -->
</complexContent>
</complexType>
<anish>
<!-- mixed="true" to handle simple type -->
<complexType name="SCAPropertyBase" mixed="true">
<sequence>
<!-- NOT an extension point; This any exists to accept
the element-based or complex type property
i.e. no element-based extension point under "sca:property" -->
<any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</sequence>
<attribute name="name" type="NCName" use="required"/>
<attribute name="type" type="QName" use="optional"/>
<attribute name="element" type="QName" use="optional"/>
<attribute name="value" type="anySimpleType" use="optional"/>
<attribute name="many" type="boolean" use="optional"
default="false"/>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>
<complexType name="Property" mixed="true">
<complexContent mixed="true">
<extension base="sca:SCAPropertyBase">
<attribute name="mustSupply" type="boolean" use="optional"
default="false"/>
</extension>
</complexContent>
</complexType>
<complexType name="PropertyValue" mixed="true">
<complexContent mixed="true">
<extension base="sca:SCAPropertyBase">
<attribute name="source" type="string" use="optional"/>
<attribute name="file" type="anyURI" use="optional"/>
</extension>
</complexContent>
</complexType>
Motion: Resolve ASSEMBLY-175 by replacing all occurences of complex types PropertyBase, Property & PropertyValue with immediately
preceding schema in chat room m=Anish s=Scott
No discussion - No objections
Resolution: Resolve ASSEMBLY-175 by replacing all occurences of complex types PropertyBase, Property & PropertyValue with immediately
preceding schema in the chat room w/o
Action: owner=MikeE Check XSD's in SVN against CD 03 rev5
ASSEMBLY-177
SCA Assembly XSD extensibility is broken if new implementationor binding types are added from other namespaces than the SCA
one
Discussion - setting minOccurs=1 and maxOccurs=1 would fix for implementation but this breaks "Contract" type
various options considered - includung removing extension point!
<anish>
<sequence minOccurs="0" maxOccurs="1">
<anish>
<any minOccurs="0" maxOccurs="1" />
<anish>
<any minOccurs='1' maxOccurs='unbounded' />
alternative is a specific (global) extension element (wrapper)
<Scott>
<element name="extensions">
<Scott>
<element name="extensions" minOccurs="0" maxOccurs="1">
<sequence>
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</element>
Anish:
Why not add it to all extension points?
...some extra work but could save effort/issues later
Anish:
Could solve UPA problems "forever"
DaveB:
Would affect 1.1 (Tuscany) implementations
<Mike Edwards>
<element name="extensions">
<complexType>
<sequence>
<any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
MartinC:
Should include "mustUnderstand" also
<Mike Edwards>
Mike moves to resolve Issue 177 with the proposal:
1) Change the definition of the Component complex type to have a required <implementation/> subelement:
<complexType name="Component">
<complexContent>
<extension base="sca:CommonExtensionBase">
<sequence>
<element ref="sca:implementation" minOccurs="1" maxOccurs="1"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="service" type="sca:ComponentService"/>
<element name="reference" type="sca:ComponentReference"/>
<element name="property" type="sca:PropertyValue"/>
</choice>
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
<attribute name="autowire" type="boolean" use="optional"/>
<attribute name="requires" type="sca:listOfQNames"
use="optional"/>
<attribute name="policySets" type="sca:listOfQNames"
use="optional"/>
</extension>
</complexContent>
</complexType>
<Mike Edwards>
2) Introduce a new <extensions/> global element in sca-core.xsd:
<element name="extensions">
<complexType>
<sequence>
<any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<Mike Edwards>
3) Modify the Contract complex type to use the extensions global element instead of <any/> as an extension point:
<complexType name="Contract" abstract="true">
<complexContent>
<extension base="sca:CommonExtensionBase">
<sequence>
<element ref="sca:interface" minOccurs="0" maxOccurs="1" />
<element ref="sca:binding" minOccurs="0"
maxOccurs="unbounded" />
<element ref="sca:callback" minOccurs="0" maxOccurs="1" />
<element ref="sca:extensions" minOccurs="0" maxOccurs="1" />
</sequence>
<attribute name="name" type="NCName" use="required" />
<attribute name="requires" type="sca:listOfQNames"
use="optional" />
<attribute name="policySets" type="sca:listOfQNames"
use="optional"/>
</extension>
</complexContent>
</complexType>
Motion: Resolve ASSEMBLY-177 with the three actions noted above in the chat room m=MikeE s=Scott
Anish:
just affects service and reference and no others?
MartinC:
Can we make sure this "works"? - don't want to have to open a new issue for syntax
(TC reviews schema for correctness)
Motion: Amend point 2 with minOccurs=1 m=MartinC s=Ashok
<Ashok>
Martin amends to change as below:
<Ashok>
<any namespace="##other" processContents="lax" minOccurs="1" maxOccurs="unbounded"/>
No discussion - No objections
Amended motion - No further discussion - No objections
Resolution: Resolve w/o ASSEMBLY-177 with three actions above with "minOccurs=1" in "extensions" element in point 2
ASSEMBLY-178
"Multiplicity is too complex"
Criticizms valid but without proposal nothing to be done
MikeE:
Is there any prospect of a proposal before (say) next telecon?
Consensus is that it's unlikely
Anish:
speaks in favor of trying to get a proposal out for some points
DaveB:
Intention was to show how many small items added up to a significant issue.
MikeE:
E.G. it is possible to promote wiredByImpl
...which is (realtively) easy to deal with but other points much harder and far reaching
(discussion of removing wiredByImpl)
Action: o=MikeE E-mail list giving deadline for proposal for ASSEMBLY-178
MikeE:
We need a concrete proposal before next teleconference
ASSEMBLY-188
<policySetAttachment/> element is not recognized by Assembly spec
Motion: Resolve ASSEMBLY-188 with the proposal in Jira extended to handle the parallel issue
<Ashok>
wrt @requires and <requires> subelement.
<Ashok>
Update the schemas and pseudo schemas to refer to the <policySetAttachment/> element at all the places where @policySets is
allowed. Also do the same thing for @requires and the <requires> sublement.
No further discussion - No objections
Resolution: Resolve ASSEMBLY-188 with the proposal in Jira extended to handle the parallel issue wrt @requires and <requires> subelement.
Update the schemas and pseudo schemas to refer to the <policySetAttachment/> element at all the places where @policySets is
allowed. Also do the same thing for @requires and the <requires> sublement w/o.
ASSEMBLY-189
Allow intents to be associated with WSDL using a child element
Scott:
This could be in SCA Policy spec
MikeE:
A lot of overlap in this section - almost a separate spec
<anish>
i'm quite convinced that it is a mistake to not separate out stuff that will be consumed by WS-* stacks
<anish>
... all I can say is that I tried :-(
(Section 6.5 SCA - Specific Aspects for WSDL Interfaces)
Discussion & agreement on direction of proposal
Action: owner=MikeE Produce specific (normative) proposal for Section 6.5
ASSEMBLY-192
Wrong WS Binding Examples - Resending with a minor fix
Action: owner=editors Make non-normative changes in proposal for ASSEMBL:Y-192
<jeff.mischkinsky>
Standing rules may be adopted, amended, or rescinded by Full Majority Vote of the TC.
Motion: m=Scott s=Scott Close ASSEMBLY-192
No discussion - No objections
Resolution: Close ASSEMBLY-192 w/o
Public Comment Issues - Siemens & Microsoft
Action: to Assembly editors to make changes as recommended by Dieter in ASSEMBLY-192
MartinC:
Doesn't seem to be anyone arguing for dropping req for Web Service binding
Some members expressed sympathy but no argument
Some "heated" discussion on req for Open CSA implementation language
Meeting recessed 5:40PM PDT - restart tomorrow 02-Dec-02
Dale:
a channel could be thinner if it just provides routing functions
Mike: In the current OSOA model we have removed the ability for a producer to be connected to a consumer. There is no good
reason for restricting that.
Anish is going through the presentation that is linked in the chatroom...
Anish:
there is a difference between a launchMissile() and WMDFound
Danny:
SCA is all about senders of content and receivers of content. The only contract that we should care about is the contract
between the component writer and the container
Mike: in the services world, a 1..1 on a reference that has a request-response operation means that the component implementation
is prepared to handle only one response message
Jeff: this debate reminds me about a debate we had 15 years ago. That was about location transparency.
<Danny van der Rijn>
Sorry I can't be in the debate at the moment, but I'd ask Anish where the difference between launchMissile() and WMDFound
come from? You're implying differences in application semantics from how messages are transported. I *certainly* don't make
that inference.
Mike: the component developer could annotate a reference with an intent that requires the reference to be wired by the assembler
to 1) a service, 2) a channel and 3) anything
<anish>
i just hope we don't become architectural astronauts and ignore the realities of WSDL/WS-Eventing and wrapped/unwrapped issues.
We *could* change things to make it work. BUT we are not going to change WSDL 1.1 and how it works.
Agreement: From the implementation prospective, it is desirable that the developer is able to indicate what his intentions
are w.r.t. whether the reference is used for event processing style, for p2p processing style or for either styles
<Martin C>
the implication for this wrt a language such as java, is tthat the "dont care" case the developer has one single proxy, but
that proxy may send a single 1 to 1 message or a 1 to many message
<Bob>
does this help? "A.1.2.2 Binding for Wrapped Notifications
The information about an Event Type contained in the eventType element binds to a Wrapped Notification for that type
as follows:
*
The /soap:Envelope/soap:Body/wse:Notify/@actionURI attribute of the Wrapped Notification has the value of the actionURI
attribute of the eventType element corresponding to the type of the event being transmitted.
*
The /soap:Envelope/soap:Body/wse:Notify element has a single child element. This child element is an instance of the
Global Element Declaration referenced by the element attribute of the eventType element corresponding to the type of the event
being transmitted. "
<Bob>
use MEX to pull back the WSDL for wrapped, or raw - you choose which WSDL you want - assuming the src has it
http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#iddiv3_1_2760
"When using WS-MetadataExchange to transfer Notification WSDLs, the corresponding Format IRI for that Notification
WSDL MUST be represented via the @Identifier attribute. " FormatURI == raw vs wrapped
<Bob>
So the question is if the link is strong enough
Anish:
the main reason for bringing the XPath filter as a requirement in SCA was to make the filtering mechanism independent of the
binding type
Agreement: 1) In terms of the component type, body filters can only be specified on consumers. They cannot be specified on
Services.
Agreement: 2) We only support filters based on event body and event types. We must allow for extensibility so that filters
on headers or other metadata can be defined
Agreement: 3) Filters are additive and stateless
Agreement: 4) Xpath 1.0 is the required body filter language
Agreement: 5) We should not dissalow filters that are defined in a component implementation to be specified again on consumers
Discussion point that we need to reopen: whether or not we want to require QNames for identifying event types
OSOA Eventing Proposal (cont'd)
Possible to define event type in Java, XML, etc.
E.G. Java -> binding.sca -> BPEL should work but OSOA doesn't explicitly say so
Scott:
Would we get more leverage from Interfaces?
Discussion on how interacting/event based application differs from SCA Composite
Channels organize physically not logically and cannot be promoted
Event Description Language
JMS Topic <=> OSOA Channel
MikeE:
Would be nice to have an interoperation (JMS isn't) similar to binding.sca
Anish:
There needs to be serious discussion on how bindings work with channels
MikeE:
OSOA specifically uses "Destinations" to allow producers and consumers to be directly connected without a channel
Peter refuses to wake the sleeping dog
General agreement that dynamic pub/sub will not be included in 1.2
Scott:
Can a channel be promoted as a producer xor consumer?
Anish:
That could lead to a channel hirearchy
Scott:
Do implementations have to support the "//" Domain channel?
MartinC:
Yes it's a default so that there's always something to connect to
MikeE:
Scoping of channels is different from services
MartinC:
Oracle only wants Domain channels and not private ones (to allow optimization)
Action: owner=Scott Provide proposal for alternative to Domain Channel
Action: owner=Scott Provide proposal for promotion of channels
Discussion on subscriptions, bindings & channels
<anish>
Agreement: don't need consumerBinding, producerBinding and channelBinding and existing binding extensibility is good enuf.
We may have to define extensions to existing bindings
Review of OSOA event specification completed
<anish>
Agreement: allow binding-specific filters, event type filters, canonical XML infoset rep for the "body" but no canonical rep
for "metadata"
<Dave Booz>
is anyone watching the chat?
There's some "clarification" going on between a few individuals
Remaining points of contention
Interfaces vs. Event Types
Recessed 4:25PM PDT resume tomorrow at 9:00AM PDT
Discussion of significant areas of flexibility required in the Event Processing model
Needs, Wants & Nice to have
Scott:
TIBCO has strong need for promoting private channels as producers and consumers
MartinC:
Oracle has no objections to promoting private channels
Event Types (contd)
Scott; In consumer in Java how are event types named? Annotations?
...Assembler sees qnames from "bottom up"
Anish:
Just a regular part of contribution mapped via JAXB
MikeE:
We need to define rules of how this mapping takes place
clarification of Event Type semantics - not just matching shapes must be same Event Type
MikeE:
Can't just invent Event Types IF you want to work with others - an implied "contract"
Scott; May need an aliasing mechanism to translate "yourWMDfound" to "myWMDfound"
EricW:
Can we please stick to Anish's WMD examples - Earthquakes are funny here!
Anish give further clarification on how independent Event types are "isolated" and mapped
MartinC:
SCA runtime doesn't do type checking
general agreement with this
Anish:
With service and reference there is a coupling - you have to explicitly connect the two
...with events you CAN decouple because you don't KNOW what's going to be done with an event
...HOWEVER - if you specify an Event Type then you are explicitly restoring the coupling (at least partially)
Scott:
Accept that produces & consumers are different from services & references
...but don't want to have completely different metadata
MartinC:
Metadata is not completely different - there's a lot in common
Clemens:
Problem is that WSDL is too much for simple use cases
Anish:
Tools can check for matching Event Types but SCA allows any to be connected to any
...even if there's no consumer that will accept the producers Event Types
Sabin:
We could have Event categroies?
...far too many problems - as found when considered for OSOA
DaleM:
There's a lot of "pub" in the proposal but not a lot of "sub"
...e.g. can't "OR" filters - only "AND"
...There should be more flexibility on how consumers can subscribe to events
Can producers produce events they have not declared?
Arguments for and against
Currently OSOA says producers SHOULD only produce events they have declared
However several member think that IF producers specify their events then they MUST only generate those an no others
Brief discussion but left at present as in OSOA
Event Types (contd)
Event Type is extensible - exentType.sca, eventType.java, etc
Is it necessary to define mappings between different Event Type implementations?
Do we have to have eventType.wsdl?
MikeE:
Absolutely do have to have eventType.wsdl
...and have to define mapping to this
Discussion on how "dual nature" of reference/producer service/consumer affects requirement for need for wsdl
Use of Qnames in Events
Scott:
TIBCO wants to use WSDL to define events but WSDL operations can't be mapped to Qnames
EDL
MikeE:
Instead of defining an SCA EDL we could just point to WS-Eventing Event Description (WS-RA)
MartinC:
That's what I was envisioning
MikeE:
Problem is that it isn't finished and may be contorversial
...Would need to ensure our definitions are compatible
<Peter Niblett>
its 10pp at the moment
Agreements
1) Event Type extensibility
<Scott>
attempted agreement wording: there can be a "blessed" event description that uses QNames for event type identity, and XSD
GED event shape definition
(Discussion on wording of agreement)
MartinC:
Interoperable events MUST map to THE canonical form
<Scott>
attempt2: there can be defined an "<eventtypes.sca ..../>" canonical extension of the extension point that uses QNames for
event type identity and XSD GED as an attempt to define the logical infoset for event shapes
<Martin C>
the eevnt type filters are moved as an extemxible element under consumer and producer
<Martin C>
these become the eventtype extensibility point
<Scott>
I would simply say that the <eventtypes.sca/> element (whatever its name) serves as a filter on the consumer side, and therefore
replaces the existing built-in type filter
<Scott>
there is not yet clear agreement on exactly where the substitutable element sits on the consumer, directly or as a subelement
of <filters/>
<Scott>
agreement that it is a minor point
Do we need to include eventType.wsdl in the first version of the eventing spec?
MikeE:
May not require a full definition but will need enough to get an idea of how it fits into C&I specs
MartinC:
C&I should not be part of SCA Assembly - let BPEL TC deal with BPEL
...we haven't discussed anything about what eventType.wsdl would look like
MikeE:
In practice if we wait for other TC's to get around to working on events then it may never happen
MartinC:
Cannot start doing the work of other TC's
Scott:
We HAVE spent a lot of time talking about Java and BPEL
SCA Assembly 1.1 Completion
ASSEMBLY-149 and ASSEMBLY-152
149 is duplicate of MS public comments
Motion: Close ASSEMBLY-152 with no action m=MartinC s=JeffM
MartinC:
Discussed previously - no proposal to make specific changes
...would need to craft response to Siemens
No further discussion - No objections
Resolution: Close ASSEMBLY-152 with no action w/o
Action: owner=Chairs Create (diplomatic) response to Siemens PC on support for web services
ALL MUSTS in SCA ASSEMBLY
Implement ONE or more of the OPENCSA implementation languages
Motion: Close ASSEMBLY-132 and ASSEMBLY-149 with no action m=JeffM s=AnishK
MartinC:
This is essentially saying that the conformance requirements are as is for version 1.1
...subject to supermajority reopening of the issues
JeffM:
Can always revisit for 1.2
...Essentially it seems that current proposals allow companies to claim conformance to standards without going through the standards
proccess
...MS could always do a BPEL implementaion but it is their problem not ours
MartinC:
We've actuaally spent a lot of time on this and been unable to find a satisfactory solution
...the issue is delaying the spec and we shouldn't spend more time on this for 1.1
EricW:
Hitachi would like somoe relaxation, but as we can't find any suitable wording we are not going to object
Resolution: Close ASSEMBLY-132 and ASSEMBLY-149 with no action w/o
Action: owner=Chairs Create response to MS & Siemens regarding language support noting the effort made by the TC to acommodate
MikeE:
Estimate by next call should have version that incorporates all the required changes to create CD
MikeE:
BUT ... Do we need to rev the namespace
MartinC:
Have there been any backwards incompatible changes?
JeffM:
Are there any rules that require namespace changes?
MikeE:
Not but we have said this will occur as a matter of TC policy
Anish:
Will need to notify all the other TC's if we do
MartinC:
By the letter of the law we should rev the namespace but are there any implementations/code that would be impacted?
JeffM:
Practically what would happen if we don't rev the namespace - what would break?
MikeE:
constriainingType is the biggest - its been removed - implementations that use it would break (fail validation)
JeffM:
That's much better than getting the "wrong answer"
Scott:
We should "do the right thing" unless there's a real good reason not to
MikeE:
Consult with other TC's first or make the changes and then notify
<Dave Booz>
rev-ing is the right thing to do
MartinC:
This is probably the final rev for 1.1
No further discussion - No objections
Action: owner=Chairs Inform all TC's via E-mail of namespace change
Action: owner=Editors Make the required namespace changes to the SCA-Assembly 1.1 spec and Test Suite
When should CD discussion take place - now?
Ashok:
SCA-Policy still have some open issues and MAY have implications for SCA-Assembly
...we should wait unitl SCA-Policy seems to be wrapped also
<Dave Booz>
Martin, FWIW - I'm ready to finish policy so you need to talk to Ashok
<Martin C>
dave, i'll look after him
What document do we use as a base for 1.2?
Use next CD04 as base for 1.2 spec
OSOA Eventing is written as delta against SCA-Assembly (prior to CD03)
MartinC:
Think it was the OSOA contribution that became SCA-Assembly 1.0
Discussion on best way to merge documents
MikeE:
Intention is to cut off chnages to 1.1 and open new issues against 1.2
JeffM:
In reality you may find a lot of pressure to "fix" 1.1 once it's out in the field
Anish:
Is there an errata process?
JeffM:
No in OASIS just produce a new version
...can't make any changes that could change any implementaions - non-normative spelling corrections only
Scott:
Want to avoid discussion about detailed wording if the wording isn't finalized anyway
MartinC:
Hope to have initial Eventing only document ready to start incorporating into spec around 2010-01-19
MikeE:
SVN needs to be branched to keep the XSD's separate
MartinC:
Deliverable of Jan 19th will not include BPEL or Java considerations
MikeE:
Thinks it should or it will be difficult to incorporate into spec
Meeting Schedule
Wednesday meetings on 2009-12-16 and 2009-12-30 are cancelled
<Dave Booz>
i will not make 22nd or 29th
Tuesday meetings on 2009-12-22 and 2009-12-29 are cancelled
<Dave Booz>
Thanks TIBCO....the audio was very good
Next meetings are on Tuesday 2009-12-08 then 2009-12-15
Resolution: TC thanks to TIBCO for hosting w/o
Meeting adjourned 3:10PM PDT
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 428 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 125: s/ou /out /
edits: Line 157: s/caht/chat/
edits: Line 158: s/room/room m=Anish s=Scott/
edits: Line 159: s/schema/immediately preceding schema/
edits: Line 223: s/review/reviews/
edits: Line 250: s/Ashok/Scott/
edits: Line 298: s/hat/that/
edits: Line 304: s/list/link
edits: Line 312: s/one/the
edits: Line 367: s/contentionInterfaces vs. Event Types/contention/
edits: Line 433: s/Scott;/Scott:/
edits: Line 437: s/Agreements/topic: EDL/
edits: Line 456: s/firstt/first/
edits: Line 515: s/1.1No further discussion - No objections/1.1/
citation-detection-scribed: Line 69: Check for possible unrecognized nick 'Point of discussion'
citation-detection-scribed: Line 72: Check for possible unrecognized nick 'Next section from TIBCO proposal'
edit-substitute: command on line 125 succeeded, changed line 124 from 'ou ' to 'out '
edit-delete: Line 125 was deleted
edit-substitute: command on line 157 succeeded, changed line 156 from 'caht' to 'chat'
edit-substitute: command on line 158 succeeded, changed line 156 from 'room' to 'room m=Anish s=Scott'
edit-substitute: command on line 159 succeeded, changed line 156 from 'schema' to 'immediately preceding schema'
edit-delete: Line 157 was deleted
edit-delete: Line 158 was deleted
edit-delete: Line 159 was deleted
edit-substitute: command on line 223 succeeded, changed line 222 from 'review' to 'reviews'
edit-delete: Line 223 was deleted
edit-substitute: command on line 250 succeeded, changed line 247 from 'Ashok' to 'Scott'
edit-delete: Line 250 was deleted
citation-detection-scribed: Line 257: Check for possible unrecognized nick 'Meeting recessed 5'
citation-detection-scribed: Line 263: Check for possible unrecognized nick 'Mike'
citation-detection-scribed: Line 273: Check for possible unrecognized nick 'Mike'
citation-detection-scribed: Line 275: Check for possible unrecognized nick 'Jeff'
citation-detection-scribed: Line 294: Check for possible unrecognized nick 'Mike'
citation-detection-scribed: Line 296: Check for possible unrecognized nick 'Agreement'
edit-substitute: command on line 298 succeeded, changed line 297 from 'hat' to 'that'
edit-delete: Line 298 was deleted
edit-substitute: command on line 304 succeeded, changed line 303 from 'list' to 'link'
edit-delete: Line 304 was deleted
citation-detection-scribed: Line 308: Check for possible unrecognized nick 'Agreement'
citation-detection-scribed: Line 309: Check for possible unrecognized nick 'Agreement'
citation-detection-scribed: Line 310: Check for possible unrecognized nick 'Agreement'
edit-substitute: command on line 312 succeeded, changed line 311 from 'one' to 'the'
citation-detection-scribed: Line 311: Check for possible unrecognized nick 'Agreement'
edit-delete: Line 312 was deleted
citation-detection-scribed: Line 313: Check for possible unrecognized nick 'Agreement'
citation-detection-scribed: Line 316: Check for possible unrecognized nick 'Discussion point that we need to reopen'
edit-substitute: command on line 367 succeeded, changed line 366 from 'contentionInterfaces vs. Event Types' to 'contention'
edit-delete: Line 367 was deleted
citation-detection-scribed: Line 369: Check for possible unrecognized nick 'Recessed 4'
citation-detection-scribed: Line 386: Check for possible unrecognized nick '... '
citation-detection-scribed: Line 404: Check for possible unrecognized nick 'All'
edit-substitute: command on line 433 succeeded, changed line 432 from 'Scott;' to 'Scott:'
edit-delete: Line 433 was deleted
edit-substitute: command on line 437 succeeded, changed line 436 from 'Agreements' to 'topic: EDL'
edit-delete: Line 437 was deleted
edit-substitute: command on line 456 succeeded, changed line 455 from 'firstt' to 'first'
edit-delete: Line 456 was deleted
citation-detection-scribed: Line 481: Check for possible unrecognized nick 'Currently to conform'
edit-substitute: command on line 515 succeeded, changed line 514 from '1.1No further discussion - No objections' to '1.1'
edit-delete: Line 515 was deleted
citation-detection-scribed: Line 551: Check for possible unrecognized nick 'Meeting adjourned 3'
command-autoroll/oasis: Line 552: Attempting to fetch roll from http://www.oasis-open.org/apps/org/workgroup/sca-assembly/event.php?event_id=25874
command-autoroll/oasis: Line 552: Successfully fetched roll from http://www.oasis-open.org/apps/org/workgroup/sca-assembly/event.php?event_id=25874
system: Transformer: SAXON 9.1.0.7
[End of Schreiber diagnostic output]