Skip to end of metadata
Go to start of metadata

This is the application compliance evaluation template which can be used to "grade" how well an ESB service or web service follows the recommended approaches documented in the integration analysis template and design practices.  This template can be completed as part of an ART review, technical review, or code review and can be used as a tool in that over-arching process. Clearly, the template and data points will evolve over time, but this should provide a solid basis for the discussions that trigger that evolution.  While scoring something like this can be somewhat subjective, the goal is to provide as many objective data points as possible, and as quantifiable of an assessment as possible to improve compliance and consistency going forward.

For a completed example, see the example completed template child page.

Category IDCategoryPoints AvailableDocumented PracticeExample(s)Application ApproachScoreComments
1Integration Analysis Template10An integration analysis template should be completed for each integration project. The main sections of this template are a description of the flow of data, integration components, data object definitions used and re-used, messages used and re-used, and stories for message consumption and production. See the detailed documentation on the integration analysis template.Example of completed analysis template are available in the Integrations section of the main EAI/SOA wiki page.   
2Message Definitions and Message Object API10Message definitions should be created in the Emory message tree in Subversion. Message definitions should conform to the OpenEAI Message Definition guide and sample messages should contain realistic data. A Message Object API (MOA) should be generated with the message objects contained in these definition and sample messages or re-generated if new objects have been added to an existing MOA. See the OpenEAI Message Definition guide and OpenEAI Message Object API Introduction for details.The Emory MOA message definitions and message object API and the Symplectic message defintions and message object API are good examples of a internal Emory and vendor system message object API.   
3Enterprise Object Documents10Enterprise Objects Documents are XML files generated by MoaGen and used at runtime to provide MOA objects with information about which fields are required, what formatting rules, translations, masks and other field level rules. These XML documents may also contain descriptive metadata about the object. These XML documents can be started at design and development time and should be completed with all descriptive data and rules by deployment time.
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 2 U (http://www.xmlspy.com) by Tod Jackson (University of Illinois) -->
<!DOCTYPE EnterpriseObjects SYSTEM "http://xml.openeai.org/xml/configs/xml/dtd/1.0/EnterpriseObjects.dtd">
<!--Copyright 2002-2003 OpenEAI Software Foundation.  All Rights Reserved.-->
<!--This file was automatically generated by the OpenEAI MOA Generation Application on Fri Jan 10 23:53:05 CST 2003-->
<EnterpriseObjects>
    <ObjectDefinition name="Name">
        <Description>The name of a person</Description>
        <ClassName>com.any_erp_vendor.moa.objects.resources.v1_0.Name</ClassName>
        <Field name="Type" type="Attribute" isKey="false">
            <Description>Definition of the Type child field of the Name Enterprise Object.</Description>
            <Format required="false">
                <Translation>
                    <Mapping>
                        <EnterpriseValue>Formal</EnterpriseValue>
                        <ApplicationValue applicationName="Default" preferred="true">
                            <Value/>
                        </ApplicationValue>
                    </Mapping>
                </Translation>
            </Format>
        </Field>
        <Field name="Current" type="Attribute" isKey="false">
            <Description>A flag indicating whether the name is current</Description>
            <Format required="false"/>
        </Field>
        <Field name="LastName" type="Element" isKey="true">
            <Description>The last name or family name of the person</Description>
            <Format required="true">
                <Scrubber sequence="1">
                    <ClassName>org.openeai.scrubbers.CaseConverter</ClassName>
                </Scrubber>
            </Format>
        </Field>
        <Field name="FirstName" type="Element" isKey="true">
            <Description>The first name or given name of a person</Description>
            <Format required="true">
                <Scrubber sequence="1">
                    <ClassName>org.openeai.scrubbers.CaseConverter</ClassName>
                </Scrubber>
            </Format>
        </Field>
        <Field name="MiddleName" type="Element" isKey="false">
            <Description>The middle name of a person</Description>
            <Format required="false">
                <Scrubber sequence="1">
                    <ClassName>org.openeai.scrubbers.CaseConverter</ClassName>
                </Scrubber>
            </Format>
        </Field>
        <Field name="Prefix" type="Element" isKey="false">
            <Description>A prefix such as Mr, Mrs, Ms, Dr</Description>
            <Format required="false"/>
        </Field>
        <Field name="Suffix" type="Element" isKey="false">
            <Description>A suffix such as Jr, Sr, III, etc.</Description>
            <Format required="false"/>
        </Field>
        <Field name="LegalName" type="Element" isKey="false">
            <Description>The legal name of a person is a combination of all names in a legal format that might not be expressed as first, middle, and last</Description>
            <Format required="false"/>
        </Field>
        <Field name="PreferredFirstName" type="Element" isKey="false">
            <Description>The first name that the person prefers</Description>
            <Format required="false"/>
        </Field>
    </ObjectDefinition>
</EnterpriseObjects>

   
4Project Name

5

 organization-appname-apptype

emory-redcap-connector, actsi-mppi-service, openeai-pacs-service   
5Project Organization10The project should include a java source, lib, and test directories for any source code, libraries required to build the project, and any tests implemented with code. Additionally, the project should include any configurations required to build the project and configurations required to run the connector—typically these are development or sample configurations without sensitive credentials or data. Variation in the location and naming of source, test, and documentation or other artifacts are naturally allowed as long at the package contents remain clear and easily navigable.
actsi-mppi-service
¿¿¿ config
¿   ¿¿¿ service.properties
¿   ¿¿¿ serviceAppConfig.xml
¿¿¿ src
¿¿¿ trunk
    ¿¿¿ .classpath
    ¿¿¿ .project
    ¿¿¿ .settings
    ¿   ¿¿¿ org.eclipse.jdt.core.prefs
    ¿   ¿¿¿ org.eclipse.wst.common.project.facet.core.xml
    ¿¿¿ build.xml
    ¿¿¿ etc
    ¿   ¿¿¿ mppi.pptx
    ¿   ¿¿¿ rs.dtd
    ¿   ¿¿¿ rs.xsd
    ¿¿¿ java
    ¿   ¿¿¿ src
    ¿   ¿   ¿¿¿ org
    ¿   ¿       ¿¿¿ actsi
    ¿   ¿           ¿¿¿ services
    ¿   ¿               ¿¿¿ mppi
    ¿   ¿               ¿   ¿¿¿ CciMppiTest.java
    ¿   ¿               ¿   ¿¿¿ IdentityGenerationScheduledCommand.java
    ¿   ¿               ¿   ¿¿¿ MasterPatientParticipantIdentityRequestCommand.java
    ¿   ¿               ¿   ¿¿¿ MppiRequestCommand.java
    ¿   ¿               ¿   ¿¿¿ ReleaseTag.java
    ¿   ¿               ¿   ¿¿¿ StudySubjectSyncCommand.java
    ¿   ¿               ¿   ¿¿¿ provider
    ¿   ¿               ¿       ¿¿¿ CciMasterPatientParticipantIdentityProvider.java
    ¿   ¿               ¿       ¿¿¿ DemoMasterPatientParticipantIdentityProvider.java
    ¿   ¿               ¿       ¿¿¿ ExampleMasterPatientParticipantIdentityProvider.java
    ¿   ¿               ¿       ¿¿¿ MasterPatientParticipantIdentityProvider.java
    ¿   ¿               ¿       ¿¿¿ ProviderException.java
    ¿   ¿               ¿¿¿ mssi
    ¿   ¿                   ¿¿¿ provider
    ¿   ¿¿¿ test
    ¿       ¿¿¿ log4j.properties
    ¿       ¿¿¿ org
    ¿           ¿¿¿ actsi
    ¿               ¿¿¿ services
    ¿                   ¿¿¿ mppi
    ¿                       ¿¿¿ TestMasterPatientParticipantIdentityRequestCommand.java
    ¿¿¿ lib
        ¿¿¿ actsi-moa.jar
        ¿¿¿ ant-launcher.jar
        ¿¿¿ ant-nodeps.jar
        ¿¿¿ ant.jar
        ¿¿¿ aopalliance.jar
        ¿¿¿ cci-actsi-mpi-service-1.0.jar
        ¿¿¿ cglib-nodep-2.2.jar
        ¿¿¿ commons-collections-3.1.jar
        ¿¿¿ commons-logging-1.1.1.jar
        ¿¿¿ commons-validator-1.4.0.jar
        ¿¿¿ dom4j-1.6.1.jar
        ¿¿¿ emory-hals-service-1.0.jar
        ¿¿¿ emory-moa.jar
        ¿¿¿ hibernate-jpa-2.0-api-1.0.0.Final.jar
        ¿¿¿ hibernate3.jar
        ¿¿¿ javassist-3.9.0.GA.jar
        ¿¿¿ jdom.jar
        ¿¿¿ jms-1.1.jar
        ¿¿¿ jta-1.1.jar
        ¿¿¿ junit-4.10.jar
        ¿¿¿ log4j-1.2.15.jar
        ¿¿¿ mail.jar
        ¿¿¿ mysql-connector-java-5.1.12-bin.jar
        ¿¿¿ openeai-moa.jar
        ¿¿¿ openeai.jar
        ¿¿¿ org.springframework.aop-3.0.2.RELEASE.jar
        ¿¿¿ org.springframework.asm-3.0.2.RELEASE.jar
        ¿¿¿ org.springframework.beans-3.0.2.RELEASE.jar
        ¿¿¿ org.springframework.context-3.0.2.RELEASE.jar
        ¿¿¿ org.springframework.context.support-3.0.2.RELEASE.jar
        ¿¿¿ org.springframework.core-3.0.2.RELEASE.jar
        ¿¿¿ org.springframework.expression-3.0.2.RELEASE.jar
        ¿¿¿ org.springframework.jdbc-3.0.1.RELEASE-A.jar
        ¿¿¿ org.springframework.orm-3.0.1.RELEASE-A.jar
        ¿¿¿ org.springframework.transaction-3.0.1.RELEASE-A.jar
        ¿¿¿ slf4j-api-1.6.1.jar
        ¿¿¿ slf4j-simple-1.6.1.jar
   
6Distribution Package Organization10

A distribution package are the materials included in a software package that do not appear in the project. This may include items that developers typically do not need at build time such as:

1) Libraries required to run the application (the project include libraries required to build the project). There may be other runtime libraries required.

