sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 30 Oct 2007 15:01:17 +0000
Folks,
I think that there is still a problem
here that has not been tackled.
I think that it is all down to the usage
intended for the composite. I believe that there are 2 cases
and that they are distinct:
a) Use of a composite as a component
implementation.
b) Use of a composite for inclusion
into the Domain (ie where the composite's contents become part of the Domain).
I leave out the case of a composite
being included into another composite - the rules for that case are actually
then
simply applied to the containing composite....
Case A. Use of Composite as a
component implementation
In this case, there is nothing that
will ever occur that can change or add to the wiring within the composite.
If it is not complete at the time the
composite is used as an implementation, then it never will be complete
and
there is an error. The error can
be generated as soon as the using component is deployed.
Case B. Use of a composite for
inclusion into the Domain.
This is VERY different for the simple
reason that either some wire targets may get added to the Domain later
than the composite, or that the wires
themselves may be added to the Domain later than the composite.
There can be no error up until the moment
that someone tries to invoke the service(s) provided by a component
whose references are not wired - and
only then for cases where the multiplicity is 1..1 or 1..n.
We may have to look much harder at some
of the dynamic aspects of Case B before we can give proper words
to the spec.
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
"Peshev, Peter"
<peter.peshev@sap.com>
29/10/2007 07:57
|
To
| "David Booz" <booz@us.ibm.com>,
<sca-assembly@lists.oasis-open.org>
|
cc
| "Blohm, Henning" <henning.blohm@sap.com>,
"Martin Chapman" <martin.chapman@oracle.com>, "Michael
Rowley" <mrowley@bea.com>
|
Subject
| RE: [sca-assembly] ISSUE 6: usage of
not promoted references |
|
Just to make a summary - it seems the text & the proposal are accepted,
and the only exception is what should happen in case there is reference
with multiplicity 1..1 or 1..n , however it is not wired. Initially that
was proposed as deployment error, however since both Dave & MR seems
to
prefer a runtime error during the first usage to the component, the
proposal is updated to reflect their opinion.
Btw, I would assume the same behavior should happen in case the target
of the reference is component, which is invalid. Since the same
arguments can apply (the target component may come as later
contribution), then there should be NO deployment error and the same
runtime error during the first usage should happen.
@Dave & Michael -- what's your opinion on this & do you think
that we
should add a text about that case in the proposal or that is another
issue ?
PROPOSAL
The following description should be added in section 1.6.2
References, after line 1387 (that line is after the
paragraph that
explains attaching a binding to a reference and before
the
paragraph
explaining callback) :
Promotion of references accessing endpoints via bindings
is
suggested practice since it allows the assembler to
change the
targets of the references or the specified bindings
and encourages
component reuse, however the lack of such promotion
by itself
MUST
NOT cause errors during deployment or runtime if the
target of the
reference can be identified. The assembler is expected
to
guarantee
for an unpromoted reference with multiplicity 1..1
or 1..n that
one
of the following conditions holds : there is either
internal wire
within the scope of the current composite or
a binding that
identifies correctly either the component/service
for a wire to an
endpoint within the SCA domain or the accessible
address of some
endpoint outside the SCA domain. If the assembler
does not
provide
these conditions for a reference that has a multiplicity
of 1..1
or
1..n, then such an unresolved reference MUST generate
a runtime
error
at latest during the first attempt to use the component.
If the assembler does not provide these conditions
for a
reference that has a multiplicity with 0..1 or 0..n
, then the
programming model MUST not generate deployment errors
and the
reference's wiring state will be represented in accordance
to the
implementation type in question (e.g. null, handle
that throws
exceptions when accessed, extensibility hooks,
etc.).
For example the following definitions MUST NOT generate
deployment
error
:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="MyValueComposite">
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<reference name="StockQuoteService">
<binding.ws uri=",http://www.sqs.com/StockQuoteService"/>
</reference>
<reference name="StockQuoteService2">
<binding.jms>
<destination
name="StockQuoteServiceQueue"/>
<connectionFactory
name="StockQuoteServiceQCF"/>
</binding.jms>
</reference>
</component>
<!-- no references and promotion on purpose -->
<composite>
however the following definitions MUST generate one
:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="MyValueComposite">
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<reference name="UnwiredReference">
<!-- the target cannot be determined, that shouldbe an error-->
<binding.ws/>
</reference>
</component>
<!-- no references and promotion on purpose -->
<composite>
-----Original Message-----
From: David Booz [mailto:booz@us.ibm.com]
Sent: Saturday, 27. October 2007 00:18
To: sca-assembly@lists.oasis-open.org
Cc: Blohm, Henning; Martin Chapman; Michael Rowley
Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references
I agree with Mike R's comments.
I don't think we should complicate multiplicity. In my mind, your
second
and third cases are not distinct because they occur at different points
in
the lifecycle of the composite. I think we should assert that it
is
just
not possible to detect an error in these cases until the component
owning
the reference is started/initialized/dispatched (whatever word you want
to
use, they are all the same to me). That is, I don't think we should
attempt to support your 3rd point.
A batch deployment mechanism with special validation semantics sounds
like
an interesting vendor extension. Since this kind of extended behavior
effectively constrains what can be successfully deployed, it doesn't
make
the app incompatible with a vendor that doesn't do batch deploy +
validation.
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"Peshev, Peter"
<peter.peshev@sap
.com>
To
"Michael
Rowley"
<mrowley@bea.com>,
10/24/2007 02:00
"Martin Chapman"
PM?
<martin.chapman@oracle.com>,
"Blohm,
Henning"
<henning.blohm@sap.com>,
"OASIS
Assembly"
<sca-assembly@lists.oasis-open.org>
cc
Subject
RE: [sca-assembly]
ISSUE 6: usage
of not promoted
references
Hi Michael,
Thanks very much for the clarification, now I understood what you
had
in
mind.>,
Do you think that would lead to a new option for multiplicity (maybe
raised
as another issue ) ?
Since it seems we are wanting to cover 3 scenarios in case the target is
unavailable
-- error during first use of the reference (the 0..1)
-- error during first instantiation of component (what you are
suggesting
for 1..1 in order to solve the bulk deployment for cross-referenced
components)
-- error during deployment (1..1 in the current proposal,
and what
probably many people would expect.
I.e. even if such spec expert as you thought for a moment this
is the
1..1 meaning, than obviously the mortal guys (me & the assemblers)
may
be
thinking the same meaning as well :)
Best Regards
Peter
From: Michael Rowley [mailto:mrowley@bea.com]
Sent: Wednesday, 24. October 2007 20:32
To: Peshev, Peter; Martin Chapman; Blohm, Henning; OASIS Assembly
Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references
From: Peshev, Peter [mailto:peter.peshev@sap.com]
Sent: Wednesday, October 24, 2007 12:40 PM
To: Martin Chapman; Blohm, Henning; Michael Rowley;
OASIS Assembly
Subject: RE: [sca-assembly] ISSUE 6: usage of not
promoted
references
HI Michael,
Since the old text got too much inlined and I
am usually confused
with that, I will try to summarize the opened sub-issues.
- you are saying
"Having 1..1 instead of 0..1 could mean that
an error should be
generated at runtime, possibly at the first use of
the component "
That indeed contradicts the proposal, however I have
formed the
proposal entirely based on your input to the issue
on 5th of
October,
where you have stated explicitly :
"If the reference has a multiplicity of 1..1
or 1..n, then such an
unresolved reference should generate a deployment
error."
You got me there. I guess I didn't concentrate very closely before
on
deploy vs. runtime for this error.
Maybe I have misunderstood you & the intention
for 0..1, sorry for
that , but that only shows that the issue is
valid and it needs
clarification :).
I personally believe that the initial suggestion based
on your
email
(deployment exception for unwired reference with 1..1)
is better
for
the assembler who is alarmed immediately of wiring
problems at
deployment, instead of deferring them to the first
runtime
invocation. Often applications are complex and the
assembler would
have very hard time verifying each possible path of
the business
logic (full cyclomatic complexity search) to check
for such
unwired
references and whether everything is working. That
feature at
least
to me seems more valuable than covering the use case
of having A
wired to B via reference X with 1..1, B wired to A
via reference Y
with 1..1, A is deployed as single contribution, afterwards
B is
deployed as single contribution.
In addition if we delay the exception at runtime in
the 1..1 case,
I
am still lost what exactly is the difference between
0..1 and
1..1.
In both cases we will allow deployment if there is
no target for
the
reference, in both cases there will be exception at
runtime if the
target is still not available, and in both cases if
there is
target
the call will pass.
The difference is that in the 1..1 case the error will be raised on the
first use of the component, not on the first use of that reference (that
way you don't have to wait until the reference is used before getting
your
NullPointerException, or whatever it is).
I'd be OK with generating the error at deployment time if we invented
some
means of doing batch deployment - to tell the system not to do its
checks
until a group of related deployments are all complete. However, writing
up
such a mechanism would be a bit more work.
Back to some other raised issues and raised points:
- I have changed the first sentence in the
way you have
suggested,
also specified that it's neither in runtime
nor in deployment
there
will be errors. Thanks for the suggestion
Great.
- The MUST in the last sentence is not bringing enough
information,
very good point. I switched it to use "will
be represented" and
added mentioning of the extensibility hooks.
I like that.
So here is the new
PROPOSAL :
I like the new proposal, except the fact that it creates a need for some
kind of bulk deployment mechanism, as noted above.
Michael
The following description should be added in section
1.6.2
References, after line 1387 (that line is after the
paragraph that
explains attaching a binding to a reference and before
the
paragraph
explaining callback) :
Promotion of references accessing endpoints via bindings
is
suggested practice since it allows the assembler to
change the
targets of the references or the specified bindings
and encourages
component reuse, however the lack of such promotion
by itself
MUST
NOT cause errors during deployment or runtime if the
target of the
reference can be identified. The assembler is expected
to
guarantee
for an unpromoted reference with multiplicity 1..1
or 1..n that
one
of the following conditions holds : there is either
internal wire
within the scope of the current composite or
a binding that
identifies correctly either the component/service
for a wire to an
endpoint within the SCA domain or the accessible
address of some
endpoint outside the SCA domain. If the assembler
does not
provide
these conditions for a reference that has a multiplicity
of 1..1
or
1..n, then such an unresolved reference MUST generate
a deployment
error. If the assembler does not provide these conditions
for a
reference that has a multiplicity with 0..1 or 0..n
, then the
programming model MUST not generate deployment errors
and the
reference's wiring state will be represented in accordance
to the
implementation type in question (e.g. null, handle
that throws
exceptions when accessed, extensibility hooks,
etc.).
For example the following definitions MUST NOT generate
deployment
error
:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="MyValueComposite">
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<reference name="StockQuoteService">
<binding.ws uri=",http://www.sqs.com/StockQuoteService"/>
</reference>
<reference name="StockQuoteService2">
<binding.jms>
<destination
name="StockQuoteServiceQueue"/>
<connectionFactory
name="StockQuoteServiceQCF"/>
</binding.jms>
</reference>
</component>
<!-- no references and promotion on purpose -->
<composite>
however the following definitions MUST generate one
:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="MyValueComposite">
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<reference name="UnwiredReference">
<!-- the target cannot be determined, that shouldbe an error-->
<binding.ws/>
</reference>
</component>
<!-- no references and promotion on purpose -->
<composite>
Best Regards
Peter
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Wednesday, 24. October 2007 19:24
To: Blohm, Henning; 'Michael Rowley'; 'OASIS Assembly'
Subject: RE: [sca-assembly] ISSUE 6: usage of not
promoted
references
do i smell some confromance targets here...what do
we (abstractly)
install and to what, and where do we deploy it?
-----Original Message-----
From: Blohm, Henning [mailto:henning.blohm@sap.com]
Sent:, Wednesday, October 24, 2007 4:46 PM
To: Michael Rowley; OASIS Assembly
Subject: AW: [sca-assembly] ISSUE 6: usage of not
promoted
references
Michael,
on the deployment error issue. In SCA we seemed
to use the term
deployment as "making available to process requests"
and used the
additional term "installation" for getting
something into the
system.
Reading deployment as "making available
to process requests" it
is
very close to "use" in which case you and
Peter seem to talk
about
the same point in time.
It could be best if the assembly spec would
include some
wording
to describe the exact meaning of "deploy"
and "install". You
agree?
Thanks,
Henning
Von: Michael Rowley [mailto:mrowley@bea.com]
Gesendet: Mittwoch, 24. Oktober 2007 15:28
An: OASIS Assembly
Betreff: RE: [sca-assembly] ISSUE 6: usage of not
promoted
references
[MR: inline]
-----Original Message-----
From: Peshev, Peter [mailto:peter.peshev@sap.com]
Sent: Wednesday, October 24,
2007 3:26 AM
To: Michael Rowley; OASIS Assembly
Subject: RE: [sca-assembly]
ISSUE 6: usage of not promoted
references
HI Michael,
Comments inline, I have pasted
your issues with ">"
>- First, "RECOMMENDED"
and "NOT REQUIRED" are not a
defined
keywords.
PP : There is no ""RECOMMENDED"
in this proposal. In
addition
when
looking at http://www.ietf.org/rfc/rfc2119.txt
RECOMMENDED
and REQUIRED
are mentioned as key words.
[MR: Good point on RECOMMENDED (I had originally
written just
"NOT
REQUIRED", but then belatedly (and incorrectly)
added
"RECOMMENDED"
when I happened to see it - apparently when I was
looking too far
down in the email to the old proposal). Regarding
"NOT REQUIRED"
-
yes "REQUIRED" is a keyword, and "MUST
NOT" is also a key phrase,
but "NOT REQUIRED" is not.]
Anyway as per the notes
of the OpenCSA
Steering Committee Minutes from
28 September the keyword
SHOULD and
its synonym RECOMMENDED are
supposed to be avoided, and
only
the rest of
the keywords remain to be used.
However being a developer I
don't claim
any competence in speac creation,
so maybe you are right.
> In particular, the bit
that says that "an implementation
which does
not include a particular option
MUST be prepared to
interoperate with
...". What does that
mean when the "implementation" is the
assembler?
PP : At least my understanding
of the keyword usage is
that
they should
be used whenever there is requirement
towards the SCA
Runtime
(i.e. the
vendors that will implement
the spec), and not to be used
for
any users
of the spec -- assembler, deployer,
etc. That's what was
supposed to be
in the proposal, If something
is not done in that way, I
will
be glad to
fix.
if the first sentence is not
clear enough, maybe we can
adapt
it to :
Promotion of references accessing
endpoints via bindings is
common
practice since it allows the
assembler to change the
targets
of the
references or the specified
bindings and encourages
component
reuse,:
however the lack of such promotion
MUST NOT cause error in
SCA
Runtime-s
.
[MR: I think it is worthwhile to say that promotion
is
recommended
(lowercase). I think it is very valuable for
the specification
to
include directives and suggestions to our various
human roles.
Changing the MUST NOT to be on the runtime seems
better, but
perhaps
it should be on deployment, as in "lack of promotion
MUST NOT
cause
an error during deployment."]
>- I suspect that we should
not REQUIRE that a deployment
error be
generated for unwired 1..1 references.
Consider what would
happen if
someone developed deployable
composites A and B (each from
different
contributions) with the intention
of wiring at least one of
the
components from A to something
in B and wiring at least one
component in
B to something in A. There
would be no legal ordering of
the
deployments, as the first deployment
would always fail.
PP : Yes, it will be an
error. In that case the assembler
should use
0..1 if he wants to deploy the
first component and after
some
time the
other. Isn't this exactly what
0..1 was intended for ?
Otherwise what is
the difference between 0..1
and 1..1 ?
[MR: Having 1..1 instead of 0..1 could mean that
an error should
be
generated at runtime, possibly at the first use of
the component
that includes that reference, rather than at deployment
time. It
would be unfortunate for someone to have to declare
a reference
that
is really required as 0..1 just to get around deployment
order
issues.]
>- The last MUST, which is
on the programming model, says:
"MUST
represent the reference's wiring
state in accordance to the
implementation type in question".
Presumably Peter meant
to
include the
words "as invalid"
after the word "state". However, even
with
this
modification I don't like the
requirement. SCA is intended
to
be an
integration technology, which
means that it needs to be
able
to
accommodate a wide variety of
implementation types. Some
of
these
implementation types will use
programming models where
external services
can be used, but some kind of
default behavior occurs if
one
isn't
(think
of extensibility hooks). Such a programming model
should be able
to represent these as references
to SCA, in spite of the
fact
that they
don't follow the admonition
that unwired references be
presented as
nulls.
PP : The wording "according
to the implementation type in
question" was
supposed to cover the "wide
variety of implementation
types"
that you
are speaking. If you prefer
some other wording I would be
glad
to
include. Maybe mentioning explicitly
extensibility hooks
if
you
consider them so important :
... MUST NOT generate deployment
errors and MUST represent
the
reference's wiring state in
accordance to the
implementation
type in
question (e.g. null,
handle that throws exceptions
when accessed, extensibility
hooks, etc.).
[MR: I was reacting against this on the assumption,
apparently
incorrect, that the words "as invalid"
had been removed
accidentally, since the current sentence doesn't
seem to make any
sense. I read the current wording as saying
"the programming
model
MUST represent the reference however it wants."
What kind of a
requirement is that?]]
Michael
Best Regards
Peter
________________________________
From: Michael Rowley [mailto:mrowley@bea.com]
Sent: Tuesday, 23. October 2007
20:54
To: Peshev, Peter; OASIS Assembly
Subject: RE: [sca-assembly]
ISSUE 6: usage of not promoted
references
I'll comment on the RFC 2119
usage, which I had hoped to
avoid, but I we,
have to address it at some point,
so we might as well start
with this
proposal.
- First, "RECOMMENDED"
and "NOT REQUIRED" are not a defined
keywords.
If we changed it to use the
closest defined keyword ("MAY")
it
might be
something like "The assembler
MAY promote references...",
but
that would,
be odd, given the definition
of MAY according to 2119:.
5. MAY This word, or
the adjective "OPTIONAL", mean that
an
item is
truly optional.
One vendor may choose to include the
item
because a
particular marketplace
requires it or because the vendor
feels that
it enhances the
product while another vendor may omit
the
same item.
An implementation
which does not include a particular
option MUST be
prepared to interoperate
with another implementation
which
does
include the option,
though perhaps with reduced
functionality. In the,
same vein an implementation
which does include a
particular
option
MUST be prepared
to interoperate with another
implementation which
does not include
the option (except, of course, for the
feature the
option provides.)
In particular, the bit that
says that "an implementation
which
does not
include a particular option
MUST be prepared to
interoperate
with ...".
What does that mean when the
"implementation" is the
assembler?
- I suspect that we should not
REQUIRE that a deployment
error
be
generated for unwired 1..1 references.
Consider what would
happen if
someone developed deployable
composites A and B (each from
different
contributions) with the intention
of wiring at least one of
the
components from A to something
in B and wiring at least one
component in,
B to something in A. There
would be no legal ordering of
the
deployments, as the first deployment
would always fail.
- The last MUST, which is on
the programming model, says:
"MUST
represent the reference's wiring
state in accordance to the
implementation type in question".
Presumably Peter meant
to
include the,
words "as invalid"
after the word "state". However, even
with
this
modification I don't like the
requirement. SCA is intended
to
be an
integration technology, which
means that it needs to be
able
to
accommodate a wide variety of
implementation types. Some
of
these
implementation types will use
programming models where
external services,
can be used, but some kind of
default behavior occurs if
one
isn't
(think of extensibility hooks).
Such a programming model
should be able,
to represent these as references
to SCA, in spite of the
fact
that they
don't follow the admonition
that unwired references be
presented as
nulls.
Michael
-----Original Message-----
From: Peshev, Peter [mailto:peter.peshev@sap.com]
Sent: Tuesday, October 23, 2007
12:31 PM
To: OASIS Assembly
Subject: RE: [sca-assembly]
ISSUE 6: usage of not promoted
references
Once again, replacing
the funny idea of :
"reference with reference
1..1 or 1..n"
with the intended wording. Otherwise
everything is the
same.
Sorry :(
PROPOSAL :
The following description should
be added in section 1.6.2
References,
after line 1387 (that line is
after the paragraph that
explains
attaching a binding to a reference
and before the paragraph
explaining
callback) :
Promotion of references accessing
endpoints via bindings is
common
practice since it allows the
assembler to change the
targets
of the
references or the specified
bindings and encourages
component
reuse,
however it is NOT REQUIRED.
The assembler is expected to
guarantee for
an unpromoted reference with
multiplicity 1..1 or 1..n that
one of the
following conditions holds :
there is either internal wire
within the
scope of the current composite
or a binding that
identifies
correctly
either the component/service
for a wire to an endpoint
within
the SCA
domain or the accessible address
of some endpoint outside
the
SCA
domain. If the assembler
does not provide these conditions
for a
reference that has a multiplicity
of 1..1 or 1..n, then
such
an
unresolved reference MUST generate
a deployment error. If
the
assembler
does not provide these conditions
for a reference that has
a
multiplicity with 0..1 or 0..n
, then the programming model
MUST not
generate deployment errors and
MUST represent the
reference's
wiring
state in accordance to the implementation
type in question
(e.g. null,
handle that throws exceptions
when accessed, etc.).
For example the following definitions
MUST NOT generate
deployment error,
:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="MyValueComposite">
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<reference
name="StockQuoteService">.
<binding.ws
uri="http://www.sqs.com/StockQuoteService"/>
</reference>
<reference
name="StockQuoteService2">
<binding.jms>
<destination name="StockQuoteServiceQueue"/>
<connectionFactory name="StockQuoteServiceQCF"/>
</binding.jms>
</reference>
</component>
<!-- no references and promotion
on purpose -->
<composite>
however the following definitions
MUST generate one :
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="MyValueComposite">
<component name="MyValueServiceComponent">
<implementation.java
class="services.myvalue.MyValueServiceImpl"/>
<reference
name="UnwiredReference">
<!-- the target cannot be determined,
that should be an, error-->
<binding.ws/>
</reference>
</component>
<!-- no references and promotion
on purpose -->
<composite>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and 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]