Plug in style architecture for enterprise applications

Approaches, exploration of some details - by Kinshuk Adhikary

A plugin approach to building enterprise applications helps in many ways

To plan properly and deploy small “plugin” applications around a “core”

As and when the smaller applications are budgeted, conceived, and completed

Makes distributed development easier, i.e. not a monolithic model

Changes can be isolated, implemented, tested and deployed

Retains a sense of “core” i.e. centralized rules and knowledge and control

With enough flexibility flowing over to the federated “plugins”

Plugins can align with the organizational structure, depts, regions, partners etc.

Some of the terms used here are Eclipse style – see eclipse.org

There are two approaches – one, the master center

The core is aware of the life-cycle of plugin objects

CORE – a repository of ALL common

concerns

PLUGIN app, say HR

Core is made aware whenever the plugin creates a new object, say Person

AOP or other instrumentation can be used to communicate from the plugin

Core uses this knowledge to update its identity store, ACLs or other KBs

In extreme scenarios, core can even influence object creation, but this is NOT recommended

The 2nd approach – one ring rules them all

A non-intrusive core that mostly supplies knowledge (I like this one ! )

A little difficult, it entails “giving up the appearence of centralization while retaining the core of it :-)”

CORE – is mainly a rules

repository, a knowledge base,

and a few common concerns Plugin proxy

#2

Plugin proxy #1

New plugin or legacy app # 1

New plugin or legacy app # 2

HTTP style messaging- via integration medium

Every object in the proxy apps has “request scope”

It only receives and processes just as much info as the core needsto process a KB

The core has one main responsibility – to supply an answer if asked a question.

It may insist on being kept aware of other minimal things, to build its own KB

It can also do things like keeping audit trail

Each app is pretty much independent, unless the core has something better to offer

A hybrid of the two approaches may be nicerBecause an enterprise is too complex a noodle to unravel easily

Familiar with this kind of an enterprise diagram ? If not, you soon will be, give it 5 years of IT success.

Central HR

The CEO dashboard

Sales and CRM

Accounts

Document management

Tech or domain apps

Dept # 1

Time/issue trackers

Data vendors

Vendor locked ERP

Region # 5

Project management

Real time factory apps

Partner vendors

Management

Users

A PLUG-IN approach may resolve this problem somewhat.

An ESB may not, esp. if all the noodle goes into the ESB.

Minimal plugin responsibilities

It must decide which of the core's interfaces it needs to implement to integrate itself sufficiently to the core, in addition to mandatory ones

It has to declare itself to the core as a valid plugin

It has to implement the interfaces extended by the core (contribute to the extensions)

It has to submit a list of such “contribution points” corresponding to each “extension point” it integrates with in the core, i.e. which classes in the plugin implement the core's mandated interfaces

It may have to call-back the core on create/update/delete of objects, via interceptors

It may have to seek “answers” from core on permission, security, workflow etc.

It may want to substitute the core's default resources as far as where this plugin is involved – by supplying a set of “features”

Contributions by plugin

Other extensions implemented

Call-back to certain core methods Plugin local data and logic

(optional) – a list of “features”

Contribution points list

Responsibilities of the core

It must decide what kinds of behavior it can extend to make plugins work better

It has to pick valid plugins on every start-up

It has to call the plugin's implementations to enforce required behavior

If the plugin supplies features (resources), then it has to substitute those

It may have to maintain identities of objects

It may have to maintain ACLs and supply permission flags on request

It can also maintain higher level logics/rules about the interactions between various plugins and plugin objects – for example Person with Vendor

The design of the core is really the heart of a well designed plugin-style application set.

What sort of contributions does the core expect ?

PostCreate, PostSave, PostDeleteWriteLog, DoAudit, DoExport, DoImportGetPermissionEnvironment, GetObjectMetadata, GetObjectTree etc etc.

Basically, any method that “will be implemented by the plugin but will be called by the core”.

On a higher level...

The plugin must supply the data to implement object identity, object security, logs, audits

Other plugins when calling this one would only use some specified implementations and go via the core etc.

Resource sharing considerations

Both the core as well as the plug-in may need to deal with the same resource.

So, it is a good idea to split the resource (object, database row, file etc.) into some parts

MetaData – for use mainly by the core and maybe by other plugins

Data, (fat) - for use mainly by the plugin and rarely or almost

never by the core

The shape of most business related objects would be something like the one at left

IdentityData - for use by everyone

Build, test and distribution considerations

The core can be a single build

The individual plugins can be separate builds

A combination would have to go thru automated tests for validity etc.

In general, creating a good test bench is a good investment and makes distributed design and development easy

Licensing considerations

For SaaS type apps, this can be quite important

The plugin approach makes it possible to introduce pay-by-plugin licenses

Design and analysis considerations

What is the least, the absolute minimum the core ought to actually do ?

To do so, what would be the least expectations from any arbitrary plugin ?

Can useful plugin's be classified, by behaviors they (the plugin's) will exhibit ?

What common utility does the core provide for each such class of plugin ?

What therefore are the extension points the core extends to each class of plugin ?

Will the core get more “loaded” as more and more plugins get “added” ?

Others...

THANKS,

To discuss please feel free to email at kinshuk_in@yahoo.com