**Preliminary High Level Scope Items**

The preliminary scope items are divided into two groups. Group one is
the minimum scope without redeployment requirements. Additionally, the
minimum scope group takes into account that a larger time and resources
supports from both CCTS and LSB are required (worst case scenario).
Group two is a scenario where the caGrid team takes a lesser hit from
those supports activities.

Before we finalize on which group of scope items we shall commit to,
there are several keys questions must be solved. They are:

**caCore:**

When is caCORE 3.1 going to be deprecated?

When will the caDSR API for accessing UML/XML binding information be
available?

Will it require us to move to caCORE 4.0 (the places we will make use of
it also currently use the 3.1 caDSR APIs)?

Avinash:

1)  caCORE 3.1 will be de-commissioned after caGrid dependency is
    removed. Currently, caGrid has dependency on caDSR and EVS. The
    caDSR dependency (on XML binding) will require the caGrid to move to
    caDSR 4.0. Please check with the caDSR Project Manager (Steve Alred)
    for timeline for releasing caDSR 4.0. EVS grid service may need to
    be upgraded to use caCORE 3.2 in the short term until the "lexbig"
    grid service becomes available. When the LexBIG grid service becomes
    available, it will be "separate" from the caGrid core
    infrastructure. The caCORE 3.2 migration of EVS grid service is
    being currently planned (but no solid date as yet). So, for now,
    caGrid can plan to release keeping the support for caCORE 3.1.

**Deployment:**

Dorian CRF part 2111 changes may require a large effort, are they
critical for the release?

Avinash: The CFR Part 11 validation process typically tends to be
lengthy with a bunch of requirements that are "process" oriented such as
getting appropriate docs, access to code, etc. As a first step, BioPharm
should be doing a "gap" analysis to determine what needs to be
fixed/changed by the development team. That can occur now since it is a
separate team (Biopharm). Once the gaps are identified, the caGrid
development team can evaluate and come up with a schedule to fill the
gaps. The entire process will take most likely more than a few months.
So, I don't think we need to plan to make the system compliant in the
upcoming realease, but we need to allocate sufficient time to provide
support to biopharm and start making changes. Otherwise, this may not
get done in time for the CCTS deployments next year!

**Statistics (caGrid metrics):**

What caGrid metrics is needed? Seems like pressing need is for stats on
non-core services; if we want stats on core services for 1.2, we may
need to do a full re-deployment (depending on how it is implemented)

Avinash: This is fine as starting point. Once you have a basic
"strawman" proposal, have it signed off by Subha. I am assuming that the
work here will be really minimal (basically, whatever Globus does, but
just packaged for consumption by caGrid community). If this is not true,
then, please re-evaluate because there are other higher priority items
(Data services, WS-N , etc below) that would take precedence.

-   **Proposed Minimum Scope baseline (without redeployment)**

    -   Data

        -   SDK 4 support and general improvements to introduce
            integration

> Avinash: High Priority and also want to see if a process can be put in
> place that can make this integration happen in coordination with
> future releases (PM: Charles Griffin for SDK)

-   New data service tutorial

> Avinash: The Georgetown U team (Baris) is currently developing a data
> service focused tutorial. Instead of developing a separate one, I'd
> rather support that effort in any way possible, including helping them
> add specific tutorial material, reviewing content, etc.

-   Security

    -   WebSSO

    -   Delegation Service

    -   Delegation Service UI

-   Introduce

    -   Undeploy Support

    -   Updated Service Creation tutorial

> Avinash:
>
> 1\) Doc comment, same as above. Please coordinate with GU (Baris) and
> make sure that it is done in one place.
>
> 2\) Support for WS-Notification based services is becoming important.
> So, it would be important to see if this can be added to the system

-   Metadata

    -   Additional Metadata Processing Utility

> Avinash:

1)  I am assuming that this refers to allowing much easier ability to
    build "join" statements for CQL (based on my email). That is fine.
    Otherwise, one area that has come up is in the area of having
    additional metadata on the grid-side (Index service) to be able to
    handle BDT metadata (e.g. understanding the content of zips, text
    files etc).

    -   Other

        -   Build system supporting dependency management
            (internal/external)

        -   Installer maintenance and new components (portal2, websso)

> Avinash:

1)  Keep it to a minimum (maintenance and bug fixing only)

-   **Proposed Scope baseline (without redeployment)**

-   **Avinash: Instead of commenting on the items below, because many of
    them are similar to the section above, I am going to add general
    comments for the direction of the components in the next release.
    Also, I am thinking that instead of coming up with 2 scenarios,
    simply pick a** **set of scope items and adjust the release date
    based on time needed to support bundle activities.** **This will
    minimize having to scale back at the end of the release.**

    -   Data

        -   SDK 4 support and general improvements to introduce
            integration

        -   DomainModel generation from XMI support

        -   New data service tutorial

    -   Security

        -   WebSSO

        -   Delegation Service

        -   Delegation Service UI

        -   Dorian delete host cert bug fix?

        -   CRF part 2111 changes? (changes reported by dec 18?)

    -   Introduce

        -   WS-Notification

        -   Persistent resources

        -   Undeploy Support

        -   Migration to Grape (common UI framework)

        -   Extension to add service statistics support

        -   Updated Service Creation tutorial

        -   XSD from XMI move to SDK 4.0

    -   Metadata

        -   Additional caDSR semantic operations

        -   Additional Metadata Processing Utility

    -   Other

        -   Service validation/testing suite

        -   Build system supporting dependency management

        -   Statistics support (server, new services support)

        -   Installer maintenance and new components (portal2, websso)

General Comments:

1)  I have seem many requests (e.g. TBPT, Imaging, etc) for improvements
    to be made to the data service capability in areas including but not
    limited to:

    a.  Ability to do more complex query (GroupBy, Having, Hierarchical
        query from TBPT)

    b.  Get results that can go much deeper in the object graph

    c.  Ability to improve scale by allowing more targeted data
        retrieval (instead of entire objects),

    d.  Improve performance of XML-\>Object de-serialization

Essentially, I'd like to focus on "data" service capability enhancements
as soon as possible. This is becoming critical since now that the grid
services are available, new client apps are being written that want to
use the grid services in the backend and would want them to have the
same performance/scale as a client-server environment. I realize that
there are implications of this on the "specification" for data service,
but I think it is important enough that we need to come up with a
mechanism to allow this capability for our users who need it.

2)  Easy support for WS-Notification is also important since it is one
    of the requirements for CTMS products. Making the notifications
    "reliable" is also important, but that may need coordination with
    the Globus team. So, at a minimum, it would be important to have the
    WS-N integration be available for introduce toolkit generated
    services.

3)  It is important for grid-service developers to be able to develop
    grid-services without having to wait for caDSR registration of the
    model to be completed. I am assuming that "DomainModel generation
    .." item above refers to it\... Also, it is important to have some
    programmatic ability to control this activity and make sure that the
    caDSR registration is done before being allowed to publish on the
    production grid.