ABSTRACT

Chapter-1

Introduction

Service Oriented Computing (SOC) is an emerging distributed computing technology that is set to replace the existing ways of building software [1]. It is an architectural practice followed by organizations to reduce total cost of ownership, ease of maintenance in software development. Many organizations today are looking up to SOA as an architectural solution to provide a robust computing platform to connect to legacy systems. The main causes of acceptance of this latest design paradigm are its distinct advantages of reusability ease of maintenance, interoperability, reduced development cost, defined standards and many more. SOA based solutions promise a better landscape in terms of all benefits mentioned and has proven to be a boon for large scale organizations.

Being service oriented basically means employing an architecture that consists of a variety of services, the basic building block of SOA application. Service is a unit of solution logic specially designed to attain the inter operability, federation, agility, loose coupling and other strategic goals of Service Oriented Computing. It is a self contained stateless business function that accepts multiple requests and returns multiple responses through well defined standard interface. They are hosted by the service provider and are initially discovered and further invoked and interacted by the service consumer through UDDI (Universal Description, Discovery and Integration) public service registry following the service contract as shown in Figure1.

Figure1: Service Oriented Architecture.Service orientation, services, service compositions, service inventory and SOA are essential elements for realizing Service Oriented Computing. SOA might be defined as an application architecture in which all functions are implemented as independent services with well-defined invokable interfaces, which can be called in sequences to form business processes. Recent IT developments have pushed SOA forward. For instance with personalized, portal-style user interfaces over multiple wired and wireless channels an increasing number of solutions require the reuse of application components. Different users such as customers, employees, managers using many devices in different situations all may request access to the same set of business applications. Flexibility in design of new software, reuse of business components, interoperability, integration capability, and ease of assembling new business processes are few of the advantages of SOA. SOA is not always a remedy for existing shortcomings in todays mix and match IT-architectures. This approach of distributed computing is not suitable for homogenous IT environment, true real time systems, old legacy systems and systems where tight coupling is required. SOA is also not recommended for standalone short lived applications. Moreover it is also not useful for applications that need GUI based functionality. Besides certain areas where SOA has not proved to be beneficial there are certain critical aspects that are to be considered. Service versioning, service security, availability, service discovery, unfurnished standards, request change etc. are few of them.It has been almost a decade since the advent of SOA. Expectations for SOA were high, but early adopters faced obstacles that inhibited the realization of SOAs benefits. Many of the failed IT projects blamed SOA, but the actual cause did not lie in the technology, but was in the way it was implemented. Although lot of work has been done to develop design patterns for SOA development, the 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. A careful and intensive study of existing antipatterns of SOA is done. These antipatterns are categorized are categorized as SOA development process, SOA framework and SOA design antipatterns. They are presented in a proposed SOA antipattern template specifying there name, root cause, primal forces and description. Various case studies, implementations, intensive study and research we identified four antipatterns in SOA design 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. 1.1 Aim

The aim of our research work was to identify and formalize new antipatterns in SOA design.1.2 Objectives

1) To analyze various design patterns and antipatterns.

2) To identify various problems and failures in SOA design.

3) To identify various Antipatterns.

4) To formalize new Antipatterns.

Chapter-2Literature Review

Readily accessible internet and World Wide Web (WWW) in past few years has increased the use of distributed systems by enterprises exponentially. Initially, distributed systems interacted using proprietary protocols. Certain application specific methods were used to manage these systems.

SOC is a latest computing paradigm that utilizes services as the basic constructs to support the development of rapid, low-cost and easy composition of distributed applications, even in heterogeneous environments [1]. SOC has not occurred with an impact but it has been gradual evolution overtime from the basic object oriented paradigm. The presented work started with the depth study of the origin of SOC. Roots of service orientation lie in one of the oldest design paradigm object orientation [3, 4]. It laid the foundation of important principles like abstraction, encapsulation and reusability etc. that were further reinforced by component based development, with its advantages of extensibility and maintainability [2]. Component based development could not cater complex issues such as distributed deployment, application integration, heterogeneous platforms, web based access and diverse protocols. These drawbacks led to the evolution of client server computing [3-5]. Its tightly coupled nature paved the way to distributed computing. It supported highly dispersed heterogeneous systems with reduced coupling between the components [7, 8, 12, 13].

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. Many papers and articles have matriculated the use of SOA [10, 11, 24, 29, 39, 42].Various implementations of SOA approach derived the best practices and design patterns of SOA documented in [15, 22, 26, 32, 40]. In first phase of our work systematic review of various antipatterns in SOA has been done. Antipatterns have been addressed by practitioners after years long experience in the field. A survey on different antipatterns was done exploring various worst practices and the causes of the failure of SOA projects [23, 28, 32]. The dissatisfactory performance of SOA projects has stimulated the developer to analyze the SOA worst practices or antipatterns. This module of SOA development has been weakly analyzed. Antipatterns for SOA have already been documented [16-20, 25, 28, 37, 44], but the major concern was on the development process and SOA framework [48]. Moreover, they have been described at different levels of abstraction, which makes them appear independent and isolated. SOA antipatterns have been categorized as development process, framework and design antipatterns. There details include name, root cause, primal forces, description and the name of the antipattern to which the current antipattern is similar to, following the standard antipatterns template [21, 37]. SOA design antipatterns were further emphasized and classified and re-factored solutions were provided to them After studying various SOA implementations, case studies [9, 12, 33-35], News agency Service project of Signett IT enabled services, Travel Portal project of HCL systems and few others [38, 40-42] , it has been observed that there are some flaws in implementation of SOA. The problem exists more in companies transiting from traditional approach to SOA. The reason can be any beginning from lack of experience to haste or others. Companies implementing SOA for the first time, start creating services as nothing else, but methods that bind inside SOAP envelop and can be described through WSDL. Some of the domain areas which should be considered while implementing SOA in projects are highlighted in the presented work. [44] Specifies various other research challenges and issues in SOC.

Chapter-3

Scope and Research Methodology Used

SOA is the latest design paradigm for distributed systems. It has a wide scope for research. Major concern for SOA is to readily develop applications with the integration of services and composite applications within the enterprise by supporting the features such as reliability, proper routing and coordination of services, and managing other technical details including protocol and integrating party agreements [44].