2) Scripts or instructions for users of the packaged software to build and run the software. These do not appear in the package, because our developers typically know the conventions for building and running these applications and services, but external users or deployers may not.

3) Test suites for demonstrating or verifying the functions of the application or service

4) Documentation and examples

actsi-mppi-service-1.0
¿¿¿ .DS_Store
¿¿¿ build.sh
¿¿¿ lib
    ¿¿¿ actsi-moa.jar
    ¿¿¿ ant-launcher.jar
    ¿¿¿ ant-nodeps.jar
    ¿¿¿ ant.jar
    ¿¿¿ cci-actsi-mpi-service-1.0.jar
    ¿¿¿ commons-validator-1.4.0.jar
    ¿¿¿ emory-hals-service-1.0.jar
    ¿¿¿ jdom.jar
    ¿¿¿ jms-1.1.jar
    ¿¿¿ log4j-1.2.15.jar
    ¿¿¿ mail.jar
    ¿¿¿ openeai.jar
    ¿¿¿ org.springframework.beans-3.0.6.RELEASE.jar
    ¿¿¿ org.springframework.context-3.0.6.RELEASE.jar
    ¿¿¿ org.springframework.core-3.0.6.RELEASE.jar
   
7Configuration Document (Deployment Descriptor)10See the OpenEAI API Introduction section on the deployment descriptor for details and examples.   
8Consumer Foundation and Patterns10See the OpenEAI API Introduction section on JMS Foundation for details and examples.   
9Command Foundation and Pattern10All ESB connectors, services, and scheduled applications should use the command pattern to process messages or take actions. This should almost always be relevant since nearly all ESB services will use either message consumers or scheduled actions which require the command pattern.See the OpenEAI API Introduction section on Message Gateways and Scheduled Applications for details and examples.   
10Producer Foundation and Pattern10Every ESB connector, service, or scheduled application that sends messages should use the Producer foundation. If relevant and not used, deduct 10 points.See the OpenEAI API Introduction section of JMS Foundation for details and examples.   
11Integration and Persistence10ESB services, connectors, and scheduled apps should invoke other ESB services and scheduled apps that expose needed data and operations and not re-implement them. If no existing service exists, then the logic or persistence may be implemented in the new service. If existing logic or persistence is re-implemented unnecessarily, deduct 10 points.    
12Uses RDBMS Connector Foundation and Pattern10If relevant and not used, deduct 10 points.See Hibernate Persistence for OpenEAI RDBMS Connector for details and examples.   
13Uses HAPS or HALS for HIPAA Audit Logging10If the ESB service operates on ePHI, it should use the HIPAA Audit Proxy Service (HAPS) or HIPAA Audit Logging Service (HALS) to implement HIPAA audit logging. Note that using HAPS with a properly designed service eliminates the need for the developer to code any audit logging and ensures that logging standards are met. Therefore, HAPS is the preferred approach. There may be some applications and services for which HAPS is not appropriate and the HALS convenience API is an alternative approach. If HIPAA audit logging is relevant for a service and HAPS or HALS are not used, then deduct 10 points.See the HAPS and HALS documentation for details and examples.   
14Uses ServiceGen Generated Web Service Facade10If the ESB service needs to be exposed as a web service, a web WSDL-described web service facade should be generated using ServiceGen. If relevant and not used, deduct 10 point.See the detailed documentation on ServiceGen for details and examples.   
15Uses Other Relevant Existing Foundation Components10Most every connector or service will need to make use of existing foundation components such as message balancers, locks, authenticators, etc. Developers should learn, re-use, and extend these foundation components. If new foundation is developed that is not necessary, because it has already been implemented, 10 points should be deducted from the compliance score.    
16Deployment5The runtime artifacts should be deployed to a standard ESB server instance through Subversion. The configuration artifacts should be managed through the ESB console. If there is a web service facade, the generated Axis2 web service archive (.aar) should be deployed through Subversion to the appropriate JBoss application server cluster    
        
 Total Grade150 possible    %  Compliance Score

General Comments

This is where the evaluator can add general comments about the application that either add to comments made above or discuss other items that may not be covered in the categories above.

This section allows the reviewers to document action items and assign those tasks to an individual or group to be completed.

Action Item DescriptionAssigned ToDue DateDate CompleteComments
     
     
  • No labels