Re: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified

[Mike Edwards <mike_edwards@uk.ibm.com>]

Duane,

Are you suggesting that SCA should consider
stepping into the space of Registry/Repository, or at least a definition
of
the service interfaces for Registry/Repository?

I note that this falls outside the charters
of the current TCs, but a new TC can always be considered for some new
area
of work.

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

Duane Nickull <dnickull@adobe.com>

08/10/2007 17:45

To	"Blohm, Henning" <henning.blohm@sap.com>, Mike Edwards/UK/IBM@IBMGB, <sca-assembly@lists.oasis-open.org>
cc	"Mittag, Frank" <frank.mittag@sap.com>
Subject	Re: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified

All:

This has always been one of the caveats of most registry-repository implementations.
 The lack of synchronization between the registry index and the repository
artifact can have major implementation issues.  UDDI had this as an
Achilles heel too.  The registry basically reports its last know state
of the artifact (in this case component) to the entity wanting to consume
that component however in most implementations, it has no knowledge of
whether or not the actual artifact is still in that state.  Coupling
the methodologies of 11179 (part 3) with another mechanism like WS-Eventing
would possibly work but no one has whipped up such a profile or test to
see what a difference it might make.

Adobe’s LiveCycle Platform has had a registry-repository in it since 2003
and we have learned a lot.  ( It also implements several of the patterns
of SCA).  We have not fully explored all the possibilities for reporting
the fail safe state events as customers are not quite there yet but anticipate
this is going to be an area of interest.  If one were to implement
all the patterns for state detection, synchronization, it *could* be monumentally
expensive in terms of bandwidth and processing power.  Alternatively,
not doing it can result in state exceptions.

Registry-repository or some similar infrastructure is sadly needed in the
WS-* and other stacks IMO.  All the major specs are either not complete
or suffering from the same problems they were years ago.  Maybe its
time for a new initiative on this subject?  My gut feeling is that
all the pieces for building a solid registry-repository spec are there,
they just have to be wired together.  I had hoped WS-I might come
up with a basic profile for discovery, search and state management of ws
components using SOAP, WSDL, WS-Eventing, the probe and match pattern,
and other specs.

Thoughts?

D




On 10/8/07 9:30 AM, "Blohm, Henning" <henning.blohm@sap.com>
wrote:

Mike,

 as you point out, retrieval is fast. Scanning artefacts and updating indexes
often create performance problems. Many technologies therefore try to limit
the scope they have to introspect by starting from some well defined scan
roots (actually one of the downsides of EJB3 is the effort needed to scan
classes for EJB annotations).

 It would be interesting to learn about what the EEG is coming up with.

Thanks,
  Henning

---

From: Mike Edwards  [mailto:mike_edwards@uk.ibm.com]
Sent: Montag, 8. Oktober 2007  17:26
To: sca-assembly@lists.oasis-open.org
Subject: RE:  [sca-assembly] ISSUE 8: SCDL artifact resolution
 underspecified

 

Folks, 

I tend to agree with Michael Rowley.  The  assumption that artifacts
are somewhere in the contribution seems a  reasonable 
way of limiting the search  time.   

If the contribution  is large and complex, it will still have to be
scanned by the runtime to  discover all the artifacts that need 
dealing with - implementation artifacts as well as SCA metadata.  
 There are various techniques for handling large 
contributions and making them more manageable.   Examples include
Registries and Repositories which can store  
the information in such a way as to make  retrieval very fast.  There
is an argument for saying that in any complex  SCA 
installation, a  Registry/Repository solution is very desirable. 

As for dealing with OSGi bundles and Java EE  applications, well there
is a group in OSGi looking at that little issue right  now 
in the Enterprise Expert  Group.... 

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 


   
 "Michael Rowley"  <mrowley@bea.com>
 08/10/2007 16:12

 To

<sca-assembly@lists.oasis-open.org>  

 cc

 

 Subject

RE: [sca-assembly] ISSUE 8: SCDL  artifact resolution underspecified
 
 




The key concern here seems to be w.r.t. performance.  In my  opinion, if there is only one definition of an artifact within a contribution  (as I think _should_ be the case), then it should not be necessary for  a human to point at it.  Searching is one of the things that computers  are good at.  Quite a large body of data can be searched in a very short  time.

Michael
   

---

From: Martin Chapman  [mailto:martin.chapman@oracle.com]
Sent: Monday, October 08, 2007  9:48 AM
To: sca-assembly@lists.oasis-open.org
Subject:  [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified  

Logged: http://www.osoa.org/jira/browse/ASSEMBLY-8 <http://www.osoa.org/jira/browse/ASSEMBLY-8>  
-----Original Message-----
From: Blohm, Henning  [mailto:henning.blohm@sap.com]
Sent: Friday, October 05, 2007 8:01  PM
To: sca-assembly@lists.oasis-open.org
Subject:  [sca-assembly] NEW ISSUE: SCDL artifact resolution underspecified  

TARGET: Assembly specification, section "SCA  Artifact Resolution" (1.10.2.1)  

DESCRIPTION: Resolution of SCDL artifacts is  currently specified only as far as cross-contribution export/import is  concerned. As far as QName to SCDL artifact resolution within a contribution  is concerned the specification does not say what is the exact scope of such  resolution nor how to extend/modify that scope.  

Choosing the whole contribution as resolution scope  may be prohibitive considering that contributions may be large and distributed  (across different execution environments) so that deep traversal of all  contribution resources for scdl artifacts may easily introduce a severe  performance problem and easily get out of control from a developer  perspective.  

As an analogy, suppose the group would perceive a  contribution format that would encompass java ee applications together with  OSGi bundles. Chosing a contribution wide resolution scope would correspond to  chosing a contribution wide class loading scheme (which I assume all agree is  highly undesirable).  

On the other hand, if the resolution scope is not  the whole contribution, it is necessary to allow specification of locations  within a contribution.  

PROPOSAL:

- use sca-contribution / import as a means to  implement a namespace -> location mapping also for contribution-local  artifacts  

- support an scaLocation attribute to be used for  namespace -> location mapping from within SCDL artifacts

---

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

--
**********************************************************************
"Speaking only for myself"
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
MAX 2007 - http://technoracle.blogspot.com/2007/07/adobe-max-2007.html
**********************************************************************

---

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