As the next step in the architectural evolution, service-oriented architecture captures many best practices of the architectures that preceded it. Taking into account the number of existing systems and investments made by the industry in them, any new architecture should leverage and improve upon existing infrastructures and shouldn't discard any part of these infrastructures. This is really the essence of SOA; it aligns the existing technical infrastructure closer to business.
 |
| Figure 1 -illustrates a logical architecture for a system based on a SOA. The layers in blue are the existing tiers of an N-tier application architecture and the remaining are the SOA-specific layers. The combination of infrastructure service layer, business service layer and the service composition layer is also referred to as the service layer. |
As depicted, the SOA-specific layers are additional layers sandwiched between the existing tiers of the current architectures. The layers in the diagram are stacked in standard manner, based on usage. The top layers use the services of the bottom layers to satisfy requirements and the functional expectations from the layers above.
Non-SOA-specific layers: Existing layers
Every business's IT infrastructure has systems built in various architectures and methodologies. The systems can be Web-based, desktop-based, pure backend systems, or any other kind of application. The entire exiting system infrastructure can be broadly classified into three tiers: data tier, business tier and presentation tier.
Enterprise data layer: Data tier
The enterprise data layer is the enterprise's datastore. All data requirements for successful business operations are part of this logical layer. The data includes database information, file systems, hierarchical directories, legacy storage systems and all other storage media. This layer is the data tier of the traditional N-tier architecture.
Enterprise business layer: Business tier
The enterprise business layer consists of the business applications (and logic) that exist in the enterprise. It includes applications (and logic) developed using .Net, Java Enterprise Edition, and various other technologies. The logic in stored procedures is also part of this layer. In short, this layer is the enterprise's existing business backbone and the traditional N-tier architecture's business tier.
Enterprise frontend apps/channels: Presentation tier
All business front-end applications and channels are part of this third layer, including the entire desktop and Web-based front ends that work with the enterprise backbone. The business channels include external business-to-business interface systems like dealer access systems and address verification systems. This layer constitutes the presentation tier of traditional N-tier architectures.
SOA-specific layers
Before delving into the SOA-specific layers, considerable understanding of a business process and its constituents is necessary.
Figure 2 illustrates a simplified block diagram of a business process. A business process is a series of business tasks tied together. Each business task accomplishes a specific business step in the whole process. For example, "validating account number" and "checking account balance" are business tasks in a "bank amount transfer" business process.
 |
| Figure 2. Simple business process. Click on thumbnail to view full-sized image. |
A set of business tasks can be grouped together based on the coupling of their usages. Such a group can itself be considered a business task, referred to as a composite business task. For example, the "transfer funds" business task is a composite business task consisting of business tasks "debit source account" and "credit destination account." The composite business task provides a reusable group of business tasks.
All the individual business tasks along with the composite business tasks form the complete business process. For example, "bank amount transfer" is a complete business process with steps like the ones mentioned above.
With this background of business process and business tasks, let's look into the SOA-specific layers.
Infrastructure service layer
Non-business functionalities such as logging, auditing and provisioning can be exposed as services. Such services are referred to as infrastructure services and do not contain any business logic. Pure data-access services are also infrastructure services; they merely expose the underlying datastore as a service. This layer is also referred to as the functional services layer. Infrastructure services are built on the existing enterprise data layer and enterprise business layer.
A service that authenticates a user, taking as input the username and password is a good example of an infrastructure service. Such a service can be the backbone of an enterprise's security setup — authenticating users from disparate systems against a single user registry. This allows the user to work with one set of credentials on various systems. In addition, such a service would aid in the implementation of uniform security policies across systems.
Business service layer
Each business step in a business process can be exposed as a service, which is referred to as a business service. The "validating account number" and "checking for account balance" tasks referenced earlier are business services in the banking business. The granularity of a business service is determined by the business task it implements. The business service layer builds on the existing enterprise data layer and enterprise business layer.
Service compositions
A service implementing a composite business task (mentioned above) is a service composition. "Transfer funds" is a service composition of "debit account" (source) and "credit account" (destination) business services. Composite business tasks provide a layer of abstraction, hiding the details of the constituent business tasks. For example, it's immaterial to the user of "transfer funds" composition whether the account is credited or debited first. In addition, new services like a "transfer notification" service can be introduced transparently without a change in the "transfer funds" interface. This layer builds on the business service layer and the infrastructure service layer.
Service compositions can be created by design-time or deployment-time assembly. Design-time assembly involves programming the sequence of calls to the business (or infrastructure) services. For example, the transfer funds service can be built programmatically by first placing a call to "debit account" and then invoking a "credit account" business service. This method of implementation is referred to as design-time assembly. Deployment-time assembly involves building the sequence through configuration, where the call sequence is provided in the appropriate configuration language. This approach does require configuration support from the underlying software.
Orchestration layer
Orchestration services encapsulate the entire business process. For example, a service containing the entire flow of the "bank amount transfer" business process is an orchestration service. The complete bank amount transfer process includes identification of the destination bank and the source/destination accounts, verification of balance in source account, transfer of funds, and various other steps.
Languages such as Business Process Execution Language (BPEL) are used to implement orchestration services. An orchestration service is built by tying together the required business services, service compositions, and the infrastructure services. This layer is also referred to as the business process layer.
Service registry
The service registry layer maintains an information record of the available services. A service registry is not restricted to Universal Description, Discovery, and Integration or Java Naming and Directory Interface only; the services information can be stored in any suitable form for service lookup. The registry contains details of the orchestration services, service compositions, business services and the infrastructure services. This layer is the inventory of the services existing in an enterprise. For example, a registry containing the details of an existing debit account service, credit account service or transfer funds service for use by the enterprise is a service registry.
Messaging layer
The messaging layer includes business messages, which are the messages used for interaction among the service layers; these messages carry data among the service layers. The definition of such messages is part of this layer. For example, "transfer funds message" is a business message. The structure of such a message could include details of the source account, destination account and the amount to be transferred.
The messaging layer also provides the messaging system support for communication among the other layers. The messaging system facilitates interaction among the service layers. For example, an enterprise service bus product can be the messaging system for the services.
The enterprise data layer, the enterprise business layer, and front-end applications/channels can continue to use the existing business data carriers and existing communication protocols among themselves.
Service management
Service management and monitoring systems are part of the service management layer. Monitoring systems can provide valuable information on services, such as usage, throughput and other performance-related information. Real-time information related to business key performance indicators can be extracted using these systems. Service management tools are also part of this layer, which include tools that aid in security, load balancing and other management activities related to the services. This layer is also referred to as the SOA management layer. Business activity monitoring tools support the requirements of this layer.
Conclusion
This story tries to conceptualize a logical architecture independent of various implementation methodologies and technologies for SOA. Such a logical architecture is useful in design and for organizing systems in enterprises moving towards SOA. The architecture described is independent of vendor product/terminologies and can be easily mapped to them.
This architecture is intended for use during the creation of a technical SOA road map for an organization. It helps in identifying the gaps in the current environment and the target SOA-based infrastructure. The architecture serves as a good reference for the projects that require development of reusable SOA frameworks. Mapping the logical architectural layers to a product matrix will assist in determining the SOA-related products required for use in projects.
No comments:
Post a Comment