This section includes the following:
Overview of Inception Phase
The inception phase of the Semantic Infrastructure 2.0 and caGrid 2.0 Roadmap projects will inform the follow on requests for proposals (RFPs) and those to whom contracts are awarded.
The inception phase is part of the Rational Unified Process (RUP), also known as the Unified Process (UP). The Unified Process is:
- Iterative and Incremental
- Use case Driven
- Architecture Centric
- Risk Focused
An inception phase (as described on Wikipedia) has the following goals:
- Establish a justification or business case for the project
- Establish the project scope and boundary conditions
- Outline the use cases and key requirements that will drive the design tradeoffs
- Outline one or more candidate architectures
- Identify risks
- Prepare a preliminary project schedule and cost estimate
The Inception phase for the Semantic Infrastructure 2.0 and caGrid 2.0 are especially focused on risk mitigation, to enable success of the caGrid 2.0 and Semantic Infrastructure 2.0 platforms. Some of the risks are cited here. The inception phase includes the following:
- Interim platform development (caGrid 1.x Legacy Compatibility, section 10.5 of caGrid 2.0 Roadmap), answering the question "How will software be developed in the interim period: for caGrid 1.x or caGrid 2.0 or both?"
- Migration strategy for Semantic Infrastructure and support of current users, providing support for users of Semantic Infrastructure
- Semantic workflow prototyping, finding services and applications, and assembling them into workflows
- Security prototyping, answering the question "Will Security Services satisfy use cases and requirements?"
- Other activities including support for generating specifications and for conformance and compliance, and testing domain modeling for Life Sciences
Interim Platform Development (see https://wiki.nci.nih.gov/x/9AH0AQ
)
Interim platform development focuses on section 10.5 of the caGrid 2.0 Roadmap, caGrid 1.x Legacy Compatibility. There will be periodic interaction with caCIS team and other development teams to update this section as necessary. In addition, feedback from the community and other consumers such as Legacy Sequential Layered Refactoring (LSLR) will be included. It is likely that a parallel section in the Semantic Infrastructure 2.0 Roadmap will be written, especially with results from the Migration Strategy project described in the next section.
Migration Strategy for Semantic Infrastructure (see https://wiki.nci.nih.gov/x/WAwSAg)
The migration strategy for Semantic Infrastructure includes:
- Support for current users of CDEs
- Transforming a set of CDEs to the new Semantic Infrastructure representation
- Determining the process for the transformation
- Determining how many CDEs need to be transformed, including usage and re-use
- Determining whether parts of process can be automated
- Determining the level of effort
- Determining what will the user experience will be, that is, what interfaces community members will use
Semantic Workflow Prototyping (see https://wiki.nci.nih.gov/x/cpIhAg)
Semantic workflow prototyping includes:
- Defining three specific use cases, and resulting requirements for workflows, for example from:
- Life Sciences
- TCGA (Translational medicine)
- caBIG® Clinical Information Suite
- Defining the metadata and data needed for discovery, composition and execution of a workflow
- Bottom up: from use cases and requirements
- Top Down: In part from Behavioral Framework Metamodel outlined in HL7 SAIF
- Meet in the middle
- Determining the usefulness of World Wide Web Consortium tooling for computational derivation of metadata
- Contract metadata from Web Service Definition Language (WSDL) and Web Application Description Language (WADL)
- Semantic queries
- Prototyping workflows (concentrating on exercising the INFRASTRUCTURE)from the above use cases
- Determining how to discover, assemble services
- Use of tools (for example, high level programming language, Taverna, Business Process Execution Language (BPEL) engine)
Security Prototyping (see https://wiki.nci.nih.gov/x/cJIhAg)
Security Prototyping includes:
- Consideration of aspects of interoperability
- RESTful and SOAP programming models
- Interoperability between Java and .NET technology security services at different institutions
- Working in concert with three other teams:
- Enterprise Security Program at NCI CBIIT
- caBIG® Clinical Information Suite
- MD Anderson
- Develop and Deploy a Security Token Service (STS) with multiple interfaces
- WS- Trust Service: capable of issuing SAML 2.0 Assertions and X.509 Certificates
- SOAP and REST
- Develop and Deploy a secure SOAP Web Service that is secured using tokens from a Security Token Service (STS)
- Leverages WS-Security SAML Token Profile to accept and process SAML 2.0 assertions issued by the STS (Task 1)
- Leverages WS-Security X.509 Token profile to accept and process X.509 credentials issues by the STS (Task 1)
- Develop and Deploy a secure RESTful service that is secured using tokens from a Security Token Service (STS)
- Web Single Sign On (in concert with the Enterprise Security Program at CBIIT): prototype Web SSO solution for facilitating single sign on across web application, SOAP Web services, and RESTful services
Other Inception Phase Activities
The other inception phase activities include:
- Support for specification generation: discussions between Semantic Infrastructure group and SAIF IG group, caBIG® Clinical Information Suite team (see https://wiki.nci.nih.gov/x/LA89Ag)
- Models (UML, OWL) and tools
- DITA Framework and Eclipse Modeling Framework (EMF)
- Determining how to ensure conformance and compliance
- Within a specification stack?
- Of implementations to specifications?
- Further Requirements gathering (see https://wiki.nci.nih.gov/x/GCY9Ag)
- Support for Life Sciences Domain Modeling: How can we ensure timely discovery and deployment in the high change, environment of Life Sciences?
- "Dynamic Extensions"
- Life Science Modeling in new representation.