Service Oriented Architectures - Essay Example

Service Oriented Architectures Word Count – 3177 {Business Case Analysis to Implementation of SOA} Contents of the Report Business Case Analysis Technology Specification SOA: An Introduction Technical Details Implementation of SOA: Technical and Business Aspects References Business Case Analysis The following sub-sections aim at introducing the subject of the report. Apart from detailing all the Organizational details, the following sections will also present the current technology being adopted, its inherent drawbacks and the need for change in technology. ‘United Bank’, is considered to be one of the top tier banks in the United Kingdom with approximately £ 20 Billion in revenues. It operates with a massive workforce that crosses 100,000 people. United Bank has 2500 branches across UK and approximately 1000 financial offices worldwide. United Bank has relentlessly provided top quality financial services and consequently built a very strong client base. They are involved in the funding of massive corporate and government projects apart from providing personal finance solutions such as mortgages, credit cards, loans, long term investments and insurance cover. With over 8 million customers, United Bank is a reputed organization with well established clientele. In the world of international banking it pays to have the most optimum and advanced Information Technology driving the core business. Most of United Bank’s clients use the Online Banking facility provided by it. The bank currently employs a tightly coupled client server based architecture with 11 main internal services providers. An internal audit of the IT services of the company reveals that it functions on nearly 650 distinctly accessible services in the production department and nearly 900 services in the development department. Although in the initial stages, as United Bank had just entered the Online Banking domain, their current tight coupled services architecture worked really well for them. However as the number of clients started to grow, they started expecting more out of the bank’s services. There is now a growing demand for improved web based services from both clients as well as the staff. One of the main initiators of the constraint faced by the bank is different tools. Since the various services that have been deployed, have been developed using different tools and technologies, the bank now faces the problem of lack of coordination and control over the huge data base. When a complete internal audit of services was proposed, the IT department of the bank experienced difficulty in discovering clearly the various services offered. Thus the new set of requirements of United Bank is multifold. They can be enumerated as: Means to record various services in a consistent and enterprise-level way. Develop and launch new products and services on the fly. Accelerate new customer ramp up. Deliver on the all the quality assurances made to the customer. Eliminate unnecessary redundancy by reuse of services. So the main question is, ‘How can United Bank gear up to all the changes that are needed?”. A Service Oriented Architecture (SOA) is the answer. SOA is the latest buzzword that possesses all that is needed to provide a springboard to any organization that aims at utilizing IT services to the most optimum extent possible. It induces agility and competitiveness in commercials banks. It transforms the IT assets of a bank directly into bottom-line goals and objectives. While SOA requires some upfront strategy and investment, its benefits are numerous. The following sections will cover the various technical aspects of SOA and its implementation strategy in general and to United Bank in particular. Technology Specification The following sub-sections will cover the various aspects of the technology behind Service Oriented Architectures. The details about the technical requirements, features, deployment and implementation are enumerated in the subsequent sections. SOA: An Introduction “Just as the Databases were at the center of design of applications of the 70s and 80s, Components are at the center of design of the applications of the 90s and the next century” – David Vaskevitch, VP, Microsoft. Almost anyone with a sufficient amount of experience in the world of information technology would agree that the concepts of ‘Objects’ have drastically changed the way, large scale software systems are built and deployed. Objects are the basis for advanced graphical user interfaces. Their power comes from their single most useful feature of reusability. Objects are built in such a way that they can be used to build ‘components’ that can be collaborated across multi-vendor platforms. These component based architectures have modernized the way large scale enterprise level software systems are built. The large scale success of component based architecture has lead to the development of Service Oriented Architectures (SOA). The concept of SOA is an evolution of the Component Based Architecture in which the enterprise’s architecture is developed in a ‘Service Driven Approach’ (Sriraman & Radhakrishnan, 2005). Service driven approach means that the requirements of an infrastructure are broken down into multiple components; each component providing a distinct service and each service is autonomous. These services are embedded into the business process of the enterprise that supports customer and business goals. Although the large scale deployment of Service Oriented Architectures is relatively new, there are traces that show the development of SOA, right from the earliest monolithic applications era. When the large scale organizations of the 1960s and 1970s identified the requirement of enterprise level software systems, they were provided with applications that were developed using procedural coding. In this type of coding, a massive portion of the system would be abstracted as a single procedural block. Inherent problems and shortcomings with procedural coding led to the development of Object Oriented Technology where the applications were divided into separate blocks based on functionalities. It has been claimed that object oriented technology was the first major step towards SOA (Nickull, 2005). The next major development was the development of the Client Server Architecture. This technology elevated the power of computation to new heights. Here the applications were split into a client and a server. Multiple functionalities were bundled into the server and they were invoked by the various clients (Orfali et al, 2007). The next milestone of significance was 3 Tier Technologies where the application logic was entrusted in the middle layer separated from data and user interface. An enhancement of the 3 Tier Technology was the N Tier Technology which facilitated any number of middleware layers between applications. A major breakthrough was achieved as Distributed Objects and Components came into the picture. Ubiquitous and Heterogeneous objects were created each with specific functionalities. Finally, as an evolution of the Distributed Component Technology was the Service Oriented Architectures, which is now on the fast lane, to provide ubiquitous computing solutions, using distributed components. Although new, SOA has very quickly captured the creativity of the world of business because of the architecture’s technical characteristics that translate directly into bottom line benefits for the company. Web Methods (http://www.webmethods.com), a prominent industry in the SOA domain; claims four major benefits derivable from SOA. They are enumerated: Increase in Organizational Agility Competitive Advantage through Flexibility Reduced Implementation Costs through Reusability Increase in IT Adaptability It can clearly be seen that adopting SOA has obvious positive effects on the net ROI of any business organization. The reason behind the several success stories of SOA is due to its power that arises from its technology. The technical aspects behind SOA are presented in the sections to follow. Technical Details Toby Harris Business Solutions (http://www.thbs.com), a leader in middleware services industry, claims that looking at Service Oriented Architecture as a methodology of implementing IT solutions, allows more significant benefits to an enterprise that seeks to adapt to change rather than thinking about it as a technology in itself (thbs.com, 2006). This is primarily because SOA is not a new technology; rather it is an effective utilization of the popularly existing N Tier and Distributed Technologies. Before proceeding to the in depth technical details, a sound understanding of the term ‘service’ is mandated. Service is infact the cornerstone of the entire SOA. Several different literatures exist on SOA and consequently several different definitions crop up as well. However one of the most apt and integral definition of service is provided by Alan Brown and his colleagues working in SOA Domain at Rational Software Corporation. According to them, “A service is generally implemented as a course-grained, discoverable software entity that exists as a single instance and interacts with applications and other services through a loosely coupled (often asynchronous), message-based communication model” (Brown et al, 2002). The service is requested by a ‘Service Requester’ which is provided to it by the ‘Service Provider’. The exchange of requests and response takes place with the help of communication systems known as ‘Service Broker’. A ‘Service Locator’ is also present that emulates a registry which holds the information about services and their locality. Together they can be called as the components of an SOA. The schematic in between the various parts of the SOA is presented. Figure: SOA Architecture XML is an essential part of Service Oriented Architectures. The interfaces that are the key entry/exit points of any module of the SOA is built in form of platform independent XML Documents. These XML services are described by a standard known as Web Services Description Language (WSDL). The World Wide Web consortium defines WSLD as, “WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information” (W3C, 2001). The messages here refer to the packets that are exchanged across the service requestors, service providers, service locators and service brokers for exchanging the information in between them. The end points refer to the interfaces that act as entry/exit points for each of these components. Whenever a requestor places a request for a service, the appropriate service provider processes the documents and sends the documents back to the requestor in form of messages. For cross platform operation, the XML Schema is used to build the appropriate messages. XML is the most favorite language for developing documents, messages and interfaces since they support total platform independence. Another feature that makes XML an optimal choice for SOA is its self descriptive nature and various inherent options for representing various types of data which is a major requirement in large SOA. The SOA Registry which is also known as Service Locator provides the lookup service. Universal Description, Definition and Integration (UDDI) is the standard used for SOA Locator. Finally the Quality of Service provides the various essential elements that provide quality assurance to the SOA architecture. The key QoS elements are Reliability, Authentication, Authorization and Integrity. A Service Provider generally offers a service as well as a contract for its use along with any necessary description of the service. The contract assures several of the key QoS elements such as authorization and confidentiality. The description consists of the actual functionalities that are provided by the particular Service Provider. From time to time the Service Providers advertise their descriptions across the SOA. The Service Locators update their tables based on these advertisements. Apart from the Service Locators, the currently active Service Consumers update their tables too. Nickull provides with an apt schematic to describe this model. Figure: SOA Model (Nickull, 2005) Two more essential technical features of SOA that mandate a proper understanding are Loose Coupling and Cross Platform. Loose Coupling: The success of entire SOA depends mainly on one feature of the underlying technology: Loose Coupling. Loose Coupling means that the services offered by the provider can be invoked without the requester having to anything about the locality or technical details of the provider. Cross Platform: SOA allows for effective communication in between many different types of services. This is incorporated with the help of virtual directory service that has information about all services and their native specifications. Because these features are developed using XML, cross platform functionalities can be achieved. Implementation of SOA: Technical & Business Aspects Building an enterprise-scale software system is not an easy task. Although there have been several groundbreaking technological advancements, the demands imposed by the users of these information systems frequently stretch to a break point after which the current IT establishment of the company wont work any longer. However a software architect’s role is to extend the life of an existing solution by describing new logic that can provide the needed enhancements. The major boom of Client Server Architectures and Distributed N Tier Architectures has resulted in most organizations using these services to automate their services. But as it has been observed the industry is now shifting focus on the Service Oriented Architectures. Therefore a company that intends to upgrade its services providing architecture to SOA has to incorporate several critical technical and business aspects into its consideration. The most important rationale that the company must always keep in the backdrop is internal IT savings. By nature, justifying a new project totally on the basis of expenditure is not possible. However by taking the significant Return Of Investment (ROI), and agility into account, a positive justification can be arrived at. Many companies find the process of upgrading to SOA an uphill task. Particularly because SOA is based totally on open standards, the main drivers of this technology are realized through web services; which leads to confusion and drives the companies to ‘wait-it-out’ (Sun Microsystems, 2004). Sun Microsystems also provides three key SOA realities to help companies dispel any myths about the technology. SOA is an architectural style that has been around for many years: Many customers have an impression that SOA is a new technology and requires a complete white wash of the existing IT infrastructure. However in reality SOA implementation aims at leveraging the current IT services of a company to optimum levels. Successful SOA implementation is more that just deploying Software: Many customers believe that SOA implementation is merely about installing softwares. However in reality, SOA works in parallel with not just the technical aspects of the company but also its business aspects. SOA implementation requires evaluation of several key aspects of the company such as processing models, customer relationship, locality of services and short term and long term goals of the company. Moving to SOA is not a small feat: Unlike most IT based deployment; implementation of SOA is not a one shot activity. It is a long term process that is performed in increments. One of the important issues that must be addressed while implementing SOA is establishing the correct level of granularity. Finely grained component services may be used by business services but would not be exposed to other systems (Wilkes & Harby, 2004). One way to begin the process of upgradation is to focus on the creation and utilization of the actual services (Sun Microsystems, 2004). For example, a banking organization might decide to standardize on their Web Services as its main delivery driver while at the same time writing new Web services to deliver the SOA benefits. This methodology will work until the amounts of services are small and infact is a good first iteration. However as the number of services grow; the shortcomings of this system become apparent. As the next set of iterations begin, enterprise wide services must be considered and incorporated into the system. The organization must provide for a sound implementation environment in which the SOA can successfully operate. The research team of Middleware Company provides a good insight into the implementation environment needed by an organization. In the proceeding section, these requirements are considered in the framework of United Bank. Definition of services independent of implementation: This is the first step towards developing a solid SOA framework. The main motivation behind SOA is accessibility of services irrespective of their location or use. To accommodate this step, United Bank must run a thorough audit of their internal services and describe them in a manner which can be accessed without any dependency on their locality or use. Implementation of “Provider” and “Consumer”: The driver components must then be established and the providers and consumers must be clearly analyzed. This will require the United Bank to classify their services into two categories: “Providing Services” and “Consumer Services”. For example the service that checks for authenticity of the customer is a provider service whereas the user interface which the client uses to access his online account can be considered to be the consumer service. Types of services must be identified: Some services need acknowledgements, some do not. The company must identify such classifications clearly. From perspective of United Bank, services such as online transactions can be provided with synchronous features whereas features such as checking balance may be left asynchronous. Identify Enterprise-Level Rules: Every service must be associated with a contract. This contract is obtained from an enterprise-level directory that contains rules that are periodically updated. Being in the banking domain, United Bank must have a huge database for a central policy administration. Provision for testing services: Since implementing SOA is a time consuming activity, provision must be provided for testing the integrity of services at various levels of development. The technical success of SOA is directly related to three important factors: Technology and Tools Alignment of Organizational strategy Methodology The Integrated Development Environment (IDE) is extremely crucial to the success of SOA. The tools are generally custom built and therefore the vendor must be chosen very carefully. Several vendors provide SOA services. IBM, MiddleWare, ORACLE, Sun Microsystems and Infosys are some of the market leaders in SOA domain. Since United Bank is an organization in the financial services domain, a company that has sufficient experience working in the financial services domain must be chosen for technology. Case Studies published by these companies can play a major role in the decision making process of the organization. The organization must also ensure that their business process drivers are in line with the objectives of the SOA. Evaluate of the business strategy plays a very important role, since the main goal of SOA is to maximize the net ROI of the organization. Finally the methodology adopted for the SOA implementation plays a crucial role to carry the architecture for many years without risk of breakdown. As it has already been discussed, iterative approach would be the best methodology. Sun Microsystems, a leading company is SOA domain provides the basic methodology framework. United Bank may follow this methodology to ascertain success in their endeavor. The first step towards a successful implementation is gaining a thorough understanding of all the principles of SOA. Since the staff of United Bank will be the main drivers of the services, they must be educated about the benefits of SOA. They must be trained in the field of the new technology and sound principles of operations. Secondly a detailed assessment must be made to identify all the service and classify them in a clear manner. Planning is the next step where the bank must identify in which ways the ROI can be substantially improved. Finally the vendor will provide the executables which will be deployed for use. Thus with proper planning, design and execution of SOA, any company can maximize its IT resource utilization and provide enhanced services to their customers. References Badri Sriraman & Rakesh Radhakrishnan (2005), “Component Based Architecture Supplementing Service Oriented Architectures”, Sun Microsystems Inc Press. Duane Nickull (2005), “Service Oriented Architecture”, Adobe Systems Inc Press. Robert Orfali, Dan Harkey & Jeri Edwards (2007), “Client/Server Survival Guide”, Wiley Publications, Third Edition, Pg. 15. Thbs.com (2006), “SOA”, THBS Publication, found at: http://www.thbs.com/soa. Alan Brown, Simon Johnston & Kevin Kelly (2002), “Using Service-Oriented Architecture and Component- Based Development to Build Web Service Applications”, Rational Press Publication. W3C (2001), Information on: WSDL, found at: http://www.w3.org/TR/wsdl Sun Microsystems (2004), “Assessing your SOA Readiness”, Sun Press, found at: http://www.sun.com Steve Wilkes & John Harby (2004), “SOA Blueprint Concepts”, Published by: Middleware Company research team. Read More