3.1Scope

SOA has been implemented in major projects of many companies but since it is in its nascent stage developers are learning more from there ill experiences with it. Our work aims to highlight certain steps which if taken wrongly may prohibit the desired results of the project. After an intensive study and implementation we identified few antipatterns in SOA design. These are just a small fraction of the major SOA areas where more antipatterns could be identified. The proposed antipatterns will definitely help programmers to be aware of various wrong practices in SOA implementation, specifically in designing of such applications. This work specifies four antipatterns in service design and will assist the SOA designers for developing better frameworks and tools to develop integrated SOA applications.

Quality of Service (QoS) requirements, security, management and monitoring of services are also other requirements that need to be clarified when designing service based application architectures. SOA has a broad influence in each stage of application development including analysis and design of individual services, service deployment, creation of new applications from services and implementation of services through service oriented strategies and approaches. There are various other aspects like SOA versioning, change request, service security, data sources, load balancing etc which need the attention of the developers and have vast scope of research.3.2Research MethodologyThe main aim of our research was to identify antipatterns in SOA design. We started with the in depth study of the subject. This latest design paradigm has its roots in the decades old object oriented paradigm. In order to understand the subject it was necessary to compare SOA with other common approaches. Software development and computing trends were discussed in context to evolution of SOA, showing changes in their implementation with time and their role [2-8]. Various design patterns and antipatterns of SOA were reviewed and a template for SOA antipatterns was proposed and used to represent studied antipatterns. They were further categorized as SOA development process, SOA framework and SOA design antipatterns [21]. The work was supported in parallel by news agency registration service for implementing SOA. After intensive case studies of SOA failures various weak areas of SOA implementation were identified. Some of them were service designing, versioning, service discovery, request change, load balancing etc. Based on the research work certain antipatterns were proposed and which were further implemented and formalized in an antipattern template. For the support of the proposal, registration service was implemented both as SOAP based and REST based. Chapter-4

Service OrientationService orientation is a design paradigm comprised of a specific set of design principles. The application of these principles to the design of solution logic results in service-oriented solution logic [11]. The most fundamental unit of service-oriented solution logic is the service. The service-oriented computing platform revolves around the service-orientation design paradigm and its relationship with service-oriented architecture. This chapter introduces Service Oriented Computing and Service Oriented Architecture.

4.1 Service Oriented Computing and its evolution

A new generation distributed computing platform having its own design paradigm, principles and patterns. In the following section, SOC is briefly described.

4.1.1 Introduction

The term was formalized in 1996; prior to it many companies were able to implement service layers using a variety of distributed technologies, including Common Object Request Broker Architecture (CORBA) and the Distributed Common Object Model (DCOM). On the other hand development of enterprise application with a traditional approach was facing lots of problems. Since the solutions were created with a common approach of identifying the business task to be automated, defining there business requirements and then building the corresponding solution, the new solution logic results in many problems like significant amount of redundant functionality, targeted scope of the project and many others. Having to host numerous applications built from different generations of technologies and perhaps even different technology platforms often requires that each will impose unique architectural requirements. Applications built only with the automation of specific business processes in mind are generally not designed to accommodate other interoperability requirements. After repeated generations of traditional distributed solutions, the severity of such problems has been amplified and hence conceived the concept of Service Orientation.4.1.2 EvolutionModern software development methodologies and implementations have their roots in the decades old object oriented paradigm. Object orientation laid the foundation of important principles like abstraction, encapsulation and reusability etc. that were further reinforced by component based development, with its advantages of extensibility and maintainability. Components were not successful for web based access, hence evolved client server computing. But its tightly coupled nature paved the way to distributed computing. It supported highly dispersed heterogeneous systems with reduced coupling between the components. An efficient design paradigm for implementing distributed system is SOC [13].Development Trends

Traditionally, software ran in stand-alone systems where users interface, application logic, persistent data all reside on a single machine with attached peripherals. While todays software development is based on distributed systems, where presentation, application logic, data resources all reside on remote, heterogeneous, loosely coupled systems. Several trends are emerging to cope up with the current computational scenario. Various development and computing trends have been implemented overtime. The use of distributed systems by enterprises has increased exponentially in past few years due to certain factors such as readily accessible internet and World Wide Web (WWW) [1]. Initially, distributed systems communicated using proprietary protocols. Grid computing is such an implementation of distributed computing. Certain standards have been developed over the years to simplify the management, maintenance and deployment issues. Web services, SOA, Cloud computing are the current implementations of these standards.

Today, the key technology to implement distributed systems is SOC. Service orientation / SOA are an extensive buzzed around words today, without knowing its actual context and meaning. It is a style of building reliable distributed systems with inherent features like loose coupling, interoperability etc. Web services are a popular implementation of SOA.

Figure2: Evolution of SOC.Object Oriented Development

Object orientation is established as a dominant paradigm for virtually all modern software development, from small software to a full-fledged enterprise application. Object orientation is based on its four fundamental principles viz. Abstraction, Encapsulation, Inheritance and Polymorphism. Class is the basic construct that binds the data attributes and their associated behaviors. Object is a run time instance of class. The main emphasis is to structure a system with classes, ensuring modularity and reusability. A module or a class offering functionality exposes a set of public interfaces or contracts and hides out implementation details. The user accesses the functionality through the objects without being bothered about its implementation. This has close resemblance with SOC, which evolved as a successor of component based and object oriented computing. Object oriented design comprises of fundamental design principles which structure and organize object logic within and across classes. Object oriented principles include increased extensibility, flexibility, reusability, predictability and robustness. Many of these principles have been carried in service orientation while some like inheritance (is-a relation), abstract class, polymorphism, aggregation have been discouraged. Different component of object-oriented approach like classes, methods and interfaces relate to different components of service oriented approach as shown in Figure 3.

Figure 3: Elements of object orientation and service orientation.

