Feature Proposal
From MemberWiki
Howard says: I have updated my original proposal in accordance with some of the comments. I have removed some of the other comments (the css comments) that were not really specific to features and will create a separate page for them under interoperability. I have also added some more notes.
Contents |
Background
Mash-up components need to be loosely coupled rather than monolithic. Among other things, loose coupling requires that dependencies be expressed in terms of interfaces rather than specific implementations. We propose to add this capability to the OpenAjax Metadata.
Features
Specifically, we propose to introduce the notion of a "feature." A feature is a named and versioned specification that defines an abstract interface between components. The specification may enumerate sets of methods, properties and events. It may also identify resources (e.g. images or CSS rules) and/or higher-level message exchange protocols or other behavior.
Terms
- Feature Provider: A component that implements a feature.
- Feature Consumer: A component that makes use of a feature implemented by someone else. This dependency may be mandatory (consumer will not work if no provider/s are present) or optional (consumer can make use of feature if provider/s are present)
- Feature: A specification that defines how feature provider(s) and feature consumer(s). can interact. The feature is identified by a URL that points to the specification.
- Registry: A feature consumer can advertise a dependency on a feature, together with a set of feature-specific properties (name-value pairs).
- Discovery: A feature provider can discover compatible feature consumers.
- Binding: Feature provider can request that consumers bind to it.
Relationship to OpenAjax Metadata
The OpenAjax Metadata spec is extended to include a new type of "require" whose type is "feature", allowing gadgets and other components to require features rather than on specific implementations (gadgets, libraries) of these features.
The spec is also extended to include a new "implementsFeature" element that specifies features implemented.
Example
Suppose that a gadget depends on one feature:
* Stock quote feed feature named: "http://www.tibco.com/openajax/features/example/quotes": - Listens on a topic, "com.tibco.example.quote.start" for messages with structure { symbol: "(Stock Symbol)" } - When message received on this topic, responds by publishing stream of stock quote data on topics
"com.tibco.example.quotes.(symbol)"
Many different gadgets or libraries might provide implementations of the stock quote feed feature. The consumer may not care about the implementation -- which might take the form of a gadget or an API, a browser plug-in or a javascript component -- so long as something provides the specified capability.
The stock quote feed feature specifies not only the events (the topics and payloads) but also a higher-level relationship between them. Features allow gadgets to declare dependencies on specific higher-level behavior.
Relation to Gadgets, etc.
A gadget, library or API can implement zero or more features and consume zero or more features. Features do NOT replace gadgets, APIs or libraries.
Hub Feature Registry
It is possible for the Hub to provide a registry that allows consumers and providers to discover each other at run-time. This would be used in portals and other dynamic mash-up scenarios.
The registry can be provided at run-time by the Hub, which allows feature consumers to register themselves. When a feature provider starts serving a feature, the consumers are notified, and when a new consumer appears for a feature, the registry notifies the new consumer.
Comments
NOTE: Comments includes from email stream for discussion purposes:
- Regarding markup, my initial thinking is that we shouldn't re-use the <require> element. Instead, I suggest new and different elements. Let's leave <require> solely for the purpose of identifying the files or directories that need to be deployed for the widget to work. (Perhaps <resources> or <requiredResources> would be a better name?). And then let's have something else, such as <features> or <requiredFeatures>, that defines the interfaces that the widget needs. (One of the reasons why I propose this markup approach is that I think we should allow for easy transformation to/from JavaScript objects.) JON 2008-04-09 I withdraw my comment. OK with me to use <require type="feature">
- A number of comments were not really related to features; they were related to the need for CSS namespacing: Gadgets and CSS Namespacing
- Given the description of a feature's content (above), it seems like we are describing a dependency on an external "widget" metadata file itself. Most of the types of data in the above discussion are in the widget metadata OpenAjax Metadata Specification Widget Metadata, almost like a widget dependency whose content expansion is void or perhaps controlled by the consumer of the feature. For example, using the fragment from the metadata page to start:
<widget xmlns ="http://ns.openajax.org/widget" ...>
...
<requires>
<require [type=""] [name=""] [minVersion=""]
[src=""] [target=""] [includeAssetReference=""]>
</require>
...
<requires>
<require type="feature" name="someStandNamePerhaps?" src=""http://www.tibco.com/openajax/features/example/quotes"/>
</requires>
...
</widget>
- In the above sample, I leverage the requires metadata with the new type called "feature". I realize the comment above says not to, here is what I was thinking: In the metadata spec we have the following <require type="library" name="dojo" minVersion="0.9"> for example, which states the widget needs the full dojo 0.9 version available in order to operate correctly. We currently support the following enumeration for type: library | javascript | css | xsl | folder | . Requiring a library and requiring a feature seem pretty close semantically.
- If we use the require tag or introduce another tag we still need to define what the metadata looks like, seems to make sense to reuse the IDE metadata, a question becomes what is the containing element of the specification, what new elements do we think will be feature only related.
- JON 2008-04-09 Processing model questions. Let's say for a moment that we support <require type="feature"> and 'implementsFeature'. What are mashup runtimes, widgets and OpenAjax Hub supposed to do with this? Suppose widget A requires feature F and no other widgets implement F. Should the mashup runtime go into error mode? Should it refuse to load A? If A has already been loaded and the F provider goes away, should/must A get unloaded? What if there are 2 implementers of F. Should only one of them get linked to A as the sole provider of F, or do all of the implementations gets linked to A as providers of F? Should there be a way that A can choose which implementer it wants to use? Do we need an extra method or two in OpenAjax Hub so that A can query the Hub to see if any implementers of F exist?
