If the WSDL will always contain the same operations, this may be easier.
Create the WSDL with the operations you listed from WSRP and WSN (use the
wsn-producer sample as a template) but leave the WSRP document blank (no
<xsd:element/>s inside it). Then, turn off WSRP schema validation like so:
<resource-type>
...
<init-param>
<param-name>validate-wsrp-schema</param-name>
<param-value>false</param-value>
</init-param>
</resource-type>
Finally, you can override the Get/Set capabilities like so:
public MyGetCapability extends SimpleGetCapability
{
public Element[] getResourceProperty(QName propertyName)
{
// do your lookup here, using whatever API you need
}
}
and plugging it into muse.xml like so:
<resource-type>
...
<capability>
<capability-uri>http://docs.oasis-open.org/wsrf/rpw-2/Get</capability-uri>
<java-capability-class>your.package.name.MyGetCapability</java-capability-class>
</capability>
...
<init-param>
<param-name>validate-wsrp-schema</param-name>
<param-value>false</param-value>
</init-param>
</resource-type>
You can do the same thing for SetCapability (SetResourceProperties). This
allows you to have no pre-defined resource properties and to answer any
Get/Set call w/o worrying about Muse's WSRP validation cutting you off.
Dan
"Rosberg Mattias" <[EMAIL PROTECTED]> wrote on 01/29/2007
08:22:37 AM:
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