Object orientation evolved out of approaches that included procedural programming while service orientation builds upon object oriented principles with additional influence of component based development (CBD), aspect oriented programming (AOP), business process management (BPM) etc.Component Based DevelopmentComponent Based Development emphasizes the design and construction of computer based systems using reusable software components. Component is the most important, independent replaceable part of a system that fulfills a clear functionality. A set of pre built standardized software components are made to fit a specific architectural style. In component-based development, initially, an appropriate architecture style to meet the objectives of the system to be built is selected. The components to be reused are then identified. The selected components are then qualified so that they fit into the desired architecture. The next step is to adapt the component according to the requirement, if modifications are required. Finally all the components are integrated to form the subsystem. Separate components are created to fulfill the requirements, which could not be implemented using the existing components.Component Middleware allows a group of component objects to interact with each other through multiple interfaces provided, and also defines run time mechanism to execute these component objects in generic application servers in a distributed environment. Technologies such as Enterprise Java Beans (EJB), Common Object Request Broker Architecture (CORBA) and Component Object Model (COM) are implementing component middleware.

SOA comprises of a set of components that can be invoked and whose interface descriptions are published and discovered. Component model is used for developing and executing components. The usage of the terms invoked and execute is noteworthy. Component based architectures and service based architectures both work towards the foundation for loosely joined and highly interoperable software architectures. Services have to be publicly accessible; moreover they have to be independent of implementation specific attributes. Extensibility, reusability and maintainability issues got addressed through component-based development, but complex issues such as distributed deployment, application integration, heterogeneous platforms, and web based access and diverse protocols could not be catered. To address such issues client server computing emerged. Initially it was tightly coupled. Soon the need was felt for distributed systems to support wide area network and for communication between highly dispersed heterogeneous systems. Multi tier architecture evolved, with the front tier to deal with the client, middle tier to cater the incoming request (also called broker) and database tier to handle the backend issues. The middle tier may be comprised of multiple layers. Coupling between components was reduced, statelessness was desired and enhanced components were further represented as services, rather web services [4].

Distributed Computing

A distributed system consists of multiple autonomous computers that communicate through a

network" computer network. The computers interact with each other in order to achieve a common goal. There are several autonomous computational entities, each of which has its own local

(computers)" memory. The entities communicate with each other by passing message. Initial service based systems used different technologies like Dynamic Component Object Model (DCOM), CORBA to provide standard based interoperability in a distributed environment. CORBA has been designed to be free of the operating system. It runs on many OS platforms. Cross language, cross vendor interoperability is achieved through IIOP (Internet Inter ORB Protocol), a protocol for distributed applications written in RMI (Remote Method Invocation) or IDL (Interface Definition Language). CORBA had its own complexities like passing of object references, passing actual (not abstract) argument values etc. These growing complexities are reduced by the service oriented computing, it is a style of organizing and utilizing the distributed capabilities that may be controlled by different organizations.

Grid Computing

Grid Computing aims at utilizing the unutilized resources from different administrative domains. It involves computation in a distributed fashion, which may also involve the aggregation of large-scale cluster computing based systems. It can run the users application on heterogeneous computing resources which are dispersed geographically. It has high security mechanism involved. It has almost been two decades since the advent of grid computing even then it is not much popular in the research community. Only a small number of the researchers actually use grid software [5]. The reason behind is the complexity involved with the grid, like, its complex architecture, the grid certification process, cryptic command line options, non-assurance of the availability of resources etc. Grids are application oriented. They are not fully web based; they also have command line option to enter into a grid. Resources in a grid may be administered by different set of people. It follows dedicated resource policy i.e. a resource is reserved to a particular application for the particular time, until its use, It cannot be used by any other application.

Cloud Computing

Cloud Computing is an extension of grid computing, parallel computing and distributed computing. It aims to provide high performance computing resources to the client over the internet. It can deploy, allocate, reallocate computing resources dynamically and monitor the usage of these resources at all times. Cloud provisions multiple users to share a single resource concurrently. Simultaneously, it assures that one users data or application is not shared by the other. It uses the technique of virtualization, so dynamic scaling of resources is possible. It provides virtual data centers, but does not depend on any particular data center. Many of the internet applications are cloud based. Uploading photo, text files, online shopping, gaming, music resources etc are all cloud based. Google apps, EC2 (Elastic computing cloud) are the examples of popular clouds. Some clouds offer testing and production environment free of cost. Developers can develop and deploy their application on the cloud free of cost. Cloud data centers are owned by private vendors and are fully commercialized. They are not designed for a particular domain or problem. All activities in a cloud can be achieved through web browsers and no manual interactions are required. Like grid, cloud data centers may be located in geographically different locations but they will be under the same administrative domain in contrast to a grid, which may have different owners.

Besides normal implementation, cloud computing is also implemented in following different styles:

i) SaaS - Software as a Service. In this form of cloud, software services are hosted over the web. It is a new delivery model for software. Instead of hosting software on premise in their own data center companies and individuals use software that is hosted and managed by the SaaS provider. SaaS mainly uses REST (Representational State Transfer) and SOAP (Simple Object Access Protocol). In the users views, this approach can save some cost on servers and software. In the providers views, they only need to maintain one program, this can also save cost. SOA is a design model whereas SaaS is consumption model.

ii) PaaS - Platform as a Service. It implies the concept of using web as a platform. The providers offer application APIs and services so that the user consuming these, may write their own applications and run these applications using these APIs in the providers server, independent of other applications. Platform Oriented Architecture (POA) is the architecture on which PaaS is designed. PaaS and SaaS are virtually same for service consumption, but PaaS offers development and service hosting opportunity.

iii) Utility Computing In utility computing virtual data centers are created to provide storage and virtual services through collecting memory, input-output equipments, storage and computing power to a virtual resource pool.

iv) IaaS - Infrastructure as a Service delivers computer infrastructure, typically a platform virtualization environment, as a service. Rather than purchasing servers, software, data center space or network equipments, clients buy these resources as fully outsourced services. The service is typically billed on the basis of amount of resources consumed and therefore the cost will typically reflect the level of activity. It is an evolution of virtual private server .

Cloud computing expands SOA on the internet by adding scalability and grid computing. Many SOA based applications are deployed and hosted on a cloud network like EC2, windows Azure, etc. Although it is not necessary to host web services on a cloud but it is preferred because cloud provides no limit to the size of data, no limit to the processing power, no limit to the number of service instances. SOA applications take advantage of the elasticity of the cloud.Service Oriented Computing (SOC)

