In the traditional application architecture, and even in the more modern world of Web services, enterprise infrastructure resources typically support a specific application or organization within the enterprise. As enterprise architects plan for capacity and performance, they can test the limits of the system resources and infrastructure with a fairly good understanding of where the demand will come from and how it will be processed. With SOA, this type of planning and testing is more challenging because the infrastructure resources may support a community of users and applications through services spread throughout your enterprise. Unlike previous types of architecture, SOA introduces changes that most IT organizations have not anticipated; you must ensure that your IT infrastructure can support the dynamic nature of an SOA. Organizations that fail to consider the impact to their infrastructure may find themselves dealing with performance and security issues, a tarnished brand image and lost revenue.
Supporting business objectives with SOA
SOA is not a new concept but a different approach to designing and building systems that are flexible and adaptable to support a dynamic business environment. An SOA lets an enterprise design, build, deploy and integrate services independent of applications and the computing platforms on which they run. These services are then linked together through defined business processes to form composite services, applications and composite applications to perform complete business functions. Some examples of possible services might include: locating billing information for a patient, requesting recent transactions for a financial account, identifying the owner of a registered vehicle, checking warehouse inventory for a particular item, or requesting a list of available flights for a given destination.
In this open framework, services can be shared and reused across several business processes. The result is a highly adaptive environment, with lower costs for application development, improved integration and quicker deployments. Business rules, which can be changed dynamically, now define the application layer of business functions. A single SOA-based service can, in fact, be widely reused throughout your enterprise by many business processes. And these business processes can be changed at any time to request other new and different services. Once enterprise architect deploys SOA for the core business functions, the ability to dynamically add new capabilities through services can help reduce the development costs and almost eliminate traditional development cycles to more quickly deliver new customer services and open new market channels.
A common misconception is that an SOA is a new version of Web services. The distinction between SOA services and Web services lies in their respective designs. SOA defines a model for executing a given process. Web services, on the other hand, can provide the tactical implementation of the SOA model. Thus, Web services are essentially just one of many ways in which an SOA can be implemented.
Changes in message handling and the importance of the enterprise service bus(ESB)
The most significant change as you move toward an SOA is the way in which transactions are processed. With traditional applications, the transport and translation of messages to complete transactions occurs in the application layer. With SOA, the transaction still begins in the application. However, the messaging has moved out of the application layer and now extends into the middleware infrastructure. This extension of the transaction enables the decoupling of the individual services which makes them accessible and reusable across the enterprise. At the same time, the expanded responsibility for messaging places additional performance and scalability requirements on the middleware infrastructure.
In traditional applications, all of the steps to complete a transaction are within the application with simple point-to-point connectivity. Enterprise applications which are based on enterprise application integration, the next evolution of development architecture, allow for connection sharing; however, the application is still responsible for the full transaction. With SOA, the business process application initiates the transaction and the enterprise service bus (ESB) provides the messaging, data transformation and intelligent routing. The ESB performs the following functions:
- Routing messages between services
- Converting transport protocols between requestor and service
- Transforming message formats between requestor and service
- Handling business events from disparate sources
The ESB renders applications, consumers, and providers independent from each other. Initially, your ESB architecture may simply transport messages. More complex routing and the transformation of messages may be included in a later phase of implementation. Of course, the availability and performance of each independent service in your enterprise is important. However, it is easy to see that the ESB is a critical component in achieving end-to-end performance for all of your business processes and applications. In fact, performance issues are often the direct result of a poorly architected ESB implementation.
The importance of the business process server
The ESB is driven by the business process server where enterprise business processes are defined and managed. The process server manages and orchestrates the requests through the ESB to independent services to complete these business processes. Business process flows are used by the process server to replace the complex interdependencies of your legacy applications.
SOA provides an opportunity to make processes more efficient and should begin with an exercise to model enterprise current business processes to help improve and eliminate out-of-date steps. These updated process flows should be the source for implementing the business process server. And, then, as enterprise implements new services, the business process flows can be easily modified to include new capabilities. In addition, as services are replaced or upgraded, the ESB will automatically perform a request on behalf of the process server to access the latest version of the service. It is easy to see how the ability to dynamically change business processes to include new or upgraded services is a significant business benefit. However, this same benefit complicates enterprise ability to control and manage the IT environment. If a business process does not complete or is slow in completing, how will you know where the failure has occurred? To meet service level commitments, the IT organization must be equipped with tools which provide the ability to monitor and manage the individual services of each business process as well as the business process itself.
Impacts of SOA on performance and testing
SOA makes heavy use of a messaging structure called eXtensible markup language (XML). XML is a verbose message format which can impact the performance of enterprise network and the components of the infrastructure which are responsible for processing this message format. Your SOA services are more than likely distributed throughout the enterprise which will result in multiple interactions back and forth across enterprise network. For highly reused services, improper infrastructure planning and design can cause overload and even failure in the network or the systems, which may result in poor performance, slow response times and possibly downtime for several applications and users. It is important to consider the number of users, other services and business processes which may request a service. The objective is to ensure that the time it takes to process a complete transaction in an SOA environment will not be noticeably slower or less reliable than the traditional application environment. This ability to dynamically create new applications by redefining business processes also creates new challenges for testing. How dies an enterprise architect tests the performance capabilities of a solution prior to deployment when new services can be implemented and requested by business processes through simple process definition changes? He will need to test the performance capabilities of an individual service, the capability of your ESB architecture and the end-to-end performance of composite business services.
Changes in IT service management
SOA will force an enterprise to transform from a systems-focused systems management approach to an enterprise-focused service management architecture. As touched on earlier, an unmanaged business service is, in effect, an unreliable business service. The organization may need to implement or expand current service management capabilities so the staff can monitor and manage the infrastructure with a view of the business processes which may comprise many loosely coupled and distributed services. The dynamic nature of an SOA environment makes it more challenging to provide effective service management. Basic system management solutions are not sufficient to support quick problem determination or management. Enterprise operations team needs the ability to monitor the composite application and, when service levels are not met, they need a way to understand what services are involved to analyse and resolve the problem. When a service that is solicited by many applications begins to experience performance issues, the staff needs to rapidly understand the full impact on different business functions.
Enterprise will also need to implement tools to help the staff automatically discover relationships between all the service components of your underlying infrastructure. It will no longer be effective to maintain static diagrams to map out how transactions work and pinpoint the servers on which they run. This may change from day to day or even from hour to hour. The staff needs automated tools that display the current topology at the time of the problem. Along with expanding and integrating the service management tool set, enterprise architect may need to adjust the organization and processes. A comprehensive evaluation of current service management implementation can help to develop a strategy to optimize enterprise staff and resources.
IT virtualization to support service virtualization
With SOA, since deployments are more dynamic, there may not be adequate time to adapt and change the infrastructure. In fact, over time, there may not be such a thing as traditional release cycles. The infrastructure needs to be "componentized" and standardized, because simplification is now critical to the success of SOA implementations. As usage patterns of SOA-based services change, virtualization and automated provisioning of your IT resources can help the infrastructure adapt more quickly. A flexible IT infrastructure is required.
UltraVista can help assessing your current infrastructure, and develop and execute a roadmap for your SOA implementation. We can help you navigate the inevitable IT complexities associated with SOA adoption by providing guidance and services for architecting, designing and implementing physical and middleware infrastructures. We can help you with:
- Performing a health check of your current IT capabilities to enable SOA.
- Defining a strategy and identify initiatives as part of a prioritized roadmap.
- Defining an infrastructure architecture that embraces SOA to support your business requirements.
- Developing infrastructure conceptual and specification designs to support the requirements of an SOA application framework.
- Designing and implement an ESB to help you decouple your Web services, applications and infrastructure.