caCORE SDK

Scope/Vision for 4.0 Release

> Version No: 0.7
>
> Last Modified: 4/30/07
>
> Author : Charles Griffin, Satish Patel
>
> Team : caCORE SDK
>
> Subcontract : [26XS234]{.smallcaps}
>
> Client : National Cancer Institute - Center for Bioinformatics,
>
> National Institutes of Health,
>
> US Department of Health and Human Services

Document History

Document Location

The most current version of this document is located in CVS under
cacoresdk\\Project\\SDK_v3.2.1_4.0\\Development\\Requirements

Revision History

  -------------------------------------------------------------------------------
  **Version   **Revision   **Author**         **Summary of Changes**
  Number**    Date**                          
  ----------- ------------ ------------------ -----------------------------------
  0.1         02/12/07     Charles Griffin    Initial Draft

  0.2         03/06/07     Charles Griffin    Updated per reprioritization of
                                              tasks

  0.3         03/13/07     Satish Patel       Incorporated changes in scope items

  0.4         3/13/07      Charles Griffin    Incorporated more requirement
                                              details per QA review comments

  0.5         3/14/07      Charles Griffin    Added Gforge #s

  0.6         3/14/07      Satish Patel       Added detailed description for the
                                              requirements

  0.7         4/30/07      Charles Griffin    Added content to iteration 2 and
                                              for iteration 4

                                              
  -------------------------------------------------------------------------------

Review

  ------------ --------------- ------------- ------------ ---------------------
  **Name**     **Team/Role**   **Version**   **Date       **Reviewer Comments**
                                             Reviewed**   

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
  ------------ --------------- ------------- ------------ ---------------------

Related Documents

**More information can be found in the following related CSM
documents:**

  -----------------------------------------------------------------------
  **Document Name**

  CSM 3.2 Application Developer's Guide

  -----------------------------------------------------------------------

Table of Contents

