SOA Without the S, Part II: Shared Application Module Instances

Last week, I talked about ways to get many (though not all) of the benefits of service-oriented architecture (SOA) without the overhead of web service invocations by composing your applications out of smaller reusable applications. This week, I’m going to talk about a way to get a different subset of the benifits of SOA (without web services) in ADF 11g, using shared application module instances.

Shared application module instances don’t do quite the same thing as reusable applications. In particular, they don’t provide a controller or any UI; they just provide a reusable data service. And, since a shared application module instance is just a specialized instance of a regular application module, they can only be “composed” in the sense that any application modules can be composed, via nesting.

However, it has a lot of features in common with a reusable application or a web service:

  • You can use the definition for the shared application module again and again, in a variety of applications (like any application module).
  • You can use it to retrieve data, or to pass in parameters and retrieve values (or structured data)
  • You can develop its definition independently of other “services,” maintaining only a constant interface, seriously reducing risks from change and source control conflicts.

In addition, a shared application module instance lets you do one thing that a reusable application doesn’t. Separate instances of the objects that make up a reusable application must exist for every user of every application that uses it. By contrast, you can create an “application scoped” shared application module instance, which allows a single instance of all relevant objects (and the application module’s connection) to serve the needs of every user in the application.

You can also create a “session scoped” shared application module instance, which is really just like a top-level application module instance, except that you can use it to provide lookup data for a separate top-level application module instance via view accessors. The only reason to do this (rather than creating a nested application module instance for lookups) is if you actually need the lookup data to come from a separate transaction.

What I’d love to see, which alas isn’t available in 11g (at least in the current preview), is a process-scoped application module instance. This would create one instance of the shared application module per process, to serve the needs of sessions from multiple applications that are using that process. That would be even more SOA-like. But application-scoped instances are still a potentially highly data-saving option.

Creating shared application module instance is described in Chapter 10 of the Fusion Developer’s Guide for Oracle ADF, as is their primary use, containing view object instances for lookups, to be used in validation and LOV attributes. So I’m not going to talk about it here; the description is perfectly adequate. If you want to create an application-scoped lookup for a LOV attribute or LOV validation, go read that.

Instead, over the next couple of weeks, I’m going to talk about using shared application module instances, and the shared data they contain, for other purposes, which, so far as I can tell, isn’t documented at all.