| By Arun Candadai |
Article Rating: |
|
| September 10, 2004 12:00 AM EDT |
Reads: |
17,857 |
Today's IT environments are increasingly characterized by heterogeneous and complex applications, tight schedules, budgetary constraints, and an ever-changing landscape of business requirements.
Few businesses have been agile enough to enhance their existing infrastructures to meet and overcome these challenges in an effective manner. Even so, to deal with a continuous flow of highly complex and dynamic set of business requirements rapidly and cost effectively, businesses need a flexible and dynamic approach to automate, build, and manage critical business processes.
Solution Approach
Service-oriented architecture (SOA) is often touted as a feasible solution approach to solving the business challenges mentioned above. SOA is a method of conceptualizing, designing, and building applications by using and assembling building blocks, each of which is usually represented as a reusable service. Many current approaches to SOA simply involve wrapping pieces of business functionality and using them within applications, often in ad hoc, static, and inflexible ways. The proposed approach to develop applications and business processes of the future is to employ a formal SOA implementation framework that is dynamic, flexible, and scalable enough to meet changing and complex business requirements. Regardless of whether you buy or build a framework for your SOA implementation, the functionality of this framework will hold good for your solution.
SOA Implementation Framework Overview
The SOA implementation framework is the enabling technology for efficiently building applications and business processes using SOA principles. It provides architects, developers, and administrators with an operational framework and tools to configure, use, and manage enterprise services that form the building blocks for applications and business processes. This framework uses a service-centric approach at all levels and stages of the implementation process and has the following generic characteristics:
- Ability to dynamically connect clients with services in a highly secure, protocol-independent manner
- Ability to reliably handle synchronous and asynchronous modes of service execution
- Ability to define and handle events in a declarative manner
- Ability to dynamically convert between data formats of clients and services
- Ability to manage distributed SOA resources (services, configurations, policies, etc.) in a centralized manner
- Ability to capture and handle exceptions in the service execution process
- Ability to log and monitor various events and metrics as they arise during the client-service transaction
- Provide a unified and reusable service invocation code library for use across client applications in the enterprise
- Support for Web services standards stack to promote wide-scale adoption and interoperability
Framework Components
Service RegistryThe service registry is a foundational piece of the SOA-enabled solution for the enterprise. It is used to define, configure, and virtualize business services used by applications in a centralized manner. Most companies fail to realize the full potential of SOA due to the lack of a well-designed and managed service registry. It includes crucial information needed for defining and provisioning the services - services, providers, consumers, service interactions, policies, and all associated configurations. The service registry resides in a high performance data store and can be viewed and managed using the service manager, which is described later.
Service Bus
The service bus is a high-performance component that mediates between client applications and services and adds value by providing generic pieces of functionality on behalf of the clients, as well as the services aimed at promoting unified and reusable technical functionality - a key to real SOA implementations. It enables clients to focus mainly on business logic by providing a standard mechanism to connect to services and encapsulating service implementation details.
The service bus uses a pipeline approach, where the bus can be visualized as a sequence of components - a pipeline. Each stage in the pipeline is essentially a value-add component that takes in a set of inputs, where applicable, from the previous stage, processes the data, and passes on the outputs to the next stage.
The following are the features of the service bus:
Dynamic connectivity and routing: Dynamic connectivity is the ability to connect to Web services dynamically without using a separate static API or proxy for each service. Most enterprise applications today operate on a static connectivity mode, requiring some static piece of code for each service. Dynamic service connectivity is key to enterprise agility. The dynamic connectivity API is the same regardless of the service implementation protocol (Web services, JMS, EJB/RMI, POJO, etc.). Client applications access services via URI interfaces that may either directly map to services or be routed based on the context or content of the service request.
Reliable messaging: Reliable messaging is the ability to queue service request messages and ensure guaranteed delivery of these messages to the destination. It also includes the ability to respond, if necessary, back to the requestor with response messages. Primarily used for handling events, this capability is crucial for responding to clients in an asynchronous manner, and for a successful SOA implementation. This is typically implemented using reliable JMS queues with store and forward as well as guaranteed delivery capabilities.
Security: Generically handling and enforcing security is a key success factor for SOA implementations. The following are the main considerations:
- Federated authentication: This feature intercepts service requests and adds the appropriate username and credentials. It is also capable of authenticating service requests before dispatching the request for service execution.
- Authorization: Validates each service request and authorizes it to make sure that the sender has the appropriate privilege to access the service.
- Encryption/decryption: Encrypts XML content at the element level for both request and response messages and performs decryption for the reverse scenario.
Transformation: Needed when a client and a service use different data formats, it is the ability to transform a given source of data into a target format based on specified transformation rules.
Caching and performance strategies: Important to improve the performance and quality of services and eventually to enhance overall customer service. It is performed at various levels, including service configurations, service response data services, and other SOA resources, depending on where optimization is needed to achieve high performance. Overall performance can also be improved by using compressed XML-based messages when transporting them across the nodes; the result is reduced bandwidth utilization. To accomplish this, compression and decompression agents are installed at the edges of the SOA grid.
Logging: Needed to trace system execution and performance for auditing, troubleshooting, and monitoring purposes. Logging can be done for any of the services and can be done at various severity levels.
Monitoring: The ability to track service activities that take place via the bus and provide visibility into various metrics and statistics. Of particular significance is the ability to be able to spot problems and exceptions in the business processes and move toward resolving them as soon as they occur.
Service-level agreement (SLA): SLAs specify performance guarantees associated with Web services operations and business processes -such as response times and service availability - that are essential for business-critical operations. Service providers can use SLAs to advertise and create service-level agreements with consumers. This helps them to provide the appropriate amount of resources and prioritize the servicing of requests.
Versioning: The ability to version Web services and to proactively assist in the migration of the client applications to use new versions of the Web service as soon as they become available. Versioning support includes being able to register different versions of the same service, to provide the client with the necessary APIs and libraries for all versions, and to help in migrating clients to the new versions. The versioning component has the ability to transform requests to older versions of the service to the newer version using XLST-based transformation.
Exception management: Ability to track and handle exceptions as they occur when clients access business services. Exception details such as the exception code, name, reason, and description are captured and logged. Exceptions are also handled appropriately by retrying the connection a predefined number of times, routing to an alternate service, or by simply returning a reason for execution failure.
Custom business logic processing: Provides the flexibility to insert custom business logic during service processing. For instance, a specific business logic can be performed either on the service request, prior to submitting the service request for execution, or on the service response, prior to sending the service response back to the client.
The service bus is itself implemented as a service, using Web service or EJB technologies. This service is deployed to a server pool or cluster and is designed to scale horizontally. Each of the components mentioned above must conform to the corresponding Web services standards.
Service Manager
The service manager is a UI-based administration tool that empowers administrators and business managers to define, configure, manage, and monitor business services and related SOA resources used within the applications. It can be thought of as the control center for the SOA implementation, used mainly to provision and monitor services. The following are the two key functions of the service manager:
Service configuration management: Using this feature, administrators can onboard and configure services housed in the service registry. Users can define services, locations, binding information, and service configuration settings such as security, cache, transformation, logging, and monitoring. They can also define service providers and consumers and associated service contracts.
Service activity monitoring: Provides a dashboard for business managers and administrators to view key metrics and statistics in relation to service activities that take place via the Bus. Users can view and monitor service usage, response times, service exceptions, activity logs, messages, etc.
The service manager is delivered as a Web-based application and can be accessed without any client-side installation requirements.
Client SDK
The Client SDK is software that is needed to connect with the service bus. The SDK - downloadable from the service manager - is packaged and provided in the form of an API. It is an easy-to-use library that application developers can use to discover, access, and utilize business services from their applications and business processes. This significantly enhances developer productivity as it offloads developers from message plumbing tasks that are, in turn, performed by the service bus. The client API does not use service location-dependent, hardwired proxies and stubs to access services. Instead, it uses a dynamic mechanism to connect to the services via the bus.
SOA Implementation Framework Usage
The SOA Implementation Framework can be used to develop robust applications and business processes. Figure 2 presents a usage scenario that uses the SOA implementation framework to build a customer self-service application consisting of order management and customer support functions. The application uses the client SDK to connect - via the bus - to core business services in the order and support process, such as purchase order submission, third-party credit verification, order status, support case entry, and support case status. These functions are exposed as either Web services or other Java API by wrapping business logic from existing applications - SAP Order Management and a custom-built customer support application. Further, the credit service is a Web service that is hosted at a partner site.
This example illustrates the ability for client applications to easily connect to heterogeneous services in a unified and service logistics-independent manner.
SOA Implementation Best Practices
Any successful SOA implementation - in addition to using a robust and flexible SOA implementation framework - will require a set of guidelines and best practices at various stages of the development cycle. A core set of guidelines is provided below:
- The process of onboarding new services must be configuration and discovery process-driven as opposed to having a lengthy and manual process cycle. This ensures that the overall system can scale to future requirements with minimal efforts.
- An SOA implementation is only as successful as the method used to design the business services. Each service must abstract a coarse-grained piece of business functionality and is designed in a way that is coherent and reusable across the enterprise.
- Services must be designed as asynchronous where applicable to improve response times and overall user experience.
- Client applications must use a unified mechanism to access services in a protocol-independent manner and regardless of whether the services are local or remote. Further, the clients must focus mainly on the business logic and any service connectivity logic must be abstracted in the client SDK. This ensures centralized plumbing logic, high levels of application developer productivity, and ease of maintenance.
- The generic components of the SOA implementation framework must be exposed in standard ways to promote code unification and reuse.
- Use configuration where possible, instead of customization and code-based business logic. This improves the ability to scale to future business requirements with minimal effort and time.
- Reuse and wrap existing legacy business application logic with more coarse-grained business-level services. Avoid rewriting legacy implementation logic.
Conclusion
This article presented a flexible, dynamic SOA implementation framework for building service-oriented applications and business processes of the future. This approach aims to provide enterprises with a highly scalable and dynamic framework for defining, configuring, accessing, and managing enterprise services.
Cloud computing is a game changer. The cloud ...
Subscribe to SOA World Magazine Email News Alerts
Subscribe via RSS