1\. Introduction [4](#introduction)

2\. Positioning [4](#positioning)

2.1 Problem Statement [4](#problem-statement)

3\. Stakeholder and User Descriptions
[4](#stakeholder-and-user-descriptions)

3.1 Stakeholder Summary [4](#stakeholder-summary)

3.2 Technical Environment [5](#technical-environment)

3.3 Summary of Key Stakeholder or User Needs
[5](#summary-of-key-stakeholder-or-user-needs)

**3.3.1** **caCORE SDK 3.2.1 Requirements (Iteration 1)**
[5](#cacore-sdk-3.2.1-requirements-iteration-1)

**3.3.2** **caCORE SDK 4.0 Requirements (Iteration 2 -- Completion)**
[6](#cacore-sdk-4.0-requirements-iteration-2-completion)

**3.3.3** **Current Solution** [6](#current-solution)

**3.3.4** **Proposed Solutions** [7](#proposed-solutions)

4\. Release Functional Requirements
[7](#release-functional-requirements)

4.1 caCORE SDK Release 3.2.1 \[Iteration 1\]
[7](#cacore-sdk-release-3.2.1-iteration-1)

4.1.1 caGrid Integration [7](#cagrid-integration-1)

4.1.2 Usability and Performance [9](#usability-and-performance-1)

4.2 caCORE Release 4.0 \[Iteration 2\]
[11](#cacore-release-4.0-iteration-2)

4.2.1 Training [11](#training)

4.2.2 NCICB caCORE Bootcamp [11](#ncicb-cacore-bootcamp)

4.2.3 Architecture and Usability [11](#architecture-and-usability)

4.3 caCORE SDK Release 4.0 \[Iteration 3\]
[13](#cacore-sdk-release-4.0-iteration-3)

4.3.1 XMI and Product Interoperability
[13](#xmi-and-product-interoperability)

4.4 caCORE SDK Release 4.0 \[Iteration 4\]
[13](#cacore-sdk-release-4.0-iteration-4)

4.4.1 Usability and Architecture [13](#usability-and-architecture)

5\. Release Non-Functional Requirements
[14](#release-non-functional-requirements)

5.1 General Support Activities [14](#general-support-activities)

6\. Potential Requirements [14](#potential-requirements)

Scope/Vision for 3.2.1 and 4.0 Release

# Introduction

> The purpose of this document is to collect, analyze, and define
> high-level needs and features of the NCICB caCORE SDK Release v3.2.1
> and Release 4.0. It focuses on the functionalities proposed by the SDK
> stakeholders and target users in order to make it a better product.
> The use-case and supplementary specifications document will detail how
> the framework will fulfill these needs.

# Positioning

## Problem Statement

> The 3.2.1 release of the SDK is proposed to be the follow up release
> to the December 2006 3.2 release. This release will address
> integration with caGrid, query performance, and include a
> re-architected web application (formerly called the Happy.jsp)
> allowing users to validate database queries and data mappings.
>
> The caCORE SDK 4.0 release will include major architectural changes
> and introduce new features to the caCORE SDK. Due to depth of
> infrastructure changes and the amount of new features that will be
> introduced in release 4.0, the 4.0 release will not be required to be
> backwards compatible with the 3.2 release.
>
> The 3.2.1 release will be made available at the end of the first
> iteration of the construction phase of the project to provide users
> with high priority fixes and features. Beta versions of the 4.0
> release will be available at the end of various iterations during the
> construction phase.

# Stakeholder and User Descriptions

## Stakeholder Summary

+----------------+-------------------+--------------------------------+
| **Name**       | **Description**   | **Responsibilities**           |
+----------------+-------------------+--------------------------------+
| Avinash        | Director, Core    | Oversees NCICB caCORE Software |
| Shanbhag       | Infrastructure    | Engineering                    |
|                | Engineering       |                                |
+----------------+-------------------+--------------------------------+
| Denise Warzel  | Associate         | Oversees NCICB caCORE Product  |
|                | Director          | Line                           |
|                |                   |                                |
|                | Core              |                                |
|                | Infrastructure,   |                                |
|                | caCORE Product    |                                |
|                | Line Manager      |                                |
+----------------+-------------------+--------------------------------+
| caCORE Project | Power users who   |                                |
|                | provided feedback |                                |
|                | during user       |                                |
|                | interviews        |                                |
+----------------+-------------------+--------------------------------+
| cGEMS Project  | Power users who   |                                |
|                | provided feedback |                                |
|                | during user       |                                |
|                | interviews        |                                |
+----------------+-------------------+--------------------------------+
| Rembrandt      | Power users who   |                                |
| Project        | provided feedback |                                |
|                | during user       |                                |
|                | interviews        |                                |
+----------------+-------------------+--------------------------------+
| caAdapter      | Power users who   |                                |
| Project        | provided feedback |                                |
|                | during user       |                                |
|                | interviews        |                                |
+----------------+-------------------+--------------------------------+
| caDSR Project  | Power users who   |                                |
|                | provided feedback |                                |
|                | during user       |                                |
|                | interviews        |                                |
+----------------+-------------------+--------------------------------+
| caGRID Project | Power users who   |                                |
|                | provided feedback |                                |
|                | during user       |                                |
|                | interviews        |                                |
+----------------+-------------------+--------------------------------+
| caCORE SDK     | Users who         |                                |
| Users          | provided feature  |                                |
|                | requests and      |                                |
|                | suggestions via   |                                |
|                | GFORGE            |                                |
+----------------+-------------------+--------------------------------+

## Technical Environment

-   Client Interface

```{=html}
<!-- -->
```
-   Internet Explorer 6.0 and above

-   Mozilla v1.5.0.3 and above

```{=html}
<!-- -->
```
-   Application Server

```{=html}
<!-- -->
```
-   Apache Tomcat 5.5.9

-   Jboss 4.0.5

```{=html}
<!-- -->
```
-   Database Server

```{=html}
<!-- -->
```
-   MySQL 4.1.19

-   Oracle 9i

```{=html}
<!-- -->
```
-   Operating system

```{=html}
<!-- -->
```
-   Windows 2000, XP

-   Unix (Sun Solaris)

```{=html}
<!-- -->
```
-   Portable ANSI-SQL compliant relational schemas

-   Java 1.5 (SDK version 4.0 only)

## Summary of Key Stakeholder or User Needs

> The following subsections provide an analysis of key requirements to
> address for the security solution as perceived by the stakeholder and
> users.

### **caCORE SDK 3.2.1 Requirements (Iteration 1)**

#### caGrid Integration 

-   Support for multiple concurrent users

-   Security

##### Allow users to use security in the Thick client generated by caCORE SDK

-   Upgrade the caCORE SDK to utilize CSM version 3.2

-   Make Authentication configurable

#### Usability and Performance

-   Improve query performance

-   Re-architect the formerly known Happy.jsp into an multi-tier web
    application

-   Include information entered as tag values in the model into the java
    docs generated by the caCORE SDK

-   Integrate Castor related work performed on the SDK 3.1 branch into
    version 3.2.1 (GF#4031)

-   Provide an option in the SDK build script to only generate an XSD
    and Castor Mapping based on input XMI.

### **caCORE SDK 4.0 Requirements (Iteration 2 -- Completion)**

> The following sub 3.3.2.\* sections list requirements grouped by the
> Construction phase iteration in which they will be addressed. This
> section will be modified during the course of the project as
> additional iterations are planned and/or existing planned requirements
> are reprioritized by NCICB management. It is expected that changes to
> the scope will also be reflected in the project task plan.

#### XMI Interoperability/Round Trip Processing and Open Source Modeling Tool Support (Iteration 2)

-   caCORE SDK XMI Interoperability

    -   Support for round trip XMI processing between caCORE SDK and the
        SIW and caAdapter tools

    -   Support for round trip XMI processing between caCORE SDK and an
        open source modeling tool.

#### Multi-Server Support and Developer Efficiency Improvements (Iteration 3)

-   Support multiple ApplicationService in same JVM

-   Improve log/error message to allow users to better troubleshoot
    model problems during the code generation process

-   Build script change for downloading MySQL (GF#2933)

-   Provide valid Enterprise Architect file for the sample model
    representing all of the supported associations (GF#3955).

### **Current Solution**

> The current 3.2 release of the caCORE SDK was released in December of
> 2006. The 3.2 version can be downloaded at the caCORE SDK download
> site. The caCORE SDK 3.2 version will be supported by the caCORE SDK
> development team during the version 3.2.1 and 4.0 development
> lifecycle.

### **Proposed Solutions**

> Section 4 describes the requirements that will be incorporated within
> the scope of the 3.2.1 and 4.0 releases. The 3.2.1 and 4.0 development
> project will be performed utilizing portions of the Unified Process
> with a focus on iterative development and releasing dot or beta
> versions of the software prior to the final release to meet high
> priority customer needs.
>
> During the duration of the 4.0 development lifecycle the requirements
> of future construction iterations will be evaluated near the end of
> the current iteration under development. The caCORE SDK project
> manager along with the NCICB Product Manager will review already
> proposed requirements listed in Section five (5) of this document
> along with the requirements listed in the "Bugs", "Feature Requests",
> and "Suggestions" Trackers made to the caCORE project via the caCORE
> SDK Gforge Web Site
> ([http://gforge.nci.nih.gov/tracker/?group_id=148](https://gforge.nci.nih.gov/tracker/?atid=804&group_id=148&func=browse)),
> the NCICB Core product listservs, or face to face meetings with
> projects planning to use or already using the caCORE SDK. If an
> iteration's requirements change as a result of the review mentioned
> above, the following is expected to occur:

1.  This scope document will be updated to reflect the correct scope for
    the iteration being modified.

2.  The task plan must be adjusted to reflect the resources and time
    needed to perform the work for the updated requirements.

# Release Functional Requirements

> The following section describes in detail all the functional
> requirements, which are proposed for the coming release:

## caCORE SDK Release 3.2.1 \[Iteration 1\]

### caGrid Integration 

#### **\[GF#4581\]**Support for multiple concurrent users

> Enhancements must be made to the caCORE SDK to securely allow multiple
> users within the same web application to issue requests that invoke
> method calls on the ApplicationService class while security is
> enabled. Currently, with security enabled, the SDK generated
> application is capable to handle only one user at a time (It is a
> singleton). If two or more users issue a request, the request is made
> with the first user's credentials since the ApplicationService is a
> singleton. The code should be modified to allow multiple users issuing
> request to issue requests with only using their respective
> credentials.

#### **\[GF#4582\]**Allow users to use security in the Thick client generated by caCORE SDK

> The current caCORE SDK generated remote client has a limitation with
> the login mechanism. In the caGRID environment, when the grid service
> wants to make a secured call to the SDK generated remote service, it
> provides the public information such as user's grid identity and the
> service URL for the purpose of Authentication. Since the remote server
> is hosted centrally, there can be many other clients connecting to it.
> The other clients can easily mimic the grid user using the publicly
> known credentials therefore it is not advisable to host services this
> way. The caCORE SDK must be enhanced in such a way that the SDK
> generated application can be deployed as part of the grid service so
> that the security credentials do not travel across the unsecured
> environment to the remote caCORE SDK generated server application and
> remain local only to the grid node as the with security enabled. To
> support this requirement, the caCORE SDK Thick Client must be able to
> be created and deployed with security enabled.

#### **\[GF#4583\]**Upgrade the caCORE SDK to utilize CSM version 3.2

Currently the CSM/SDK and CSM/caGrid Integration uses a beta version of
the CSM v3.2 release. There have been many new features added to the CSM
v3.2 after this beta version. These new features cannot be leveraged by
the caGrid client. Hence in order to make these new features available,
the CSM/SDK and CSM/ caGrid integration must be updated to use the 3.2
version of CSM.

The new feature that will be utilized as part of this requirement is the
new installation/configuration process that has been introduced in CSM
3.2. The new CSM 3.2 installation process should be utilized to
facilitate ease of installation of a CSM enabled SDK generated system.
The new CSM installation procedures are detailed in the CSM 3.2
Application Developer's Guide.

#### **\[GF#4584\]**Make Authentication configurable

In version caCORE version 3.2, whenever you enable security in an SDK
generated system it turns on both the Authentication as well
Authorization. This requires the user to first provide credentials to be
authenticated and then only a session is initiated for the user. Once a
session is established the user can perform multiple query requests over
this session. The user token associated with the session is used to
determine whether the user has permissions to perform that particular
operation or access that particular resource.

However, in case of a grid node the authentication is performed by the
under lying grid security framework (GAARDS). Hence whenever the user is
trying to access data via the SDK generated client or thick-client,
he/she is already validated for authenticity using the user's grid
credentials. Currently both CSM and CSM enabled SDK generated system do
not posses the capabilities to validate the grid credentials due to the
following reasons:

1.  They are not part of the grid trust fabric as a result they cannot
    validate the grid proxy certificate.

2.  The user's private key is not available for signing. As a result the
    authentication mechanism cannot be guaranteed, as it would be based
    on user's public information i.e. the user's grid proxy certificate
    or grid identity.

The requirement for the caCORE SDK 3.2.1 release is to make the CSM
integration within the caCORE SDK configurable to allow the
authentication service to be turned off or on. When the authentication
service is turned off, CSM should generate a user session token without
authenticating the user. Turning authentication on or off should not
require users to regenerate the code.

By default, the SDK has a setting of authentication enabled. If the user
does not specify any setting then the authentication is enabled. The
authentication enable/disable flag is to be used by the caGRID project
only as the users using the grid service are already authenticated. The
setting to enable/disable authentication is mentioned in the
deploy/properties file (which is a build time configuration file). The
build script will pickup the setting from deploy.properties file and
configure the property in the CoreSystem.properties file which is used
at runtime.

### Usability and Performance

#### Improve query performance

> In caCORE SDK version 3.2, a defect was found that caused Hibernate to
> perform multiple sub-select statements during nested criteria queries
> which results in performance degradation. This defect should be fixed
> as part of the caCORE SDK 3.2.1 release.

#### **\[GF#4586\]**Re-architect and rename happy.jsp to caCORE SDK Visual Query Application

> The Happy.jsp is currently a web page allowing users to validate and
> perform queries against their caCORE SDK generated APIs. Since users
> are relying more and more on the Happy.jsp for querying data in their
> respective environments and would like more functionality, there is a
> need to build a more robust application to which features can be added
> in the architecturally sound manner. The Happy.jsp should be developed
> as a N-tier STRUTS 2 web application that with customizable options
> display options that would allow users to deploy and use the
> application as a production tool. The customizable display options are
> as follows:

1.  Allow to build search query based on object's attributes

2.  Allow to specify query on the associated objects

3.  Allow to specify the attributes to be displayed on the result page

4.  Allow to specify the display order of the result

5.  Allow to download the results in spreadsheet

> Furthermore, the Happy JSP will be renamed to the caCORE SDK Visual
> Query Application. This name should also be customizable via a
> configuration file. At the minimum, the feature set of the caCORE SDK
> Visual Query Application should initially provide the same
> functionality of the Happy.jsp.

#### **\[GF#4587\]**Include information entered as tag values in the model into the java docs generated by the caCORE SDK

> In order to reduce the caCORE SDK user work load and data reentry,
> there is a requirement for the caCORE SDK to add the text written in
> the documentation and description tags in the input XMI used for code
> generation into javadocs of the beans created by the SDK. The caCORE
> SDK will annotate the attributes of the Java beans with semantic
> information present in the UML model..
>
> Text in "documentation" tags for objects in the UML model will be used
> to generated documentation for java classes. Text provided in
> "description" tags for object attributes in the UML model will be used
> to generate documentation for java class attributes.

#### **\[GF#4588\]**Integrate Castor related work performed on the SDK 3.1 branch into version 3.2.1 (GF#4031)

> During caCORE SDK 3.1 development, on request from the caGRID team,
> work was performed to process the associations with castor. This
> required changes in the castor mapping file generator as well as
> changes in the serializer/deserializer program (XMLUtility). This
> modification must be merged in with the caCORE SDK 3.2.1 codebase.

#### **\[GF#4589\]**Provide an option in the SDK build script to only generate an XSD and Castor Mapping based on input XMI.

> In lieu of creating an entire system, an option should be provided as
> an Ant task to only generate an xsd and castor mapping for xmi.

#### **\[GF#4594\]**Unrecognized database format for EA (GF#3955)

> The released .eap file for the sample model is corrupted and users
> cannot open it. An uncorrupted model file needs to be found and
> packaged with the release

#### **\[GF#4595\]**Build script change for downloading MySQL (GF#2933) 

> The MySQL download script does not work for Unix and Linux. The build
> script needs to be changed so this works.

## caCORE Release 4.0 \[Iteration 2\]

### Training

### NCICB caCORE Bootcamp

#### **\[GF#6130\]**Support for the NCICB Bootcamp

> The caCORE SDK API team is required to develop a presentation and a
> hands-on training exercise for the NCICB Bootcamp training session.
> The caCORE SDK API team will also be required to present at the two
> planned bootcamp sessions.

### Architecture and Usability

#### **\[GF#4590\]**Support new XMI processor for round trip processing with caAdaptor and the SIW

> The caCORE SDK currently uses NetBeans MDR XMI processor. This XMI
> processor poses limitation on using roundtrip XMI files with SDK. The
> caCORE SDK system must be enhanced to support the new XMI processor
> created by the SIW team which will enable the caCORE SDK to process
> XMI files modified by the caAdapter and SIW tools in addition to the
> XMI files the caCORE SDK currently processes that are generated by the
> Enterprise Architect tool.

#### **\[GF#6131\]** [Support for java 1.5 generics. (for example: List\<Gene\>)](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6131&group_id=148&atid=774)

Provide the ability to configure the SDK to generate code which used
generics (for example: List\<Gene\>). This could be an option you can
select as part of your code gen.

#### **\[GF#6132\]** [Support for alternate way of mapping inheritance](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6132&group_id=148&atid=774)

The SDK currenlty supports only \"joined-subclass\" to map inheritance
based model to database. At runtime this causes multiple joins between
the tables. An alternate way of implemeting inheritance must be
implemented to keep information in the same table. Hibernate allows this
by using \"subclass\" to perform O/R mapping.

#### **\[GF#6133\]** [Combine generation steps so that XMI file is read only once](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6133&group_id=148&atid=774)

Currently, the SDK reads an XMI file for each type of artifact to be
generated. This causes a significant delay in the code generation
process. Enhancements must be made so that the file is read only once to
decrease the total time it takes for code generation process to
complete.

#### **\[GF#6134\]** [Many to One and One to Many do not support correlation table](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6134&group_id=148&atid=774)

Support correlation tables for the manby-to-one and one-to-one
relationships. Many-to-One and One-to-one relationship can be modeled
with tables with foreign key referring to the parent table. However, if
the relationship for many-to-one or one-to-one association is stored in
the JOIN tables then in that case, SDK had no way of specifying use of
JOIN (correlation) table in previous versions. The SDK will be modified
to support this.

#### **\[GF#6135\]** [Implement model validation routine as common project](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6135&group_id=148&atid=774)

The SDK and caAdapter do not perform an error check on the model that is
to be used for the code generation. The requirement is to create a model
error checking utility that can be reused by the SDK as well as other
projects such as caAdapter and SIW.

#### **\[GF#6136\]** Use publicId and version in the XML schema

If the object model is annotated with semantic integration information,
the same information will be pushed down in the XSDs generated by the
SDK.

#### **\[GF#6137\]** [Use permissible values in XML schema](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6137&group_id=148&atid=774) 

Generate as enums in the schema. Recognize enumerations and caDSR Value
Domains in the XMI file and create appropriate code in codegen.

####  **\[GF#6138\]** [Lazy attribute in UML model](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6138&group_id=148&atid=774)

Allow users to specify eager loading mechanism on the association.

#### **\[GF#6139\]** [Allow](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6138&group_id=148&atid=774) to use visibility specified in UML tool

The visibility specified for attributes of an object in the UML tool
will dictate the visibility of an attribute of the java the class that
is created from SDK code generation.

####  **\[GF#6140\]** [Cascade operations in UML model](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6140&group_id=148&atid=774)

Allow users to specify a cascade operation in the UML model. This is a
requirement for the writable API to work with associations.

#### **\[GF#6141\]** [Independent HBM files generator that can be plugged into caAdapter](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6141&group_id=148&atid=774) 

Work together to utilize the SDK HBM generator in caAdapter.

#### **\[GF#6142\]** [Integrate JavaDocs in the web system](https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=6142&group_id=148&atid=774)

Enhancements will be made to integrate Javadocs for the domain model.
This enhancement will help the users to obtain the annotated information
at the runtime in easier fashion.

## caCORE SDK Release 4.0 \[Iteration 3\]

### XMI and Product Interoperability

####  **\[GF#4590\]**Provide Support for an Open Source Modeling Tool

> There is a new requirement for the SDK 4.0 release to be able to
> perform code generation based on XMI for an open source modeling tool.
> This has ramifications for the SIW and caAdapter projects as well
> since both of the products will have to import XMI from the chosen
> tool. The caCORE SDK must be able to process XMI from the chosen open
> source tool with the same functionality as XMI received from
> Enterprise Architect. The first iteration would not involve supporting
> the exchange of XMI between the open source tool and Enterprise
> Architect. More specifically, XMI generated by Enterprise Architect
> would not be able to be imported into the open source tool for
> modeling.

## caCORE SDK Release 4.0 \[Iteration 4\]

### Usability and Architecture

#### **\[GF#4592\]**Support multiple ApplicationService in same JVM

> Due to the ApplicationService being a singleton in caCORE version 3.2,
> users aren\'t able to point to a multiple remote service locations.
> After the ApplicationService has been initially instantiated, the URL
> of the remote service cannot be changed. The caCORE SDK must be
> enhanced to allow users to point to N number of remote service
> locations even after the ApplicationService has been instantiated.

#### **\[GF#4593\]**Improved logging/trace messages

> Enhancements to the caCORE SDK must be made to allow users to see
> debug information during code generation. Enough information needs to
> be outputted to allow a user to easily identify what piece of the
> model is causing a problem and what the problem is.
>
> information at the runtime in easier fashion.

#### **\[GF#6216\]** Change architecture of ApplicationService

> ApplicationService is an abstract class which imposes limitation on
> creating different implementation of the class. ApplicationService
> should be changed to interface. This change will result in changes in
> the related classes and on the SDK clients (If they were using
> ApplicationService class to get instance
>
> .

#### **\[GF#6217\]** Annotation Based Web Services

> JSR 181 style web services possibly utilizing XFIRE or AXIS 2 if
> supported to eliminate the .ws layer which currently exists. This must
> be prototyped to ensure that a proper WSDL document is produced.

#### **\[GF#6218\]** Remove duplication of methods due to security injection (ACEGI Integration)

> In order to maintaian security in the JAVA API, additional wrapper
> code is maintained currently which always causes problems at the time
> of integration with caCORE API. This code can be removed by using
> ACEGI framework. The ACEGI framework also supports the decoupling of
> the code for the SDK and caCORE products.

#### **\[GF#6220**Re-architect information in SpringConfig.xml and DAOConfig.xml

> The SpringConfig file in the SDK has configuration information for the
> DAOs. At the same time DAOConfig.xml contains information determining
> which DAO should be invoked for a particular domain object. A
> determination will be made on whether or not to combine all DAO
> configuration into a single file.

# Release Non-Functional Requirements

## General Support Activities 

-   The caCORE SDK team will reserve 45% of 1 FTE to provide support,
    integration help and training to the user community.

# Potential Requirements

> The following section describes items that have been identified as
> requirements for the caCORE SDK that may be addressed in the caCORE
> 4.0 release.
>
> For readability, the potential requirements are will be provided in
> the "feature request" and "Suggestions" trackers on the caCORE SDK
> Gforge web site.