CSI Developing Enterprise Web Services

Service Oriented Architecture – A New Paradigm Debasish Jana Principal Software Engineer Anshin Software Pvt. Ltd. Treasurer, CSI Kolkata Chapter

Abstract Service Oriented Architecture (SOA) is not an entirely new concept, yet it has become a new paradigm of today’s enterprise applications. Before the Internet and the Web came into existence, communication between systems was very tightly coupled with the underlying system. Today’s complex software needs to be interoperable and loosely coupled in order to communicate with each other in a seamless manner. Earlier SOAs were built using DCOM or Object Request Brokers (ORBs) based on the Common Object Request Broker Architecture (CORBA) specification. CORBA was capable of providing standards-based interoperability and connectivity. SOAs provide loose coupling between components so that some components provide services while some others consume offered services. Web services promise to offer interoperability to cater to the growing complexity needs of software yet at the same time provide easy to access service interfaces.

1. Introduction Early programming days had monolithic code running on mainframes. The goal was to have the computing done using the machine. Earlier, computers were used more as a data processing machine or a number crunching machine. With the advent of sophisticated technology in hardware as well as advancement of communication and increased complexity of software, there emerged the need for structured programming and modularity. In 1968, when Edsger E Dijkstra wrote “Go To Statement Considered Harmful”, since then and later the designers tried to make the programs more modular, structured, compartmentalized. A new era began. But even then, in a procedural paradigm framework subroutines, functions, global data, maintenance started become nightmarish. Need of abstractions were felt. Object Orientation tried to bring a new paradigm. Concentrate on what, not how – is the theme of the OO paradigm. In OO paradigm, a module or a class offering a set of services should expose a set of public interfaces or contracts and hide out the implementation details. The caller needs to make call to the exposed interface to avail the service without being bothered how internally the service is catered to.

2. Need of Component-based Software With growing complexity of software, a need became imperative to maintain not the code only but the functionality exposed and in use, as well. Individual modules or compartments needed to be reused as components in order to reduce time, effort in further software developments. Component-based software development came into existence to build resilient architectures. In principle, software needs to be soft i.e. flexible enough to cope up with changing requirements or adapting to changing technology. Compartmentalization or breaking into multiple interrelated components and making things simple can cater to extendibility quality aspect of a software. Extensibility is the quality factor that makes a software product easy to adapt to changes of specifications or requirements. Also, by reusing commonality or patterns, the task of reinventing the same wheel can be avoided. This requires that components of a software system should not be designed to cope up specific problems in specific contexts, rather they should be designed to provide generic solutions to a class or pattern of problems in different contexts. This makes such general components to be adapted and reused many times. All modern engineering disciplines offer high levels of assurance, predictability and efficiency because new projects are based on a vast, well documented repository of experience, good practice and sound principles. Reusable software components hold the promise of contributing to software development eventually attaining the same status as the established engineering disciplines. Compartmentalization to components also need to cater to integrity so as to protect various components (programs, data, documents, system software, hardware environment etc.) against unauthorized access and modification.

3. Changing Nature of Software The nature of the software that we're building is also changing, from the simple batch systems of the 1970s that structured techniques are geared towards to the interactive, international, user-friendly, high-transaction, highavailability online systems that object-oriented and component-based techniques are aimed at. By clearly articulating the major components and the critical interfaces among them, an architecture lets one reason about reuse, both internal reuse (the identification of common parts), and external reuse (the incorporation of ready-

