Architecting solutions: A better way - II

Tech Forum - Dr. Nitin Paranjpe

When DCOM was introduced it was called COM with a longer wire (network accessibility). Now, we can call service-based architecture a longer wire that is now generic so that it can work across platforms.

These services possess certain characteristics:

Unlike DCOM, these are platform independent
To permit integration across diverse systems, services must use platform-independent representations of data and support a platform-independent approach to accessing application logic. Earlier, in DCOM days it was necessary to know the method call (function call). Now it is only messages. That makes it simpler to use services across platforms.

Why take so much trouble? Because business conditions today demand that various organisations require heterogeneous systems to communicate with each other. Batch processing is simply not feasible, unlike older days.

Based upon widely accepted interoperability standards
Earlier we wrote applications and then thought of putting in additional effort when the need for integration arose. Even this code was written on case-to-case basis. Now, why not assume that interoperability will be required and write business logic in a manner that is already compliant? Saves a lot of time and reduces complexity.

Now interoperable standards are required at various levels. One is about how to communicate the content of the messages. The other is how to transmit these messages across the Internet/intranet, which requires some wire protocol.

Now anything flowing across wire is exposed. So we need to manage security also. To avoid writing additional integration code, these services are based on:

In the DCOM context, the component and the remote client communicate using a proprietary protocol. Other than the communication required to call business logic and return results, we required a lot of other ancillary things. These included functionality like logging, security, load balancing, event management, auditing, queuing, transaction management, pooling, etc and was managed by add on features.

All these ancillary things also require some information about your business service call. Let us call this information metadata. Using the services architecture, it is now possible to package the metadata as well as the application specific data in a single message format. The header contains metadata and the body contains application data. This is what is achieved using the SOAP specification.

Different concept of granularity

Granularity means the level of detail of individual component functionality. During the DCOM days we were taught that we should expose all the business functionality at fine levels of granularity. It was recommended that the nuances of business logic should be exposed in the component model. This way, each business functionality can be called independently and quickly. This was fine while the component invocation was restricted to high speed LANs.

Now the world has changed. Everything needs to be available across the Web. Even internal applications need to be available across the Web. For example, ‘sales force automation’ requires cyber-café compatibility. The Web inherently provides lower bandwidth. Moreover, connections are intermittent. The overheads of making a connection, authentication and two-way data transfer are very high.

Therefore, we need to manage the granularity in a different manner. The aim is to reduce the number of server requests. Therefore, it is now preferred that we make a single request more fruitful. It should request a set of business activities to be performed in a single call. This is called ‘coarse granularity’.

This does not mean that we have to change all our design principles from fine to coarse granularity. It only means trying to call a service with a lot of work to do in a single call, assuming it makes logical business sense. Once the service is called, it can, of course, call internal components that will be fine-grained ones.

Moreover, calling a service functionality may not invoke components at all in certain cases. This is because, there could be some ancillary things being done before invocation of the business logic. For example, it is possible that the service first checks the base authentication, the access control and so on. If any of these fail, components containing business data may not be called at all.

Service agent

When all applications start exposing functionality as service, there will be a plethora of them. How will services interact with other services? In fact this functionality itself is a service. This service is called a service agent.

Service agent provides:

Services do not share state management

This is one important concept that differentiates traditional components from services. The services also manage state and to do that they need to manage the persistence of their data in a database. Thus, a service knows how to manage its own data. Each service can potentially have its own database.

This is a bit confusing here. If you remember, the components in a typical DCOM-based application would generally talk to a single database. In this case the reuse of the component was restricted by the database itself. In case of services, it is not prohibited to share the same database. But the implementation should be independent.

For example, if a service needs to be moved to another database (because the size grew too much and we need a separate server), it should be easily manageable.

This way, you are building for reuse from design stage itself. Earlier reuse was more at the component level. And components were expected to store as little state information as possible. Due to this the real reusability of the components has been limited.

By making services manage their data independently, it is easily possible to start with a system that could be working with the same data and same server and then scale out to more specialised infrastructures as requirements grow/change. Moreover, if some functionality that was being met with by an internal service is now available from an external agency at an attractively lower cost, you can simply switch services to incorporate new functionality.

This leads us to the most important practical benefit of the services-based architecture.

Using this architecture, you are designing for integration with even those systems/platforms that are not even built as of now.

This is where the long-term benefit really comes from.

Loose v/s Tight coupling

This is another bit of jargon. For ease of understanding let us call coupling as ‘hard coding’. Tight coupling means a component depends on one or more components, and also on a particular hardware/software infrastructure. If any of these changes, the base component needs to be changed, recompiled and redeployed.

Most of the work we have been doing in the DCOM days tends to be tightly coupled. Due to this changes are costly and time consuming.

Moreover, all the design was based upon thinking within an organisation. If the functionality has to now communicate with another system outside the organisation, it would always require a code change and redeployment.

As you must have understood now, almost every concept associated with traditional components has got reversed with services-based architecture. This applies to coupling also.

The idea is to implement ‘loose coupling’ in the services architecture. Loose coupling makes it possible to have each service run in an independent manner while providing the capability for communication from/with other services. Therefore, making changes within the service is easier and cheaper.

What could those changes be? Here is a list. While reading this list, try to apply your imagination and think of how you would have handled this in the older component era.

In all these circumstances, loosely coupled architecture is more manageable than tightly coupled.

In short, for each functionality in your application you have to decide whether to use the loose or tightly coupled approach. The decision will depend upon the interdependency of functionality. For example, an auditing functionality that could be called from any part of the application should be loosely coupled. On the other hand, if you have a component that is used from a very specific related component, tight coupling between the components would be preferred.

Does it justify the additional cost?

Designing/redesigning applications using these methodologies will take additional time, energy, manpower and of course cost.

Most companies and project teams are always running behind schedule and have tough deadlines. In fact the IT industry makes lots of money by providing services based upon application integration, where the original applications were not written with integration in mind!

So why should organisations waste additional time, which can actually reduce the revenue potential? It does not make sense at all.

Here are some compelling advantages that justify this additional effort in designing applications that are service oriented.

Which tools do you use?

Well, we discussed a lot of theory. But fortunately, all this is feasible and practical to implement today.

If you are developing a new application, especially on .NET you already have most of the tools required. Visio is a good CASE tool to use for the application design. Web services are implementations for creating services for business logic for your applications.

One word of caution. You should not convert all business components to Web services. Apply discretion. Compare the advantages and disadvantages and then take a call. When not to use Web services is a skill that is equally, if not more, important than knowing when to use it.

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