Interesting discussion here. The concept of capabilities seems to encourage a lot of brainstorming whenever it comes up.
>From my point of view, the capability (and its identifying URI) is supposed to be a design-time concept that aids in the reuse of WSDM-to-____ mappings among resource types. The two most common cases are: 1. Defining a capability that describes two resources that, while they may be different products, are really "the same" (e.g., WAS and WebLogic, or DB2 and Oracle). By reusing interfaces among your manageable resources types, you're simplifying things for the management clients - they don't have to know that they're talking to WAS 6.1 with Fix Pack 1, or WebLogic 7.0.2, they just know they're talking to a J2EE application server. It makes the introduction and replacement of resources in a system more fluid. 2. Defining a capability that describes properties/operations that are common to disparate resources types, such as performance metrics. WAS and DB2 are two very different products, but they both have thread pools, right? Why should the property that exposes ThreadPoolSize on WAS be different than on DB2? This is another area where we can simplify interfaces and make the manager's job easier. The actual values of the capability URIs are not important so long as they are unique, and they're not supposed to have any effect on the WSDL. It's just a design-time thing to keep your code modular and to get programmers thinking about reuse in "the WSDM way". The capability URIs are also exposed via muws1:ManageabilityCapability, but that is just another way to communicate to the client what a resource is capable of - not necessarily how it is implemented or how the operations are to be invoked. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 03/22/2007 04:36:45 PM: > Hi Andrew, > Yep, I always wondered what the capability URI should be because so far, I can > put any arbitrary value there and it wouldn't always cause problems. Since > Muse first looks at the java method signatures in all the capabilities to see > if any of them matches the wsdl operation input, it seems to ignore the URI entirely. > > So now, if the new update does look at the URI, it just might resolve the > problem where different namespaces may have the same operation name. > > But we have one major issue: > There is no rule yet on what the capability URI should represent. So far, it > has not been enforced to associate only with the operation message namespace. > In many cases, it has been associated with the entire wsdl namespace, so a > group of operations can be implemented by one capability. > > Now, if the we start mapping URIs to capabilities, do we enforce the namespace > to be at the operation message level, or the resource level? > > If the former, then the limitation is one capability per operation, which may not scale. > If the latter, then the limitation is one URI per capability. This might be > ok, but it breaks the current architecture where a single capability class can > address operations from WS-N, WS-RF, etc. > > So from what it seems, it might all come out to 3 general approaches: > 1) Configuration-based, where muse.xml provides configurations to map > operations to capabilities. But then this goes back to the JAX-RPC approach > Dan brought up. > > 2) Each capability can have a method that returns the URIs that it can > address. But, are the URIs at the operation message level, or the resource > level? If the resource level, what happens if multiple capabilities can > address the same URI (i.e. operations in one wsdl are separated into multiple > capabilities)? > > 3) Push it to the design level where wsdl operation names must follow a > certain naming convention in order for Muse to support the wsdl. > > > > > -----Original Message----- > From: Andrew Eberbach [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 22, 2007 12:51 PM > To: [email protected] > Subject: Re: Operation name collision > > Hi > > I included that link more for my reference than for yours (for obvious > reasons). As for your issue, as far as I understand it is the same as what > Vinh brought up > https://issues.apache.org/jira/browse/MUSE-214#action_12482863 along with the > discussion following it. > > The resolution of the problem would cover two approaches. First, it would move > the determination of the method name out to the WSDL operation name. > The second would be to include the namespace URI when doing the runtime > resolution of the name which would cover WSDL operations that have the same > name but live in different capabilities. The only trick there being that the > capability URI of the operation would be taken from the input element (since > the WSDL operation would technically live in the WSDL targetNamespace). > > Thanks, > Andrew > > Andrew Eberbach > Autonomic Computing > (919) 254-2645 > T/L: 444-2645 > [EMAIL PROTECTED] > > > > "José Antonio Sánchez" <[EMAIL PROTECTED]> > 03/22/2007 03:10 PM > Please respond to > [email protected] > > > To > [email protected] > cc > > Subject > Re: Operation name collision > > > > > > > I reported the bug so I'm following the discussion but I thought this > was not related to this issue since the operation name (completed) is > correct, it was not the case of cannot-compensate-fault element that > generated an invalid operation name. As the method is duplicated, I > would have expected an error saying that > http://www.webservicestransactions.org/schemas/wstxm/tx-lra/2003/03/completed > > maps to multiple operations but instead I get an error saying that it > cannot find an implementation for that method although it has two of > them to choose from. Also, in case of doubt I've implemented a > CompensatorCompleted method and it cannot find it too so I don't know > if there's a problem with me not following some convention or if this > is a limitation of Muse working model. > > On 3/22/07, Andrew Eberbach <[EMAIL PROTECTED]> wrote: > > Hi, > > > > You are the second person to bring this up this week :) This will be one > > of the first fixes in 2.3. See: > > https://issues.apache.org/jira/browse/MUSE-214 > > > > Thanks, > > Andrew > > > > Andrew Eberbach > > Autonomic Computing > > (919) 254-2645 > > T/L: 444-2645 > > [EMAIL PROTECTED] > > > > > > > > "José Antonio Sánchez" <[EMAIL PROTECTED]> > > 03/22/2007 02:06 PM > > Please respond to > > [email protected] > > > > > > To > > [email protected] > > cc > > > > Subject > > Operation name collision > > > > > > > > > > > > > > Hello, I'm having the following problem. In my service I have to > > implement two interfaces and they have an operation named the same but > > messages from every operation are in different namespaces. I've solved > > it in the wsdl with the following: > > > > <wsdl:message name="CompletedMessage"> > > <wsdl:part element="wsctx:completed" name="content"/> > > </wsdl:message> > > ............................. > > <wsdl:operation name="completed"> > > <wsdl:input > > wsa:Action=" > > http://docs.oasis-open.org/schemas/2005/10/wsctx/completed"; > > message="tns:CompletedMessage"/> > > </wsdl:operation> > > > > and > > > > > > <wsdl:message name="CompensatorCompletedMessage"> > > <wsdl:part name="content" element="lra:completed"/> > > </wsdl:message> > > ........................... > > <wsdl:operation name="CompensatorCompleted"> > > <wsdl:input > > wsa:Action=" > > > http://www.webservicestransactions.org/schemas/wstxm/tx-lra/2003/03/completed > > > " > > message="tns:CompensatorCompletedMessage"/> > > </wsdl:operation> > > > > WSDL2Java has generated two capabilities and every one of them has a > > complete() method. > > Now when I try to invoke my resouce I get: > > > > java.lang.RuntimeException: [ID = 'MissingOperationImplementations'] > > The WSDL file '/wsdl//Installation.wsdl' has the following operations > > which have no match in any of the resource's capabilities: > > > [http://www.webservicestransactions.org/schemas/wstxm/tx-lra/2003/03/completed] > > at > > > org.apache.muse.core.descriptor.SimpleResourceDescriptor. > createCapabilityDefinitions(SimpleResourceDescriptor.java:138) > > at > > > org.apache.muse.core.descriptor.SimpleResourceDescriptor. > load(SimpleResourceDescriptor.java:397) > > at > > > org.apache.muse.core.descriptor.SimpleDeploymentDescriptor. > createResourceDefinitions(SimpleDeploymentDescriptor.java:74) > > at > > > org.apache.muse.core.descriptor.SimpleDeploymentDescriptor. > load(SimpleDeploymentDescriptor.java:173) > > at > > > org.apache.muse.core.platform.AbstractIsolationLayer. > initialize(AbstractIsolationLayer.java:144) > > at > > > org.apache.muse.core.platform.axis2.AxisIsolationLayer. > handleRequest(AxisIsolationLayer.java:72) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:585) > > at > > > org.apache.axis2.receivers.RawXMLINOutMessageReceiver. > invokeBusinessLogic(RawXMLINOutMessageReceiver.java:88) > > at > > > org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver. > receive(AbstractInOutSyncMessageReceiver.java:39) > > at > org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) > > at > > > org.apache.axis2.transport.http.HTTPTransportUtils. > processHTTPPostRequest(HTTPTransportUtils.java:319) > > at > > org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:247) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) > > at > > > org.apache.catalina.core.ApplicationFilterChain. > internalDoFilter(ApplicationFilterChain.java:290) > > at > > > org.apache.catalina.core.ApplicationFilterChain. > doFilter(ApplicationFilterChain.java:206) > > at > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) > > at > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > > at > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > > at > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) > > at > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > at > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) > > at > > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > > at > > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler. > process(Http11Protocol.java:634) > > at > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) > > at java.lang.Thread.run(Thread.java:595) > > > > Also I had problem with some operations that did not have the same > > name as its messages but they seem to be passing once I created > > methods for them in my capability with the operation name instead of > > the message element name but this doesn't work for complete. Although > > I've created a CompensatorCompleted() method in my capability it keeps > > complaining. What's the convention Muse uses to route a message to a > > capability and a particular method? How can I change my > > wsdl/capability to get it working? I can modify the wsdl but not the > > xsd files that defines lra:completed and wsctx:completed elements. > > > > -- > > Saludos. > > José Antonio Sánchez > > > > --------------------------------------------------------------------- > > 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] > > > > > > > -- > Saludos. > José Antonio Sánchez > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
