OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-assembly] eventing - 1.2 wd01 question on use case for afeature.


On 7/26/2010 2:48 AM, Mike Edwards wrote:
>
> Eric,
>
> I'll have a go at responding to your questions.
>
> Inline as *<mje> </mje>*
>
> Yours, Mike.
>
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
> Email: mike_edwards@uk.ibm.com
>
>
> From: 	Eric Johnson <eric@tibco.com>
> To: 	OASIS SCA Assembly <sca-assembly@lists.oasis-open.org>
> Date: 	22/07/2010 21:31
> Subject: 	[sca-assembly] eventing - 1.2 wd01 question on use case for a
> feature.
>
>
> ------------------------------------------------------------------------
>
>
>
> While reviewing the assembly 1.2 WD 01, I noted an odd detail.
> Hopefully, the following question will be immediately obvious to someone
> on the TC, but it wasn't to me.
>
> In the bindings section, why in the world does the current draft include
> filters as a child element of the binding element, when filters also
> appear in the immediate parent - the containing consumer, producer, or
> channel? The text says that they can appear for binding specific
> filtering purposes, but I'm absolutely befuddled by what that means, and
> what the use-cases might be for this model extension, and I'm concerned
> by the increased complexity.
>
> Can anyone tell me what use cases drive this glorious specificity, or
> did we just go too far here?
>
> *<mje>*
> *I think that the usecase here is dealing with existing event processing
> networks that already exist*
> *outside of the SCA application. Some of these networks may not handle
> some of the event types *
> *that an SCA producer sends and in this case, we need a binding-specific
> mechanism of handling*
> *this, by filtering away these types of events.*
>
> *You may be right in saying that this goes too far when dealing with SCA
> consumers.*
> *</mje>*
>

IIRC, this was added during the Palo Alto f2f. Scott made an argument 
for including this and everyone agreed. What I remember of the argument 
was that:
once you know which binding you are in, you can get very specific about 
the filters. For example, if you are using binding.ws (and SOAP), you 
can construct specific filters that look for specific SOAP header 
blocks, for example.

I don't feel too strongly about this feature so would be ok getting rid 
of it.

> While I'm at it, I have more questions.
>
> The text on binding.sca notes that the filter element must only appear
> on bindings specific to channels, producers, and consumers. The generic
> definition of a binding omits this constraint from its description of
> the filter element, but that seems like an oversight.
>
> *<mje>*
> *Agreed, probably an oversight*
> *</mje>*

+1
oversight.

>
> Anyone have insight here?
>
> This last question highlights an interesting detail. XML Schema has a
> perfectly good way of making sure that these elements only appear in the
> appropriate place - by using a new base type definition. So instead of
> defining all binding elements as having filters, perhaps we should be
> defining an "eventbinding" that adds an optional filter, rather than
> repurposing the existing "binding" infrastructure?
>
> *<mje>*
> *The idea really is to reuse the existing binding infrastructure rather
> than create a whole*
> *load of new binding types. Do we really need a pile of new binding types?*
>
> *Another way of dealing with this might be to allow filters on any
> binding but state that if the*
> *binding declaration is for a service or for a reference then the filter
> attribute is simply*
> *ignored.*
> *</mje>*
>

I agree.
The reason we didn't create special binding elements for eventing was 
because we didn't want to create two bindings for each 
transport/protocol but reused the same binding for both service-ref and 
eventing.

-Anish
--

> -Eric.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
>
>
>
>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]