Layers
Today I would like to talk about the architectural pattern called layering. Also known as n-tier architecture.
The layering architectural pattern is a common pattern when implementing a Java CAPS solution. In fact, the product Java CAPS itself is built with this architectural principle.
So what is the purpose of designing layers? Why bother? Layering gives the advantage that each layer abstracts a level of complexity from its previous level. the higher the level, the less complex a view of the implementation is given. Thus giving an overview of the whole implementation. if more detail is required, you can drill down the layers for the information.
A simple example of a layered architecture is to pick up a text book (Which has 2 or 3 layers).
The top layer is the table of contents. It gives concise information of what is contained in the book, but does not give any detail.
The second layer is the chapters in the book. This is where most of the details are kept.
The third layer (and I'm pushing it here : ) ) is the references used in the creation of the book. These could include articles, or even other books themselves. They may contain even more detail than described in the original.
This probably isn't a great analogy, but I'm trying for an example outside of computing.
A better example (within computing) is probably the network layer architecture. (I'm simplifying this to make my point)
The lowest layer, the physical architecture, is the cabling, hardware (routers, hubs, adapters) and the electrical impulses to make networking work.
The second lowest layer is the communication layer. The electrical impulses are interpreted into 1's and 0's that a computer can understand.
The third lowest layer is the transport layer. For example TCP/IP, NetBEUI, NWLink etc. These are the building blocks used for the next layer.
The fourth lowest is the protocol layer. For example, HTTP, FTP, JMS etc.
As you can see, each layer abstracts the complexity of the lower layers from the upper layer. When we communicate over a network, we do so with HTTP, FTP etc, the highest layer. Its possible to use lower layers, but they become more difficult to implement.
Now hopefully you have a basic understanding of what layers are.
How is this implemented using Java CAPS?
Implementing Layers in Software Architecture
Well, lets start off with a diagram.
The lowest layer, you have your external applications you are trying to interface with. These could be Oracle, SAP, File systems, legacy systems etc.
The second lowest layer, the Technical Service Layer. This is where you build your interfaces to the external systems. This is in old terms the EAI (Enterprise Application Integration) layer. In the old EAI days, interfaces would link with each other and exchange data and this would be the only layer used. In some instances, this may still be the case in modern architecture. It all depends on your requirements.
This layer in Java CAPS is traditionaly implemented using Java Collaborations (JCD's).
The third lowest layer is the Business Service Layer. Here services are developed that are more inline with business functionality. This could be services such as "Get Customer Details", "Get Sales Order Number", "Email Customer", "Print Letter" etc. As you can see, these are specific service names. These services, when called will interact with the outside world via the Technical Service Layer.
This layer in Java CAPS can be implemented using either JCD's or BPEL (Business Process Execution Language) depending on the requirements.
Both the second and third lowest layers together could be considered to be the ESB (Enterprise Service Bus). Services are exposed ready to be used.
The fourth lowest layer is the Business Process Layer. This is where everything is described in Business Functionality terms. For example, "Process Sales Order", "Send Message to Customer". The whole idea here is that everything is in business terms and can be orchestrated to suit the business. This layer "orchestrates" the services built in the lower layers. Its also the layer that holds "state" which is which stage in a business process the transaction being processed has reached.
This layer is traditionally only implemented in BPEL, although I have seen it implemented in Java using a database to hold state information.
The final top layer is the visual or presentation layer. Here information is presented either through web pages or external applications. This presentation layer could range from web pages, to graphs, display screens etc.
This layer is essential for the term "Composite Application". In this layer, a front end to an application can be created where the application is completely composed of other external/third party applications.
This may look familiar to some of you as its the SOA (Service Orientated Architecture) approach to Enterprise Architecture.
The layering approach does not necessarily have to be limited to this design. You can implement as many or as few layers as required, so long as you use good architectural principles.
So why layers? Well, if done properly, it allows orchestration of existing services at a very high level (The business process level) thus giving agility to business changes and better re-use of existing components, which in turn makes development in the long term cheaper. It also reduces the complexity of the system as a whole, making it easier to manage and operate. Thus reducing maintenance requirements.
Rules and Guidelines when using Layers
There are several rules and guidelines are good practice to use when designing/developing a layered architecture.
- Each layer should be distinct and should only communicate with the layer above or below. Never skip a layer.
- Requests/Responses do not have to go through all layers. If a certain layer can service a request, then let it.
- No components should spread over more than one layer.
- When designing your layers, its best to use the black box principle. If a service is to be called from one layer to another, the calling layer does not need know about the inner workings of the callee layer. It only knows the interface and what it is suppose to do. Not HOW the service operates.
- Adjacent layers should be decoupled from each other in terms of protocol, data format and messaging. Where possible use standard protocols and data/message formats. These do not have to be public/open/known standards, they could be your own companies internal/properietry standards, but is is preferable to use public/open/known standards.
- Have an error handling strategy
- Handle errors at the lowest layer possible.
- Its best to isolateand handle errors separtely to the functionality of the system.
- Document your interfaces between layers, that way they are better re-used.
Conclusion
Layering architecture does increase the
amount of work done initially, but can reduce the amount of work
required in the long term as changes and updates to the system are
performed. Lets face it, systems are rarely stable (in terms of
functionality – they are always changing) in the enterprise. Even
specifications change during the development phase.
This architectural approach takes a big problem and breaks it down to little problems in a standard manner making the whole system easier to understand. This helps in design, development, testing and maintenance of the system which surely must be good
Posted at 03:14AM May 07, 2008 by Holger Paffrath in Sun | Comments[0]