[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA componentcode - Formal Proposal
Mark,
Here are my comments on the latest draft proposal document.
I have not yet reviewed the code files.
1. Lines 1139/1140 imply that the service name must always be
specified, even if there is only one service on the component.
Do we want to require this, or follow the assembly wiring
rules that allow the service name of be omitted in this case?
(I'm raising this for discussion, not proposing a change.)
2. I not very comfortable with having section 8.9 define the methods
of SCAClientfactory using "..." notation. The exact semantics of
these need to be part of the SCA standard. Leaving these methods
as "..." might be OK if the method descriptions specified precise
semantics, but they don't.
3. Why are there two definitions for the SCAClient interface, one
in section 8.8 and one in section B.1.1? These should be merged
into one place (section 8.8) as we do for all the other interfaces.
4. Same comment for SCAClientFactory. In this case there is slightly
more justification for the separation because this is a class.
If we are going to do this split, section 8.9 needs to point to section
B.1.2 and state that section B.1.2 is a normative part of the standard.
5. On line 2355, the package should be ".impl" not ".spi".
6. The title of section B.1.3 should be SCAClientFactoryFinder.
7. In line 2443, change SCAClientFactory to SCAClientFactoryFinder.
8. The bulleted list in lines 2445-2448 should be numbered, and
the preceding text should say that the lookup follows this order.
9. On line 2454, the package should be ".impl" not ".spi".
10. I don't think it's useful for the reference implementation code to
be part of Appendix B. This isn't a normative part of the
standard and should be provided in the zip file.
11. Comment in lines 2468-2470 is wrong.
12. Comment in lines 2499-2501 is wrong.
13. In line 2504, change SCAClient to SCAClientFactory.
14. In line 2506, change SCAClient to SCAClientFactory.
15. In line 2507, change SCAClientFactorySPI to SCAClientFactory.
16. In line 2508, change SCAClientFactorySPI to SCAClientFactory.
17. In line 2542, change SCAClientFactorySPI to SCAClientFactory.
18. In line 2544, change SCAClientFactorySPI to SCAClientFactory.
19. In line 2562, change checkMETAINFServicesForSIPClassName to
checkMETAINFServicesForSPIClassName.
20. In line 2572, change SCAClientFactorySPI to SCAClientFactory.
21. In line 2575, change SCAClientFactorySPI to SCAClientFactory.
22. In line 2594, change SCAClientFactorySPI to SCAClientFactory.
23. In line 2597, change SCAClientFactorySPI to SCAClientFactory.
24. In line 2600, change checkMETAINFServicesForSIPClassName to
checkMETAINFServicesForSPIClassName.
25. In line 2688, change SCAClientFactorySPI to SCAClientFactory.
26. In line 2691, change SCAClientFactorySPI to SCAClientFactory.
27. In line 2693, change SCAClientFactorySPI to SCAClientFactory.
28. In line 2695, change SCAClientFactorySPI to SCAClientFactory.
29. Section B.1.4 should not be in the appendix. It needs to be
moved into the main body of the spec with appropriate normative
language.
Simon
Mike Edwards wrote:
>
> Mark,
>
> Looks fine to me, thanks for the update.
>
> 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
>
>
> From: "Mark Combellack" <mcombellack@avaya.com>
> To: <sca-j@lists.oasis-open.org>, "David Booz" <booz@us.ibm.com>, Mike
> Edwards/UK/IBM@IBMGB
> Date: 19/03/2009 15:01
> Subject: RE: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA
> component code - Formal Proposal
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi,
>
> Thanks Mike for putting all the pieces of this proposal together.
>
> I’ve updated the text of the proposal to incorporate feedback from Dave
> and other earlier comments on the mailing list. The changes I have made
> are:
>
>
> * Corrected the import statements in the sample code in section 4.2.1
> * Delete text at end of section 8.1 which talked about non-SCA
> Clients using the ComponentContext to look up services
> * Changed private defaultFactory to protected in section 8.9
> * Changed private defaultFactory to protected in Appendix B.1.2
> * Trimmed the implementation code out of the SCAClientFactory in
> section 8.9
> * Changed SCA domain to SCA Domain in the modified text to be
> consistent with the rest of the specification
> * Delete paragraph saying vendors are free to replace
> SCAFactoryFinder with their own version
> * Deleted option 4 in Appendix B.1.4
>
>
> It should be noted that I have not addressed two of Dave’s issues. These
> are the last bit of point 2 and point 3
>
> I have created a new revision 2 of this proposal which can be found at:
>
> Proposal (PDF):
> _http://www.oasis-open.org/committees/download.php/31746/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%202.pdf_
>
> Proposal (Word):
> _http://www.oasis-open.org/committees/download.php/31745/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%202.doc_
>
>
> Thanks,
>
> Mark
> Mark Combellack| Software Developer| Avaya | Eastern Business Park | St.
> Mellons | Cardiff | CF3 5EA | Voice: +44 (0) 29 2081 7624 |
> _mcombellack@avaya.com_ <mailto:|mcombellack@avaya.com>
>
> ------------------------------------------------------------------------
>
> *From:* David Booz [mailto:booz@us.ibm.com] *
> Sent:* 18 March 2009 17:20*
> To:* sca-j@lists.oasis-open.org*
> Subject:* Re: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA
> component code - Formal Proposal
>
>
> All line numbers are from the pdf.
>
> 1) delete works for me
>
> */[Mark Combellack] Deleted this text/*
>
> 2) I don't feel strongly about the full source being in an appendix, if
> there's a good reason, I am ok with it. My point on #2 was focused on
> the FactoryFinder, and esp. in that it appears on line 1179. Option4 in
> B.1.4 is not an option for vendors, we removed that in the last call.
>
> */[Mark Combellack] Deleted option 4/*
>
> And further, I don't think any of the implementation of those
> SCAClientFactory methods should appear in the body of the spec (near
> line 1179). Appendix is fine.
> Concretely I think you should remove lines 1164, 1168, 1172, 1176-1185,
> and lines 2776-2779.
>
> */[Mark Combellack] Deleted implementation code in the text in the lines
> specified./*
>
> If we have to publish in the spec, all the classes that are part of the
> OASIS ref impl, then I think we should also consider merging the factory
> finder into the OASIS SCAClientFactory since it's no longer an SPI (and
> then we can remove B.1.3 entirely).
>
> */[Mark Combellack] I have not addressed this issue/*
>
>
> 3) The point here was the info in B.1.4, line 2745 is actually part of
> the end user programming model (option1 and option2), and thus I think
> it should appear in the body of the spec somewhere near or in 8.9.
>
> */[Mark Combellack] I have not addressed this issue/*
>
>
>
> 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:booz@us.ibm.com
>
> Inactive hide details for Mike Edwards ---03/18/2009 10:19:16 AM---Dave,
> In response:Mike Edwards ---03/18/2009 10:19:16 AM---Dave, In response:
>
>
> From:
> Mike Edwards <mike_edwards@uk.ibm.com>
>
> To:
> sca-j@lists.oasis-open.org
>
> Date:
> 03/18/2009 10:19 AM
>
> Subject:
> Re: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA component code
> - Formal Proposal
>
>
> ------------------------------------------------------------------------
>
>
>
>
>
> 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: mike_edwards@uk.ibm.com
>
> From: David Booz <booz@us.ibm.com>
> To: sca-j@lists.oasis-open.org
> 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:booz@us.ibm.com
>
> Inactive hide details for Mike Edwards ---03/17/2009 10:20:04
> AM---Folks, I have created a formal proposal for Issue 1 based onMike
> 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 <mike_edwards@uk.ibm.com>
>
> To:
> "OASIS Java" <sca-j@lists.oasis-open.org>
>
> 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: mike_edwards@uk.ibm.com
>
> ------------------------------------------------------------------------
>
> /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]