made, off-the-shelf components. Architecture can also facilitate reuse on a larger scale: the reuse of the architecture itself in the context of a product line that addresses different functionality in a common domain. Extensibility, reusability and maintainability issues got addressed through component-based software development. But complexity issues could not be catered to by just breaking into components. Today’s software needs to cater to distributed deployment, application integration, heterogeneous platforms, diverse protocols, web based access to cater homogeneity in access, so on and so forth. With all these requirements in mind, software compartmentalization task begun. From monolithic mainframe based systems it was a paradigm shift when the era of client-server computing emerged. The client, typically a personal computer with graphical user interface (GUI) connected with a backend server with shared resources or database became tightly coupled. The client or the front-end used to typically depend on the backend server. But, soon from the single-server within a LAN based client-server system, a need was felt for distributed system to support wide area network and with the new intergalactic demand or need of communicating between hugely disperse heterogeneous systems spread out in different geographical areas. The tight coupling of the client and server is sought to be broken. In a distributed system, the client does not know the server, the server does not know the client. Multi-tier architecture evolved. The front end tier is supposed to deal with user interface issues. This tier needs to talk to a middle tier to take care of requests that would be catered by some backend server, and the reply or response from the server will reach the client via the middle tier. This middle tier is often called a broker.

4. Loose Coupling and Statelessness To cater growing need of complexity, we try to minimize the coupling between the components in the system so as to reduce dependency and increase flexibility. The interacting software components should know other components minimally. The idea is to discover information when needed. Loose coupling helps to have better flexibility of relocating a service on a different server, or replaceability i.e. changing the implementation of the server without changing the communication protocol or interface of communication. Loose coupling also helps to have better scalability in the sense that services can be added and removed with growing or shrinking demands. With loose coupling, when a service is required, the server offering the service would be discovered with its capabilities, policies, location, protocols etc. Having established the connection or binding with the server, now the client can communicate with the server to avail the service directly. Loose coupling also helps to achieve fault tolerance. If a server fails, alternate server may become operational by updating the directory service or registry service. Statelessness is a very important issue to achieve loose coupling. In a stateless communication system, each transaction is self-contained, does not depend on history or previous transaction. notion of loose coupling is—a topic that has been much-discussed and is often mentioned as a critical requirement, sometimes without a clear understanding of its significance. For complex transactions comprising of a series of smaller transactions however require stateful nature where the state needs to be preserved. However, if the server fails for some reason, the transaction ends in a spurious situation. In a multi-step transaction, a stateless service requires that at end of each step, the service must communicate to the client sufficient and meaningful state information to continue the transaction. The client must communicate back the state information on next transaction. The submitted state information must be handled in such a way that it should not depend on earlier processing steps.

5. Earlier Technologies Lets now investigate the available technologies catering to loosely coupled systems or subsystems to make earlier service based systems before service oriented architecture came into existence. The earlier serviceoriented architecture was using DCOM or Object Request Brokers (ORBs) based on the Common Object Request Broker Architecture (CORBA) specification. CORBA was capable to provide standards-based interoperability and connectivity. Also, Microsoft’s Common Object Model (COM) and Object Link Embedded (OLE) component infrastructure and object bus were among distributed objects based technology. CORBA objects used to be active objects that can stay anywhere on a network. That are packaged such that remote clients can access them via method calls. The language and complier used to create server objects used to be totally transparent to clients. Clients thus don’t need to know where the distributed object stays or what platform it runs on. Clients don’t also need to know how the server object is implemented. For example, a server object could be implemented as a set of C++ classes or it could be implemented with a set of code written in some other language, the client should not be able to make out the difference. The client needs to know only the interface that the server object publishes as a contract. The interface or contract serves as a binding rule between clients and servers. CORBA has been designed to be independent from the Operating System. CORBA runs on many operating system platforms, ranging from the Win32/UNIX up to the real-time embedded systems and supports a vast majority of programming languages as well as some scripting languages. Communication protocols used by CORBA for ORB communications include TCP/IP, IPX/SPX, ATM, etc.

Cross-language, cross-vendor interoperability used to be achieved via the Internet InterORB Protocol, or IIOP. IIOP is a transport protocol for distributed applications written in either IDL (Interface Definition Language) or Java RMI (Remote Method Invocation). In CORBA, object orientation is limited only to objects that can be passed by reference or are predefined in the overall framework. We cannot pass code from machine-to-machine. Passed and returned types must be those declared in the interface. In CORBA, the parameter or return values are limited to the capability of representation available in the underlying implementation languages. In Java-RMI, the interface and the implementation language are described in Java. As such, the code i.e. language-level objects can be passed from one process to the next, from one machine to other. Argument values or return values can be actual type, not abstracted type. Otherwise, IIOP stubs and skeletons need to be generated to remain accessible from other CORBA-compliant languages.

