Hypotheses Verification for High Precision Cohesion Metric

Total Page:16

File Type:pdf, Size:1020Kb

Hypotheses Verification for High Precision Cohesion Metric International Journal of Computer Science and EngineEngineeringering Open Access Research Paper Volume-2, Issue-4 E-ISSN: 2347-2693 Hypotheses Verification for High Precision Cohesion Metric Kayarvizhy N 1*, Kanmani S 2 and Rhymend Uthariaraj V 3 1*Department of Computer Science and Engineering, AMC Engineering College, India 2 Department of Information Technology, Pondicherry Engineering College, India 3Ramanujan Computing Centre, India www.ijcaonline.org Received: 03/03/2014 Revised: 19/03/2014 Accepted: 15/04/201x4 Published: 30/04/2014 Abstract— Metrics have been used to measure many attributes of software. For object oriented software, cohesion indicates the level of binding of the class elements. A class with high cohesion is one of the desirable properties of a good object oriented design. A highly cohesive class is less prone to faults and is easy to develop and maintain. Several object oriented cohesion metrics have been proposed in the literature. In this paper, we propose a new cohesion metric, the High Precision Cohesion Metric (HPCM) to overcome the limitations of the existing cohesion metrics. We also propose seven hypotheses to investigate the relationship between HPCM and other object oriented metrics. The hypotheses are verified with data collected from 500 classes across twelve open source Java projects. We have used Pearson’s coefficient to analyze the correlation between HPCM and the metrics in the hypotheses. To further bolster our results we have included p-value to confirm the statistical significance of the findings. Keywords—Object Oriented Metrics; Cohesion; High Precision I. INTRODUCTION values. Li and Henry [10] proposed their version of lack of Object oriented design and development continues to be the cohesion (LCOM3) as the number of connected components most widely used methodology for designing high quality in a graph with methods as node and edges between each software. Ensuring the quality of such systems is of prime pairs of methods with at least one common attribute. Hitz interest. Eliminating defects that affect quality in early stages and Montazeri [11] enhanced the LCOM3 to include edges of software development life cycle, like design, saves cost for method to method invocations as well and named it and effort [1] [2] [3]. Object oriented design-level metrics LCOM4. Henderson-Sellers [12] came up with LCOM5 and their associated quality prediction techniques attempt to which included the number of distinct attributes accessed by ensure quality during the design and early coding phase. each method. LCOM3, LCOM4 and LCOM5 show high Many object oriented metrics have been proposed to values of cohesion even with a single common attribute compute an underlying property like cohesion, inheritance among methods. After LCOM5, the cohesion metrics and coupling. Cohesion metrics indicate how well the class proposed were direct cohesion metrics compared to the elements bind with each other. Since a class consists of two inverse nature of lack of cohesion metrics proposed till then. basic sets of elements, attributes and methods, all of the The first direct cohesion metric, Connectivity (Co) was cohesion metrics revolve around the usage of these. A high introduced by Hitz and Montazeri [13]. Briand et al [21] cohesion value indicates that the class is well structured and proposed Coh which uses the concept of number of attributes provides the stated functionality with the help of well-knit used by each method. Bieman and Kang [14] introduced attributes and methods [4]. Conversely a low cohesive value TCC (Tight class cohesion) and LCC (Loose class cohesion) indicates a class that may need to be split or redesigned. A which captured the methods connected through attributes non-cohesive class is a maintenance nightmare and is prone directly and indirectly. Badri [15] introduced variations on to faults [5] [6] [7]. TCC and LCC naming them DCD and DCI which includes Several cohesion measures have been proposed in the method invocations also, directly or in the call trace literature. Chidamber and Kemerer [8] proposed the first respectively. TCC, LCC and their derivatives DCD and DCI cohesion metric. They presented an inverse metric, thus also give skewed cohesion values when a single common measuring the lack of cohesion (LCOM1). LCOM1 attribute exists in all methods. The metrics that were measures the number of pairs of methods that do not have proposed further were based on the similarity between any common attribute. Chidamber and Kemerer [9] revised methods based on the number of common attributes used their metric and came up with an altered version (LCOM2) between them. Bonja and Kidanmariam [16] defined Class which found the difference between the number of pairs of Cohesion (CC) based on this similarity of methods. The methods not sharing any attribute and those sharing at least concept was further enhanced by Fernandez and Pena [17] in one attribute. LCOM1 and LCOM2 do not have normalized their metric Sensitive Class Cohesion Metric (SCOM). Bansiya et al. [18] defined Cohesion among Methods in a Corresponding Author: Kayarvizhy N, [email protected] class (CAMC) as a modified version of Co. Counsell et al © 2014, IJCSE All Rights Reserved 238 International Journal of Computer Sciences and Engineering Vol.-2(4), pp ( 238-243) April 2014 , E-ISSN: 2347-2693 [19] also introduced Normalized Hamming Distance (NHD) shared by majority of its methods. This is not realistically and Scaled Normalized Hamming Distance (SNHD) based captured by CC and SCOM. on how many attributes each method accesses. Al Dallal and The motivation for a new metric is to have a fine grain value Briand [20] came up with Low-level design Similarity based for cohesion. HPCM differentiates classes with similar but Class Cohesion (LSCC) which finds out how many methods not identical cohesion. HPCM values are normalized on a access each attribute. SCOM, CAMC, NHD, SNHD and scale of 0 to 1. LSCC give high cohesion values in the presence of few B. Definition of HPCM common attributes across methods. In this paper, we propose a new cohesion metric, the High The High Precision Cohesion Metric (HPCM) is based on Precision Cohesion Metric (HPCM) to address the two related concepts – Average Attribute Usage (AAU) and limitations in the existing cohesion metrics. HPCM is Link Strength (LS). The AAU is a separate metric which designed to give precise cohesion values. We then analyze computes the average number of attributes used by each the proposed metric with hypotheses. This paper is organized method of the class directly or indirectly through a method as follows. Section 2 explains the High Precision Cohesion invocation. We consider only public, non-inherited methods Metric (HPCM) in detail. In Section 3 we propose seven of a class. Inherited attributes are also not considered for hypotheses capturing the relation between HPCM and other computation of AAU. Let ’c’ be the class in consideration. OO metrics. These hypotheses are verified empirically in Then is the set of non-inherited, overriding or newly Section 4. Section 5 lists the limitations and future work and implemented͇ ʚ͗ʛ methods of c. Further is the set of Section 6 concludes the study followed by a list of public methods of c. Public non-inherited͇+0 ʚ͗ ʛ or overridden references. methods are given by . The total number of methods in our case ͇is ʚthe͗ʛ ∩cardinality ͇+0 ʚ͗ʛ of such a set. It is II. HIGH PRECISION COHESION METRIC given by . The attributes referenced by a |͇ ʚ͗ʛ ∩ ͇+0 ʚ͗ʛ| A. Limitations of existing Cohesion Metrics method is given by AR(m) where m is the method. Hence total attributes referenced is given by , for each m LCOM1 and LCOM2 are not normalized in their value and in the set . Hence the∑ ̻͌ʚ͡ʛ AAU is given in hence it is difficult to compare their values between two Equation (1).͇ ʚ͗ʛ ∩ ͇+0 ʚ͗ʛ classes and understand their relative cohesion. Their values are dependent on the number of methods in a class. Hence their values can grow to very high values. Consider two ∑ ̻͌ ʚ͡ʛ (1) classes, c1 and c2 which have two and four methods each. ̻̻͏ = ʚ ʛ +0 ʚ ʛ The attributes accessed by the methods are listed here - c1m1 |͇ ͗ ∩ ͇ ͗ | {a1}, c1m2 {a2}, c2m1 {a1}, c2m2 {a2}, c2m3 {a3}, c2m4 Link Strength is a concept to capture the level of interaction {a4}. Each method accesses just a single unique attribute in between a pair of methods based on the number of attributes both the classes. But the values of LCOM1 and LCOM2 are commonly used between them. Link Strength (LS) is based very different for the classes. LCOM1(c1) = LCOM1(c2) = 1 on AAU. LS for a pair of methods m1 and m2 is given in and LCOM2(c1) = LCOM2(c2) = 6. Equation (2). LCOM3 and LCOM4 are also not normalized in their value but the range is improved over LCOM1 and LCOM2. But LCOM3 and LCOM4 suffer from a different issue. Consider ̻̽(ͥ(ͦ = |̻͌ ʚ͡1ʛ ∩ ̻͌ ʚ͡2ʛ| class c1 with the following method-attribute interactions - (2) ̻̽(ͥ(ͦ c1m1 {a1, a2, a4}, c1m2 {a3, a5, a4}, c1m3 {a6, a7, a4}, , ͚͝ ̻̽(ͥ(ͦ ≤ ̻̻͏ c1m4 {a7, a8, a4}, c1m5 {a9, a10, a4}, c1m6 {a11, a12, a4}. ͍͆ (ͥ(ͦ = ƥ ̻̻͏ The methods are not cohesive since they all share just one 1, ͚͝ ̻̽(ͥ(ͦ > ̻̻͏ common attribute between them and use their own unique set of attributes otherwise. However LCOM3 and LCOM4 HPCM is defined using Link Strength. We define HPCM as give the class a perfect cohesion value of 1. The same given in Equation (3) limitation applies to TCC, LCC, DCD and DCI. CC and SCOM cohesion metrics vastly improve on the idea of similarity.
Recommended publications
  • Focus on Apache Camel 23 3.1 Classification
    Institute of Architecture of Application Systems University of Stuttgart Universitätsstraße 38 D–70569 Stuttgart Diploma Thesis No. 3480 Complete Enterprise Topologies with routing information of Enterprise Services Buses to enable Cloud-migration Andre Grund Course of Study: Software Engineering Examiner: Prof. Dr. Frank Leymann Supervisor: Dipl.-Inf. Tobias Binz Commenced: May 01, 2013 Completed: October 28, 2013 CR-Classification: E.1, K.6 Abstract The Enterprise Service Bus is an important part of todays enterprise IT landscape. It offers the integration of applications build on different platforms without adaptation. This is accomplished by offering message transformation and routing capabilities of client requests to the designated endpoint service. However, Enterprise Service Buses also introduce an additional indirection between the client and the called backend application. Enterprise Topology Graphs capture a snapshot of the whole enterprise IT and are used in various use cases for analysis, migration, adaptation, and optimization of IT. The focus of this work is to enhance the ETG model with structural and statistical information about an enterprise. However, due to the decoupled architecture the information is hidden inside the ESB and not directly accessible. Furthermore, the arrangement and semantics of the routing entities are unknown. The existing ETG Framework includes the automated discovery and maintenance of ETGs, but offers no solution for ESB components in the enterprise IT. This thesis provides an in depth analysis of the ESBs Apache Camel and Apache Synapse. It applies information gathering concepts and evaluate them with a prototypical implementation of an ETG Framework plugin. Using tailored information gathering and presentation methods to enhance ETGs with routing information.
    [Show full text]
  • SOA and Open Source
    SOA and Open Source Service Business Ma Consumers Systems Portals Web Apps M nageme onitorin g ance Business Process n nn Management t & Composite Services Gover CEP -CEP B AA SO Core Services Business AM Systems COTS Legacy Inhouse Magnus Larsson Callista Enterprise AB Vendor support of Open Source SOA • Vendors provide services for training, consulting and support on selected Open Source SOA products • MuleSource – Over 1000 mission-critical production installations worldwide! – http:// www.mu lesou rce .co m/custo me rs/casestud ies .p hp •WSO2 – http://wso2.com/about/whitepapers/ • Progress FUSE – http://fusesource.com/resources/collateral/ SOA and Open Source Copyright 2009, Callista Enterprise AB Building a SOA Reference Model… Service Business Portals Web Apps Consumers Systems Business Systems COTS Legacy Inhouse SOA and Open Source Copyright 2009, Callista Enterprise AB Building a SOA Reference Model… • Connectivity Service Business - SOAP, Rest, Messaging, Database, FTP… Portals Web Apps Consumers Systems • Transformation - XML, CSV, Fixed Position… • Routing - Header and/or Content based • Enterprise Integration Patterns - Splitting, Aggregation, Resequencing… Core Services Business Systems COTS Legacy Inhouse SOA and Open Source Copyright 2009, Callista Enterprise AB Building a SOA Reference Model… Composite Services Service Business Portals Web Apps Consumers Systems ‐ Course Grained ‐ Internal Messaging High performance access to other services CitComposite Services Core Services Business Systems COTS Legacy Inhouse SOA
    [Show full text]
  • Return of Organization Exempt from Income
    OMB No. 1545-0047 Return of Organization Exempt From Income Tax Form 990 Under section 501(c), 527, or 4947(a)(1) of the Internal Revenue Code (except black lung benefit trust or private foundation) Open to Public Department of the Treasury Internal Revenue Service The organization may have to use a copy of this return to satisfy state reporting requirements. Inspection A For the 2011 calendar year, or tax year beginning 5/1/2011 , and ending 4/30/2012 B Check if applicable: C Name of organization The Apache Software Foundation D Employer identification number Address change Doing Business As 47-0825376 Name change Number and street (or P.O. box if mail is not delivered to street address) Room/suite E Telephone number Initial return 1901 Munsey Drive (909) 374-9776 Terminated City or town, state or country, and ZIP + 4 Amended return Forest Hill MD 21050-2747 G Gross receipts $ 554,439 Application pending F Name and address of principal officer: H(a) Is this a group return for affiliates? Yes X No Jim Jagielski 1901 Munsey Drive, Forest Hill, MD 21050-2747 H(b) Are all affiliates included? Yes No I Tax-exempt status: X 501(c)(3) 501(c) ( ) (insert no.) 4947(a)(1) or 527 If "No," attach a list. (see instructions) J Website: http://www.apache.org/ H(c) Group exemption number K Form of organization: X Corporation Trust Association Other L Year of formation: 1999 M State of legal domicile: MD Part I Summary 1 Briefly describe the organization's mission or most significant activities: to provide open source software to the public that we sponsor free of charge 2 Check this box if the organization discontinued its operations or disposed of more than 25% of its net assets.
    [Show full text]
  • Avaliando a Dívida Técnica Em Produtos De Código Aberto Por Meio De Estudos Experimentais
    UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA IGOR RODRIGUES VIEIRA Avaliando a dívida técnica em produtos de código aberto por meio de estudos experimentais Goiânia 2014 IGOR RODRIGUES VIEIRA Avaliando a dívida técnica em produtos de código aberto por meio de estudos experimentais Dissertação apresentada ao Programa de Pós–Graduação do Instituto de Informática da Universidade Federal de Goiás, como requisito parcial para obtenção do título de Mestre em Ciência da Computação. Área de concentração: Ciência da Computação. Orientador: Prof. Dr. Auri Marcelo Rizzo Vincenzi Goiânia 2014 Ficha catalográfica elaborada automaticamente com os dados fornecidos pelo(a) autor(a), sob orientação do Sibi/UFG. Vieira, Igor Rodrigues Avaliando a dívida técnica em produtos de código aberto por meio de estudos experimentais [manuscrito] / Igor Rodrigues Vieira. - 2014. 100 f.: il. Orientador: Prof. Dr. Auri Marcelo Rizzo Vincenzi. Dissertação (Mestrado) - Universidade Federal de Goiás, Instituto de Informática (INF) , Programa de Pós-Graduação em Ciência da Computação, Goiânia, 2014. Bibliografia. Apêndice. Inclui algoritmos, lista de figuras, lista de tabelas. 1. Dívida técnica. 2. Qualidade de software. 3. Análise estática. 4. Produto de código aberto. 5. Estudo experimental. I. Vincenzi, Auri Marcelo Rizzo, orient. II. Título. Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador(a). Igor Rodrigues Vieira Graduado em Sistemas de Informação, pela Universidade Estadual de Goiás – UEG, com pós-graduação lato sensu em Desenvolvimento de Aplicações Web com Interfaces Ricas, pela Universidade Federal de Goiás – UFG. Foi Coordenador da Ouvidoria da UFG e, atualmente, é Analista de Tecnologia da Informação do Centro de Recursos Computacionais – CERCOMP/UFG.
    [Show full text]
  • Full-Graph-Limited-Mvn-Deps.Pdf
    org.jboss.cl.jboss-cl-2.0.9.GA org.jboss.cl.jboss-cl-parent-2.2.1.GA org.jboss.cl.jboss-classloader-N/A org.jboss.cl.jboss-classloading-vfs-N/A org.jboss.cl.jboss-classloading-N/A org.primefaces.extensions.master-pom-1.0.0 org.sonatype.mercury.mercury-mp3-1.0-alpha-1 org.primefaces.themes.overcast-${primefaces.theme.version} org.primefaces.themes.dark-hive-${primefaces.theme.version}org.primefaces.themes.humanity-${primefaces.theme.version}org.primefaces.themes.le-frog-${primefaces.theme.version} org.primefaces.themes.south-street-${primefaces.theme.version}org.primefaces.themes.sunny-${primefaces.theme.version}org.primefaces.themes.hot-sneaks-${primefaces.theme.version}org.primefaces.themes.cupertino-${primefaces.theme.version} org.primefaces.themes.trontastic-${primefaces.theme.version}org.primefaces.themes.excite-bike-${primefaces.theme.version} org.apache.maven.mercury.mercury-external-N/A org.primefaces.themes.redmond-${primefaces.theme.version}org.primefaces.themes.afterwork-${primefaces.theme.version}org.primefaces.themes.glass-x-${primefaces.theme.version}org.primefaces.themes.home-${primefaces.theme.version} org.primefaces.themes.black-tie-${primefaces.theme.version}org.primefaces.themes.eggplant-${primefaces.theme.version} org.apache.maven.mercury.mercury-repo-remote-m2-N/Aorg.apache.maven.mercury.mercury-md-sat-N/A org.primefaces.themes.ui-lightness-${primefaces.theme.version}org.primefaces.themes.midnight-${primefaces.theme.version}org.primefaces.themes.mint-choc-${primefaces.theme.version}org.primefaces.themes.afternoon-${primefaces.theme.version}org.primefaces.themes.dot-luv-${primefaces.theme.version}org.primefaces.themes.smoothness-${primefaces.theme.version}org.primefaces.themes.swanky-purse-${primefaces.theme.version}
    [Show full text]
  • Towards Identifying Software Project Clusters with Regard to Defect Prediction
    Towards identifying software project clusters with regard to defect prediction Marian Jureczko, Wroc!aw University of Technology Lech Madeyski, Wroc!aw University of Technology Agenda •! Introduction •! Data acquisition •! Study design •! Results •! Conclusions Introduction Motivation – Why defect prediction? 20% of classes contain 80% of defects We can use the software metrics to predict error prone classes and therefore prioritize and optimize tests. Motivation – Why clustering projects? •! Defect prediction is sometime impossible because lack of training data: –! It may be the first release of a project –! The company or the project may be to small to afford collecting training data •! With well defined project clusters the cross-project defect prediction will be possible Definitions •!Defect -! Interpreted as a defect in the investigated project -! Commented in the version control system (CVS or SVN) •!Defect prediction model Values of Metrics for a given java class Estimated •!WMC = ... Number •!DIT = ... Model of •!NOC = ... •!CBO = ... Defects •!RFC = … •!LCOM = … •!Ca=... •!.... Data acquisition •! 19 different metrics were calculated with the CKJM tool (http://gromit.iiar.pwr.wroc.pl/p_inf/ckjm) •! Chidamber & Kemerer metrics suite •! QMOOD metrics suite •! Tang, Kao and Chen’s metrics (C&K quality oriented extension) •! Cyclomatic Complexity, LCOM3, Ca, Ce and LOC •! Defects were collected with BugInfo ( http://kenai.com/projects/buginfo) Compare CVS/SVN Bug CVS log against given & SVN regular expression metrics repository Data
    [Show full text]
  • Kuali Student Service System: Technical Architecture Phase 1 Recommendations
    Kuali Student Service System Technical Architecture Phase 1 Recommendations Kuali Student Service System Technical Architecture Phase 1 Recommendations December 31 2007 Kuali Student Technical Team Technical Architecture Phase 1 deliverables 2/14/2008 1 Kuali Student Service System Technical Architecture Phase 1 Recommendations Table of Contents 1 OVERVIEW ........................................................................................................................ 4 1.1 REASON FOR THE INVESTIGATION ................................................................................... 4 1.2 SCOPE OF THE INVESTIGATION ....................................................................................... 4 1.3 METHODOLOGY OF THE INVESTIGATION .......................................................................... 4 1.4 CONCLUSIONS ............................................................................................................... 5 1.5 DECISIONS THAT HAVE BEEN DELAYED ............................................................................ 6 2 STANDARDS ..................................................................................................................... 7 2.1 INTRODUCTION .............................................................................................................. 7 2.2 W3C STANDARDS .......................................................................................................... 7 2.3 OASIS STANDARDS ......................................................................................................
    [Show full text]
  • Edge-To-Business Value Chain Delivery Via Elastic Telemetry of Cyber-Physical Systems
    Edge-to-Business Value Chain Delivery via Elastic Telemetry of Cyber-Physical Systems DISSERTATION zur Erlangung des akademischen Grades Doktor der Technischen Wissenschaften eingereicht von Soheil Qanbari Matrikelnummer 1129801 an der Fakultät für Informatik der Technischen Universität Wien Betreuung: Univ.Prof. Dr. Schahram Dustdar Diese Dissertation haben begutachtet: Prof. Dr. Schahram Dustdar Prof. Dr. Frank Leymann Wien, 2. Dezember 2015 Soheil Qanbari Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Edge-to-Business Value Chain Delivery via Elastic Telemetry of Cyber-Physical Systems DISSERTATION submitted in partial fulfillment of the requirements for the degree of Doktor der Technischen Wissenschaften by Soheil Qanbari Registration Number 1129801 to the Faculty of Informatics at the Vienna University of Technology Advisor: Univ.Prof. Dr. Schahram Dustdar The dissertation has been reviewed by: Prof. Dr. Schahram Dustdar Prof. Dr. Frank Leymann Vienna, 2nd December, 2015 Soheil Qanbari Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Erklärung zur Verfassung der Arbeit Soheil Qanbari Schwemmgasse 2/3/55A, 1020 Wien, Austria Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen- deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit – einschließlich Tabellen, Karten und Abbildungen –, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Wien, 2. Dezember 2015 Soheil Qanbari v Danksagung “Betrachte den Menschen als ein Bergwerk, reich an Edelsteinen von unschätzbarem Wert.
    [Show full text]
  • REST Gateway Demo Documentation Release 1.0
    REST Gateway Demo Documentation Release 1.0 Hiranya Jayathilaka September 07, 2015 Contents 1 Introduction 3 1.1 Backend SOAP Service.........................................3 1.2 Synapse ESB Configuration.......................................4 1.3 Sample Client Scripts..........................................4 2 Getting Familiar with Apache Synapse5 2.1 Simple Proxy Services..........................................6 2.2 Messaging Model............................................7 2.3 REST API Support............................................7 2.4 More Documentation and Samples...................................8 2.5 Configuration Language.........................................8 2.6 WSO2 ESB................................................8 3 REST Gateway Tutorial 11 3.1 Prerequisites............................................... 11 3.2 Setting Up the Backend Server...................................... 11 3.3 Setting Up the ESB............................................ 13 3.4 Running the REST Client........................................ 14 3.5 Testing Content Negotiation....................................... 15 3.6 Tracing Messages............................................ 17 4 REST Gateway Implementation 19 4.1 Order API (StarbucksOrderAPI)..................................... 19 4.2 Order List API (StarbucksOrderListAPI)................................ 20 4.3 Error Handling.............................................. 21 5 Indices and tables 23 i ii REST Gateway Demo Documentation, Release 1.0 Contents: Contents 1 REST
    [Show full text]
  • WSO2 Administration Guide
    WSO2 Administration Guide WSO2 Administration Guide Documentation Carbon 4.4.x Platform 1 WSO2 Administration Guide Table of Contents 1. WSO2 Administration Guide . 5 1.1 Deployment and Clustering . 5 1.1.1 Key Concepts . 6 1.1.1.1 Clustering Overview . 6 1.1.1.2 Load Balancing . 7 1.1.1.3 Separating the Worker and Manager Nodes . 8 1.1.1.4 Sharing Databases in a Cluster . 10 1.1.1.5 Sticky Sessions with Manager Nodes . 11 1.1.2 Production Deployment Guidelines . 12 1.1.2.1 Security Guidelines for Production Deployment . 19 1.1.2.2 Troubleshooting in Production Environments . 25 1.1.3 Configuring rsync for Deployment Synchronization . 28 1.2 Data Stores . 29 1.2.1 Working with Databases . 30 1.2.1.1 Setting up the Physical Database . 30 1.2.1.1.1 Setting up IBM DB2 . 30 1.2.1.1.2 Setting up IBM Informix . 33 1.2.1.1.3 Setting up H2 . 34 1.2.1.1.4 Setting up MariaDB . 36 1.2.1.1.5 Setting up Microsoft SQL . 37 1.2.1.1.6 Setting up MySQL . 38 1.2.1.1.7 Setting up a MySQL Cluster . 40 1.2.1.1.8 Setting up Oracle . 40 1.2.1.1.9 Setting up Oracle RAC . 41 1.2.1.1.10 Setting up PostgreSQL . 43 1.2.1.1.11 Setting up Derby . 44 1.2.1.2 Changing the Carbon Database . 44 1.2.1.2.1 Changing to Embedded Derby .
    [Show full text]
  • Open Source SOA
    Jeff Davis MANNING Open Source SOA Licensed to Venkataramanan Tharagam <[email protected]> Licensed to Venkataramanan Tharagam <[email protected]> Open Source SOA JEFF DAVIS MANNING Greenwich (74° w. long.) Licensed to Venkataramanan Tharagam <[email protected]> For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. Sound View Court 3B fax: (609) 877-8256 Greenwick, CT 06830 email: [email protected] ©2009 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine. Development Editor: Cynthia Kane Manning Publications Co. Copyeditor: Liz Welch Sound View Court 3B Typesetter: Krzysztof Anton Greenwich, CT 06830 Cover designer: Leslie Haimes ISBN 978-1-933988-54-2 Printed in the United States of America 12345678910–MAL–16151413111009 Licensed to Venkataramanan Tharagam <[email protected]> brief contents PART 1HISTORY AND PRINCIPLES ...........................................
    [Show full text]
  • Guide De L'open Source
    GUIDE DE L'OPEN SOURCE I .T IS OPE N PREAMBULE SMILE Smile est une société d’ingénieurs experts dans la mise en œuvre de solutions open source et l’intégration de systèmes appuyés sur l’open source. Smile est membre de l’APRIL, l’association pour la promotion et la défense du logiciel libre, du PLOSS – le réseau des entreprises du Logiciel Libre en Ile-de-France et du CNLL – le conseil national du logiciel libre. Smile compte plus de 1200 collaborateurs dans le monde ce qui en fait le premier intégrateur français et européen de solutions open source. Depuis 2000, environ, Smile mène une action active de veille technologique qui lui permet de découvrir les produits les plus prometteurs de l’open source, de les qualifier et de les évaluer, de manière à proposer à ses clients les produits les plus aboutis, les plus robustes et les plus pérennes. Cette démarche a donné lieu à toute une gamme de livres blancs couvrant différents domaines d’application. La gestion de contenus (2004), les portails (2005), la business intelligence (2006), la virtualisation (2007), la gestion électronique de documents (2008), les PGIs/ERPs (2008), les VPN open source (2009), les Firewall et Contrôle de flux (2009), les Middleware orientés messages (2009), l’ecommerce et les Réseaux Sociaux d'Entreprise (2010), le Guide de l’open source et NoSQL (2011), Mobile et Recensement et audit (2012), et plus récemment Big Data et ERP open source pour l’e-commerce (2014). Chacun de ces ouvrages présente une sélection des meilleures solutions open source dans le domaine considéré, leurs qualités respectives, ainsi que des retours d’expérience opérationnels.
    [Show full text]