The service-oriented computing paradigm uses services to support the development of rapid, low-cost, interoperable, evolvable, and massively distributed applications. It evolved as the latest design paradigm for developing distributed enterprise applications.4.1.3 Elements of SOC

Following elements are essential to realize service oriented computing:

a) Service Orientation: It is a design paradigm comprised of a specific set of design principles. The application of these principles to the design of solution logic results in service oriented solution logic.b) Services: The most fundamental unit of service-oriented solution logic is the service. Each service is assigned its own distinct functional context and is comprised of a set of capabilities related to this context. Those capabilities suitable for invocation by external consumer programs. c) Service Compositions: These are a coordinated aggregate of services. The consistent application of service-orientation design principles leads to the creation of services with functional contexts that are agnostic to any one business process. These agnostic services are therefore capable of participating in multiple service compositions.d) Service Inventory: It is an independently standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise. An enterprise environment can contain multiple service inventories, each of which can be individually standardized, governed, and supported by its own service-oriented technology architecture. Service inventories are typically created through top-down delivery processes that result in the definition of service inventory blueprints.

e) Service Oriented Architecture: SOA is an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise by positioning services as the primary means. They represent the solution logic in support of the realization of strategic goals associated with SOC. SOA implementation can consist of a combination of technologies, products, APIs, supporting infrastructure extensions, and various other parts.

4.1.4 Service Models

Services can be categorized depending on the type of logic they encapsulate, the extent of reuse potential this logic has and how this logic relates to existing domains within the enterprise.

Hence services can be classified in three broad categories:-

a) Entity Services

It is the business model document that defines the organizations relevant business entities. Examples of business entities include customer, employee, invoice, and claim. The entity service model represents a business centric service that bases its functional boundary and context on one or more related business entities. It is considered a highly reusable service because it is agnostic to most parent business processes. It is also sometimes called entity centric business services or business entity services.

b) Task Services

A business service with a functional boundary directly associated with a specific parent business task or process. This type of service tends to have less reuse potential and is generally positioned as the controller of a composition responsible for composing other, more process-agnostic services. Task services are also known as task-centric business services or business process services.

c) Utility Services

It is dedicated to providing reusable, cross-cutting utility functionality, such as event logging, notification, and exception handling. It can consist of a series of capabilities that draw from multiple enterprise systems and resources, while making this functionality available within a very specific processing context. Utility services are also known as application services, infrastructure services, or technology services. The use of these service models results in the creation of logical service abstraction layers.

4.2Service Oriented Architecture Software architecture is a description of a software system in terms of its major components, their relationships, and the information that passes among them. A fundamental purpose of software architecture is to help manage the complexity of software systems and the modifications that systems inevitably undergo in response to external changes in the business, organizational, and technical environments. SOA is an architectural style for building enterprise solutions based on services. More specifically, SOA is concerned with the independent construction of business-aligned services that can be combined into meaningful, higher-level business processes and solutions within the context of the enterprise. An architectural model that enhances the cost effectiveness, efficiency, agility and productivity of an enterprise by positioning services as the primary means to represent logic and by reducing IT burden on the overall organization

4.2.1Strategic Goals of SOA

The vision behind SOC is extremely ambitious and therefore also very attractive to any organization interested in truly improving the effectiveness of its IT enterprise. A set of common goals and benefits has emerged to form this vision [15].Increased Intrinsic Interoperability

Interoperability refers to the sharing of data. Software programs that are not interoperable need to be integrated. Therefore, integration can be seen as a process that enables interoperability. A goal of service-orientation is to establish native interoperability within services in order to reduce the need for integration

Increased federation

A federated IT environment is one where resources and applications are united while maintaining their individual autonomy and self-governance. SOA aims to increase a federated perspective of an enterprise.

Increased Vendor Diversification Options

Vendor diversification refers to the ability an organization has to pick and choose amongst multiple vendor products and technology innovations and use them together within one enterprise. It is not necessarily beneficial for an organization to have a vendor diverse environment; however, it is beneficial to have the option to diversify when required.

Increased return of investment

SOC advocates the creation of agnostic solution logic i.e. logic that is agnostic to any one purpose and therefore useful for multiple purposes. Agnostic services have increased reuse potential that can be realized by allowing them to be repeatedly assembled into different compositions. Any one agnostic service can therefore find itself being repurposed numerous times to automate different business processes as part of different service-oriented solutions.

Increased Business and Technology Domain Alignment

Although initial applications have traditionally been designed to address immediate and tactical requirements, it has always been challenging to keep applications in alignment with business needs when the nature and direction of the business changes. The fact that services are designed to be intrinsically interoperable directly facilitates business change. As business processes are augmented in response to various factors (business climate changes, new competitors, new policies, new priorities, etc.) services can be reconfigured into new compositions that reflect the changed business logic.

Increased Organizational Agility

Agility, on an organizational level, refers to the efficiency with which an organization can respond to change. Increasing organizational agility is very attractive to corporations, especially those in the private sector. Being able to more quickly adapt to industry changes and outmaneuver competitors has tremendous strategic significance. Services have been positioned as reusable IT assets; they can be repeatedly composed into different configurations. As a result, the time and effort required to automate new or changed business processes is correspondingly reduced because development projects can now be completed with significantly less custom development effort

Reduced IT Burden

Consistently applying service-orientation results in an IT enterprise with reduced waste and redundancy, reduced size and operational cost, and reduced overhead associated with its governance and evolution. Such an enterprise can benefit an organization through dramatic increases in efficiency and cost-effectiveness.

4.2.2 SOA Design principles

A principle is a generalized, accepted industry practice. It represents a highly recommended guideline for shaping solution logic in a certain way and with certain goals in mind. These goals are usually associated with establishing one or more specific design characteristics [15]. Standardized Service Contract

Services express their purpose and capabilities via a service contract. It is the most fundamental part of service orientation in that it essentially requires that specific considerations be taken into account when designing a services public technical interface and assessing the nature and quantity of content that will be published as part of a services official contract.

