JADE Environment Development Ideas

The concept of an application context was introduced with packages. When a process is initialized, in addition to the main process application, an application context is created for each application associated with an imported package.

The implementation of this uses a recursive approach, where imported packages may have other packages into their schema which also need to be initialized, which can ultimately result in common packages being initialized multiple times.

In principle, this works fine for basic scenarios, but in my experience limits what we're able to do with packages for a couple of key reasons:

- We cannot initialize a package/module once and reuse it across all schemas importing it.
- It assumes applications are always configured/run in a way that's synonmous with package dependencies.

To use a real-world example,

We have a 'workflow' system, which was implemented using packages not too long after they were introduced with the goal of reusing it in other contexts.

This exposes a package via which business processes/activities can be kicked off in various ways, as part of which an object from the client schema is supplied (implements an interface), with which any workflow item created as a result will be associated.

Workflow items may be manual (goes into a workflist for users to action) or automatic where hooks are called in the client schema to perform a predefined function. Regardless, there are hooks called in the client schema at various stages of the overall process - all of which need to be called in the client schema application context.

As you might have already guessed, workflow has it's own server application that handles the scheduling of workflow items - But it's also become responsible for a lot of other automated processing that we've been able to shift from the workstation to the server.

In order for this to work - We had to define & run the workflow server application from the client schema via the package, as this was the only way for us to have all application contexts initialized/available for automated processing which invokes client schema methods.

This defeated our original goal of having a reusable package, that could be plugged into any schema in order to have a common workflow system. While we could run a workflow server from the context of every importing schema, this is a work-around and we'd have to redesign the data model and how the processing works to accommodate high-level seperation by importing schema(s).

Going forward,

- We need is a way of getting an application context for a schema/app directly, initializing it if it doesn't already exist.
- For general start-up, the same principle should apply, there should only be one application context for each schema/app needed for an imported package.

This approach will provide the ability to use application contexts independently of packages, but whether it's with packages or superschema frameworks - It means we'll be able to create applications where 'exporting' schemas will be the main process with them optionally loading/using functionality schemas which implement interface(s) that have either been imported or inherited from a superschema.