sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: Duane Nickull <dnickull@adobe.com>
- Date: Tue, 9 Oct 2007 09:46:00 +0100
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
<sca-assembly@lists.oasis-open.org>
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]