Service Loose Coupling

Coupling refers to a connection or relationship between two things. A measure of coupling is comparable to a level of dependency. This principle advocates the creation of a specific type of relationship within and outside of service boundaries, with a constant emphasis on reducing dependencies between the service contract, its implementation, and its service consumers.

Service Abstraction

This principle emphasizes the need to hide as much of the underlying details of a service as possible. Doing so directly enables and preserves the previously described loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions.

Service Reusability

The principle of Service Reusability emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

Service Autonomy

For services to carry out their capabilities consistently and reliably, their underlying solution logic needs to have a significant degree of control over its environment and resources. The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments

Service Statelessness

The management of excessive state information can compromise the availability of a service and adversely affect its scalability potential. Services are therefore ideally designed to remain stateful only when required.

Service Discoverability

Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted

Service Composability

The ability to effectively compose services is a critical requirement for achieving some of the most fundamental goals of SOC.4.2.3 Types of SOA

The intentional design of technology architecture is very important to successfully implement SOC. The following types of technology architecture exist underneath SOA [15].

1) Service Architecture:

It refers to the architecture of a single service. Services exist as independent and highly self sufficient and self contained software program requires that each be individually designed.

Abstraction (Information Hiding): In support of service abstraction design principle their contents are often protected and hidden from other project team members.

Design Standards: Various design standards are created and followed at Endpoint, Application and Data level while designing services.

Service Contracts: The technical contract expresses the scope and nature of underlying capability. It is in form of XML schema documents (XSD) and WSDL (Web Service Description Language) documents and Service Level Agreements (SLA).

Service Agents: Event Driven Intermediary programs, capable of transparently intercepting and processing messages sent to or from a service.

Service Capabilities: Functionality offered by a service resides within one or more capabilities.

2) Service Composition Architecture:

The architecture of a set of services assembled into service composition. Compositions are fully functional solutions capable of automating larger, more complex business tasks. Security, Transaction management, reliable messaging, and other infrastructure extensions may all find way into typical composition architecture. When composition architecture refers to another, it is called Nested Compositions.3) Service Inventory Architecture: The architecture that supports a collection of related services that are independently standardized and governed. The service inventory is first conceptually modeled leading to the creation of service inventory blueprint.

4) Service Oriented Enterprise Architecture: It represents all service, service composition and service inventory architectures that reside within a specific IT enterprise.

The following Figure4 represents the relative positions of the above architectures in SOA. SHAPE \* MERGEFORMAT

Figure4: Layered architectures.

4.2.4 Limitations of SOA

Where SOA is not to be used.

Following we highlight certain areas where SOA is not of much use [23].

1. Homogenous IT environment: If an organization uses the technologies of a single vendor then it is possible that the additional overhead of an SOA would not be cost effective. This is generally the case for small IT infrastructures like running a website. Homogeneity can be at hardware, software infrastructure, applications and data level.

2. True real time systems: SOA relies on asynchronous communication to provide loose coupling between service consumers and producers. It is not well suited to situations that require strictly enforced response times.

3. Old legacy systems: If the existing legacy system not requires and not expects any change in business logic, presentation, data flow, process or any other aspect of the application then there is no need to convert the application to SOA based.

4. Tight Coupling is required: Loose coupling is required for enabling communication in distributed computing environment, however if the communication need to know the details of the other end or if developer controls all the components at once then the components need to have an intimate understanding. So if you require tight coupling for high performance communications among components then SOA may not be appropriate.

Barriers of SOAHindrances on the way of implementing SOA can be at organizational, technical or at security level [15]. Some of these are discussed below:

1. Immutable Interface: Any change in a web service due to any reason may require a change in the interface, which may further break the service contract. Hence the updates are very hard to accommodate.

2. Standards are not furnished: Although organizations like OASIS (Organization for the Advancement of Structured Information Standards) are driving to develop standards for SOA, but the standards on security and interoperability are not yet complete.

3. Skill set: SOC is new paradigm, hence finding the right expertise is a challenging task.

4. HTTP Protocol: Web Services is the fundamental approach implementing SOA. It uses HTTP to send and receive messages between users and service providers. It is a stateless unreliable protocol. Newer protocols such as JMS, ESB supported by web services allow automatic handling of failure mechanisms which cannot be handled by HTTP.

5. XML Parsing: Parsing of XML (Xtensible Markup Language) is a time consuming process and directly proportional to the complexity of the XML data transferred between user and the service. Although newer technologies like XPP (XML pull parsing) are introduced, but there application is limited.

6. Reliability: Reliability on a third party unknown service is a major issue in SOC. For e.g. Web services are based on unreliable open internet connection, can be invoked by unknown parties and involve runtime discovery and dynamic binding.

4.3 Design Patterns

Concept introduced by Alexander Christopher. They are the proven solution to a common problem individually documented in a consistent format and usually as a part of a larger collection. They are generally repeatable by most IT professionals involved with design and can be used to ensure consistency in how systems are designed and built. Design pattern should have a consistent profile format and structure based on certain templates. These are used in most of the popular design patterns.

4.3.1 Design Pattern TemplateEach pattern description must follow a consistent rhetorical structure called the pattern template. There are many pattern templates viz. Alexanderian form consisting of name, problem and solution in form of diagram and description, Micro-pattern template containing name, problem and solution in precise manner, Inductive Mini pattern consisting of Name , context, forces and solution and many other [37]. A system of pattern templates comprises of the following elements, explained as the element followed by their context:

Name: What is this pattern called?Also Known As: What are other names for this pattern?

Example: What is an example of the need for this pattern?Context: When does this pattern apply?

Problem: What is the problem solved by this pattern?

Solution: What is the underlying principal underlying this pattern?

Structure: What objects are involved and related?

Implementation: What are some guidelines for implementing this pattern?

Variants: What are important variations of this pattern?

Known Uses: What are real world systems using this pattern?

Consequences: What are the benefits and liabilities of using this pattern?

See Also: What are related patterns and how do they differ?

Many best practices in the form of design patterns have been defined for SOA. Since services, service inventory, service composition are basic elements of service orientation, SOA design patterns have been classified as service inventory design patterns, service design patterns, service composition design patterns and common compound design patterns.

