Howard Abrams |
| Software Architect |
| Cordys, Inc. |
This repository has two primary actions. First, developers of "modules" will add their ISV packages into the repository. Second, other developers will search the repository for "modules", downloading and installing those components plus any dependent components.
Adding to the repository amounts to creating a "Cordys Module" in the form of an ISVP file, Jar or Zip archive, and uploading it into the repository.
The server analyzes the component and attempts to extract any helpful metadata (from either the isv.xml or meta-inf files). The uploading developer then has a chance to add more information to the metadata. This would include things like programming notes and installation instructions. The metadata is stored in a database for ease in searching, and the ISVP is stored on the file system for ease in downloading via URLs.
Note: This metadata is important for searching and understanding the components in the repository database.
Each module will have one or more versions. Each version is associated with the module, and dependencies between the modules may specify version. Extra documents formatted in Word, PDF, Powerpoint presentation or other helpful documents can also be uploaded and stored along-side the module.
Once the module and its metadata have been stored in the repository, other developers can use the repository to search the database for the components they need.
They can search on a number of criteria, including full text searches on the descriptions. Once the modules have been identified, they can either be downloaded directly, or can be downloaded as a package that contains the component plus and dependencies that component (and its subcomponents) may have.
Documents that are associated with the module may also be downloaded.
The SDF Project is developing the Solutions Development Framework within the US Technology and Industry Solutions Group. The following describes the architecture and code details for the current version of the project (http://srv-us-sol1/sdf)
The current version of the SDF was prototyped using a Java framework and currently runs under the Resin app server (due to its small size) and uses a MySQL database for its object persistence. The "modules" and their associated documents are stored directly in the file system.
What is stored in the SDF is called a module, and can refer to a solution, component, a 3rd party Jar file, etc. Each module is rendered in the system using the Component class. This class is persisted in the database, and refers to all of the other classes (see the diagram below).
The Component class has one or more instances. This Instance class refers to different versions of the module. For instance, we could have a version of the module for C2 and another one for C3, and each version would have an associated ISVP file.
When an ISVP or a Jar file is uploaded to the system, we need to analyze it in an abstract manner. To do this we use the APackage, and its children. The uploaded file is first checked based on its file extension, and then one of the children classes are created. Once this is done, we can then have it generate a Component class with some of the Component's metadata already assigned. We can then pass this to the view for the user to update and change.
The ModulePackage is only used during the Bootstrap phase if the database has been corrupted beyond recognition. For the Bootstrap will read all of the ISV files in the repository and attempt to recreate the repository based on the information stored in the isv.xml files within those packages. The ModulePackage then represents one of these modules with all of the instances in that directory.