Hi Mike,
If I'm not mistaken, we run into a problem whenever we're talking
about recontributing to the domain anything that can referenced from
a different contribution. This encompasses, for example, XML Schema
namespaces, WSDL namespaces, event definitions, anything that goes
into a definitions.xml file (intents, policy sets, available binding
types, available implementation types, etc.).
At least for what goes in definitions.xml, normative constraint
ASM10001 restricts the possibility of duplicate deployment, but I
didn't immediately discover anything about redeployment, and this is
the area of the spec where my understanding is weakest, so perhaps
someone else has pointers. In any event, it would be easy enough to
redeploy a contribution and *remove* a definition that used to be
present. Or, in the case of definitions.xml, redefine a policy set
in a way that is inconsistent with current use. What happens in
these cases?
Further, why are those problems fundamentally any different from
what we're talking about with global domain channels (GDCs)?
The way the WD 03 currently reads, deployers can define GDCs in any
top-level composite. In practice, how does this play out? The
deployers might create a single contribution containing a single
composite defining a single GDC, and they don't ever have
redeployment problems. However, they might instead establish a
pattern of collecting GDCs into composites, and deploying a set of
them at a time, or worse yet, they'll mix the definition of a GDC
with components that get deployed at the same time. If they choose
either of the latter two, they'll run straight into the redeployment
problem.
(Of course, if you don't associate any semantics with a GDC (no
filters, no bindings, no intents), then redeployment of a name is
pretty much a no-op.)
I'm with Danny: auto deployment is a shorthand for actual
deployment. If you're concerned about redeployment, that seems like
a good issue to raise.
-Eric.
On 2/9/11 9:25 AM, Danny van der Rijn wrote:
Mike -
Your arguments seem to me to be more arguing against case a) than
against autocreation, as they hold for *any* more restrictive
redeployment, not just one whose previously deployed state was
perhaps auto-deployed.
Auto-deployment (as I envision it) is merely shorthand for an
actual deployment. ("Your composite references a global domain
channel that hasn't been deployed. Shall I create one for you and
deploy it, or would you prefer me to reject deployment of your
composite outright?") Your arguments just point out another
weakness I see in the concept of global domain channels.
Danny
On 2/9/2011 2:45 AM, Mike Edwards wrote:
Danny,
SCA Runtime "styles";
a) Reconfiguration/Redeployment
is allowed
b) Reconfiguration/Redeployment
is not allowed
Case b) is the simpler of the
two. In this case, all the configuration must be present when
the runtime is started.
Either Domain channels are part
of the configuration at this point or not - if not, then any
references to Domain
channels would either be errors
(no auto-creation of channels) or would require auto-creation
of channels.
Case a) is the case where there
can be separate deployment of (some) consumers & producers
and of the
channel(s) that they connect
to. I note that this can only happen for Domain level
channels. Once separate
deployment is possible, then
the timing of deployment matters - if Channel deployment is
later than deployment
of any of the producers that
connect to the channel, then it the question of auto-creation
comes into play.
If no auto-creation is NOT
allowed by the runtime, then any event produced will have
nowhere to go, which might
be flagged as an error (since
the producer is configured to transmit the events). If
auto-creation is allowed, then
the events will be flowed to an
auto-created Channel and on to whatever consumers are
connected to that channel.
When the Channels are later
deployed into such a runtime, I assume that the auto-created
Channels get "replaced"
by the deployed versions, with
whatever configuration they carry. Since the configuration
may carry Filters, this may
mean that some events get
forwarded by the auto-created channel that don't get forwarded
by the specifically
deployed channel. I'm not sure
what this would mean for the consumers attached to the
channel. More problematic
would be any binding and policy
information attached - the binding could indicate the need to
have the channel use
some specific existing
infrastructure (eg some MQ queue) - and if the intention is
that events flow to/from the existing
infrastructure, then the
auto-deploy channel is unlikely to do this.
I think the result of this is
that during the period when any auto-deploy channels are being
used, before the point
where the specifically
configured channels are active, that some events may not reach
all their intended destination(s)
and some events may not be
received by some SCA consumers listening on those channels.
All of which might argue for a
process of deploying the Domain channels first, which kind of
undermines the idea of
auto-deploying those channels.
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:
From:
Danny van der Rijn <>
To:
Mike
Edwards/UK/IBM@IBMGB
Cc:
Date:
08/02/2011 22:02
Subject:
Re: [sca-assembly]
[Issue 253]: (1.2) Must a global domain channel be
deployed before it can be used?
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:
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:
From:
Anish
Karmarkar <>
To:
Date:
08/02/2011 09:15
Subject:
Re: [sca-assembly]
[Issue 253]: (1.2) Must a global domain channel be
deployed before it can be used?
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:
>>>
>>>
>>>
>>>
>>>
>>> From: Eric Johnson <>
>>> To: Anish Karmarkar <>
>>> Cc:
>>> 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<>
>>> >>>>> To: OASIS SCA Assembly<>
>>> >>>>> 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
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
