Hi, We've never tested Muse in a clustered environment, but it has been used to create ws-resources where all of the state was maintained outside the Muse application (which is the foundation of your clustering setup). Of course, WSN has always been tricky. In general, most people don't have a "subscription manager" service/data store that fits the WSN model - they either want us to handle all WSN-related things or they want to adapt something like JMS. The former is easy - we implement all of the WSN data structures and operations; the latter is harder - we haven't tried to do a mapping of WSN to X, where X is any number of messaging frameworks/systems.
It's certainly possible to write a WSN implementation that maps onto JMS instead of our data structures. If you implement Muse's NotificationProducer interface (using AbstractWsResourceCapability as a base class), you can provide an alternate WSN impl that plugs right into Muse and works with all of the other WS-* capabilities. To my knowledge, WSN and WS-ServiceGroups are the two areas where the implementation would break in a clustered environment. Ideally, I guess we could break off the WSN and WSSG data structures into some kind of independent service that could be deployed on its own, and which Muse's implementations could talk to. That sounds like a lot of middleware and configuration, though, and would hinder our out-of-the-box experience (which already has a number of imperfections). Perhaps it would be possible to refactor the code so that you could configure it for a clustered environment, but then have a simple setup for other users; this would be a very interesting item to pursue, but I'm afraid it's not the case right now. Dan [EMAIL PROTECTED] wrote on 05/08/2007 08:09:14 AM: > All, > > as I am currently facing some load balancing and high availability > requirements regarding a WS-N implementation to be created (which will > have to provide a Web Services adapter/"profile" for existing JMS > destinations), I am looking for comments/best practices/input about > using Muse in a clustered environment: > > By "clustered" environment I mean an environment that consists of two or > more "deployment units" (instances) of Muse within two or more instances > of an app server/web container (ideally stateless by itself, but using a > cluster-wide backing store for stateful data). > > So the main question is: Is it possible at all/what does it take to add > clustering capabilities to a Muse (or Muse WS-N) deployment scenario? > > (1) The two stateful entities that would have to be managed in a > cluster-complient way are > > (1a) Subscriptions (implement NotificationProducerFilePersistence) > (1b) PullPointDatastores (implement PullPointDataStore) > > But I doubt that (1a) and (1b) will be sufficient to create the same > notion of state within all instances at all times: > > E.g. a NotificationConsumer freshly subscribes with cluster node 1 - how > would cluster node 2 be noticed about the state change (i.e. share the > state of the HashMap _subscriptionsByEPR of SimpleNotificationProducer)? > > (2) Are there other issues or incompatibilities that - after having > implemented the management of state for (1a) and (1b) in a cluster-aware > way - would break a cluster deployment scenario? > > Many thanks in advance for any comments, pointers or feedback! > > Best regards, > > Andreas > > -- > Andreas Loew > Java Architect > Sun Microsystems (Germany) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
