I'm confused - you say you don't know what your resources will be, but you have descriptors (service map, etc) that specify the executables, operations, etc. You must also have some idea of what WS-* capabilities you wish to use, so that you can add them to the WSDL you generate for ?wsdl requests. If someone is creating these descriptor files and then the factory service is creating services from them, is this not the same as creating WSDL files (a descriptor) and creating Muse-based services? Your email implies that this is a fully-automated process, but the user guide sounds more like ours; perhaps you are using your toolkit in a more advanced way (not for 'normal' users) as part of the LEAD project?
My other question is - why use Muse? Are you trying to add WSRF/N/DM support to your scenario? It seems like you're mostly interested in the SOAP routing, but not the Resource model. To answer your question: I'm guessing that it could be bundled as a .mar, but it was easiest to put things in WEB-INF/lib as part of code gen. Dan "Srinath Perera" <[EMAIL PROTECTED]> wrote on 01/23/2007 12:46:53 PM: > Hi Daniel; > > Thanks very much for the answer! please find the comments in line. > > > I'm not totally clear on what you want to do. I looked at your project > > page and user guide, and it seems you have created a system for exposing > > command line apps via SOAP using a custom service descriptor; your toolkit > > that creates a WSDL and mapping layer that can be deployed as a web > > service. Is that right? > > Yes, it creates services remotely. There is a factory service that > create services in remote hosts. We use Grid to access to remote > machines/data transfers and exposed applications are Weather > simulation applications. (It is part project called LEAD > http://www.itsc.uah.edu/lead/index.html) > > We end up creating hundreds of services and we are trying to use WSDM > to manage and monitor those services and back end Grid infrastructure. > Those services are created and used by a work flow system, and each > service may run for hours. Right now we use in house soap stack but > we might move to Axis2 soon. (I myself a Axis2 developer). > > However due to dynamic nature of system we need to avoid code > generation and need close access to the SOAP stack. Also we prefer to > have our deployment model and integrate Axis2/Muse into that model. > Even we used Axis2, we would with jetty and closely integrated to our > deployment. > > I understand if we use internal API they might change in the future. > But I hope they will reasonably stay fixed. Hopefully I can understand > Muse internals to keep the things going. > > Let me ask a one more question, Is there a way to use Muse with Axis2 > without code generation? Is it possible to make Muse a Axis2 module? > My Gut feeling is it is possible, but may be there is something I > missed. > > Thanks very much again for you comments! > Thanks > Srinath > > > -- > ============================ > Srinath Perera: > Indiana University, Bloomington > http://www.cs.indiana.edu/~hperera/ > http://www.bloglines.com/blog/hemapani > > --------------------------------------------------------------------- > 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]
