Hi Mike,
Very well. I've raised an issue.
-Eric.
On 07/26/2010 02:48 AM, Mike Edwards wrote:
OF94CC12DD.D8F034FF-ON8025776C.00351ED0-8025776C.0035BD96@uk.ibm.com"
type="cite">
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
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>
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>
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>
-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
|