I was wondering how can I create a module, which configuration would be external. I mean that not having the module lookup a specific URI to get the config, but in having some kind of injection of the configuration, at module load time.

Is anything like this already experimented by someone?

Hi Laurian,

I kind of see what you are saying. With a resource oriented mindset I believe you can rephrase what you are asking as:

When my module starts up I want it to read a configuration that has been pushed to it by a third party.

Now all modules are bootstrapped concurrently in a simple sequence of 1) construct, 2) link, 3) ready for requests. So it not possible for an active module inject configuration into another still starting module. This sounds like a limitation and indeed it is a restriction but it greatly simplifies and decouples the developed system.

Usually the way to achieve the result I think you want is to have lazy initialisation and when a service needs said configuration it will SOURCE it from a documented URI. The injection is achieved by another module providing a resolution for that URI.

This has the added benefit that the service in your module that requires configuration state can remain stateless and pull it's configuration on demand. So configuration can dynamically change and remember that the cache will ensure that no additional work is done whilst the configuration remains constant.

As an example look at the database accessors and how they always look to the resource referenced by URI ffcpl:/etc/rdbmsConfig.xml to provide configuration.

Points to note:

1) no ordering of startup of modules
2) everything is a resource
3) keep as much stateless as possible
4) achieve indirection through URI references

I've been thinking for a while now that what's really needed is a book/reference on resource oriented analysis and design. Similar to all those object oriented ones that came out in the 90's.

Cheers,
Tony

So, if the module looks up for ffcpl:/etc/rdbmsConfig.xml, can I export this URI from another module?

Laurian,

Yes.

This is a common way to manage configuration information. Let's say you have an application with a Fulcrum (with HTTP transport) - we'll call it "F". You have a module with configuration information "C" (such as ffcpl:/etc/ConfigRDBMS.xml) and you have an application module "A" and a library module "L".

F imports "C" and "A"
A import "L".

If A issues a request for active:sqlQuery which is found in module "L" (mod:db) then active:sqlQuery will issue a sub-request for its configuration "ffcpl:/etc/ConfigRDBMS.xml". NetKernel will search in module "L", then module "A" then module "F" and finally module "C" to find the configuration.

This approach is commonly used in deployments where a system is put on a test machine, the a staging machine and finally the production machine. Each machine can have a different "C" module while using all the same "F", ""A" and "L" modules.

Randy

Great, thanks.

I was looking now on how you actually manage the config.xml in the db module, interesting idea of having a transreptor (ConfigToRDBMSConnection.java).

Hi Laurian,

the example search process to find resources that Randy describes about in his previous post is called "resource resolution". There is a well defined algorithm behind this resolution.

In pseudo code it goes something like this:
1) look at all mappings in the current module recursively traversing any imports
2) if no resolution is found pop to the module of the caller and repeat step 1
3) when the root request (usually from the transport) is reached terminate with a resolution failure exception

There was some more in-depth discussion on the resolution process in this previous post:
http://1060.org/forum/topic/393/1

Cheers,
Tony

Laurian,

Yes, we transrept the database configuration information into a physical database connection pool.

In resource-oriented computing one can focus on the logical level - what happens at the physical level (compilation, optimization, etc.) is transparent and does not interfere with one's architectural thinking.

Randy

I'm having module Foo and Bar.

Foo imports Bar, Foo exports ffcpl:/etc/bar.xml.

When I call Bar from Foo, Bar cannot find ffcpl:/etc/bar.xml

If I test Foo within resource request trace tool, it can find the file, both on internal and external request injection.

Where to dig?

Laurian,

It is not clear where the resource ffcpl:/etc.bar.xml resides. I'll presume module "BAR".

If you issue an internal request for "ffcpl:/etc/bar.xml" in BAR AND you have a <this> entry for the resource, then the resource request trace tool should show the resolution and you should be able to see the resource representation when you request it.

If you make an internal request for "ffcpl:/etc/bar.xml" in the "FOO" module AND "FOO" imports "BAR" AND "BAR" exports that resource, then you should also be able to also access the resource.

Does this help?

Randy

I have the ffcpl:/etc/bar.xml in Foo. Bar is a library, and Foo should provide Bar configuration for Foo purposes.

So, Foo imports Bar, and Foo exports ffcpl:/etc/bar.xml

I thought that a request from Foo to active:bar (exported by Bar), would have Bar on that request be able to load ffcpl:/etc/bar.xml from Foo's "point of view."