4.4 Antipatterns

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 resolved, reengineered and beneficial form of antipatterns. Those that describe only the negative solution are called pseudo antipatterns [37].

4.4.1 Antipattern viewpoints:

There are three major viewpoints in which the antipatterns can be discussed: the software developer, the software architect and the software manager. Hence the antipatterns can be discussed as development antipatterns, architectural antipatterns and management antipatterns.

Development or Design Antipatterns:They describe situations encountered by the programmer when solving programming problems. The antipatterns encountered in programming and code management, i.e. at the lowest level, are the design antipatterns. Popular design antipatterns include the Blob, Lava flow, Poltergeists, Dead end, C-P programming, Mushroom management etc.

Architectural Antipatterns: Architecture provides a view of the whole system through different viewpoints. Architecture antipatterns focus on system level and enterprise level structure of applications and components. Antipatterns that occur in defining and maintaining large structures of the system are architecture antipatterns. Software architecture is distinguished from development in many ways. The architect takes into account the cost of their decisions. He is responsible for managing complexity. Architecture focuses on three aspects of design viz. Partitioning, Interfaces and Connections. These decisions are implemented by a much larger group of developers. There are significant challenges for architects for example communicating the design to developers, managing the implementation and extension of the design. Popular antipatterns in this category include Stovepipe systems, Re-invent the wheel, Swiss army knife etc.

Management Antipatterns: Traditionally management chains conveyed information across organizational boundaries whereas in electronic organization communication can occur seamlessly across space, time, and boundaries. However managers still play important roles in the areas of software process management, resource management, and external relationship management. Antipatterns related to management i.e. in adoption, management of system and people, fall in the category of management antipatterns. Common management antipatterns include Blowhard jamboree, Analysis paralysis, Intellectual violence etc.

4.4.2 Antipattern Templates: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 are the some of the antipattern templates used to describe antipatterns:PseudoAntipattern Template:

Name: What is the Antipattern called?

Problem: What are its characteristics?

Mini Antipattern:

Name: What shall this Antipattern be called by practitioners?

Antipattern Problem: What is the recurrent solution that causes negative consequences?

Refactored Solution: How do we avoid, minimize, or re-factor the Antipattern problem?Full Antipattern Template:

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 organizations terminology when members discuss and document software and architectures.

Also Known As: This identifies additional popular or descriptive names and phrases for this Antipattern.

Most Frequent Scale: This identifies where this Antipattern fits into the software design level model. Each antipattern is logically placed in the scale where it is most applicable. The scale can be any of the following levels:

- Object level: It is concerned with the development of reusable objects and classes.

- Micro architecture: It involves patterns that combine multiple objects or object classes.

- Framework: This level includes patterns at the macro component level, involving one or more micro architectures.- Application: Applications typically involve numerous object classes, multiple micro architectures, and one or more frameworks.- System: A system comprises several integrated applications, which provide the functionality. It also adds interoperation between the applications

- Enterprise: The enterprise level is the largest architectural scale within an organization. Enterprise level software comprises multiple systems, where each system comprises several applications

- Global/industry: The global level is the largest scale of the architectural levels, comprising multiple enterprises.Re-factored Solution Type: It identifies the type of action that results from the Antipattern solution. It can be software, technology, process, or role. Software indicates that new software is created by the solution. Technology indicates that the solution entails acquisition of a technology or product. Process indicates that the solution entails pursuing a process. Role indicates that the solution entails assigning responsibility to an individual or group.

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: Distributed object technology enables application developers to define system level interfaces quickly using the ISO Interface Definition Language (ISO IDL). 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 slothlack 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 responsibility: 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 ad IT artifacts.

-Management of technology transfer refers to controlling the change in technology.

Background: This is an optional section. The background can contain further examples of where problems occur or general background information that is useful or interesting.

Symptoms and Consequences: This is a list of symptoms and consequences that result from this Antipattern.

Re-factored Solutions. This section explains a re-factored solution that is structured in terms of solution steps.

Chapter-5

SOA AntipatternsThere 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. Antipatterns 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 full antipattern template as described in the previous chapter comprises of number of required and optional sections. The core sections are the general form of the antipattern, and they specify the name, root cause, primal forces, description, the name of the antipattern to which the current antipattern is similar to, background, consequences, variations, known exceptions, example, related solution etc. The SOA antipatterns discussed below utilize this 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.

5.1 SOA Antipattern Categories

Antipatterns in SOA can also be classified primarily on the basis of classification of traditional antipatterns, as SOA management antipatterns, SOA architecture antipatterns and SOA development/ design antipatterns.5.1.1 SOA Development Process antipatterns

Development process comprises of all activities that have to be performed in order to arrive at an implemented system. Initial development of SOA based applications includes software process management, resource management, and external relationship management. Antipatterns related to such aspects of the development process i.e. in adoption, management of system and people, fall in the category of SOA development process antipatterns as shown in Table 1.

Table 1: SOA Development Process Antipatterns

5.1.2 SOA Framework antipatterns

Framework provides a view of the whole system through different viewpoints. It focuses on system level and enterprise level structure of applications and components. SOA antipatterns that occur in defining and maintaining large structures of the system are SOA framework antipatterns. The following antipatterns focus on some common problems and mistakes in the creation, implementation, and management of SOA framework. These are listed in Table 2.

Table 2: SOA Framework Antipatterns

5.1.3 SOA Design antipatterns

The antipatterns encountered in programming and code management, i.e. at the lowest level are the SOA design antipatterns as shown in Table 3. Patterns in IT that revolve around the design of automated systems are called design patterns. Many of the SOA design patterns have their origin and influences to established design concepts and pattern catalogue of object orientation, enterprise application and software architecture in general. Design patterns concentrate on design, development and realization of SOA. Design antipatterns focus on the worst practices encountered in programming and code design. Their knowledge is useful for the practitioners while, they work on designing services. Designing of service oriented systems involves the design of service inventory, service compositions and lastly services. On the basis of these, we further categorize SOA design antipatterns as follows:

Service inventory design antipatterns

