OK, I'll take a stab at answering your question, although I'm just
presenting one alternative among many.
First, though, your wording interests me:
in the case
where the channel concerned DOES
have configuration and it so
happens
that the channel is deployed to the Domain some time after some
of the
producers and consumers using the
channel
are deployed to the Domain.
What intrigues me is the notion that your use case allows you to
assert that something about the channel's configuration. Can that
configuration never change? If so, how would you deal with changing
that? By undeploying and redeploying it? Some other means?
I would apply whatever answer you have to that question to this one.
To wit:
Say that you do allow some form of runtime redeployment or
modification. So in this case the implementation MAY autodeploy the
channel (RFC 2119 wording intentional). If someone chooses to
redeploy the channel with further configuration later, so be it.
Use whatever form of modification you were going to support in the
case where the prior configuration was not auto-deployed.
Say you don't allow modification. Then I'd say that your
implementation should either not allow for autodeployment, or that
your implementation should put up some reasonable bar to
autodeployment.
Danny
On 2/8/2011 1:51 AM, Mike Edwards wrote:
OFBEA914B6.9F117D4C-ON80257831.003530EA-80257831.00358641@uk.ibm.com"
type="cite">
Folks,
I'd appreciate it if someone
could explain
how things would work in the case where the channel concerned
DOES
have configuration and it so
happens
that the channel is deployed to the Domain some time after some
of the
producers and consumers using the
channel
are deployed to the Domain.
Yours, Mike
|
|
Dr
Mike Edwards
|
Mail Point
146, Hursley
Park
|
|
STSM
|
Winchester,
Hants SO21
2JN
|
SCA
& Services
Standards
|
United
Kingdom
|
Co-Chair
OASIS SCA
Assembly TC
|
|
|
IBM
Software Group
|
|
|
Phone:
|
+44-1962
818014
|
|
|
Mobile:
|
+44-7802-467431
(274097)
|
|
|
e-mail:
|
mike_edwards@uk.ibm.com
|
|
|
|
|
Danny and Eric's arguments have convinced me
that
auto-creation of
global channels make sense. It would certainly simplify
config/deploy --
I won't have to create a separate composite that contains only
the
channel name and then deploy it to the domain. Currently we do
allow
this for the default channel ("//"). As Eric points out, my
issue
wrt
error detection can be dealt with by tools (I can have a
global option
or flag for the deployer). Given that we already allow this
for the
default channel, and channels currently require no additional
configuration (one can have configuration, but is not required
to),
autocreation would provide a consistent model and would make
simple
deployment scenarios easier.
-Anish
--
On 2/7/2011 9:50 AM, Eric Johnson wrote:
> To be more explicit, and echo Danny's point, I think we
have
four options:
>
> 1) Mandate that auto-creation of channels works
> 2) Mandate that auto-creation of channels never works
> 3) Identify specific situations where #1 or #2 are
possible
> 4) Take no position (this may still imply changes to the
spec, insofar
> as we highlight the point, while taking no sides)
>
> I raised the issue because #4, it seems to me, leaves the
door open
for
> interoperability failures. ("I deployed X over here with
no problems,
> but it doesn't work over there.")
>
> Insofar as I've recall the discussion of the concrete use
cases for
> global domain channels (Oracle's F2F presentation), we
explicitly
noted:
> no filters, no policies, and no bindings on said
channels. Meaning,
> configuration optional, and it's just a name. If it is
just a name,
why
> can't I auto-create?
>
> Anish notes that some people like the safety net of
predefined names,
> and I agree that's useful. However, that can be addressed
in a variety
> of ways that aren't nearly so heavy-handed as to simply
deny the
> deployment. ("The domain contribution includes references
to
global
> domain channel "foo" that doesn't yet exist.
Continue/Cancel?).
>
> -Eric.
>
> On 2/7/11 9:30 AM, Danny van der Rijn wrote:
>> Yet all their configuration is optional?
>>
>> On 2/7/2011 3:39 AM, Mike Edwards wrote:
>>>
>>> Eric,
>>>
>>> My view is that global channels - indeed any
channels - are
more than
>>> a name - they have configuration associated
>>> with them. A system which does not require them
to be declared
makes
>>> it difficult to provide required configuration.
>>>
>>> Yours, Mike
>>>
------------------------------------------------------------------------
>>>
>>> Dr Mike Edwards
Mail Point 146, Hursley Park
>>> STSM
Winchester, Hants SO21 2JN
>>> SCA & Services Standards
United Kingdom
>>> Co-Chair OASIS SCA Assembly TC
>>> IBM Software Group
>>> Phone:
+44-1962 818014
>>> Mobile:
+44-7802-467431 (274097)
>>> e-mail:
mike_edwards@uk.ibm.com
>>>
>>>
>>>
>>>
>>>
>>> From:
Eric Johnson <eric@tibco.com>
>>> To:
Anish Karmarkar <Anish.Karmarkar@oracle.com>
>>> Cc:
sca-assembly@lists.oasis-open.org
>>> Date:
04/02/2011 17:14
>>> Subject:
Re: [sca-assembly] [Issue 253]: (1.2) Must
a global domain
>>> channel be deployed before it can be used?
>>>
>>>
>>>
------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> On 2/4/11 1:37 AM, Anish Karmarkar wrote:
>>> > I don't see this being different than say
requiring that
a variable be
>>> > declared before it is used.
>>> <eej>
>>> Which might be a perfect analogy.
>>>
>>> If the only point of a global channel is to
establish a name,
then
>>> there's actually minimal value to declaring it
before it is
used. Many
>>> dynamic languages work this way - Python &
Ruby. In the
case of global
>>> domain channels, for many use cases, filters and
bindings
don't make
>>> sense, so the channel just becomes a name. At
which point,
declaration
>>> before use looks like ceremony over substance.
>>>
>>> </eej>
>>> >
>>> > -Anish
>>> > --
>>> >
>>> > On 2/1/2011 10:11 AM, Danny van der Rijn
wrote:
>>> >> An interesting argument for tight
coupling...
>>> >>
>>> >> On 2/1/2011 6:19 AM, Anish Karmarkar
wrote:
>>> >>> I think this is a fine issue to
raise, but I
don't quite support the
>>> >>> auto-creation proposal. The only
global channel
that is
>>> >>> 'auto-deployed' or always exists is
the default
channel.
>>> >>>
>>> >>> I would want the runtime to tell me
if I referenced
a channel
>>> that has
>>> >>> not been deployed (unless it is the
default channel,
which is the
>>> >>> exception). If I want a producer and
consumer
(especially if they are
>>> >>> in different composites) to
communicate over
a common channel, I
>>> would
>>> >>> want the system to catch typos. For
example,
if the producer is
>>> >>> connected to the channel "//omg" and
the consumer is connected to
>>> >>> "//zomg", they would be deployed
fine
but my application would not
>>> >>> work correctly.
>>> >>>
>>> >>> -Anish
>>> >>> --
>>> >>>
>>> >>> On 1/31/2011 10:19 AM, Eric Johnson
wrote:
>>> >>>> Hi Peter,
>>> >>>>
>>> >>>> On 1/31/11 10:02 AM, Peter
Niblett wrote:
>>> >>>>> Eric
>>> >>>>>
>>> >>>>> You said..
>>> >>>>>
>>> >>>>> Neither of the above
indicate whether
or not the global domain
>>> >>>>> channel
>>> >>>>> can be used before it is
referenced.
>>> >>>>
>>> >>>> Ah yes, the joys of a muddled
brain on Monday
morning. You're
>>> >>>> correct -
>>> >>>> the question is whether or not
the global
domain channel can be used
>>> >>>> before it is *created* via a
contribution.
>>> >>>>
>>> >>>> Thanks for catching my
circularity.
>>> >>>>
>>> >>>> -Eric.
>>> >>>>>
>>> >>>>> I'm not sure how you can
"use"
a channel without referencing it (I
>>> >>>>> assume "reference" means
"wire
to/from"), but I think the question
>>> >>>>> you
>>> >>>>> are asking is the one in the
title -
"can you reference a channel
>>> >>>>> that
>>> >>>>> hasn't been defined to the
SCA assembly?".
I think this is one
>>> place
>>> >>>>> where the current spec is
clear.. you
can't reference a domain
>>> >>>>> channel
>>> >>>>> that hasn't been defined.
>>> >>>>>
>>> >>>>> So it looks as though your
issue is to
say that we should
>>> change the
>>> >>>>> spec to say that it permits
(in fact
requires) autocreation of
>>> domain
>>> >>>>> channels. Presumably these
channels would
have to be created with
>>> >>>>> default attributes (though I
know you
think they shouldn't have
>>> >>>>> attributes at all).
>>> >>>>>
>>> >>>>> Regards
>>> >>>>>
>>> >>>>> Peter Niblett
>>> >>>>> IBM Senior Technical Staff
Member
>>> >>>>> Member of the IBM Academy of
Technology
>>> >>>>> +44 1962 815055
>>> >>>>> +44 7825 657662 (mobile)
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> From: Eric
Johnson<eric@tibco.com>
>>> >>>>> To: OASIS SCA
Assembly<sca-assembly@lists.oasis-open.org>
>>> >>>>> Date: 31/01/2011 17:19
>>> >>>>> Subject: [sca-assembly] NEW
ISSUE: (1.2)
Must a global domain
>>> channel
>>> >>>>> be deployed before it can be
used?
>>> >>>>>
>>>
------------------------------------------------------------------------
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> Title: Must a global domain
channel be
deployed before it can be
>>> >>>>> used?
>>> >>>>>
>>> >>>>> Target: Assembly 1.2 WD 03
>>> >>>>>
>>> >>>>> Description:
>>> >>>>>
>>> >>>>> Via the "@target" and
"@source"
attributes defined on a consumer&
>>> >>>>> producer, the assembler can
reference
global domain channels.
>>> >>>>>
>>> >>>>> In section 5.8, the presumed
to be normative
text reads "SCA
>>> runtimes
>>> >>>>> MUST support the use of
domain channels
[ASM????]." That is
>>> followed
>>> >>>>> by:
>>> >>>>>
>>> >>>>> "To create a Domain Channel,
deploy
a composite containing a
>>> channel
>>> >>>>> directly to the SCA Domain
(i.e., do
not use that composite as the
>>> >>>>> implementation of some
component in the
Domain)."
>>> >>>>>
>>> >>>>> Neither of the above
indicate whether
or not the global domain
>>> >>>>> channel
>>> >>>>> can be used before it is
referenced.
>>> >>>>>
>>> >>>>> Proposal:
>>> >>>>>
>>> >>>>> General theme: do not
require the global
domain channel to exist
>>> >>>>> before
>>> >>>>> it can be used.
>>> >>>>>
>>> >>>>> Specific text (needs
refinement?):
>>> >>>>>
>>> >>>>> In section 5.8, Paragraph
#2, append:
>>> >>>>>
>>> >>>>> When contributing artifacts
to a domain
that contain references to
>>> >>>>> global domain channels that
have not
been created, the SCA runtime
>>> >>>>> MUST
>>> >>>>> automatically create said
global domain
channels, and cannot reject
>>> >>>>> such
>>> >>>>> contributions [ASM????].
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>>
---------------------------------------------------------------------
>>> >>>>> 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/
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>
>>> >>>
---------------------------------------------------------------------
>>> >>> 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
>>> >>
>>> >
>>> >
---------------------------------------------------------------------
>>> > 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
>>>
>>>
---------------------------------------------------------------------
>>> 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/
>>>
>>>
>>>
>>>
>>>
>>>
---------------------------------------------------------------------
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
|