Re: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA component code -Formal Proposal

[David Booz <booz@us.ibm.com>]

All line numbers are from the pdf.

1) delete works for me

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. 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. 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).

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.


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

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

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 <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