Service composition design antipatterns

Service design antipatterns

General compound design antipatterns.

Table 3: SOA Design Antipatterns

These antipatterns are described individually with the following template: name, also known as, root cause, primal forces, description and re-factored solution. The term re- factored solution is the description of the positive consequences, after the re-factoring i.e. when the antipattern solution has been applied.

5.2 Conclusion

SOA antipatterns have been classified as SOA development process, SOA framework and SOA design antipatterns. 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. Interrelationships between these categorized antipatterns could also be established.Chapter-6

Proposed SOA AntipatternsIn order to fulfill the main objective of identifying new antipatterns, 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.

Viewing at different architectures underneath SOA as described in chapter 4, designing of a Service oriented application can be further broken up as service design, service composition design and service inventory design. Hence the SOA design is further categorized as

1) Service Design (SD)

2) Service Composition Design (SCD)

3) Service Inventory Design (SID)

4) 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. Following are the considered domain areas, the category in which they may be include is mentioned in brackets:

i) Concept of Service (SD)

ii) Service Scalability/Load Balancing (CD)

iii) Service discovery (CD)

iv) Service Composition (SCD)

v) Data Sources(CD)vi) Security (SID)

vii) Change request (SID)

The study of the above domain areas could be a major research area. Following are the observed common ways of implementing SOA but which later proved to be wrong way, hence can be identified as Antipatterns.6.1 SOA=SOAP

Newbies implementing SOA often consider that, the three standards that enable implementation of Web services are the Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). Here, 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-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 (Representational State Transfer) 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 implementing 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 (Create, Read, Update, Delete) operations REST way of implementing services is simpler and lightweight.

6.1.1 Refactored 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.

Following, we compare both the approaches 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. a) Approach

REST and SOAP are parallel ways of implementing web services. Let us first discuss the two different approaches of implementing web services. RESTful 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.

SOAP Based Web Services

In this method provider creates and implements a web service interface onto 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.

b) 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.

REST

In it 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 to access next.

SOAP

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.

c) Caching

It refers to the ability to maintain a copy of the desired resources in order to improve the performance.

REST

The result 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.

SOAP

A SOAP message is always with a POST method, which makes the cache server unaware of the actual intension 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.

d) 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.

REST

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.SOAP

There is no defined set of methods. Any type of methods could be defined which makes customization on application basis and reduces scalability.

e) InteroperabilityInteroperability means sharing the data amongst multiple applications. The more interoperable software programs are, the easier it is for them to exchange information.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).

SOAP

In this approach, each SOAP message provides its own unique method of naming a resource moreover 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.6.1.2 Standard Representation

Following the Standard Antipattern Template [14] and SOA Antipattern Template [37], 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.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 through Visual Studio 2008 and REST Based web service in java through Netbeans7.0.1.Figure5 represents a structure of SOAP based service. It shows various methods which are application specific and need not have a generic structure.

Figure5: Structure of SOAP based serviceFigure6 shows the structure of REST based service. It reflects certain methods like getJSON() to retrieve java script object notation form of data, getXML() to retrieve its XML format.

Figure6: Structure of REST based service.The figure 7 and figure8 below show the interface of the two services developed.

Figure7: SOAP based web service.

Figure8: REST based web service.

The Figures 9 and 10 below show the WSDL for SOAP based service and WADL for REST based service. Figure9: WSDL file for the SOAP based web service.

Figure10: WADL file for the REST based web service.

The next set of figures11 and 12 represent the checking of availabilty of the user ids. In REST Http get method is used while in SOAP appropriate application specific methods are used.

Figure11: Verification in SOAP based service Figure12: Verification in REST based service6.2 Using Plain WSDL to define all service interfaces.

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.

6.2.1 Refactored 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 [43]. 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 EJBs, Remote Java Objects and .NET objects without having to write SOAP bindings for them.

Currently, the WSDL specification introduces specific binding extensions for the following protocols and message formats:

- SOAP

- HTTP GET/POST

- MIME

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.

ImplementationThe figure13 below show the standard WSDL file for a simple web service in java.

Figure13: Standard WSDL representing a service.In the code segment below the information for locating the EJB is stored in section of the WSDL definition and the information for invoking the EJB is stored in the section.

Figure14: Code representing WSDL extensions using WSDL4J.6.2.2 Standard Representation

According to SOA Antipattern Template [37], 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 haste, 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 ejbs. Techniques for defining WSDL extensions have been proposed [12] and are one of the major research areas in WSDL.

6.3 Discovery of web service 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 and, quite often, end up becoming another bottleneck of SOA.6.3.1 Refactored 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. 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 Oracles OSR (Oracle service registry), But these application specific registries are very complex and far from the reach of a simple programmer.

6.3.2 Standard Representation

According to SOA Antipattern Template [37], 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 prefered for data access services. They are directly accessed through URIs hence require no central registry. Implementation

This antipattern can also be easily observed in the implemented module. The REST services are available as URIs hence require no service registry.

Figure14: REST based service discovered through URIs.6.4 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 oriented 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.

6.4.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 as mentioned in Figure7 [45]:

1) Standardized Service Contract: Services in the same inventory should follow same design contract.2) 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.The Figure7 below represents various service design principles.

Figure 7: Design principles playing their role in creation of a service [45].6.4.2 Standard Representation

According to SOA Antipattern Template [37], 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.Chapter-7Results and Conclusions7.1 Results

Service Oriented Architecture is the latest design paradigm for distributed applications. It has not been able to gain acceptance by mediocre and small companies as expected, even though software giants are shifting towards service oriented applications. The reason behind appears to be the complexity of SOA implementation and initial failed projects. After careful study of various SOA projects and its implementation certain root causes of the SOA revulsion were identified and presented in the given work as antipatterns. The main focus in the submitted work was identification of new SOA antipatterns.

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. The codes were developed in .Net and Java using VS2008 and NetBeans7.0.1 respectively.

7.2 Conclusions

