Difference between revisions of "Corona Design Project"

Revision as of 05:44, 30 June 2006

Corona ProjectContainer

Description

The ProjectContainer is a Server Side Corona Component that manages Project Context so that it can be shared with many Eclipse Client RCP's. For example an active Project User List will be maintained as part of the Context Information.

References

• See IoC Container
• See Collaboration Framework
• See Corona Knowledge Base

Scope

Assumptions

• Security will be added via an IoC Interceptor.
• A repository of users will be accessable.

Design

Generic Container

Project Container is a specialization of Generic Container. Generic Container model is described by the following schema:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:con="http://www.eclipse.org/corona/server/container" targetNamespace="http://www.eclipse.org/corona/server/container">

  <xs:complexType name="context-container">
    <xs:sequence>
      <xs:element name="container-uri" type="xs:anyURI"/>
      <xs:element name="container-path" type="con:container-path-element-uri" maxOccurs="unbounded"/>
      <xs:element name="container-type" type="xs:anyURI"/>
      <xs:element name="container-description" type="xs:string"/>
      <xs:element name="repositories" type="con:repository" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="subcontainers" type="con:subcontainer" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="container-properties" type="con:container-property" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="relationship-resource-set" type="con:relationship-file" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="relationship-file">
    <xs:attribute name="type" type="xs:string" use="required"/>
    <xs:attribute name="version" type="xs:string" use="required"/>
    <xs:attribute name="uri" type="xs:anyURI" use="required"/>
  </xs:complexType>

  <xs:complexType name="repository">
    <xs:attribute name="uri" type="xs:anyURI" use="required"/>
    <xs:attribute name="type" type="xs:anyURI" use="required"/>
  </xs:complexType>

  <xs:complexType name="subcontainer">
    <xs:attribute name="uri" type="xs:anyURI" use="required"/>
    <xs:attribute name="type" type="xs:anyURI" use="required"/>
  </xs:complexType>

  <xs:complexType name="container-property">
    <xs:attribute name="name" type="xs:string" use="required"/>
    <xs:attribute name="value" type="xs:string" use="required"/>
  </xs:complexType>

  <xs:simpleType name="container-path-element-uri">
    <xs:restriction base="xs:anyURI"/>
  </xs:simpleType>

</xs:schema>

This schema serves as an input for SDO model code generator.

Generic Repository

Collaboration Events

Collaboration Events will notify the Project Container of project change activities occurring on Eclipse Client. The ProjectContainer will if needed forward Collaboration Events from one Eclipse Client to another.

Event Focus

The ProjectContainer acts as lense to focus all events related to a project. This focus create a central knowledge collection point for the Corona Knowledge Base.

Resources

The ProjectContainer will not typically contain project resources. The ProjectContainer will usually deal with references to the resources and artifacts. The ProjectContainer will use URI based references whenever possible. The URI identification approach meshes with the Corona SOA orientation as well as the Knowledge Base OWL/RDF object metadata defintion.

IoC

The ProjectContainer utilizes an Inversion of Control (IoC) implementation for extensibility. As new ProjectContainers are instantiated the chain of registered intercepters will be called. Likewise, when an object is added to the ProjectContainers the object is accessable to the registered interceptors.

Containers Nested with a Project Container

ProjectContainers can be nested within other ProjectContainers. This gives sub-projects access to information in their containing parent Project Containers.

Main objects used with ProjectContainer

• ProjectManager
  • how does this relate to ContainerHome ?
  • responsible for locating ProjectContainer
  • API
    • getProjectContainer(MemberName, ProjectName)
    • getProjectContainers(MemberName)
    • mapProjectToProjectContainer(MemberName, MemberProjectName, ProjectContainerName)
• ProjectContainerFactory
  • just utilizes a ContainerHome to instantiate a ProjectContainer

• ProjectContainer
  • holds the context and state of a project
  • the initial context is loaded from the ProjectContainerConfiguration
  • holds a list of active Project Team Members
  • API
    • AddRepository - add a respository to ProjectContainer. Typically used to add a CollaborationRepository i.e. TeamRepository, TaskRepository
    • removeRepository - remove a repository from ProjectContainer
    • Question should I just continue with ContextRepository?
    • saveContext - causes the context of the ProjectContainer to be persisted
    • restoreContext - restores the context of the ProjectContainer from the persisted backing store
    • addSubProject - add a ProjectContainer reference to the current ProjectContainer
    • removeSubProject - remove the reference to a ProjectContainer in the current ProjectContainer
    • listChildSubProjects - list ProjectContainers within current ProjectContainer
    • listAllSubProjects - recursively list all ProjectContainers within the current ProjectContainer

