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

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

Ok, I thought you were trying for an approach where the OASIS reference implementation would be able to delegate to vendor B's factory finder even when running in vendor A's runtime. That's what you'd really need, otherwise you're just lucky if it works.

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

Simon Nash ---04/02/2009 08:54:12 AM---Dave, Because the vendor controls the injected factory finder, they

From:	Simon Nash <oasis@cjnash.com>
To:	sca-j@lists.oasis-open.org
Date:	04/02/2009 08:54 AM
Subject:	Re: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA component code - Formal Proposal update

---

Dave,
Because the vendor controls the injected factory finder, they
control how it does the lookup, based on any properties and
classLoader that may have been passed in, system property settings,
META-INF/services settings, OSGI bundle repositories, phase of
the moon, etc., etc.

For example, a property setting could be passed in to say that the
factory wanted by the client is com.vendorb.sca.ClientFactory.
If vendor A's runtime can find this class (using whatever lookup
it supports... maybe searching the classpath or looking in the
supplied class loader), then the mixed case can work.  If vendor A
chooses not to support the mixed case, it can reject any requests
for factories other than its own.

The client would need to know how vendor A's implementation does
lookups and would need to install the vendor B factory in the
appropriate place for the vendor A product to be able to find it.

If this works 90% of the time we are still in much better shape than
the 0% for mixed cases that we have with the current proposal.

   Simon

