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 ID||Category||Points Available||Documented Practice||Example(s)||Application Approach||Score||Comments|
|1||Integration Analysis Template||10||An 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.|
|2||Message Definitions and Message Object API||10||Message 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.|
|3||Enterprise Object Documents||10||Enterprise 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.|
|emory-redcap-connector, actsi-mppi-service, openeai-pacs-service|
|5||Project Organization||10||The 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.|
|6||Distribution Package Organization||10|
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
|7||Configuration Document (Deployment Descriptor)||10||Every ESB connector, service, or scheduled appplication should be configured with an OpenEAI deployment descriptor. Other configuration files and properties may also be required depending on what other foundation components are used such as Hibernate, Spring, etc.||See the OpenEAI API Introduction section on the deployment descriptor for details and examples.|
|8||Consumer Foundation and Patterns||10||All point-to-point and pub/sub consuming services and connectors should a PointToPointConsumer and/or PubSubConsumer. If relevant and not used, deduct 10 points||See the OpenEAI API Introduction section on JMS Foundation for details and examples.|
|9||Command Foundation and Pattern||10||All 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.|
|10||Producer Foundation and Pattern||10||Every 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.|
|11||Integration and Persistence||10||ESB 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.|
|12||Uses RDBMS Connector Foundation and Pattern||10||If relevant and not used, deduct 10 points.||See Hibernate Persistence for OpenEAI RDBMS Connector for details and examples.|
|13||Uses HAPS or HALS for HIPAA Audit Logging||10||If 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.|
|14||Uses ServiceGen Generated Web Service Facade||10||If 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.|
|15||Uses Other Relevant Existing Foundation Components||10||Most 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.|
|16||Deployment||5||The 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 Grade||150 possible||% Compliance Score|
|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 Description||Assigned To||Due Date||Date Complete||Comments|