by
dcooper@jade.co.nz >> Tue, 16 Jul 2002 11:41:33 GMT
[snip] it appears to me as a more 'advanced', reusable partial schema extraction.
Not really. You can achieve (sort of) similar results using partial schema extracts, but:
- For large units of reusable code, partial extracts can quickly become cumbersome.
- Client schemas can become bloated with implementation details that they don't need/want to know about (even if the source is stripped, you still have all of the implementation classes loaded and visible in the client schema).
- You can encounter class/property/method conflicts when loading reusable partial extracts from multiple different sources.
- There is no (easy) way for the provider of the reusable code to enforce an interface because all of the implementation classes are visible in the client schema.
- For multiple client schemas to reuse the code, the partial extract must be loaded into a common top-level schema (which encourages large, monolithic reuse schemas). Otherwise, the partial extract must be loaded (duplicated) multiple times, once for each client schema (this duplication is also necessary where multiple, unrelated schemas want to reuse the code).
Packages in JADE 6 recognise that single schema inheritance is limiting when you want a framework of classes implemented in one schema to be available to multiple other, unrelated schemas. For example, you may want to implement a "services" layer of schemas below the RootSchema in which you package all of your common class frameworks. You may want these services to be available to all application schemas implemented in unrelated schema branches. Each application schema may want to use classes from multiple frameworks.
Such a structure is possible, but difficult, to implement today (using global instance visibility) and is subject to several restrictions (which Packages remove). Typically, developers create few framework schemas (often only one) at the top of their schema hierarchy, from which all application schemas inherit. This can result in large and inflexible top-level schemas, as it is difficult to insert new framework schemas into an existing schema branch. Too many top-level framework schemas can lead to a top-heavy hierarchy as in order to maximise reuse, all framework schemas must be defined in a common branch from which all application schemas inherit.
Packages provide an easier and more effective way to build and reuse common code/components/frameworks. Existing schema hierarchies will require no changes and new functionality will be able to be added without the need to insert schemas into an existing schema branch.
A Package is part of a schema. A Package is *implemented* in a schema using class inheritance, just as you implement a schema today - that doesn't change. However, in JADE 6, the implementation schema can export one or more Packages, with each Package defining only those classes, properties, methods and constants that it wants to expose to other schemas. The implementation schema (ie: the schema that exports a Package) is also referred to as an *exporting* schema. From the exporting schema's point of view, think of a Package as a set of export definitions. The ability to export multiple Packages from a schema is important because you may implement a NetworkServicesSchema, for example, that provides SMTP, LDAP, FTP and SNMP functionality. You need to be able to expose each capability in its own logical Package (but with them all implemented in the same schema). The schema can still be used as the unit of deployment. For example, I can extract my NetworkServicesSchema (which will extract the implementation and all Package definitions) and load it into another environment (which will make the exported Packages available for use in that environment).
Another schema can import and use the features exposed in the Packages exported by an exporting schema. A schema that imports a Package is referred to as an *importing* schema. A single schema may be both an importer and an exporter. Importing and exporting schemas can be totally unrelated (ie: they may exist in completely independent schema branches).
The import name of a Package can be defined at import time (the default is the exported Package name). This caters for situations where an importing schema wants to make use of multiple exported Packages with the same name. However, Package definitions and export characteristics cannot be changed by an importer.
Where an imported class can unambiguously be identified (ie: its name does not conflict with a class already defined in the importing schema's branch, or another imported class), that class can be accessed by name. Where the name of an imported class does conflict with another class, you can access the imported class by prefixing the class name with the imported Package name using a new <Package name> :: <Class name> syntax. This addresses the problem of namespaces when several Packages export classes with the same name.
Hope this helps.
Dean.