6. Service Oriented Architecture Service Oriented Architecture (SOA) is the answer to meet the problem of growing complexity. The key premise is the abstraction layer. Abstraction involves the formulation of representations by focusing on similarities and differences among a set of things or entities to extract intrinsic essential characteristics (relevant common features or behaviors). It also avoids extrinsic incidental characteristics (irrelevant distinguishing features) in order to define a single representation having those characteristics that are relevant to defining every element in the set. Service-oriented architecture (SOA) provides a loosely coupled composition of services. A service in SOA should be an exposed piece of behavioral aspects such that the contract for service (i.e. the exposed interface in highest level of abstraction) to the service remains platform-independent. Also, the service should be dynamically discoverable and callable as requests. Dynamic discovery requires a discovery or directory service available at runtime. A service should be defined to be as an atomic operation encapsulating a particular business process. As such, the service must be self-contained i.e. service should be stateless. Thus, a service needs to be communicable, publishable, self-containable, well-definable, and also should be platform independent, and independent on the state of other services. Service providers and consumers need to communicate via messages. The service contract must clearly define the behavior of the service and the platform-independent messages exchangeable. The service invocations should be interoperable such that heterogeneous platforms can offer and avail services through exchange of platform-independent, interoperable messages. In a service-oriented architecture (SOA), there should be a bunch of service providers, service requesters, and service administrators to facilitate services. A service providers should provide facility for service registration, dynamic discovery, exception handling with automatic failover, distributed security, platform independent interoperability, and clustering as well as grid computing. Fig. 1 shows SOA in perspective of service providers, consumers as well as service registry providing directory services for available services. Service providers register themselves with Service Registry, Service consumers discover or find provider for required services from service registry. Then, service consumer binds the service provider to execute the service request by the provider of services.

Fig. 1. SOA – relationship between service providers, consumers and registry

7. Web Services in SOAs With heterogeneous platforms offering service, web services technology plays a major role in a SOA. Web Services are basically distributed middleware technology that uses simple XML based protocol to allow applications to exchange data across the web. Services are described in terms of the messages accepted and generated. Web services hide out or abstract the underlying complexity of the service providing system the service consumer is talking to. Web services are built on top of well-known and platform-independent protocols such as HTTP, XML, UDDI, WSDL, and SOAP. Dynamic discovery and dynamic invocation is possible in

UDDI, WSDL, SOAP. Sometimes, Service Oriented Architecture (SOA) is often mystified with web services. SOA concepts were around long before web services came into existence. Still, the growing popularity of web services are catering the need of SOA in a heterogeneous distributed environment. SOA attempts for loose coupling between components by providing a software service that is consumed by another software service. SOA stresses interoperability. This requirement is fulfilled by hypertext based protocol HTTP. SOA, in combination with web services can cater to growing need of application integration, cross-platform interoperability, scalability, availability, dynamic discovery and invocation of services as well as reliability. With web services, application integration has become convenient with standardized APIs. References [1] Fujita Satoru, Dynamic Collaboration of Businesses using Web Services, NEC Journal of Advanced Technology, Vol. 1, No. 1, Jan, 2004, P. 36-42 [2] Jana D, “Java and Object-Oriented Programming Paradigm”, ISBN 8120327756, Prentice Hall of India, 2005. [3] Jana D, Chaudhuri A, Datta A and Bhaumik B B, “Privacy Protection of Grid Services in a Collaborative SOA Environment”, IEEE International Region 10 Conference, Proceedings of the IEEE TENCON 2005, Melbourne, Australia, Nov. 21-24, 2005. [4] Web Services Architecture, W3C Working Draft 14 November 2002, from http://www.w3.org/TR/ws-arch/ on 5th March 2002 [5] About the World Wide Web Consortium (W3C), http://www.w3.org/Consortium/, March 2000 (updated in April 2004)