App Services Implementation Design

In the last post, we did an overview of App Services Design Criteria. Now lets consider implementation options for this layer.

Language
One of the important considerations is the choice of programming language. Lets start the discussion with some common, widely supported popular languages: C, C++, JAVA, Python, Ruby, Javascript.

Considering OOP, we can rule out C. Great IDE's are still not available for Javascript, Python & Ruby, so (unfortunately) we can rule out these great languages.

Left are C++ & JAVA. C++ is statically linked (good), complex (bad). Java too is statically linked (good), too simple and verbose (bad). However, the JVM is now becoming a standard piece of infrastructure for other upcoming functional and succinct languages such as Scala.

Also, JAVA has sophisticated framework support like Spring.

Object and Access Design
As discussed before, the desired architecture is RESTful. This lends a simplicity to the external object interface as far as method operations are concerned. A concern is in balancing number of resources so as to allow applications simplicity of query, but richness of behavior.

OOP systems typically specialize on IS-A hierarchy. In a RESTful system, IS-A would be represented with a type field in the data definition. This type field would influence behavior of GET, PUT, DELETE, POST operations.

How would encapsulation of other other (objects) resources work? A RESTful interface only works with one resource (object type or class) at a time. This means that whenever there are two or more kinds of resources, we would need to expose a new composite resource in the RESTful interface.

An example is in order: in a banking system - Users can have Accounts. However, Accounts can have many Activities taking place in them. Activities are a classic encapsulation object, based on a type field, they may encapsulate Users or Accounts. In a RESTful design, we will expose three top level resources:

1. Users: /Users/Sumeet/ will return user details, the type field might have values such as normal user
2. Accounts: /Accounts/Sumeet/ will return account details, the type field might have values such as corporate account
3. Activities: /Activities/23 will return details of activity id 23

Extensibility

Any object definition and behavior can be extended by an adjunct data service. This allows build up of custom object and behavior extension API.

Multi-tenancy

Custom objects/ behaviors can be specialized per tenant. For example, an important enterprise customer might additional fields to a given data object.

Deployment

Since this layer is stateless, all business objects can be located within a single container. This allows objects to easily and efficiently communicate to each other.