SLP 2.0 Summary

View: New views
1 Messages — Rating Filter:   Alert me  

SLP 2.0 Summary

by simonebordet :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

here's a summary of the what SLP 2.0 provides/will provide:

+ SLP 2.x is incompatible with 1.x, as many classes have undergone
substantial modifications in the API, although the concepts are
obviously unchanged and the migration from 1.0 to 2.0 should not be
difficult.
+ Rewritten API, now I hope much clearer and easier to use, especially
during creation and configuration.
+ Support for non-listening (and hence light on resources) UserAgent,
called UserAgentClient (UAC): UACs do not spawn threads to listen for
SLP messages, they only issue requests and receive replies to those
requests.
+ Support for listening user agent, called UserAgent (UA): UAs listen
on the SLP multicast ports for SLP multicast messages.
+ Support for non-listening (and hence light on resources) service
agent, called ServiceAgentClient (SAC): same advantages of UACs.
Communicates with a SAS (see below).
+ Support for listening, standalone, service agent, called
ServiceAgentServer (SAS): it listens on the SLP TCP port, so only one
instance can be deployed per host. This deployment mode is equivalent
to the default OpenSLP deployment.
+ Support for listening, non-standalone, service agent, called
ServiceAgent (SA): unlike the SAS, it does not listen on the SLP TCP
port, and hence many instances can be deployed for host. It listens
however for multicast SLP messages so it's a useful hybrid between SAS
and SAC, as it allows any service provider to expose services without
worrying of additional setups.
+ Support for listening, standalone, DirectoryAgent, called
DirectoryAgentServer (DAS): like the SAS, it listens on the SLP TCP
port, so only one instance can be deployed per host. This deployment
mode is equivalent to the OpenSLP deployment when isDA=true.
+ Support for RFC 3082 Small Network Notifications: SA and SAS emit
notifications for service registration and deregistrations, while UA
listens for those notifications. No support for RFC 3082 Large Network
Notifications. The RFC 3082 notifications allow to build a cluster of
nodes that are aware of each other.
+ Support for multihomed hosts and use of broadcast instead of
multicast (still experimental, but all the bits are there).
+ Listeners and events for all important SLP events (service
registrations/deregistrations, notification, directory agent
advertisements, ...).
+ Support for JDK 5 JVMTI Agent (arriving).

All in all, 2.0 should be much easier to use, more configurable, more
tested, and more stable than 1.0.

Enjoy !

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email