Towards Introducing and Implementation of Soa Design Antipatterns free essay sample

Service Oriented Architecture (SOA) is an architectural practice followed by organizations to reduce total cost of ownership, ease of maintenance in software development implementing various SOC principles. Dissatisfactory performance of SOA projects has stimulated the developers to analyze the SOA worst practices or antipatterns. Our research aimed at identifying these wrong practices in implementation of SOA, i. e. antipatterns. In this paper, four antipatterns SOA==SOAP, using plain WSDL, web service discovery only through UDDI, and service for an application have been identified and presented in SOA antipattern template. These antipatterns are related to the use of SOAP, WSDL, UDDI and basic service definition, which initially seemed to be correct but later resulted into reduced performance benefits. Keywords- Service, Service Oriented Computing, SOA, Design patterns, Antipatterns. Introduction Service Oriented Computing (SOC) is the latest design paradigm used to implement distributed systems. Service Oriented Architecture (SOA) implements various service orientation principles, which are designed for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It comprises of a set of components as services that can be invoked and whose interface descriptions are published and discovered [1-3]. The popularity of SOA has motivated designers to document its applications and implementations. Many best practices in the form of design patterns have been defined for SOA. They capture expert knowledge about best practices in software design, in a form that allows that knowledge to be reused and applied in the design of many different types of software. Some of the solutions have stood the test of time while others have not. These blemishing design patterns lead to the concept of Antipatterns. Antipatterns are specific repeated practices that appear initially to be beneficial but ultimately result in undesirable consequences Documentation of antipatterns helps the programmer to be aware of the common wrong practices, and hence improves the project statistics. There are various problems in adaptation of SOA, which result into the dissatisfactory performance of SOA projects. These problems are to be seriously catered; hence practitioners have started addressing different bad or worst practices of SOA implementation in form of antipatterns. SOA is a logical way of designing a software system to provide services either to end-user applications or other services distributed in a network via published and discoverable interfaces. There are several available SOA best practices and design patterns, which are currently used in the implementation of SOA based projects [14, 15, 22, 26, 29, 32]. Antipatterns have been addressed by practitioners after year’s long experience in the field. A survey on different antipatterns was performed exploring various worst practices and the causes of the failure of SOA projects [9, 14, 23, 28]. Antipatterns for SOA have already been documented [16-20, 25, 28, 31], but our major concern was on the SOA design antipatterns. Moreover, they have been described at different levels of abstraction, which makes them appear independent and isolated. After studying various SOA implementations, case studies [9, 12, 18, 32], News agency Service project of Signett IT enabled services, Travel Portal project [20] and few others [28-32] , it has been observed that there are some flaws in implementation of SOA. Since SOA is still in its nascent stage. Its success and importance still needs to be proved. Four antipatterns have been identified in this research work. They concentrate mainly on SOA design. These are SOA==SOAP, Using Plain WSDL, Web service discovery only through UDDI and Service for application. The first antipatterns SOA==SOAP focuses on ignorance of other parallel approaches to SOA. Second antipattern focuses on improper representation of service using WSDL. Third antipattern recommends the use of REST services which do not require any service registry to be discovered and prefers using customized registries. The fourth antipattern highlights the wrongly implemented concept of service forgetting the basic service design principles. The proposed antipatterns focus on SOA design and would definitely reduce certain overheads and result into a successful SOA implementation. It is sincerely hoped that these antipatterns would help the programmers to design a successful strategy for SOA implementation in their project. Some of the domain areas such as request change, data handling have been left unexplored and few more antipatterns can be identified. A framework for building SOA applications could also be developed which would integrate various features necessary features for SOA implementations. The rest of the paper is organized as follows. Section II of the paper briefly explains the antipattern template that will be used to describe the proposed antipatterns. Section III explains each of these proposed antipatterns along with their implementation and re-factored solutions. The fourth section provides future work in this direction of research and the conclusion of the paper followed by the references used. SOA Antipattern Template Antipatterns describe a commonly occurring solution to a problem that generates negative results i. e. seemingly well but in fact, wrong solutions. Design patterns and antipatterns are closely related. Former defines commonly applied solutions to well known problems, while later are the specific repeated practices that initially appear to be beneficial but ultimately result in undesirable consequences. An essence of antipattern is two solutions. First is the commonly occurring problematic solution that generates wrong results, another is the re-factored solution i. e. the esolved, reengineered and beneficial form of antipatterns. Those that describe only the negative solution are called pseudo antipatterns [31]. There are various problems in the adaptation of SOA, which result into the failure of SOA projects. These problems are to be seriously catered; hence practitioners have started addressing different bad or worst practices of SOA implementation in form of antipatterns. Antipatt erns proposed by different organizations have been fragmented and have been focusing on the complete SOA life cycle i. e. from the origin of concept to realization. The pioneer work on the subject focused primarily on object oriented antipatterns. It should be known that object oriented patterns and service oriented patterns have a subtle difference between them. Some of the object oriented design patterns form the major antipatterns for SOA such as No legacy Antipattern and vice versa. The SOA antipatterns discussed in the next section utilize the following SOA antipattern template to document the common dysfunctional practices in the adaptation of SOA. It specifies the name, root cause, primal forces, description and the name of the antipattern to which the current antipattern is similar to. Patterns have a problem and a solution while antipatterns have two solutions (instead of a problem and a solution). The first solution generates negative consequences (forces that must be resolved). The second solution is a migration (or refactoring) from the first solution that provides dramatically improved benefits and much reduced consequences. Like design patterns, antipatterns should also follow a general profile format for their representation [9]. Following is the antipattern template used to describe SOA design antipatterns. It comprises of a number of required and optional sections. The core sections are the general form of the antipattern and the re-factored solution. ? Antipattern Name: The Antipattern name is a unique noun phrase. The name is used for future reference to the principles contained in the antipattern. They form the basis for an organization’s terminology when members discuss and document software and architectures. ? Also Known As: This identifies additional popular or descriptive names and phrases for this Antipattern. ? Root Causes: These are the general causes for the antipattern. They can be one or more of the following values: Haste: It is popularly said ‘Haste makes waste’. Hasty decisions lead to compromises in software quality. As successive project deadlines are missed, anything that appears to work is considered acceptable, regardless of quality. Apathy: It refers to not caring about solving known problems. It is a basic unwillingness to attempt a solution. Narrow-mindedness: It is the refusal to practice solutions that are otherwise widely known to be effective. Sloth: Automatically generated interface stubs and skeletons make the task of constructing a distributed system relatively easy. The ease of creating and changing interfaces leads to the deadly sin of sloth—lack of configuration control. Avarice: Architectural avarice means the modeling of excessive details, which results in excessive complexity due to insufficient abstraction. Ignorance: It is the result of failing to seek understanding. The problem of ignorance (implementation dependency) often occurs in the migration of applications to distributed architectures. Pride or resp onsibility: Often, developers unnecessarily invent new designs when knowledge from preexisting systems, products, and standards are readily applied through architecture mining. Reinvention involves many unnecessary risks and costs. Primal Forces: Forces are concerns or issues that exist within a decision-making context. In a design solution, forces that are successfully addressed (or resolved) lead to benefits, and forces that are unresolved lead to consequences. The choices include any of the following: -Management of functionality i. e. meeting the requirements. -Management of performance refers to meeting the required speed of operation. -Management of complexity means defining abstractions. -Management of change controlling the evolution of software. -Management of IT resources refers to controlling use and implementation of people and IT artifacts. Management of technology transfer refers to controlling the change in technology. ? Re-factored Solutions. This section explains a re-factored solution that is structured in terms of solution steps. Proposed SOA Antipatterns Design patterns are proven solutions to a task presented in a standard format and antipattern are the wrong ways of doing a task which initially seemed to be correct. Here, certain domain areas were identified as most error prone areas of SOA implementation, hence probable areas of finding new antipatterns. This was on the basis of the implemented module, case studies and study of the subject. SOA comprises of different architectures as shown in Fig1. Based on these designing of a service oriented application can be further broken up as service design, service composition design and service inventory design. [pic] Figure1: Layered architectures. SOA design is further categorized as Service Design (SD), Service Composition Design (SCD), Service Inventory Design (SID), and Service Oriented Enterprise Design (SOED). The identified domain areas prove to be the weaker links of SOA and need to be implemented correctly and carefully. Few of these domain areas are concept of service, service scalability/load balancing, service discovery, service composition, data sources, security and request change. In this paper, SOA==SOA, using plain WSDL, web service discovery only through UDDI and service for an application are identified as antipatterns and these are discussed in the following subsections. 1 SOA==SOAP Practitioners implementing SOA often consider that, the three standards required for implementing web services are the Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). SOAP is an XML-based protocol to support communication between a Web service, its clients, and UDDI registry. WSDL is an XML-based standardized interface definition language used to describe what a web service can do, where it resides, and how it can be invoked. A WSDL file associated with a Web service contains important details about the Web-service interface for client-service interaction. UDDI standard is used to publish, discover, and manage Web services in an UDDI registry. Although it is a good and most preferred way to implement web services, the other ways to create light weight services should also be preferred. A REST (Representational State Transfer) web service is basically a simplified model where everything is wrapped around the HTTP send/receive protocol. Using services based on SOAP envelop always, may be an overhead, whereas that same work could be done using lightweight approach like REST using traditional methods. The main responsibility of accessing the service in the SOAP-WSDL process lies on the consumer. He will have to programmatically extract the Web service SOAP message in order to do something useful with it in the application. Although core services holding logic should be bind in an SOAP envelop but simple data handling services , CRUD operations should be implemented using traditional Http methods viz. GET, PUT, POST, DELETE i. e. through RESTful way. REST emphasizes resources with a uniform interface for addressing them, while SOAP based RPC emphasizes processes with a uniform interface for invoking them. With a RPC-based architecture, there is no limit to the number of processes. In REST we can everything get by only four basic methods GET, POST, PUT and DELETE of the Http standard, and make the resource addressing handle the variability. For services representing basic CRUD operations, REST way of implementing services is simpler and lightweight. 1 Re-factored Solution In the development of Web service based SOA applications, the designing of services should not be adamant to a traditional style but other approaches should equally be used when and where required. Both the approaches SOAP based and REST based have been compared in the following paragraphs and depending on the requirement, appropriate method for implementing services could be selected. Both these approaches are not the counterparts and can be used together in the same application. 1 Approach REST and SOAP are parallel ways of implementing web services. Let us first discuss these two different approaches of implementing web services. REST is an architectural style that prescribes the use of standards such as Http, URL, Resource representations (XML, HTML, Gif etc. ), MIME Types etc. [11]. The RESTful web service makes available URL to a resource and it may allow the client to specify the format of the returned resource i. e. HTML or an XML document. The service itself may be described using WSDL (Web Service Description Language) or WRDL (Web Resource Description Language) and can be accessed either as a resource or using JSON (Java Script Object Notation). RESTful services are stateless; each request from client to server must contain all necessary information. All resources are accessed with generic interface (Http GET, POST, PUT, DELETE). These resources are named using URI (Uniform Resource Identifier). The client may progress from one state to another using interconnected URL representation. In SOAP method, provider creates and implements a web service interface on an existing application. He has to create a XSD (XML Schema Document) and WSDL contract in order to distribute the web service details to potential consumers. Consumer obtains WSDL contract for consumption through UDDI registry. Then the consumer implements the WSDL in a specific platform Java, C#, PHP, Perl and creates a caller application. Client sends multiple requests using the same URL for all transactions. It is the responsibility of the SOAP server to a parse the SOAP message and determines which method to invoke. The returned data would not contain any URL, since a URL that points to a SOAP service is just to the SOAP server. In REST all decisions are made based upon the URL and the Http method selected while in SOAP, server receives all messages, peeks into the SOAP envelop and then distributes each message to the appropriate application for processing. 2 Proxy servers Proxy servers play a major role as web intermediaries for a web application. Below we briefly discuss their functionality for a web service. In the REST approach, the URL identifies the resource that is desired. The Http method identifies the desired operation. The Proxy server decides based upon the identified resource and the Http method whether or not to allow the operation. Using XLink (the XML hyperlink technology) in addition to providing a URL to the target resource, data about the resource could also be provided using Xlink:role. The application can dynamically make decision about what resource is to be accessed next. In SOAP based approach, proxy server cannot directly allow or disallow the message since it is unaware of the desired contents or resources. Either the proxy server should understand the semantics of each SOAP application that a client will access, but for that the proxy server will need to be updated for each new SOAP application. 3 Caching It refers to the ability to maintain a copy of the desired resources in order to improve the performance. In the REST approach, The response of a resource contains an indication in the Http header of whether the results are cacheable or not. If it is, cache servers make a local copy, which can be returned for the same request if repeated. A SOAP message is always with a POST method, which makes the cache server unaware of the actual intention of the request type (GET or POST). Moreover the SOAP URI is always to the SOAP server which prohibits the cache server again from knowing the actual resource requested. Hence no caching is possible with SOAP. 4 Generic Interface Generic interfaces imply generalized functionality and hence support scalability whereas application specific or custom interface interfaces may need some additional functionality to be called in a generic context. In REST, every resource has a generic interface namely Http GET, PUT POST, and DELETE which enable caching and proxy servers to do their work. Whereas in SOAP, There is no defined standard set of methods. Any type of methods could be defined which makes customization on application basis and reduces scalability. 5 Interoperability Interoperability means sharing the data amongst multiple applications. The more interoperable software programs are, the easier it is for them to exchange information. In REST, Interoperability is based on standardization. REST relies on standards of addressing and naming resources (URI), resource interfaces (GET, POST, PUT etc. ), representations (HTML, XML etc. ), and media types (MIME types). In SOAP, each SOAP message provides its own unique method of naming a resource. Each SOAP application defines its own interface hence interoperability is possible only for closed systems where all participants are known prior. REST and SOAP do not replace each other, each of them have their uses but when making high performance and client rich websites REST can provide a significant improvement. Traditional way of implementing SOA only through SOAP also leads to other antipatterns. REST style needs no registry and makes resources directly available hence it also helps in overcoming the following two antipatterns viz. Discovery of web service through UDDI and Using plain WSDL to define service interface. 2 Standard Representation Following the Standard Antipattern Template [14] and SOA Antipattern Template [31], the above proposed antipatterns can be described as follows: Antipattern Name: SOA==SOAP Also known as/ similar to: Not Applicable Root Cause: The common and fundamental reasons for the problem can be coined as haste, apathy, ignorance. Primal Forces: These are certain architecture and development related concerns or issues present in most decision making context. They greatly affect the design and development process and in this case it can be management of functionality and management of technology transfer. Misuse of these above mentioned forces leads to the development of this antipattern. Description: SOAP-WSDL is considered to be the only way of implementing SOA by companies implementing SOA for the first time. Solution: Although SOAP-WSDL is the established way of SOA implementation through web services but other alternative ways like REST should be equally considered. For CRUD applications RESTful services should be preferred and for application specific services holding core logic SOAP based services should be preferred. 3 Implementation The above antipatterns were derived after final implementation of both the ways of implementing web services i. e. SOAP and REST. Following are few screenshots of their implementation i. e. SOAP-WSDL based web service in . Net hrough Visual Studio 2008 and REST Based web service in java through Netbeans7. 0. 1 Fig. 2 represents a structure of SOAP based service. It shows various methods which are application specific and need not have a generic structure. Figure2: Structure of SOAP based service Fig. 3 shows the structure of REST based service. It reflects certain methods like getJSON() to retrieve java script object notation form of data, getXML() to re trieve its XML format. [pic] Figure3: Structure of REST based service. The Fig. 4 below shows the interface of the REST based web service. In it the resources are available in the form of URI (Uniform Resource Identifier) in the returned page. User can access these web services by simple clicking on the URL shown, the getXML() or getJSON() methods are called accordingly. [pic] Figure4: REST based web service. 2 Using Plain WSDL WSDL (Web Service Description Language) is used to define service interfaces. It describes two different aspects of a service: its signature (name and parameters) and its binding and deployment details (protocol and location). WSDL describes services in three layers: Layer 1: It describes the interface of a service. Layer 2, describing the binding of a web service i. e. protocol and format for which web operations are provided. Layer 3 defines the physical location i. e. address URL where service is available. WSDL does not contain full interface of a service, it does not have any semantic information. A WSDL file does not specify how to access next desired service, how long a service usually runs, who is allowed to call it, how much a service call cost and many other non functional attributes. All these aspects must usually be known in order to manage a service in a large SOA landscape. With future WSDL versions this might change. 1 Re-factored Solution Service Description should be provided in a separate format and WSDL should be generated from it when required. WSDL files can be extended internally with additional XML elements and attributes or externally with supplementary files [20]. WSDL allows elements representing a specific technology under various elements defined by WSDL. These elements are known as extensibility elements. Extensibility elements allow vendors to expose their Web Services as EJB’s, Remote Java Objects and . NET objects without having to write SOAP bindings for them. Currently, the WSDL specification introduces specific binding extensions for the SOAP, HTTP GET/POST, MIME protocols and message formats. Using the extensibility mechanism a service developer can describe commonly used services such as EJB, . NET and Java Objects. The consumer of the service can use the WSDL and generate the necessary client side stubs to invoke the endpoints in the native protocol. This approach has a several advantages. The service developer does not have to spend time in exposing his service with SOAP bindings. Also, invocation of the service will be faster since the call will occur over the native protocol, and less time will be spent for SOAP marshalling and un-marshalling. A service can have multiple bindings associated with it and the consumer of the service will have the choice of selecting one binding or the other. Implementation The Fig. 5 below shows the standard WSDL file for a simple web service in java. [pic] Figure5: Standard WSDL representing a service. In the Fig. 6 code segment the information for locating the EJB is stored in lt;ejb:portgt; section of the WSDL definition and the information for invoking the EJB is stored in the lt;wsdl:bindinggt; section. [pic] Figure6: WSDL extensions using WSDL4J. 2 Standard Representation According to SOA Antipattern Template [31], the above proposed antipatterns can be described as follows: Antipattern Name: Using Plain WSDL to define all service interfaces. Also known as/ similar to: Not Applicable. Root Cause: It can be the result of h aste, sloth and ignorance. Primal Forces: Management of change, management of complexity and management of technology transfer. Description: Simple WSDL describes only two different aspects of a service: its signature (name and parameters) and its binding and deployment details (protocol and location). This does not describe various non functional attributes like how to access next desired service, cost of service etc. Solution: WSDL files can be extended internally with additional XML elements and attributes or externally with supplementary files. Certain extensibility mechanisms have been defined for specific purposes like, those supported by WSDL4J for ejb’s. Techniques for defining WSDL extensions have been proposed [12] and are one of the major research areas in WSDL. 3 Web service discovery only through UDDI In a real SOA enterprise infrastructure with hundreds of services, it is safe to assume that service endpoints are going to constantly be subjected to changes in areas such as location (URL), policy (security, etc) or contract (WSDL, operations). A common practice to accomplish that is to have client application to resolve service metadata such as endpoints or policies against a service repository. In order to address these challenges, the big SOA vendors  (Microsoft, Oracle, IBM etc. ) created a standard that with the purpose of modeling service metadata information that could be used to enable service discovery capabilities. The standard was known as Universal Data Discovery and Integration (UDDI) and, unfortunately, it became the cornerstone of SOA governance products. UDDI has proven to be an incredibly ineffective mechanism to enable service publishing and discovery. The SOA models created with UDDI are incredibly complex to implement and use. They end up becoming another bottleneck of SOA. 1 Re-factored Solution While building SOA application, the complexities of UDDI should be avoided and instead use a simpler mechanism to facilitate the discovery and query of services. This can be achieved by implementing a 100% RESTful API that allows querying the entire service registry using plain HTTP GETs methods. There is no requirement of centralized registry. More advantages of REST are discussed in previous section. User defined or application specific registries can also be defined like Oracle’s OSR (Oracle service registry), But these application specific registries are very complex and far from the reach of a simple programmer. Standard Representation According to SOA Antipattern Template [31], the above proposed antipatterns can be described as follows: Antipattern Name: Discovery of web service through UDDI. Also known as/ similar to: Not Applicable. Root Cause: It can be haste, sloth and ignorance. Primal Forces: Management of performance, management of IT resources and management of technology transfer. Description: Since SOA literatures and previous implementation of the technology, effectively present the usage of UDDI as the central registry for SOA services, the new small projects consider it to be an un-detachable component of SOA. The truth lies behind the fact that UDDI is incredibly complex and difficult to implement. Even and Microsoft have refrain from their UDDI registries. In such case, adhering to UDDI seems to be right but in fact not the perfect way of service discovery. Solution: Customized registries according to the application should be created. Various other registries using JNDI (Java Naming and Directory Interface), OSR (Oracle Service Registry) can also be used in an SOA application. REST based services should be preferred for data access services. They are directly accessed through URI’s hence require no central registry. Service for an application In the development phase of the module it has been observed that the first step in implementation of SOA, if taken mistakenly can prove to be a useless investment. Services are supposed to be designed for achieving main goals of SOA viz. reusability, interoperability, increasing organizational agility etc. Many IT developers with object orie nted experience implement SOA in the way they started Object oriented software. Services are designed application specific. No enterprise level service classification is involved. Service just become another way of creating an application, hence, provides no business benefits. Large numbers of services are designed, leading to another antipattern: Service Silos. These services have little or no reuse across applications. 1 Refactored Solution Proper training and education of basic SOA goals and principles should be given to the involved members before the actual work begins on the project. The service design should also follow basic SOA design principles [12]: 1) Standardized Service Contract: Services in the same inventory should follow same design contract. ) Service Loose Coupling: Services should be loosely coupled with customer requirements and their own surrounding environments. 3) Service Abstraction: Service contract should contain only the essential generic information. 4)Service Reusability: Services should have reusable enterprise logic. 5) Service Autonomy: Services should be autonomous i. e. their runtime environment should be under their control. 6) Service Statelessness: State information should not be maintained with service itself. 7) Service Discoverability: Services should be effectively discovered and interpreted through suitable mechanisms. 2 Standard Representation According to SOA Antipattern Template [31], the above proposed antipatterns can be described as follows: Antipattern Name: Service for an Application. Also known as/ similar to: Not Applicable. Root Cause: It can be haste, apathy, sloth and ignorance. Primal Forces: Management of functionality, management of change, management of complexity and management of technology transfer Description: Services are built for use within an application forgetting the basic service design principles. Solution: The services should be classified as intra application and inter application. Inter application services should be designed for interoperability. Application specific services if required should be at the lowest level and callable only by the generic services providing interface to the service consumer. Services at lowest level should further be properly identified as entity services, task services and utility services [15]. Services should essentially follow basic design principles for a successful SOA implementation. Conclusion and Future Work It has been observed that amongst the large number of addressed SOA antipatterns, failures are mainly due to limited number of interrelated antipatterns focusing mainly on the SOA design. Four antipatterns SOA==SOAP, Discovery of web service through UDDI, Using Plain WSDL to define all service interfaces, Service for an application were identified and represented. The above conclusions and derivations were based on the case studies and SOA implementation, using both, SOAP based and REST based services. In this paper we mainly emphasized SOA design antipatterns. Some of the domain areas such as request change, data handling have been left unexplored and few more antipatterns can be identified.