From application architecture to enterprise architecture - First steps

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Gabriel Bechara's Blog | November 11, 2006  11:07 AM | Comments (0)

We have proposed different approaches for application architecture using Weblogic Integration in a previous blog Application architecture using Weblogic Integration.

The intent was application architecture of one Workshop/Weblogic Integration application, meaning one unit of deployment (one ear).

In this blog we will be taking the application some steps further, splitting it into multiple applications then exposing some parts using Web Services. Each application exposed as Web Service becoming an SOA building block.

We will be starting from the simple case exposed in Application architecture using Weblogic Integration - Part 2 and moving toward an enterprise architecture thus promoting re-use at the service level.

Let's take go back to the typical case described in Application architecture using Weblogic Integration - Part 2, the case was about having:

-         Two back-end systems one for CRM and one for billing

-         Two groups of reusable processes dealing with business logic

-         A group of long living processes representing business processes

-         A group of processes for handling errors, this group being one of the technical aspects we want to handle

We ended up with this diagram:

Diagram 1

The graphical representations being:

In diagram 1 we had one application containing different projects, the communication between different projects being done using process controls or the message broker.

When adding applications, for example a self services portal and some processes involving human interactions for decision making, we may want to split the previous application in reusable parts, sharing backend accesses with the new applications.

This will lead to diagram 2:

Diagram 2

In diagram 2, if all applications (ears) were on the same Weblogic domain, the communication between them can continue to work using Process Controls or the Weblogic Integration Message Broker.

But in the context of enterprise applications the objective is to be able to communicate between services being deployed on different domains, being eventually in different networks, and exposed as services to be reused from other applications in the enterprise.

Weblogic Integration Processes are naturally callable as Web Services without any other development efforts. On the other hand, Common Workshop controls needs to have a Web Services as a façade; this can be easily generated using Weblogic Workshop.

The case of diagram 2 may seem rather simple; nonetheless in a real context the communication between the different applications becomes quite complicated:

-         The communication is done point to point, therefore the configuration of each application will become very difficult and prone to errors: all the applications must know where to find each others

-         It may become rather difficult to control versioning of the services: all the interactions are dependent on the versions of each service so if the interface of one service get modified we need to change all the clients that access to it

-         There is no easy way to guarantee some SLA when using Web Services

-         There is no easy way to easily monitor the services in a centralized manner

-         It may become difficult to apply security policies; this becoming essential when exposing services for reuse inside the enterprise

-         Etc.

Thereafter, when applications exposing services becomes numerous, communication between them may become chaotic if not federated.

The common sense in today enterprise applications is to federate all communications between applications using an enterprise service bus. AquaLogic Service Bus can be used in this context as a mediation layer between applications giving diagram 3.

Diagram 3

The direct benefits, only to mention some, using a service bus as a mediation layer in our case are:

-         Alleviating point-to-point communications

-         Being able to apply a versioning strategy on Web-Services

-         Guarantying quality of service and offering monitoring for services

-         Handling security policies for accessing Services

And the process of using exposed services in client applications is not as straightforward. Even if you had an ideal XML canonical model exposed by each service you will still need to do some transforms to extract data from a model, representing an entity or a group of entities to another representing another entity or a group of entities. A typical pattern that need to be implemented when getting data from a backend is, applied to an example:

-         extracting data from an account representation, coming from a billing backend thru the access layer that returned the canonical account representation

-         enriching it with data coming from the CRM back end

-         transforming this data so it can be easily used by the application that will do the order processing

This being done each time you need some data by an application in the orchestration layer. Each application on the orchestration layer may have its own requirement since it could be handling a different group of entities. Thereby, after dissociating the orchestration layer from the data access layer, you might still need to do some transforms in the orchestration layer. Depending on the transform it might not be conceptually clean to do this in the orchestration layer; thereafter you may want implement this pattern in the Service Bus.

In a more general manner, applications communication using Web Services is usually done:

-         validating data coming from application 1

-         enriching this data with data coming from another application

-         transforming this data

-         calling the destination application

This is a common integration pattern that can also be delegated to the Service Bus. This pattern is also known as the VETO pattern (Validate, Enrich, Transform and Operate).

On the other hand, the data access layer should be responsible of providing to the upper layers the enterprise canonical model, and this can be automated in numerous cases using data services based on SDO (Service Data Objects).

Implementing the data access layer requires significant amount of custom code and this code need to be maintained. In the context of application architectures, access to data uses some very well known patterns such as DTO (Data Transfer Object), Data Access Object (DAO) for insulating applications from physical data source. This concept, known as separation of concerns, is transposed in enterprise architectures using a data access layer. Conversion of data from a backend to the enterprise canonical model can also be automated and simplified using adequate tools.

In other terms a universal data access layer in the context of SOA, known as a Data Service, for enterprise architectures can be viewed as a backend to canonical XML mapper; the same as the O/R (Object to Relational) mapping tools widely used when building applications accessing databases. O/R mappers are the right tooling in the context of application architecture; a Data Service is the right approach in the context of enterprise architectures.

Using AquaLogic Data Services Platform as an automated data access layer can accelerate and simplify the building and maintenance of an SOA data access layer.

Diagram 4

A larger version of diagram 4 can be viewed here.

Comments