sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] [Issue 253]: (1.2) Must a global domain channel bedeployed before it can be used?
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Thu, 10 Feb 2011 10:54:01 +0000
Eric,
Redeployment is indeed a tricky issue.
Deployment is in principle at the level
of a composite (or possibly of sets of composites) and there is the possibility
of
deployment taking place as a sequence
of separate actions. When deployment takes place as a sequence, then
the
timing of deployments matters.
I tried to point out that a drawback
with auto-deployment is that the "first mention" of some Domain
channel may be in a
using Component that is part of a first
deployment operation, where there is a definition of that Domain channel
in some
other deployment operation. If
there is auto-deployment for the first deployment operation, then what
happens when the
second deployment operation takes place?
This is why I mentioned redeployment.
Is redeployment tricky? You bet
- absolutely yes!! It is bad enough for individual components, probably
worse for
"globally applicable" items
like PolicySets and equally nasty for things like Domain channels that
may have users
all over the place. It is worthy
of discussion because it's tricky.
Perhaps you can convince me that auto-deploy
does not imply redeployment - but in that case you'll need to address the
deployment sequences such as the one
I tried to describe above.
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:
| Danny van der Rijn <dannyv@tibco.com>
|
| Cc:
| Mike Edwards/UK/IBM@IBMGB, OASIS Assembly
<sca-assembly@lists.oasis-open.org>
|
| Date:
| 09/02/2011 18:47
|
| Subject:
| Re: [sca-assembly] [Issue 253]: (1.2)
Must a global domain channel be deployed before it can be used? |
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:
| mike_edwards@uk.ibm.com
|
|
|
|
|
| |
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:
| 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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
