Whether you implement the database lookup in the getter methods or in
getResourceProperty(), you won't be storing the properties in memory, so
that should not be a concern. Implementing in the getters just allows you
to use the getters in your server side code so that capabilities can use
each other without parsing DOM fragments. The default
getResourcePRoperty() implementation eventually invokes the getter
methods.
For your #3, I'm not sure why you'd have to modify the WSDL or muse.xml. I
would just do a search and replace, swapping 'extends
AbstractWsResourceCapability' in every capability class with 'extends
CiscoBaseCapability'. Any IDE should let you do this on multiple files in
one step (Eclipse does). Your getter methods would then look something
like this:
public CiscoBaseCapability extends AbstractWsResourceCapability
{
protected Element[] getProperty(QName qname)
{
// do your database lookup here
}
}
...
public MyCapability extends CiscoBaseCapability
{
public String getFoo()
{
Element[] results = getProperty(FOO_QNAME);
return XmlUtils.getElementText(results[0]);
}
public int getBar()
{
Element[] results = getProperty(FOO_QNAME);
return XmlUtils.getInteger(results[0]).intValue();
}
// etc.
}
Now, for #2, you have an interesting problem. We dealt with this when we
were building a WSDM-CIM bridge. It's a lot of work to create a truly
dynamic resource. For one, since you don't know your resource interface
ahead of time, you'll need to dynamically generate a WSDL for any client
that wants one, including the WSRP doc. This is not particularly fun. You
also won't be able to rely on Muse's WSRP fault checks or validation, so
you will need to do this yourself; you won't be able to make assumptions
about a property already existing in a valid state like in the getters, so
you need to provide the logic to handle this. Also, for each operation you
will need to do the basic WS-A/WS-RF fault checks to see if a resource
exists and/or is available. Basically, you end up re-doing a lot of Muse
itself, plus the WSDL generation bit. We still have not totally figured
out how to reuse the WS-N implementation for this case, since there is
absolutely no state of any kind for the resources, so
subscriptions-for-resources is hard to deal with. I'm not sure how this
would pan out in your situation.
Your idea of creating a "resource properties property" has been tried in a
previous WSDM-CIM bridge by IBM on alphaWorks:
http://www.alphaworks.ibm.com/tech/wsdmbrowser
This does work, but it's kind of a hack (it's a WSDL/XSD replacement),
which is why they've tried to get around it by generating the proper
interface at runtime. This is more work, but makes it easier for other
WSRF clients to use the resources (since a resource properties property is
not part of the spec).
Dan
"Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/22/2006
04:59:57 PM:
> I have these concerns:
> 1) Ensuring that resource properties don't persist in memory for the
> life of the app. Otherwise, this layer would start using a lot of
> memory resources. We can still use the Java class/fields generated by
> wsdl2java to get the data from an external source, therefore ensuring
> that the data doesn't persist in memory.
>
> 2) The ability to pass back properties that may only be known at
> runtime, so these can't be predefined in the wsdl. This expands on the
> resource "discovery" concept of Muse. So I was testing the approach of
> overriding the SimpleGetCapability methods. But as you mentioned, this
> bypasses the WSRP schema validator, so this may not be a good approach.
> The balance could be to predefine a property in the wsdl that happens to
> be a collection. Then, at runtime, this collection can be populated
> with various child properties, and then be passed to the client as a
> whole unit.
>
> 3) Building some kind of custom base resource class that has methods for
> getting the resource properties in a generic fashion. This way, all our
> resources can extend from this base class, and we won't need to
> implement anything new for each resource. In the current Muse
> architecture, the implementation is in a separate cability class, which
> would require us to define this feature in the wsdl and muse.xml for
> every resource. This is probably not a big deal, but anything that
> would help ease the development/maintenance efforts would be good.
>
>
> -----Original Message-----
> From: Daniel Jemiolo [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 22, 2006 7:36 AM
> To: [email protected]
> Subject: Re: dynamic resource properties
>
> I would actually override SimpleGetCapability.getResourceProperty(),
> because the other two WSRP 'get' operations use getResourceProperty() as
> part of their implementation. So, if you override this one, you get the
> other two for free.
>
> This will work just fine, but I'm not sure the problem you stated is
> accurate. Muse reads in the WSRP document *schema* and creates data
> structures around it in order to provide proper WSRP behavior... but it
> certainly does not load your actual WSRP *document* (the thing with all
> of the actual names-values). The code that is generated by wsdl2java
> does have Java fields for each of your resource properties, but that's
> only because it has no other option (it has no idea what kind of
> technology you intend to use for state, so it just makes fields as a
> default). The process you're referring to is valuable in that it ensures
> you have setup your WSRP doc correctly, that it remains schema valid,
> that proper faults are thrown at proper times, and that there is some
> handler/implementor for each property (even if that's just one piece of
> code).
>
> So... you may want to just implement the getter methods generated by
> wsdl2java with logic similar to the above rather than modifying
> getResourceProperty(). Then you can read resource properties on the
> server side (between capabilities) without parsing DOM fragments. Either
> way, I don't think you want to disconnect the WSRP schema loader...
>
> Dan
>
>
> "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/22/2006
> 05:21:58 AM:
>
> > What's the best way to customize Muse so that values in the resource
> > properties document can be loaded dynamically from an external source?
> > In a stateless environment, we do not want to use the default
> > implementation where resource properties are loaded into memory from
> the
> > wsdl file when the resource is first called. We'd like requests to
> pass
> > thru, and resource properties be retrieved from an external source,
> like
> > a database.
> >
> > For testing, I've been able to extend the SimpleGetCapability class
> and
> > override the getResourcePropertyDocument() method to dynamically add
> > properties to the collection to be returned. Then I specify my custom
> > class in muse.xml, replacing the original SimpleGetCapability
> reference.
> >
> > This method works easily, but I'm not sure if it's the
> best/recommended
> > way to do it.
> > -Vinh
>
>
> ---------------------------------------------------------------------
> 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]
