| RE: [higgins-dev] Registry: Need for two, Need for factory config, and cpid format --correction #1 |
|
I made some
errors when I wrote my email. See corrections/improvements in red. From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim, I’ve been
thinking about this problem independently of your email below. Let me share
what I’d come up with first and then relate it to your preferred proposal
#4. I see two kinds
of information “service” and
“consumer” (a) Information about
a service that can serve up a Context and what protocols this
service (e.g. IdAS (e.g. an LDAP backing store, an OpenID
“OP”, or a PeopleSoft database) supports that can be used to access it by a “consumer” (e.g. an IdAS Context
Provider). [Note:
with the xri resolver code that we envision using, there is a way to configure
the “root” service URL so that
this registry can be on the net, on a LAN or on localhost].
(b) Information
describing how to identify and configure a consumer (e.g. a Context
Provider) to gain access to (a). This would include:
To me: ·
(a)-type (service-related)
information belongs in an XRDS document (preferably globally accessible)
discovered by resolving a ContextID [registry #1]. ·
(b)-type (consumer-related) information that is Provider-specific but Context-independent belongs <somewhere, another XRDS document?>, that is managed by “IdASRegistry” [registry #2]
and is looked up by matching
the service <type> from (a). ·
(b)-type (consumer-related) information that is Provider-specific
and Context-specific (e.g. auth materials) belongs <somewhere> and is
looked up by matching a combination of <type> and some or all of the
ContextId itself. Okay, now on to
your email... We’re in
agreement on the need for two registries. You propose
using your new CPID element to bind (a) to (b) type information. Instead of
<CPID> I propose we use the <type> element to bind (a) to (b). The
value of <type> is an XRI that indicates both the protocol to use and the
API of the service. So the values are things like “http://openid.net/server/2.0”
or “http://opensql.org/sql92” that represent (HTTP protocol with
the OpenID API) and (SQL protocol with SQL API) respectively. The new element metamodel (the optional schema) mentioned under (a) above to the
<Service> block will enable a Context Provider to know if it really could
open this Context (i.e. that there really is (or could be) Context data there).
The label could also be useful. You proposed
that (b)-type (consumer-related) information is stored in another section
of the same XRDS document. I don’t agree. The (a)-type information is an
advertisement of services -Paul From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim We came up with a
non-contrived example today of why a context factory would need some config
data. A context provider which produces contexts that are backed by
non-local data may want to build a pool of reusable and/or shared contexts
for purposes of connection pooling and sharing. The pool/sharing logic
makes sense to happen in the CP's factory, and would need to be
configurable. Therefore, we see a need to pass configuration data to a
factory when it is instantiated. Furthermore, we see use cases where an
application might need to adjust this configuration at a later point (I'll talk
to that point later). We looked at
three possibilities of where a context factory's config data might be
placed. 1) It could
be placed with the application (i.e. the application could have a config file
and in that config file, we could list all the config data for all factories
that application might ever use. We didn't like this due to the
manageability problems it would likely create. 2) It could
be "registered" in the "IdASRegistry" along with the
factory that it belongs to. We didn't like this because it precludes the
ability to instantiate multiple instances of a factory, each with different
config data, plus it increases the number of locations which hold config data. 3) It could be
located with the cpid in the context's service element in the XRDS
document. We didn't like this due to the foreseen duplication of config
data across context services. 4) It could
be represented as another service in an XRDS document. It could have a
type like " Imagine something
like (the actual values are invalid made up junk at this point): <XRD> <Service> <Type> <CPID> ... other config data necessary for a </Service> <Service> <Type> <CPID> ... other config data necessary for a </Service> <Service> <Type> <CPID> ... other config data necessary for a </Service> <Service> <Type> <CFClass>org.eclipse.higgins.idas.cp.JNDIContextFactory</CFClass> ... other config data necessary to configure the JNDIContextFactory. </Service> <Service> <Type> <CFClass>org.eclipse.higgins.idas.cp.JNDIContextFactory</CFClass> ... other config data necessary to configure the JNDIContextFactory (i.e. max pool size, idle timeouts, etc). </Service></XRD>Assuming we can
do something like that (I'm pretty sure we can in spite of the way I've botched
up the identifiers), then the work flow would go something like this: - Resolver turns
the cid into a contextSEP. - From the
contextSEP, <something> gets the CPID and resolves to the providerSEP. - Using the providerSEP,
the IdASRegistry can produce and configure an instance of IContextFactory. -- We believe
it's a good idea that the IdASRegistry would only return a single instance of
IContextFactory for any given CPID (which is the <Type> in the
providerSEP). Thus the IdASRegistry would have a table of {key, value}
where key = CPID, and value = IContextFactory instance. - From the
IContextFactory and contextSEP, <something> can produce an instance of
IContext. An existing
IContextFactory instance could be re-configured not by the IdASRegistry, but by
the application at any time via a call to a method like
IdASRegistry.config(XML) Anyway, it seems
there *is* a need for two registries (though I see IdASRegistry as really
just a way to manage factory instances at this point -- so not sure
"registry" is the right term), a need for factory config, and there's
a proposal for a cpid format. On the subject of
what in the " Unless there are
problems with this, I'll try to move the contents of this mail over to the wiki
later. I think it just refines what's there right now. Jim |