• CollaborationRepository
  • holds basic information used to locate a respository of information for example URI, authentication properties, connection properties
  • holds properties regarding access to the repository
  • API
    • openRepository - uses connection properties and authentication properties to connect to the respository. Should there be a reopenRepository when a reconnection to a repository is needed?
    • closeRepository - closes the connection to a repository
    • updateRepositoryProperties(RepositoryName, Properties) - add/remove/change properties defined in the Repository
  • ArtifactCollaborationRepository
    • holds properties regarding access to artifacts probably just a wrapper around CVS, Subversion etc.
    • see ALF vocabulary definitions for Source Code Management (SCM).
    • I think we only want to be able to retrieve a specifically versioned artifact.
    • Do we need to update a versioned artifact or can we just receive notification of the update?
  • ProcessCollaborationRepository
    • holds properties regard access to process defintion, hopefully the API on the Eclipse Process Framework (EPF Project) will be rich enough that can access Process information.
    • will have to monitor EPF API's to see how this will work
  • TeamCollaborationRepository extends CollaborationRepository
    • Assumption: Team members could have different roles in different project contexts. So, I think TeamCollaborationRepository only make sense in the context of a project
    • Subclass of CollaborationRepository
    • API
      • addMember(MemberName)
      • removeMember(MemberName)
      • setMemberRole(MemberName, RoleName) - the role name should be well defined and each role name be unique, I'm thinking OWL/RDF defintion of Roles.
      • getMemberRole - return the primary role defined in this Repository
      • getMemberRoles(MemberName) - return list of all roles on a project
      • deleteMember(MemberName) - remove the member from this repository
      • setMemberPrimaryRole(MemberName, Role)
      • setMemberProperties(MemberName, Properties
  • TaskCollaborationRepository extends CollaborationRepository
    • Subclass/interface of CollaborationRepository
    • API
      • addTask
      • removeTask
      • setTaskProperties

Client Collaboration Nature

The Client Collaboration Nature forwards events similar the events received by "builders". These events include create/read/update/delete. They are sent to the ProjectContainer as Collaboration Events.

Risk

• ProjectContainer needs to allow knowledge collection. Iformation in the Project Container must be complete enough to collect knowledge within correct context.
• Performance Risk, Many client may generate so many Collaboration Events the the Project Container cannot process them "fast enough".
• Hooks to other Repositories have to be written and we may not have enough people to write all required interfaces to an ever expanding set of repositories.

!Project to ProjectContainer Communication The first implementation is target ECF as the communication mechanism between the RCP Application and the Corona ProjectContainer

• Scenerio One
  • User creates a Client side project and adds a collaboration nature to it
  • The client side project sends an collaboration message to the ProjectManager on the Corona Server. The collaboration message contains the name of a ProjectContainer instance.
  • The ProjectManager looks to see if a ProjectContainer instance with the client specified name exists.
  • If the name doesn't exist then the ProjectManager
    • calls the ProjectContainerFactory to create a new ProjectContainer with the specified name
    • The ProjectManager adds the ProjectContainer name to its active list as wells as its available list (available ProjectContainers have been serialized out so they do not take up memory whereas, active ProjectContainers are in memory.
    • ProjectManager creates an Collaboration Topic matching the name of the ProjectContainer (an ECF Topic in this case).
    • the client is added to the active user list
    • After the topic has been created the ProjectManager publishes a collaboration message on the Collaboration Topic indicating a new ProjectContainer with the client specified has been created.
    • The client receives the collaboration message and subscribes to the ProjectContainer Topic (does an ECF join).
  • when the name does exist the ProjectManager
    • loads Project Container if it is not on its active list.
    • adds the user to the ProjectContainers active user list - after authentication
    • the client subscribes to the Project Container Topic
    • use is then part of workgroup and receives Project collaboration events