Service Oriented Architecture

Types of Application Architecture

Traditional

Applications have always been built with some sort of architecture.  Traditionally, the application architecture consisted of a monolithic system where the data access, business rules, and user interface were combined into a single program.
 

This type of approach worked well for many years, as long as the system resources were carefully controlled and all developers used the same programming language and techniques.

With advent of the personal computer, the same types of monolithic applications were being built, but in an environment which was less controlled.  Developers used multiple programming languages that were easier to program.  These same developers were less disciplined and did not adhere to a standard structure or follow best practices.

The end result of the traditional architecture was minimal reuse of existing code.  The platforms had no support for components and reuse was achieved by source code sharing.  Additionally, there was no separation of the logical layers in the application (data, business logic and user interface).  Each layer was compiled into a single deployable unit.

Some problems with this type of architecture include:

•    The application functionality could not be reused in another application

•    As the application grew, it became increasingly difficult to debug and maintain

•    Security was hard to enforce due to a lack of separation between the user interface and the business logic.

•    Integration was impossible or difficult at best because the business logic was not buried within the application and not accessible.

•    Scalability was limited because all code had to execute on the same machine

A different type of application architecture was required for software developers to achieve increased productivity and for systems to achieve reusability, maintainability, and scalability.

Component-based Architecture.

The component-based architecture was the next evolution in application architecture.  This involved building systems in a layered approach with a data layer, data access layer, business layer and presentation layer. The data access layer included all code and logic which accessed the data.  Many systems packaged all SQL statements in a data access layer to isolate database schema changes. The business layer consisted of a domain model and/or services which encapsulated the business rules of the application.  In a distributed system, the business layer usually was deployed to an application server. The presentation layer consisted of all user interface related functionality.  This includes web-based interfaces and rich windows-based interfaces.  Other application types, such as console applications can also be considered part of the presentation layer.

On Windows, Microsoft provided a component infrastructure called COM.  Other platforms supported an industry specification call CORBA.  Both COM and CORBA provided a similar concept, in that developers could share code across applications.  Java and the J2EE specification also have a component-based architecture.  The main benefit was that systems became more robust, scalable, and maintainable.

Some problems with this type of architecture include:

•   Component implementations are tied to a particular language or technology.  Both COM and CORBA provided mappings for different languages, but the interoperability and support across languages was not fully compatible.  Java components could only be accessed by Java clients.

•   Components could not be shared across heterogeneous platforms.  COM components were not compatible with CORBA or JAVA components and vice versa.  Further more, within the CORBA platform, each vendor implementation was not compatible.

•   Components could not be accessed through a firewall.  With internet connectivity and broadband access, business to business connectivity is required for integration between systems.  The component technologies and associated network protocols were not compatible with network configurations and firewalls.  Each technology, COM, CORBA, and JAVA was built upon proprietary protocols.

•   Components and calling applications were tightly coupled.  In order for a calling application to invoke a server component, the calling application must know the component interface and methods.  A proxy object, compatible with the server component and programmed in the same technology, must be used on the calling application.  This shared code leads to tightly coupled systems where a change in the server dictates a change in the client.

Component-based architectures allowed developers to build extremely scalable and distributed applications.  But the underlying component technology did not adhere to industry standards and forced vendor lock in.  

Furthermore, the lack of interoperability between different component technologies hampered the business-to-business integration scenarios required in today’s internet based business environment.

Service-oriented Architecture

Service-oriented architecture, or SOA, is the next step in the application architecture evolution.  In order to solve the problems with today’s component-base architectures, we need to architect systems that expose business logic in a well defined way, adhere to industry standards, and do not require any specific implementation or technology by the calling application.

In other words, we need a mechanism to wrap the business objects and provide a well defined access point for calling applications.     

A service-oriented architecture is layered just like the component-oriented architecture.  It consists of a data access layer and a business layer.  The presentation layer exists, but is not part of the service-oriented definition.Additionally, a service-oriented architecture contains a well defined service interface.  This is the access point for all external calling applications.  Each method on the service interface has a single, well-defined input parameter and a return type.  The service interface method supports a request/response metaphor. The service interface is responsible for controlling access to the business layer.  Any applications or other services calling the service interface do not have access to the business layer.  This provides a loosely coupled architecture – the service’s implementation can be changed without requiring any changes on the calling application.

A service-oriented architecture solves the following problems:

•   The service can be deployed to any type of machine.

•   The service can physically reside anywhere on the network

•   The service can be developed in any language.

Definition of a Service

We have defined what a service-oriented architecture is, but what exactly is a service within a service-oriented architecture?

A service can be defined as a software system that:

•   Corresponds to a real-life business activity ( placeOrder or submitClaim )

•   Is the interface for a business function or functions

•   Is usually discoverable, but not always

•   Has a well-defined interface, which is exposed through some sort of contract

•   Interacts with other services and components using loosely coupled, message based architecture and asynchronous or synchronous access models

•   Uses industry standards for communications

•   Provide interoperability

•   Is up and running all of the time, versus a component that must be instantiated

Benefits of a Service-Oriented Architecture

Applications are complex to design and build.  Businesses need software to be agile and flexible to ever changing business requirements.  Businesses need software to interoperate with other businesses software. 

Today’s component-based architectures cannot provide this flexibility and interoperability.  Service-oriented architectures, on the other do, provide a flexible and interoperable solution for the agile business.

Service-oriented architectures provide additional benefits by:

•   Encapsulating complexity – systems are hard to build and very complex.  SOA provides the mechanisms to hide the complexity and provide a simple well-defined interface to the business logic.

•   Providing location independent code – the service can be located anywhere on the network on any machine.  Additionally, the service can be written in any programming language.  The client does not need to know how the service was implemented and what language was used.

•   Allowing developer to focus on specific issues – service developers will be concerned with things like transactions and messaging.  The client developer only needs to know how to invoke the service.

•   Allowing parallel development – once a service interface is defined, the service can be implemented in parallel with the client application.

•   Providing support for multiple client types – different types of clients can access a service.  As long as the client is network aware, it can invoke the service.  Clients can be web-based, windows-based, console-based, or pda-based type of applications.

•   Providing a standard place for implementing security

•   Increasing re-usability

Conclusion

This article defined as Service Oriented Architecture and how it is different from other types of systems. The next few artciles will try to slice and dice .Net and look at issues and options involved in developing systems today that can be enabled as services.