Using a Common Architecture for the Services Product Line

November 20, 2009

I introduced the data services product line in earlier posts here and here. As  a follow up I wanted to set the context for a common architecture for this product line. The idea is to have all products in a services product line need to share the same underlying architecture. The common architecture enables the development of a set of common software components and also facilitates variation management, product configuration, and consistent behavior across all the services.

The architecture typically consists of both domain agnostic technical assets and domain specific assets. The domain agnostic assts includes logging, error handling, auditing, metrics, and legacy service invocation modules. The domain specific assets includes data assets, relationships, domain events, and business process workflow components that get triggered based on rules. The common architecture also provides components to integrate with the workflow engine, initialize business processes, as well as provide approval, routing, and escalation steps for any kind of enterprise data entity.

The architecture needs to be reviewed to ensure that it meets the product line’s non-functional requirements such as availability, scalability, and runtime performance.  For instance, supporting high availability can be tricky when data repositories undergo scheduled maintenance on a periodic basis. Scalability is also a key quality attribute that needs to be addressed by the architecture where the need for connection pools, thread pools, and messaging session pools are extensively utilized. Additionally, the architecture can provide caching capabilities for most accessed data records as well as integrate with a lightweight rules engine for fast and efficient rule execution.

Data visibility is another key capability that the architecture needs to address – it can do so by providing an extension point in the processing lifecycle to integrate visibility logic (e.g. filtering attributes, masking data, or utilizing a third party authentication service to validate the identity of the caller etc.).  Ability to assign priorities to jobs in the processing queue based on SLA needs is another feature that could be provided by the common architecture.

Finally, the architecture needs to support several utility features: manage connectivity to each data source, allocate dedicated processor threads based on message volume, and monitor the health of each integration point outside the data service logic. The common product line architecture can potentially address both domain agnostic & domain specific needs.

In a follow up post, I will provide more detail on each of these capabilities and how they align with an agile software reuse approach.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

Create interfaces from a product line context

October 20, 2009

If you ask developers about interfaces they typically build you will hear some form of create, read, update, and delete (CRUD). CRUD-type interfaces are simple to understand and are intuitive. They tend to be used heavily in the data access layer operating on your various data entities. At a high level these interfaces seem to meet your product line needs. This may not always be the case though! Why do I say this? The interfaces you create for a product line depends on the variations you need to support and manage. Variations will require interfaces that vary in granularity. Some operations might operate on a data entity while others might operate on an aggregate. Still others might operate at a subset of a data entity. For example, say you develop solutions for the banking product line where in you have an online portal, mobile bank, and branch services. All these products in your product line might support money transfer. Online portal might display a complete set of from and to accounts while mobile might display only a primary account. Branch might provide only accounts eligible when initiated by a branch. To address the variations you have to go beyond just getting the right set of accounts and have a reusable asset use a mechanism to access and execute business rules.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

%d bloggers like this: