Thank you for your reply and suggestions. Actually the application will have a finite number of Resources, each with a large number of simple properties (name-value pairs). The properties is organised in a tree-structure and the property names could be represented in a xpath-like way.
What I did in Pubscribe was that I created a WSDL for a generic Resource. I then could create new Resources by getting a handle to the GenericResource's home and call it's init-method (createInstance) with a unique ResorceId. I then could access each Resource and create ResourceProperties and topics, although this part is rather cumbersome. Apart from the dynamic nature of the creation of resources and properties the requirements on the system are very limited. Only the following operations are needed: Subscribe Destroy Subscription GetCurrentMessage GetProperty SetProperty Basically, simple subscription handling and getter/setter functionality. /Mattias -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Fri 1/19/2007 5:03 PM To: [email protected] Subject: Re: Creating Resources at runtime from another application This sounds similar to some work done around mapping WSDM to CIM: http://www.alphaworks.ibm.com/demo/flash/display/wsdmbrowser0 That project was very hard to create with Muse because none of the resource types were modeled - it was 100% dynamic. In this case, the authors had to go through a lot of hassle because not only were they dynamically creating and validating resource types, they also had to dynamically create the WSDL(!). If you want to start with a web app that has no info at all about the possible resource types that will be found, you should probably start from scratch (or your current work); you won't get to take advantage of the Muse programming model much because your project is not allowed to make any assumptions about what properties/operations will be executed (i.e., you will never write code that uses the Capability API because you don't know what your resources are, what capabilities they may have, and how you may combine them to create more powerful operations on the server-side). Now, I have seen Muse-based resource types implemented using MBeans - see the following: http://www-128.ibm.com/developerworks/autonomic/library/ac-muse.html but that still requires that you know the resource types ahead of time and have WSDLs for them. you can then implement the resource types such that all state/operations are handled by MBeans (as in the article). without any metadata (WSDL) to start from, though, you will need to create a generic operation handler and use if/else blocks to determine if the current request is a) targeting a valid resource type, b) if the operation is valid, c) if you have code to handle any of the faults/conditions that are specific to that operation. So, there's a tradeoff - no design/model/codegen means you don't have to modify code to add/subtract resource definitions. at the same time, your code is limited to being a simple pass-through mechanism. Dan "Rosberg Mattias" <[EMAIL PROTECTED]> wrote on 01/18/2007 04:50:49 AM: > I'm looking for a more dynamic approach when it comes to creation of Resources > (compared to the wsdl2java approach). The system I'm integrating with muse is > very dynamic. The resources and properties may change depending on the > configuration and environment. > > I would like to create my resources from another application in runtime, > starting with a clean Muse configuration. Is there a way to do this with Muse? > > I have done a similar solution for Pubscribe, but the programing model in Muse > is much more attractive so I'm thinking of moving to Muse. In short my > Pubscribe solution exposed an Mbean configured in the wsrf-config.xml. Through > that Mbean another application could get a handle to the WsrfRuntime and > create Resources, Topics, adding ResourceProperties etc. Is there a way for > another application to get a handle to the ResourceManager in Muse or maybe > there's a better approach? --------------------------------------------------------------------- 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]
