Dave,
In response:
1) I simply missed it. I propose
that we remove the final paragraph of section 8.1.
2) I think there is a problem here -
we are defining code that WILL be published as artifacts of the OASIS SCA-J
TC
If they are not published in the spec,
what standing do they have?
Personally, I see no problem in publishing
the code in full in the Appendix.. Their standing is then very clear.
The fact that the implementation is
there for all to see is not a problem in my opinion.
3) I chose the appendix for the information
for the providers since this is a very different level of material from
a description of
APIs, which is what the main part of
the spec is supposed to be (from its very title!!). I suppose this
material could be placed into
some new section in the body of the
spec, which would have to be given a title like SCAClient SPI, but I don't
feel very
enthusiastic about doing it that way.
I'm not sure how much of this information
is useful to end users. Perhaps if you could point it out in detail,
we could agree
to include that in the main text. The
problem I see is that for a given provider, the user information is likely
to be unique to
that provider.
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:
From:
David Booz <>
To:
Date:
18/03/2009 13:46
Subject:
Re: [sca-j] [ISSUE 1] Accessing SCA
Services from non-SCA component code - Formal Proposal
Thanks for writing this up. It's a really good start.
Just a couple of comments:
1) I was surprised that you didn't address your Word comment at the end
of section 8.1
2) I don't think we want to expose the implementation of the SCAClientFactory
methods in the spec....esp. the FactoryFinder usage. I think we do need
to expose the defaultFactory attribute as that is the injection point for
vendors. Further, section B.1.3 goes into detail about FactoryFinder being
overridden, but I thought we agreed on the last call that factory finder
had become an implementation detail of the OASIS SCAClientFactory. Vendors
will replace SCAClientFactory (possibly through injection) and therefore
the finder factory becomes moot. This comment ripples into B.1.4 also.
3) There's good info at the start of B.1.3 and in B.1.4 about what vendors
have to do, including the text about how to override the SCAClientFactory
class. Is an appendix really the right place for that? It's always difficult
to balance writing the specs for vendors vs the vendor's users/customers.
Seems that some of this is very important for users to know.
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:
Mike
Edwards ---03/17/2009 10:20:04 AM---Folks, I have created a formal proposal
for Issue 1 based on CD02 Rev3 and on
From:
Mike Edwards <>
To:
"OASIS Java" <>
Date:
03/17/2009 10:20 AM
Subject:
[sca-j] [ISSUE 1] Accessing SCA Services from non-SCA component code -
Formal Proposal
Folks,
I have created a formal proposal for Issue 1 based on CD02 Rev3 and on
Mark's latest email:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31702/sca-javacaa-1.1-spec-cd02-rev3%2BIssue1.pdf
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31701/sca-javacaa-1.1-spec-cd02-rev3%2BIssue1.doc
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:
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
