Enterprise applications with plugin architecture, SaaS or otherwise

2. 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

3. The 2 nd 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 needs to 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

4. A hybrid of the two approaches may be nicer Because 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.

5. 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

6. 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.

7. What sort of contributions does the core expect ? PostCreate, PostSave, PostDelete WriteLog, DoAudit, DoExport, DoImport GetPermissionEnvironment, 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.

8. 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

9. 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

10. 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...

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