[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] [SCA EVENTS] Summary of tentative agreements
Scott, Can we at least agree it's a point for discussion since there are differing views here? Other comments below. Martin. > Subject: Re: [sca-assembly] [SCA EVENTS] Summary of tentative agreements > > Martin, > > I was afraid that I mis-heard Peter's question to me, and it looks > like I did. I'm not in agreement with number 4, and I think I can > safely say I speak for TIBCO on this. > > In my view, the constraints on "wiring" and interface compatability > should be contingent upon the character of the interface. For > example, an interface entirely full of one-way operations (I'll call > them events) does not require a producer of those events to produce > any or all of them; it merely guarantees that no *other* events will > be produced by that producer. [<MartinC>] I think you are going to have to clarify "who" the interface is defined by. However this seems to me like saying a client specifying a reference is not obliged to invoked any operation on the service, which in my mind is not worth saying;) As to the other point, can a producer produce things that it didn't declare, we had a long discussion on that in OSAO and compromised on a SHOULD - one of the rationale being that in wsdl you can define faults, but other faults may be sent that were not explicitly declared (e.g. SOAP faults) > > Our current wiring and interface compatibility rules simply make the > assumption that every interface has at least one request-reply > operation. [<MartinC>] Mike E replied to that point, but another discussion point is would/can a one-way operation mixed in with request-responses in an interface be considered as an event or not i.e. what is special about that one-way in a mixed interface vs an interface exclusively comprised of one-ways? I think questions like this are interesting, and point to the fact that while we might not agree about position 4, we should explore the area? > > Scott > > On Sep 10, 2009, at 6:22 AM, Martin Chapman wrote: > > > Here is a summary of what I think we agreed yesterday, and are > > therefore areas for the TC to explore further. > > > > > > > > Position 1: the current SCA 1.1 model needs tweaking/adding to, to > > support a pub/sub paradigm. > > > > > > > > Position 2: SCA 1.1 use of WSDL has certain assumptions in > > assemblers'/developer's heads (and current tooling), which need re- > > examining for pub/sub. > > > > > > > > Position 3: SCA 1.1 wires and wiring may be too restrictive for pub/ > > sub and need to be relaxed/extended. > > > > > > > > Position 4: We agreed that an assembler looking at SCDL should be > > able to distinguish between events and one-way requests. > > > > > > > > Cheers, > > > > Martin. > > > > > > > > > > Martin Chapman | Standards Professional > > Mobile: +353 87 687 6654 > > > > ORACLE Ireland > > "Please consider your environmental responsibility before printing > > this e-mail" > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]