|
|
| (15 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| − | ==Corona Project Container=== | + | <table border='1' cellpadding='3'> |
| | + | <tr> |
| | + | <td>[http://www.eclipse.org/corona Eclipse Home]</td> |
| | + | <td>[[Corona|Corona Wiki Home]]</td> |
| | + | <td>[[Corona Development Community|Development]]</td> |
| | + | <td>[[Corona Design|Design]]</td> |
| | + | </tr> |
| | + | </table> |
| | + | ---- |
| | + | ==Corona Exemplary Implementation: Project Collaboration == |
| | | | |
| − | ===Description=== | + | === Description === |
| − | The Project Container 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.
| + | Corona's exemplary implementation provides collaboration on a ''Project''. It will allow multiple Eclipse Workbench IDE's to participate in a ''Workgroup''. Project collaboration is based upon a ''Project Container'', an extension of Corona's context container framework. |
| | | | |
| | + | In addition to providing a ''Project Container'', the exemplary implementation will also extend Corona's collaboration event model. A ''Project Event'' is defined that extends the ''Collaboration Event''. |
| | | | |
| − | ===References=== | + | === Project Events === |
| − | *See IoC Container
| + | |
| − | *See Collaboration Framework
| + | |
| − | *See Corona Knowledge Base
| + | |
| | | | |
| − | ===Scope=== | + | ==== Project Open ==== |
| | + | The Project ''open'' event is published whenever a Project Container is opened. |
| | | | |
| | + | ''''Event Attributes'''' |
| | + | <table border=1> |
| | + | <tr><td>CONTEXT_TYPE</td><td>"Project"</td></tr> |
| | + | <tr><td>CONTEXT_NAME</td><td><i>Project Container's name</i></td></tr> |
| | + | <tr><td>COLLABORATION_ID</td><td><i>Project Container's ID</i> </td></tr> |
| | + | <tr><td>ACTION_TYPE</td><td>"open"</td></tr> |
| | + | </table> |
| | | | |
| − | ===Assumptions=== | + | ===Project Context Container Manager=== |
| − | *Security will be added via an IoC Interceptor.
| + | [[Image:ProjectContextContainerManager.png]] |
| − | *A repository of users will be accessable.
| + | |
| − | | + | |
| − | ===Design===
| + | |
| − | ====Collaboration Events====
| + | |
| − | Collaboration Events will notify the Project Container of project change activities occurring on Eclipse Client. The Project Container will if needed forward Collaboration Events from one Eclipse Client to another.
| + | |
| − | | + | |
| − | ====Event Focus====
| + | |
| − | The Project Container 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 Project Container will not typically contain project resources. The Project Container will usually deal with references to the resources and artifacts. Project Container 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 Project Container utilizes an Inversion of Control (IoC) implementation for extensibility. As new Project Containers are instantiated the chain of registered intercepters will be called. Likewise, when an object is added to the Project Containers the object is accessable to the registered interceptors.
| + | |
| − | | + | |
| − | ====Containers Nested with a Project Container====
| + | |
| − | Project Containers can be nested within other Project Containers. 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)
| + | |
| − | ***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 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
| + | |
| − | *** 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.
| + | |
| − | | + | |
| − | **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" the create/read/update/delete are sent to the Project Container as Collaboration Events.
| + | |
| − | | + | |
| − | ===Risk===
| + | |
| − | *Project Container 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
| + | |
