Architecting solutions: A better way

Tech Forum - Dr. Nitin Paranjpe

Traditionally, we have been used to one-, two-, three-tier architectures. Three-tier typically includes front-end, business logic and data handling as the three tiers. However, the complexity and interplay between all technologies involved in application design has increased greatly in recent times. Therefore, the original three-tier way of architecting solutions is grossly inadequate to create a fully functional system that utilises all the technology components effectively.

To give you an example, in earlier days the performance of applications was primarily driven by database performance. Even today database performance plays a major role. However, a database is just one of the items that can affect performance. I just tried to make a list of all possible things that can impact performance and slow down the response time.

This just goes to show that the simple architectural division of three layers (or even n layers) is grossly insufficient.

Reuse (what is that?)

Reuse of code and logic has been the buzzword for years. But a real hard look at the amount of reuse within IT companies as well as non-IT companies reveals that reuse is very minimal and primitive, to say the least. The platform is immaterial here. What is important is the actual reuse of code. Very often the architectural phase focuses only on the current project at hand and not the overall picture. We do create the Vision/Scope document in order to document the larger picture. But the larger picture becomes smaller and smaller as the technical implementation goes ahead.

Alternate way

Here is an alternative way of architecting solutions. This architecture is based on the concept of services rather than n-tiers. Software is a collection of services that interact with each other in a pre-defined manner to solve user needs.

To understand this methodology, we first need to get some definitions right.

Services:

Services are:

• a piece of useful code
• which implements some business logic
• is controlled by certain policies
• has a state management mechanism built-in
• communicates with the external world, including other services through messages

Great definition. In effect it could be the good old COM component or a Web service (if all items of this definition are to be satisfied). In simple words, it is a self-contained piece that hides all the complexity within its code and allows others to do some useful stuff programmatically.

Messages:

This is the language that services use to communicate with each other and the rest of the programmatic world. The way messages are to be used is predefined by the service designer. A message intended for a given service destination is delivered by a routing mechanism which is a part of the enterprise level application development and hosting environment.

For example, DCOM was a layer on top of the Operating System which could take a remote request from the remote computer, locate the destination component, invoke the component on the intended server, run the component and carry results back to the remote computer.

Contracts:

The details of how messages have to be managed is called a contract. This includes the format, order of message submission, content definition and anything else that is required to ensure that messages are received and responded to in a predictable manner.

Policy:

This is a set of rules and regulations the services must adhere to. Policies are created and governed by the end user as well as technical requirements. End users will typically define the access control needs, functional performance needs, security requirements, etc.

These policies would be directly based upon the business policies. When we are trying to automate a business process, the process already is running on day-to-day basis. Policies for managing the process already exist. When we architect the automated solution, we need to ensure that all these policies are considered and implemented appropriately.

State:

We have had many debates in the past on stateful and stateless programming. State is a piece of information that needs to be retained within a service for a service request. State is most often stored in databases. State needs to be maintained between shutdown and restart of the service. State stored in memory alone will be lost if there is a mishap. The decision about storing state in one or both of the mechanisms is driven by business needs.

Process:

A set of activities that defines a business process. Each activity has a beginning and an end. Completion of one activity may trigger another or it may just change some state for the business process instance.

Application:

This is a collection of all the above items as well as UI. Some applications may not require a UI service at all.

Services v/s Components

The above description of services will sound very similar to what we used to call business logic components in the COM+ context. However, these are not the same. There is substantial difference between these. The common thought is self-contained functionality with emphasis on the ability to reuse.

However services have some different ways of doing things. I would say, components were thought of as encapsulated utilities. Services should be thought of as small but full-scaled independent applications, which can work with each other.

To highlight one difference, services need some database to manage persistence. Components also require databases. But from a traditional enterprise architecture perspective, a collection of related components would typically use the same database storage. In case of services this is possible but not necessarily advisable. For example, if the service is not integrated with the core application data, it is possible to implement it in a different database, server, location or even vendor.

Thus I would say that services-based architecture is a more matured and far-reaching version of component-based design principles.

The major difference between services and traditional components are the calling semantics. While objects are generally instantiated at invocation and have relatively fine-grained methods, services are usually long running and manipulate large messages. Significantly, service invocation does not imply that an object is instantiated in order to process the message. It is possible to process messages as tokens, or to process specific pieces of the message prior to committing to full processing.

Components were supposed to be written in a stateless manner, whereas services are written to manage state because these are more aligned to business processes.

In short, services are a conceptual (and very often actual) superset of components.

Why take all this trouble?

Even today, it is possible to just go by your skill sets in traditional application design and develop applications using the good old way. Nothing prevents you from doing so. In that case, why take all this trouble to develop applications using the new methodology at all?

The answer is simple. There is no absolute rule that prevents you from doing this the old way. But the way IT works, you will soon be outdated and phased out!

Sounds drastic? Imagine that you are a wizard in Oracle 5. Absolutely great. You know every syntax, feature, optional arguments, flags, utilities, tips and tricks, internals and so on. You are a great developer and architect. You have developed many applications successfully on Oracle 5. Everyone regards you as God in Oracle 5.

Now this position was great when Oracle 5 was the current version. Now it is Oracle 9i. Now, you are still great at Oracle 5. Would you get any job? Definitely not.

But what if you are a freelancer? You could deliver solutions for customers directly. They don’t bother which is the latest version. Yet, would you survive?

What if customers ask for Web-based application? Coding that in Oracle 5 is very, very cumbersome. Someone using later versions may compete with you and deliver the solution at a much cheaper cost, and faster. Thus even if you are great at something that is phased out, the new technology either overtakes you unless you change your ways to understand the new stuff and build the new benefits into your service offerings.

We have to take all this trouble because of the benefits of the new method. There are many benefits—technical as well as business level—that are compelling enough to change our mindset and adapt to the new methodology.

In any case, like every other field of man-made knowledge, progress is incremental. At stage 5, we may feel that the evolution between stage 3 and 4 was so obvious that we should have thought of phase 5 in phase 2 itself. But life is not so simple. We need to make mistakes, even obvious ones, to progress!

Services in detail

Services are the crux of the new methodology of application design. Services do not necessarily mean Web services. Here we are talking more from a conceptual perspective rather than implementation-specific details.

Typically, services provide both the business logic and the state management relevant to the problem they are designed to solve. When designing services, the goal is to effectively encapsulate the logic and data associated with real-world processes, making intelligent choices about what to include and what to implement as separate services. This choice is called granularity.

Because they are designed to be called across a network, services should usually be coarse-grained. That is, services should wrap a substantial body of application logic, delivering value that justifies the latency cost of a network request.

Similarly, services should expose coarse-grained interfaces: rather than exposing many interfaces that each manipulate small amounts of state, services should expose fewer interfaces that allow a single request to perform a complete query or update.

A service consists of four things:

As you can observe, the method of thinking has become more mature than the underlying technology. In fact, it is important to note that the base RDBMS functionality has not changed substantially. However, two-tier, three-tier, n-tier, service oriented and so many other paradigms have changed.

There are two things to learn from this:

We will cover more about services and other pieces of the puzzle in the next article.

About the Author:Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in