Discovery based bootstrapping for advertisements

• Key: MUSE-256
• Type: New Feature
• Status: Open
• Priority: Major
• Assignee: Dan Jemiolo
• Reporter: Balan Subramanian
• Component/s: WSDM MUWS Advertisement
• Fix Version/s: 2.3.0

Description

Currently Muse expects users to provide the EPR of the intended receiver of advertisements in muse.xml. The suggestion is to automatically discover this at runtime / initialization time using discovery mechanisms like SLP and WS-Discovery.

We can implement this in a pluggable manner by providing an abstract discovery definition of which a concrete implementation can be specified in muse.xml. If such a definition is present, Muse must first invoke the discovery code to discover the intended advertisement receiver. It is expected that advertisement receivers will "lend" themselves for discovery through various mechanisms like being Service Agents or in the case of WS-Discovery will be listening for probe messages. Hence this requirements actually has a endpoint side requirement for endpoints implementing advertisement capability and "client" side requirements for WS-N consumers (to advertise or listen for probe messages). The actual implementation is not a consideration for Muse.

Before sending advertisements, Muse will check to see if a consumer-epr.xml file is specified or a discovery class is specified. If a discovery class is specified it will query the class to find the EPR of the WS-N consumer before sending the advertisement.

The suggested default implementation is WS-Discovery.

Comments

[Nalini]

Proposed Design document for Discovery based bootstrapping for advertisements

[Kam K. Yee]

Instead of directly modifying SimpleAdvertisement, why not create new classes (e.g., WSDiscoveryDynamicAdvertisement and SLPDynamicAdvertisement) that either extend SimpleAdvertisement or AbstractAdvertisement (which ever is more appropriate) and implement the newly introduced DiscoveryCapability? This would not require changes to the muse descriptor schema and retain the now known and stable implementation of SimpleAdvertisement (which other classes extend).

One suggestion I would make is to use Resource.getCapability( ) or Resource.hasCapability( ) rather than creating another init-param. Have the Advertisement implementation(s) check for the presence of the Discovery capability in the containing Resource and start the discovery process if it's there; the ability to have these kind of conditional features was one of the main goals of having the *Capability( ) methods in the Resource API and making sure all capabilities had interfaces. This way you can have the optional discovery stuff without adding another init-param - discovery just gets turned on if you add the capability, and advertisement is augmented if it's there as well.

[Kam K. Yee]

Attached is the implementation of this new feature contributed by the IBM Team