Categorization of SOA antipatterns as development process, framework and design will definitely help the developers to concentrate on specific areas of SOA design. Identification of weak domain areas in SOA implementation will open wide aspects for SOA research. It is sincerely hoped that the identified four antipatterns will make SOA programmers more aware of the commonly made mistakes in SOA design and implementation. In our study we importantly laid stress on 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. A framework for building SOA applications could also be developed which would integrate various features necessary features for SOA implementations. WSDL extensions could also be defined for other approaches other than java and .Net. The concept of service registry should be simplified and a simpler tool than the existing ones should be developed.

Our Contribution

[1] D. Tripathi, Development Trends and Evolution of SOA, Proceedings of National Conference on Emerging Trends in Mechanical, Electronics and Computer Engineering, held at IIST Indore on 17th & 18th April 2010, pp 139-143.

[2] D. Tripathi, U. Suman, M. Ingle. A Systematic Review of Antipatterns in SOA , Proceedings of The International Conference on Computing Business Application and Legal Issues, Ghaziabad, 3-4 march2011, pp 1-7.

REFERENCES[1] L. Srinivasan, An overview of Service Oriented Architecture, Web Services and Grid Computing, HP (Hewlett Packard) White Paper, November 2006.

[2] D. Jana, Object Oriented Technologies, CSI Journal, February 2008, pp 4-5.

[3] http://en.wikipedia.org/wiki/Component-based software engineering.

[4] S. Chatterjee, An Introductory Overview of Web Services, CSI Journal, March 2007, pp 6-12.

[5] K. Kalaiselvan, P. Venata Krishna, Grid to Cloud (G2C) - A infrastructure based transition, CSI Journal, February 2010, pp 22-25.

[6] http://en.wikipedia.org/wiki/Cloud_computing.

[7] S. Zhang, X. Huo, X. Chen, Cloud Computing Research and Development Trend, Second International Conference on Future Networks, 2010.

[8] L. Hancheng, Design of SaaS-based Software Architecture, International Conference on New Trends in Information and Service Science, 2009.

[9] D. Chappell, Introducing Windows Azure, sponsored by Microsoft White Paper, March 2009.

[10] D. Jana, Service Oriented Architecture-A new Paradigm, CSI Journal, March 2006, pp 12-15.

[11] T. Erl, SOA: Principles, Concepts and Techniques, 1st Edition Prentice Hall, 2009.

[12] A. Kontogogos, P. Ageriou, An overview of Software Engineering approaches to Service Oriented Architectures in various fields, 18th IEEE International Workshop on Enabling Technologies, 2009.

[13] D. Tripathi, Development Trends and Evolution of SOA, Proceedings of National Conference on Emerging Trends in Mechanical, Electronics and Computer Engineering, held at IIST Indore on 17th & 18th April 2010, pp 139-143.

[14] J. Evdemon, Principles of Service Design: Service Patterns and Antipatterns, Microsoft Corporation, Architecture Strategy, August 2005.

[15] T. Erl, SOA: Design Patterns, 1st Edition Prentice Hall, 2009.

[16] G. Farrow, SOA Antipatterns, IBM White paper, June 2009.

[17] J. Kral, M. Zemlicka, The Most Important Service Oriented Antipatterns, ICSEA 2007.

[18] SOA Antipatterns: How not to do service Oriented Architecture, Oracle White Paper in Enterprise Architecture, January 2010.

[19] H. Hacigumus, Antipatterns: Integrating Distributed and Heterogenous Data Sources in SOA, IEEE Congress on services, www.IEEEXplore 2008.

[20] J. Kral, M. Zemlicka, Popular SOA Antipatterns, Computation World: Future Computing, Service Computation, Cognitive Content, Patterns, 2008.

[21] D. Tripathi, U. Suman, M. Ingle, A Systematic Review of Antipatterns in SOA , Proceedings of The International Conference on Computing Business Application and Legal Issues, Ghaziabad, 3-4 March 2011, pp 2-7.

[22] M. Endrei, J. Ang, A. Arsanjani, S. Chua, P. Comte, P. Krogdahl, M. Luo, T. Newling, Patterns: Service Oriented Architecture and Web Services, IBM Redbook, April 2004.

[23] C. Satish, Barriers of SOC, Proceedings of the Second Workshop on Introducing Service-Oriented Computing WISOC, 2007.

[24] S. Moosavi, M. Seyyadi, A method for Service Oriented Design, 6th International Conference on IT, New Generations, 2009.

[25] J. P. Hayes, K. Ford, Antipatterns in the creation of Intelligent Systems, Human Centered Computing, Published by IEEE computer Society 2007.

[26] N. Milanovic, Service Engineering Design Patterns, 2nd International Symposium on Service Oriented Systems Engineering SOSE, 2006.

[27] soa-rm-cs.pdf -Oasis reference model for SOA 1.0, Committee specification 2006.

[28] C. Smith, L. G. Williams, Software Performance Antipatterns, 2nd International Workshop on Software Engineering and Research, 2008.

[29] http://www.SoaPatterns.org.

[30] S. Chatterjee, A introductory overview of Web Services, CSI journal vol-29 issue-9, March 2007, pp 6-12.

[32] J. fronckowiak, SOA Best practices and design patterns, White paper, www.Oracle.com/technologies, March 2008

[33]http://java.sun.com/developer/techArticles/WebServices/soa3/loanprocessing.htm.

[34] T. Pandey, B. Singh, Authentication and Billing Framework for Service Oriented Architectures in various fields, 4th International Conference on Systems, 2009.

[35] S. Punita, C. Babu, Performance Prediction Model for Service Oriented Applications, 10th International Conference on HPC and Communications, 2008.

[36] Y. Zhao, Service Oriented Infrastructure Framework, IEEE Congress on Services 2008.

[37] W. J. Brown, R. Malveau, Antipatterns: Refactoring software, Architectures and Projects in crisis, 2nd Edition John Wiley & Sons, Inc, 1998.

[38] N. M. Josuttis, SOA in Practice, 1st Edition OReilly Media, August 2007.

[39] M. Mabrouk, SOA fundamentals in a nutshell, Technical Article www.IBM.com, September 2008.

[40] Mainframe SOA Implementation Best Practices, Technical article, SOA Software, April 2011.

[41] S. Tilley,SOA Migration Case Studies and Lessons Learned, IEEE 2011.

[42] F. Zao