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 | 

From:
David Booz [mailto:] 

Sent: 18 March 2009 17:20

To: 

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:

Mike Edwards ---03/18/2009 10:19:16
AM---Dave, In response:

 

  
  

  From:

  
  
  

  Mike Edwards
  <>

  
 

 

  
  

  To:

  
  
  

  

  
 

 

  
  

  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:  

 

  
  
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