David Booz wrote:
> Simon, I'm agreeing with your use cases, but not following the code 
> (http://lists.oasis-open.org/archives/sca-j/200903/msg00224.html)
> 
> What are you assuming that vendors will do when running code in their 
> own Domain? If they inject their own default factoryFinder, then you're 
> back in the same boat not being able to support mixed cases.
> 
> So can you tell me what I'm missing?
> 
> 
> thanks
> 
> 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 Simon Nash ---03/31/2009 08:35:29 AM---Mike 
> Edwards wrote: >Simon Nash ---03/31/2009 08:35:29 AM---Mike Edwards wrote: >
> 
> 
> From:		 
> Simon Nash <oasis@cjnash.com>
> 
> To:		 
> OASIS Java <sca-j@lists.oasis-open.org>
> 
> Date:		 
> 03/31/2009 08:35 AM
> 
> Subject:		 
> Re: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA component code 
> - Formal Proposal update
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Mike Edwards wrote:
>  >
>  > Folks,
>  >
>  > I think the main disagreement here relates to the form of replacement
>  > that is expected at runtime.
>  >
>  > Simon makes the point that the replacement he would like to see allows
>  > for Vendor A's implementation
>  > of the org.oasisopen.sca.client.SCAClientFactory class to load Vendor
>  > B's SCAClientFactory class.
>  >
>  > I find this a little strange.  If you want Vendor B's SCAClientFactory
>  > class, why don't you load
>  > Vendor B's implementation of org.oasisopen.sca.client.SCAClientFactory
>  > in the first place?
>  >
>  > I suspect that we are using different models of replaceability here.
>  >  Let me try to discuss this:
>  >
>  > 1) In one model, the idea is that
>  > org.oasisopen.sca.client.SCAClientFactory is NOT replaceable.
>  > It is exactly as described in the (current) spec, with the injectable
>  > SCAClientFactory implementation
>  > and also the SCAClientFactoryFinder class which it calls.
>  >
>  > Vendor supplies their version of SCAClientFactory EITHER by injecting it
>  > into the
>  > org.oasisopen.sca.client.SCAClientFactory OR the vendor uses one of the
>  > mechanisms described
>  > by SCAClientFactoryFinder.
>  >
>  > 2) In another model, org.oasisopen.sca.client.SCAClientFactory is
>  > replaceable - it is a class supplied
>  > by the vendor.  In this case, the vendor can choose to rewrite that code
>  > in any way that they choose.
>  >
>  > There is no requirement for the code to accept some other vendor's
>  > injected SCAClientFactory.  If the
>  > other vendor wants to provide that, then the client should use the other
>  > vendors implementation of
>  > org.oasisopen.sca.client.SCAClientFactory.
>  >
>  >
>  > I think I'm prepared to vote for 1) above.  ie a fixed set of classes
>  > shipped by OASIS that must not be
>  > changed by vendors.  Vendors can use any of the mechanisms defined in
>  > the code, but they cannot
>  > invent other mechanisms.
>  >
>  >
>  > I wonder whether in reality we're trying to allow for something else
>  > entirely - but this would be more complex.
>  > Is there a desire for a client to be able to connect to multiple SCA
>  > domains, each from a different supplier?
>  > ie be able to load n SCAClientFactory implementations and to handle them
>  > in such a way that a given
>  > request for a factory for a given Domain is handed down a chain of
>  > factories until one is found that knows
>  > how to deal with the actual Domain implementation?
>  >
> I would like to enable multiple SCAClientFactory implementations
> to be loaded and used, but I don't see any need to hand requests
> down through a chain.  I think it's fine to require client code
> to know which factory object to use when looking up services in
> a given domain.  With this more limited scope, I don't think it's
> complex to allow for multiple factory objects.
> 
> There are three cases to consider:
> 
> 1. The client code is unmanaged code that is not part of any
>    vendor's SCA domain.  It wants to access SCA services in
>    both vendor A's domain and vendor B's domain.
> 
> 2. The client code is part of vendor A's SCA domain.  It wants to
>    access SCA services in vendor B's domain.
> 
> 3. Client code is written to use a service in vendor B's SCA domain.
>    The same code should be able to run either unmanaged or within
>    vendor A's SCA domain.
> 
> The current proposal supports the first of these cases.  The client
> can call the form of newInstance() that takes Properties and possibly
> ClassLoader to get an SCAClientFactory for vendor A, then call
> newInstance() again with different Properties and possibly a
> different ClassLoader to get an SCAClientFactory for vendor B.
> Because no defaultFactory was injected, the SCAClientFactoryFinder
> code will run and this will do the correct lookups both times.
> 
> Unfortunately the current proposal doesn't support the second of
> these cases if vendor A has used the defaultFactory injection point
> to hard-wire its own factory.  Code running in vendor A's managed
> environment could never get an instance of vendor B's factory
> because all forms of the newInstance() method would always return
> vendor A's SCAClientFactory no matter what Properties or ClassLoader
> objects were passed to newInstance().  It would not be possible for
> vendor A's runtime to return a vendor B client factory even if it
> wanted to, because the current SCAClientFactory implementation
> does not use its factory finding code once a defaultFactory has been
> injected, and throws away any newInstance() parameters that it
> was passed.  The name "defaultFactory" is a misnomer because it
> isn't acting as a default in the normal sense of something to use
> if nothing more specific is selected -- it's really an override
> rather than a default.
> 
> An unfortunate consequence of this is that the third case doesn't
> work.  This is because code written to use a single service from
> vendor B's domain by calling newInstance() with a suitable
> Properties object would work in an unmanaged environment but would
> fail in vendor A's managed environment.
> 
> The solution is allow vendors to provide a default factory in the
> true sense of the word, i.e., a factory that will be used in the
> absence of anything more explicit.  The code I sent shows one way
> that this could be achieved.  There is very little extra mechanism
> needed to allow vendors to enable this mixed scenario if they wish,
> and the client interface is not changed.
> 
>   Simon
> 
>  >
>  > 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: Simon Nash <oasis@cjnash.com>
>  > To: OASIS Java <sca-j@lists.oasis-open.org>
>  > Date: 30/03/2009 12:53
>  > Subject: Re: [sca-j] [ISSUE 1] Accessing SCA Services from non-SCA
>  > component code - Formal Proposal update
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  > Mike Edwards wrote:
>  >  >
>  >  > Folks,
>  >  >
>  >  > Here is a response to Simon's comments and an updated proposal 
> document
>  >  > for this afternoon.
>  >  >
>  >  >
>  > 
> http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31769/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%203.pdf 
>  >
>  >  >
>  >  >
>  >  > 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:                  Simon Nash <oasis@cjnash.com>
>  >  > To:                  OASIS Java <sca-j@lists.oasis-open.org>
>  >  > Date:                  20/03/2009 09:59
>  >  > Subject:                  Re: [sca-j] [ISSUE 1] Accessing SCA
>  > Services from non-SCA
>  >  > component code - 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.)
>  >  > *<mje> Good question.  I don't have a strong view </mje>*
>  >  >
>  > As no-one feels strongly, let's leave it this way for now.
>  >
>  >  >  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.
>  >  >
>  >  > *<mje> I view this as similar in nature to the pseudo-schemas of the
>  >  > Assembly spec and*
>  >  > *I think it is good.*
>  >  > *The "exact semantics" are NOT part of the normative part of the spec,
>  >  > since an*
>  >  > *provider can choose to vary them.  The only things that are 
> guaranteed
>  >  > are those*
>  >  > *stated in this section.  Any further semantics must be defined by the
>  >  > provider - and*
>  >  > *for the default, it is defined in the appendix of this spec*
>  >  > *</mje>*
>  >  >
>  > As we discussed on Friday's call, it's OK to have a summary here
>  > and put additional normative detail in the appendix, as we do for
>  > pseudo-schemas.
>  >
>  > Some of the semantics of this class need to be a normative part
>  > of the spec.  Specifically, this class MUST support injection
>  > of a factory into the defaultFactory injection point and use the
>  > injected factory if one is present, and the various newInstance()
>  > methods MUST result in a call to createSCAClient() on the vendor
>  > factory.  This could be stated either in the chapter 8 or in the
>  > appendix, but it needs to be stated normatively somewhere.
>  >
>  >  >  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.
>  >  > *<mje>*
>  >  > *I take the opposite view and think that all the code provided as part
>  >  > of this specification*
>  >  > *should be ALSO listed in the appendix as well as the definitional
>  >  > material in the body of*
>  >  > *the document.  I think the appendix should be a copy of the 
> actual code
>  >  > artifacts,*
>  >  > *comments and all.*
>  >  >
>  > We don't do this for any of the other interfaces or annotation
>  > definitions.  Given that we are shipping a zip file containing all
>  > the code, it would not make sense to copy every line of this zip file
>  > into to the specification as well.  I believe the resolution to
>  > JAVA-121 established the correct split between what goes in the
>  > spec and what goes in the zip file.  The SCAClient interface is no
>  > different in this respect from any other interface in Chapter 8
>  > or annotation in chapter 9 and should not be treated differently.
>  >
>  >  >  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.
>  >  > *<mje> Well, its the signature that is normative, in the sense that a
>  >  > provider could*
>  >  > *replace the behaviour completely - this is a point to discuss*
>  >  > *</mje>*
>  >  >
>  > There is a normative mechanism provided in the code for a vendor to
>  > replace the factory finder reference implementation using injection
>  > of the defaultFactory.  However, this does not replace the code in
>  > this class.  Specifically, the defaultFactory injection point MUST
>  > be supported and the newInstance() methods MUST result in a
>  > createSCAClient() call to the vendor factory.  This is necessary
>  > to allow vendor A's SCAClientFactory class to be used with vendor B's
>  > factory implementation.
>  >
>  > Having thought some more about how this A/B scenario will work in
>  > practice, I'm not sure that we have the vendor extension point right
>  > at the moment.  Injecting into defaultFactory currently short-circuits
>  > the factory finding process and causes all arguments passed to the
>  > newInstance() method to be ignored.  This means that if vendor A uses
>  > this injection point, there is no capability for vendor B's factory
>  > to be located or used, even if suitable properties and/or class loader
>  > objects were passed to newInstance().
>  >
>  > An alternative approach is for the injection point to not be the
>  > factory itself, but the factory finder.  This would allow vendors to
>  > replace the SCA reference implementation of the factory finder with
>  > their own implementation.  This implementation would be able to
>  > either use or ignore the arguments passed to newInstance().  We could
>  > have an abstract normative base class for SCAClientFactoryFinder that
>  > works in a similar way to the abstract base class for SCAClientFactory,
>  > with SCA providing a non-normative factory finder reference
>  > implementation that is a concrete subclass of SCAClientFactoryFinder.
>  > A vendor could implement their own subclass of SCAClientFactoryFinder
>  > and inject an instance of this subclass into a protected field of
>  > SCAClientFactory called defaultFactoryFinder.  If a vendor does this,
>  > the default reference implementation would not be used and would not
>  > need to be present.  I'll send a separate email with details of how
>  > the code for this would look.
>  >
>  >  >  5. On line 2355, the package should be ".impl" not ".spi".
>  >  > *<mje>Fixed</mje>*
>  >  >
>  >  >  6. The title of section B.1.3 should be SCAClientFactoryFinder.
>  >  > *<mje>Fixed</mje>*
>  >  >  7. In line 2443, change SCAClientFactory to SCAClientFactoryFinder.
>  >  > *<mje>Fixed</mje>*
>  >  >  8. The bulleted list in lines 2445-2448 should be numbered, and
>  >  >     the preceding text should say that the lookup follows this order.
>  >  > *<mje>Fixed</mje>*
>  >  >  9. On line 2454, the package should be ".impl" not ".spi".
>  >  > *<mje>Fixed</mje>*
>  >  > 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.
>  >  > *<mje>I disagree - this material IS part of the material produced 
> by the
>  >  > TC</mje>*
>  >  >
>  > The zip file is also part of the material produced by the TC.  For
>  > non-normative code in this zip file, I don't see the value in also
>  > copying this code into the spec.  However, if we are going to include
>  > this code in the spec, we should separate it into a separate appendix
>  > from any normative code and clearly mark this appendix as non-normative.
>  >
>  >  > 11. Comment in lines 2468-2470 is wrong.
>  >  > *<mje>Fixed</mje>*
>  >  > 12. Comment in lines 2499-2501 is wrong.
>  >  > *<mje>Fixed</mje>*
>  >  > 13. In line 2504, change SCAClient to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 14. In line 2506, change SCAClient to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 15. In line 2507, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 16. In line 2508, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 17. In line 2542, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 18. In line 2544, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 19. In line 2562, change checkMETAINFServicesForSIPClassName to
>  >  >     checkMETAINFServicesForSPIClassName.
>  >  > *<mje>Fixed by changing to *checkMETAINFServicesForClassName*</mje>*
>  >  > 20. In line 2572, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 21. In line 2575, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 22. In line 2594, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 23. In line 2597, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 24. In line 2600, change checkMETAINFServicesForSIPClassName to
>  >  >     checkMETAINFServicesForSPIClassName.
>  >  > *<mje>Fixed</mje>*
>  >  > 25. In line 2688, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 26. In line 2691, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 27. In line 2693, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 28. In line 2695, change SCAClientFactorySPI to SCAClientFactory.
>  >  > *<mje>Fixed</mje>*
>  >  > 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.
>  >  > *<mje>I disagree - there is nothing normative we can say about
>  >  > vendors</mje>*
>  >  >
>  > OK, I agree with this.  If we add appropriate normative language
>  > for how SCAClientFactory works, that would cover it.
>  >
>  >   Simon
>  >
>  >  >   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/
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >
>  >  >
>  >  >
>  >  > ---------------------------------------------------------------------
>  >  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  >  > generates this mail.  Follow this link to 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/
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail.  Follow this link to 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/
>  >
>  >
>  >
>  >
>  >
>  >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
> 



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php