Service Oriented Architecture: Patterns and Antipatterns - Literature review Example

? Service Oriented Architecture; patterns and antipatterns Introduction Service Oriented Architecture (SOA is an up and coming architectural technique that is largely being taken up in the industry. It makes it possible to improve distributed structures, which are adaptable, less costly and measurable. This is achieved by introducing convenient services, which are self sufficient and recyclable software components that have independent platform hence easy to retrieve through external network such as the internet. The stated architectural technique can be put into practice by employing a myriad of SOA expertise, for instance OSGi, SCA and Web Services. SOA enables the construction of a variety of Service Based Systems (SBSs) from business systems to cloud-based systems. Google Maps, Amazon, eBay, PayPal and FedEx are cases in point of extensive SBSs. Nonetheless, the up and coming of such systems brings to the fore a number of difficulties. Without a doubt, compared to other multifaceted software systems, SBSs have to undergo advancements in order to fit any arising consumer needs in terms of their workability and Quality of service (QoS). In addition, SBSs have to be advanced so as to accommodate most up-to-date implementation perspectives, for instance the inclusion of novel devices and technologies or procedures. Service Oriented Architecture (SOA) concept is intended to come up with distributed software founded in the idea of software services. A service is a distributed software element that has an open interface. It can be revealed and composed with other services so as to make available a more coarse grained functionality. SOA can put into practice business functions or business objects and thus sums up the functionality or information from one or more legacy applications. Any application that requires carrying out the business function/object can bring into play the services as a substitute for coming up with an incorporation solution for linking the applications. One of the main difficulties of coming up with service architectures in businesses is the detection of the borders. The borders mark the granularity of services involved in business procedures, thus taking into account several applications. After the services have been put into practice, they can then be oared across intranets and/or internet, thus making available a distributed software network that facilitates the uptake of diverse applications from several organizations. Initial service-oriented growth methodologies were wished for by the IT sector [2]. The two procedures centre on a business idea, and while undertaking the investigative stage, the two include the enterprise field and applications architecture field. While the enterprise field study is centered on business procedures, the examination is kick started by the review of the serviceable sectors of the business [2]. Moreover, the two have neither a thorough modeling structure nor do they talk about the cooperation between organizations. After Erl [1], the consistency organization OASIS comes up with enterprise service architectures [2]. The methodology is aimed at businesses and project levels and offers a vital notation. The notation is informally designed and is centered on a theoretical description of business services more than their comprehensive plan and execution. The investigative stage in Erl [2] only comprises of the business domain, thus ignoring the range of the concerned applications. The managerial functions refer to the service definition after which the business procedures act as a plan for service arrangements. A verifiable procedure for SOA growth was provided from academia in Erl [2].The input includes the blending of the schemes and procedures utilized for SOA growth. Included in the procedure includes preparation, examination, blueprint, assembly, testing, provisioning, operation, implementation and supervision stages. Dependence on situational models is stressed while undertaking analysis stage. Accepted modeling details are recommended for models in the various phrases of the growth course, although an integrator modeling framework is not supplied for all the phrases. Advancements, for instance the Business-driven Development (BDD) procedures, are usually supported by the stress that is often put on enterprise modeling for the SOA growth at the business level. BDD usually concerned with coming up with the intended software founded on theoretical business procedures that can be changed into implementable progressions for composed services. BDD usually uphold the quickness and plasticity in the installment of novel software solutions when alterations occur at the business process stage. At the implementation stage, an alteration on the theoretical process model can be hastily effected and thus a later implementation procedure can be developed. The Service-Oriented Architecture (SOA) design has been a controversial subject of discussion in the last 8 years. It is now well recognized and much has been documented on it. SOA is dependent on the below listed design doctrines: Standardized Service Contract – the common boundary of entry should be harmonized; Service Loose Coupling – the reliance of the service and the external environment should be unattached; Service Abstraction – the service is the concept that conceals the intricacy of business reasoning behind a harmonized boundary; Service Reusability – recycling is the fundamental feature of SOA advocating the commercial advantages of using this model; Service Autonomy – this doctrine promotes uniformity and dependability of competencies offered by a service element; Service Statelessness – the services should not be associated to any state to enhance their ability to handle the growing amount of work; Service Discoverability – it should be simple to find the services to enhance their recycle. Service Composability – intricate SOA products are usually made by configuration of exiting services. It is definite that these doctrines enhance the enlargement of SOA to handle growth and recycle of software elements, while focusing on the provision of commercial services. Architectural decision modeling is a developing discipline in software design study. Contrary to other methods to record software, architectural decision models pay attention to the adept skills hence encouraging specific designs instead of the resultant designs. Design components present style options with advantages and limitations, and also understood application; in addition they clearly show the logic behind and validation for the various kinds of decisions. In SOA construction, service realization decisions comprise of tactical matters such as technology and product selections, for instance, composition technology and workflow engine. Finer-grained modeling tasks like locating the precise service interface granularity (operation-to-service grouping, message signature shaping) develop a second decision category. Several resolutions are concerned with the redundant features for instance procedural dealings (business level compensation, system transactions). The incorporation of a situational data warehouse application on a personal computer, an e-commerce software package on a Linux workstation and a custom developed inventory management solution on a central mainframe computer are examples. In these structures, the following diverge; customer management, balance load, synchronization of simultaneous requirements, persist data and protection against security threats. These services enhance each other when being incorporated into SOA. Though the service boundary can be singled out in a theoretical, business oriented, and technology self-regulating way, the planning of the theoretical boundary to the execution apparatus while carrying out service realization vary in accordance with the three identified settings. This usually causes the variation in the resolution concerning the three systems. The mainframe often evaluates itself because the workflow engine is not always appropriate for the situational application due to granularity limitations. Common SOA design patterns SOA patterns are software blueprints in the framework of service architectures. Within their framework, they can be demonstrated in three parts based on their structure, difficulty and resolution descriptions. Renowned design prototypes for instance the GoF patterns are usually portrayed in a textual structure. The prescription of prototypes has been initiated so as to accomplish the needs of prototype upturn and automatic code creation procedures. In LABAs, SOA prototypes improve the business oriented service architecture resulting from consecutive changes from models in BML to SAL, into a service architecture that integrates prototype solutions for technological features for instance service invoking, service composition, security and others. A number of researches were examined in reference to SOA patterns [3, 4]. It has been found that the SOA patterns directory published by Erl [2] with the collaboration of many other candidate prototypes published on Lanza and Marinescu [5] website amounts to an inclusive compilation of the patterns, which are presently accessible. Erl’s compilation had all the important SOA patterns that also existed in the other works. In regards to 108 SOA, patterns were studied in two categories: A. Which pattern ought to be applied so as to enable a steady and full proof architecture when initiating the SODA conception? (Section 5.1-5.4) B. Define which of the patterns arrived at in (a) above are capable of determining the SODA-precise blueprint issues? ( Section 5.5) The usage of SODA leads to a set device services that can be applied to other services contained in a SOA. This then implies that each SOA pattern is readily usable with reference to the precise needs. Nonetheless, a division of SOA patterns can be arrived at and tried out in any SODA project so as to guarantee a reliable and foolproof architecture. Web service solutions In reference to the web service implementation study carried out in Settaset et al. (2011), value requirements, for instance the capability of the systems to accommodate what is required; dependability and workability have been rated as the next significant standard for an organization to choose web service solutions. An up to date study by Cherbakov, Ibrahim and Ang [6] shows that the majority of the value requirements can be majorly controlled by the software architecture (SA) blueprint. The study introduces a literature review of general architectural approaches for distributed web services usage founded on a cataloging format. This is projected in obtainable agent research community and the process comes up with improved SOA applications that can be used to accomplish business needs. Because of this, the designer has the will power of controlling the available architectural formats so as to come up with web services that can be pegged alongside precise system needs and resources. As a result of dissimilar cooperation styles amidst component web services, the WSC prototypes can be differentiated from orchestration and composition. Orchestration and composition models have been adequately established and clarified. The two depict two facets of WSC for generating business procedures [7]. WSC provide the theoretical framework that recommends the procedures for coming up with the web services. The three major categorization of WSC prototypes include: Composite pattern based WSC patterns This prototype is one of the commonly applied in the creation of compound apparatus. Bearing in mind, the composite web service is created from component web services, the compound prototype can be logically applied to the WSC. The two optional composite prototypes can summarize the web services in restraint composition and collective composition [8]. Evidently, the composite prototype founded on WSC prototypes signify the interior organization of composite web services. Workflow pattern based WSC patterns Implementable procedures are often explained by WSC and workflow administration and thus various workflow prototypes are usually appropriate for coming up with web services. Business Process Execution Language (BPEL) is, by law, the set format for WSC while BPEL practice requirement is a type of flowchart. Aalst et al. [9] went deep into illustrating how and to what end workflow procedures can be brought out in BPEL. In this format, individual procedure signifies a single control flow or message flow in the entire composition pattern, for instance Multi- Choice pattern and Broadcast pattern. Activity based WSC patterns Benatallah et al. [10] projected complete WSC procedures aimed at a two-sided service founded interfaces, many-sided service composition and the implementation of composite services. The stated prototypes deal with significant issues concerned with the plan, structuring and sustenance of the composite services. Every composition prototype highlighted attempts to explain each single happening that can be pegged down to the composition of web services, for instance either service discovery or service wrapping. Orchestration majors with the relationships of an individual web service in its surroundings and as a result, it can be reduced to a sequence of archaic workflow actions. On the other hand, choreography busies itself with the communication amongst the concerned web services, thus enabling conformity amongst the partakers. Implemented values or flow languages enables the detection of the prototype to which WSC fits in. As stated earlier, Business Process Execution Language (BPEL) is the legally recognizable language for web service orchestration and thus can be used in the implementation and the setting down of the regulations for running the non-observable information. The BPEL engine then implements the required activities. Web Services Choreography Description Language (WS-CDL) looks into mutual visible mannerisms of multiple web services that interrelate amongst themselves in order to attain a general objective. WS-CDL presents plans for the interaction amongst the partakers in choreography. BPEL accounts associated with WSCs, generally, have orchestration background, and on the other hand, WS-CDL accounts that include WSCs have choreography perspectives, for instance Valero et al. [11]. Because of this, the WSC prototype should not be viewed and then critiqued with reference to the keywords discussed since the technique can be taken up to suit diverse situations such as the backing of theoretical BPEL as a choreography language by a number of people. In order to arrive at a dependable opinion, the WSC process should be well comprehended. MEPs refer to prototypes that concretize the string of message broadcast in the web service situation. Under the HTTP system, RESTful web services have a simultaneous request and feedback prototype. SOAP based Web services permit rich prototypes that vary from traditional request-feedback to dissemination and complicated message interactions. The most recent WSDL 2.0 has been made available with sustaining eight MEPs [12]. Common SOA design antipatterns Although an antipattern is commonly applied, it is generally unsuccessful in solving difficulties. Initially, the phrase applied to an erroneous pattern. The same way a feasible pattern illustrates the pathway from a difficulty to an effective resolution, an antipattern illustrates the pathway from a difficulty to a less effective resolution. In addition, increasing the problems to the ones that are already available, an antipattern may place one in a shoddier spot compared to the previous one before it was applied. The most widespread antipatterns in SBSs are Multi Service and Tiny Service. It has been proven that Tiny Service is the major cause of numerous SOA malfunctions [13]. In addition, SBSs have to be advanced so as to accommodate most up-to-date implementation perspectives, for instance the inclusion of novel devices, technologies or procedures. These transformations at times demean the intended plan and QoS antipatterns arising from the said alterations thus making it difficult for the software engineers to sustain and advance the systems. Multi Service is an SOA antipattern that resembles a service that carries out several techniques associated with various business and technical abstractions. This service cannot be recycled without difficulty due to the poor interrelation of its procedures and because it is usually inaccessible to final users due to its overburden. On the other hand, Tiny Service is a little service with lesser procedures that simply executes a portion of an abstraction. This service normally needs many combined services to be applied jointly resulting in an advanced complexity and decreased flexibility. The spontaneous discovery of the above antipatterns is a vital action to evaluate the design and QoS of SBSs and simplify the upkeep and advancement activities of software experts. Nevertheless, less has been written on SOA antipatterns, and approaches and procedures for the recognition of antipatterns in SBSs are still in their initial stages. Recently, Kr?al and Zemli?cka [13] explained seven SOA antipatterns that are as a result of inappropriate application of SOA standards and inappropriate habits adopted from the OO design style. Additional books are available on SOA patterns and principles [3, 2], which offer strategies and ideologies describing “suitable” service focused designs. These books assist software engineers to evaluate the value of their systems and avail a platform of making the design better, as well as its execution. There are numerous procedures and apparatus used for identification (4; 5; 14) and rectification [15] of antipatterns in OO systems and many books are available on that subject. For instance, Brown et al. (2006) compiled a group of 40 antipatterns, Beck, in Fowler’s well known book on refactoring [17], came up with 22 code smells, which are low-level antipatterns in source code, proposing everyplace that refactorings ought to be employed. A major source of the OO antipatterns is the implementation of a methodological design style in OO system. For SOA antipatterns, it is as a result of the implementation of an OO style design in SOA system [13]. Conversely, the above OO recognition procedures and apparatus are indirectly applicable to SOA. Without a doubt, SOA centers on services as top notch objects while OO centers on categories that are at low position of granularity. Furthermore, the very flexible quality of an SOA setting has resulted to a number of difficulties that are not experienced in OO development and needs flexible assessment. Additional similar works have narrowed on the discovery of antipatterns associated with system’s functioning and resource usage and–or given know-hows. For instance, Wong et al. [18] applied a genetic algorithm in order to discover software errors and irregular performance associated with the resource usage of a system (for example memory application, processor application, and thread count). This methodology is founded on utility functions, which relate to predicates that detect doubtful performance centered on resource usage metrics. For instance, a utility function might experience an irregular performance if it identifies numerous threads. In an additional important work, Parsons and Murphy [19] suggested a methodology to be used in the discovery of performance antipatterns particularly in component-based enterprise systems (specifically, JEE applications) by means of a rule-based method dependent on rigid and flexible scrutiny. Though the past works on OO systems and performance antipattern recognition are dissimilar, they provide a comprehensive base of know-how and practical information construction procedures for the discovery of SOA antipatterns. The intricacy of enterprise applications exists because of the large quantity and range of services. These services are necessary to satisfy the requirements of customers’ diverse business situations. Company’s customers differ, and they all have different needs, which must be met by a standardized structure. In order to meet the requirements of their customers, dealers in software can add new services or make the current services multipurpose making them more internally complex. Consumers of E-SOA APIs, therefore, encounter application difficulties not yet experienced in APIs for other domains. A popular anti-pattern referred to as hazardous for usage is a fine-grained design with numerous services, which result to coming up with the right service difficulty [20]. In addition, offering uneven -grained design of less, multiuse services make it hard for them to sustain and comprehend because they have several factors regulating deviations of performance. Nevertheless, due of the widespread character of the client base, not only must business process vendors provide a continually growing range of countless services, however, many of these are also internally complex to sustain a diversity of client deeds. As a consequence, dealers at the same time experience equally the difficulties linked with fine-grained services and those linked with coarse-grained services. Innovative resolutions to lower difficulty and increase applicability of SOA APIs are essentials that may be simplified across other SOA API design attempts. Jones (2006) recorded anecdotal SOA “antipatterns”, or regular errors created during improvement of SOA architectures. They comprise of complications initiated by service hierarchies that are either excessively fine-grained or excessively coarse-grained. The answers for the two circumstances are to shift the direction of the contrasting extreme, which corporations with huge corporation software structures, will never perform before the removal of functionality and isolation of current clients. For that reason, new solutions are necessary. There are some transformations that at times demean the intended plan and QoS antipatterns arising from the said alterations thus making it difficult for the software engineers to sustain and advance the systems. A number of schemes attempting to convert business processes into implementable procedures have been brought to the fore within the perspective of BDD [13, 21, 22]. They centre on interpreting of the process modeling notations for instance, BPMN or UML- activity diagrams into implementable process languages such as WS-BPEL3. The notion of workflow is initiated by the authors so as to sustain the conversion [13]. The presumption that software services enjoy a close relationship with performance of modeled enterprise processes is usually a limitation. Software services at times usually engage a myriad of business actions or can be more granular than a business action. Apprehension regarding the limitations enforced by the applications and the final inspection on the other issues affecting the business is debated on Lanza and Marinescu [23]. Proposed SOA patterns solutions Nowadays, business Java applications are divided into three segments namely; the front-end interface to the customer, the service layer that is usually linked to the business information systems and the enterprise layer. Recent years have seen a rise in the number of structures that can accommodate the front-end interface and the service layer. Examples of such structures include Struts, Spring, Hibernate, Enterprise Java Bean and JDO. These structures are not as effective as JBoss Drools. Most linked software applications face the challenge of having to move data from one place to another, for instance, through the email. JBoss Drool In drools, specifics, which are essential for any resolution reached, are usually stored on the functional memory. These specifics are usually derived from databases, current happenings and logs. In the example of a medical doctor, the information that the patient provides, the doctor’s own practice and the disease symptoms allows them establish the illness. In business services for instance JBoss and ESB in the SOA platform, routing denotes the distribution of messages to the intended services. Various forms of routing information to a service are readily available, for instance, some are static (information is intended for a specific end user). In cases where the end user has been moved or out of stock, the delivery is unsuccessful. ESB enables one determine the route that data will take depending on the subject. JBoss Drools is also good in prototype execution because it has excellent tool support; it is readily available and is an open source invention. Rules 1 enables JBoss Drool to recognize canonical schema prototype in reference to the model alteration. This rule describes a problem by pointing out services that employ diverse models with alteration needs for similar information. The day to day operation of a bank, for instance, the loan authorization process using the Drools Flow module, is an ideal model to illustrate the functionality of rule 1. Banking fraud exposure structures are usually executed using the Drools Flow module, a multifaceted component of Drools. The same also enables other groups keep checks on deceitful customers who could be using systems unlawfully. One of the benefits is the decrease in development overheads, which is achieved by use of rules engine to decrease complexity in improvement of software components, which is simpler than using conventional code. Another benefit is the decrease in upkeep costs because when corporation rules are fixed into procedural code, any amendment experiences recompilation, analysis and rearrangement expenditures. Software upkeep costs are usually 70 percent of development overheads. In addition, when rules are controlled from a focal point, they exist for longer compared to individual application, therefore, they can be used many times as well as jointly. This ensures that skill is maintained even when people leave. Moreover, rule engines enhance operation by use of algorithms like Rete that sifts through large quantities of rule sets at a high speed, but it is difficult and costly to use conventional coding techniques. Furthermore, rules engine enables the use of a standardized framework for the citation of business rules. The frameworks make upkeep easy; value is enhanced as well as consistency. Additionally, rule engines enable a corporation prove that it conforms to regulations in its daily undertakings. This is because decision services can consist of cross-cutting concerns like logging and incident announcements while enhancing the discernibility to corporation rules controlled from a focal point. Finally, rules engine ensure that software gain value. Without rules engine, translation of rules is done by software engineers and errors are likely to occur. Taylor and Raden show that, “Inserting business knowledge in the system is difficult because those without corporate knowledge are not able to code, and those who comprehend the code cannot manage the business” [24, p. 45]. Advantages of JBoss Drool Declarative Programming: this solution allows the programmers to say what to do rather than how to do it. Therefore, it is easy to express solutions to complex problems and also verify them. Easy to code: rule systems solve complex problems very easily, and also clarify the manner in which the solution is found. It is also easy to establish why each decision is made. Data and logic separation: while the logic is the rules, the data is the domain objects. This means that OO logic and coupling is fundamentally broken, which could be an advantage. In other words, it is easy to maintain logic since it is all laid out in rules and changes in the future are available. This is particularly the case if the logic is multi-domain logic or cross-domain. Scalability and speed: the Leaps and Rete algorithm together with their descendants offer very good ways of putting equivalent rule patterns together to the domain object data. As such, the datasets are very efficient and change slightly since the past matches can be remembered by the rule engine. Centralization of Knowledge: Executable repository knowledge is created when rules are used. This makes it a very ideal single point of truth, which can be applied in business policy. Actually, the rules can act as documentation because they are very easy to read. Tool Integration: methods of editing and managing rules can be executed through tools such as Eclipse and perhaps web based interfaces; this also makes it possible to receive an immediate content and validating assistance as well as feedback. Furthermore, debugging and auditing are readily available. Explanation Facility: an explanation facility is provided by the rule systems. This is possible because the rules systems are able to log the decisions originating from the rule engine. This is done alongside the reasons for making such decisions. Understandable Rules: The Domain Specific Languages, which are used to create the problem domain, can enhance writing of rules that resemble natural language – this is improved by creation of object models. Disadvantages It is mathematical and complex to execute constraints Simplex is not implemented by drools planner The time when the optimal solution has been gotten is not easy to identify Usually, the optimal score is not known and hence it must be instructed when to end searching, depending on user input, time spent and time. Proposed SOA antipatterns solution Antipattern, though an erroneous design prototype is often sought after although it gives a fruitless conclusion to a difficult situation. Despite its inefficiencies, they have been widely adopted in many applications. They have been adopted in many applications because they uncover solutions whose implementation fails to produce the intended results. Antipatterns are usually discussed in outlines that discover indicators, costs, derivation points and the possible solutions. Although there is inadequate data about antipatterns as compared to patterns, they are easily identifiable by the software fraternity. Examples of antipatterns that have colorful monikers include analysis-paralysis, blob, spaghetti code and stove pipe systems. Antipatterns are vital because they identify issues before they turn into bigger problems. They also supply facts on how the identified problems can be overcome or offer a recuperation procedure in dire cases. Antipatterns can be comprehensively studied by reviewing the formal codification. Bell [25] introduced a simple SOA Modeling patterns and Service-Oriented Modeling Framework (SOMF) aimed at overcoming the communication barriers between IT professionals and business. The patterns provided by Bell [25] have discovery processes, road-tested analysis, as well as design solutions that can be used to build an analysis proposal, which is used to address technological and business issues. This author has focused on SOA experience and knowledge, which offers a good guide for direct service-oriented projects. His guide offers focused answers on the difficult questions that emerge in the course of the development process, which is designed to equip users with discovery services, analysis of the problem domain, and evaluation of deployment’s service feasibility. Other benefits derived from this guide includes identification of services and analysis of proposed technological solutions and business; application of SOA modeling anti-pattern and patterns for analysis and service discovery. SOA modeling patterns are essential technology and business service-oriented designs for architects, managers, analysis, developers and modeler. Furthermore, SOA Modeling Patterns for analysis and Service-Oriented Discovery enable organizations to develop services that make use of SOA benefits of SOA by applying its tools and terminology. In addition, “this guide enables design and implementation best practices for Enterprise 2.0” [25, p. 26]. Indeed, this is the up and coming SOA generation that has become very popular nowadays. A powerful technological and business strategy can be developed by the use of modeling language. These benefits can be realized in relation to Virtual Modeling Ventures, implementations, and future Cloud Computing Projects. The shiny nickel The shiny nickel is used to integrate the most recent technology within an SOA. This includes coming up with an ESB to serve 2 services, which lack routing or translation requirements. Advantages This can be fixed by establishing the root of the problem and what is intended to be achieved. It is very easy as it only requires understanding of the steps and terminologies as well as acquiring the IT procurement so that decisions are approved accordingly. Disadvantages These solutions are concerned with the use of product procurement cycle and new technologies more than the solution that is being delivered in the real situation. Furthermore, the projects are referred to names such as “SAP Netweaver”, “BizTalk” among many others, rather than referring to them according to the intended functionality. In addition, these solutions comprise of massive turnover and volume of technology, yet technologies are hardly recycled as the subsequent shiny nickel is used for IT delivery. Because of these complexities, each project increases the cost and creates integration difficulties for future projects [24]. References 1. Erl, T., 2007. SOA Principles of Service Design. Boston, MA: Prentice Hall PTR. 2. Erl, T., 2009. SOA Design Patterns. Boston, MA: Prentice Hall PTR. 3. Daigneau, R., 2011. Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services. London: Addison-Wesley. 4. Kessentini, M., Vaucher, S., Sahraoui, H., 2010. Deviance From Perfection is a Better Criterion than Closeness to Evil When Identifying Risky Code. In: Proceedings of the IEEE/ACM International Conference on Automated Software Engineering. New York, NY: ACM. 5. Lanza, M., Marinescu, R., 2006. Object-Oriented Metrics in Practice. London: Springer-Verlag. 6. Cherbakov, L., Ibrahim, M., Ang, J., n.d. SOA Antipatterns: The Obstacles to the Adoption and Successful Realization of Service-Oriented Architecture. [Online] Available at < www.ibm.com/developerworks/webservices/library/ws-antipatterns/> [Accessed 5 October 2011]. 7. Liu, L. and Ozsu, M. T., 2010. Encyclopedia of Database Systems. New York: Springer. 8. Byun, S. Y., 2007. Study on the Web service composition and connection patterns. Proceedings of the 5th ACIS International Conference on Software Engineering Research, Management & Applications (SERA 2007). IEEE Computer Society, pp. 903-910. 9. Aalst, W. M., Dumas, M. and Hofstede, A. H., 2006. Analysis of Web services composition languages: The case of BPEL4WS. Proceedings of the 22nd International Conference on Conceptual Modeling (ER’03). Heidelberg: Springer. 10. Benatallah, B., Dumas, M., Fauvet, M. C. and Rabhi, F., 2003. Towards patterns of Web services composition. Patterns and Skeletons for Parallel and Distributed Computing. Heidelberg, Springer. 11. Valero, V., Cambronero, M. E., Diaz, G. and Macia, H., 2009. A petrinet approach for the design and analysis of Web services choreographies. Journal of Logic and Algebraic Programming 78(5): pp. 359-380. 12. Lewis, A. A., 2007. Web services description language (WSDL) version 2.0: Additional MEPs. W3C Working Group Note.[Online] Available at < http://www.w3.org/TR/wsdl20-additional-meps/> [Accessed 5 October 2011]. 13. Kr?al, J., ?Zemli?cka, M., 2008. Crucial Service-Oriented Antipatterns. International Academy, Research and Industry Association (IARIA), 2, pp. 160-171. 14. Settas, D.L., Meditskos, G., Stamelos, I.G. and Bassiliades, N., 2011. SPARSE: A symptombase antipattern retrieval knowledge-based system using Semantic Web technologies. Expert Systems with Applications 38(6), pp. 7633–7646. 15. Simon, F., Steinbruckner, F. and Lewerentz, C., 2011. Metrics Based Refactoring. In: Proceedings of the 5th European Conference on Software Maintenance and Reengineering. pp. 14–16. 16. Brown, W., Malveau, R., McCormick III, H. and Mowbray, T., 2006. Anti Patterns: Refactoring Software, Architectures, and Projects in Crisis. New York: John Wiley and Sons. 17. Fowler, M.J., Beck, K., Brant, J., Opdyke, W. and Roberts, D., 2007. Refactoring: Improving the Design of Existing Code. London: Addison-Wesley. 18. Wong, S., Aaron, M., Segall, J., Lynch, K. and Mancoridis, S., 2010. Reverse Engineering Utility Functions Using Genetic Programming to Detect Anomalous Behavior in Software. In: Proceedings of the 2010 17th Working Conference on Reverse Engineering. Washington, DC: WCRE ’10, IEEE Computer Society. 19. Parsons, T. and Murphy, J., 2008. Detecting Performance Antipatterns in Component Based Enterprise Systems. Journal of Object Technology 7(3), pp. 55–90. 20. Jones, S., n.d. “SOA Anti-Patterns,” Jun 19, 2006. C4Media Inc.: InfoQ.com. [Online] Available from [Accessed 5 October 2011]. 21. Galaxy INRIA, n.d. The French National Institute for Research in Computer Science and Control. galaxy.gforge.inria.fr 22. Jones, S., n.d. SOA Anti-patterns. [online] Available from < www.infoq.com/articles/SOA-anti-patterns>[Accessed 5 October 2011]. 23. Lanza, M. and Marinescu, R., 2006. Object-Oriented Metrics in Practice. London: Springer-Verlag. 24. Taylor, J. and Raden, N., 2007. Smart Enough Systems: How to Deliver Competitive Advantage by Automating Hidden Decision. Boston: Pearson Education, Inc. 25. Bell, M., 2010. SOA Modeling Patterns for Service Oriented Discovery and Analysis. London: Wiley. Read More