Tools to test SCA applications
Hello. I am a contributor to the SCA tooling within the Eclipse STP project [0], and I'm trying to evaluate the testing tools for SCA. The STP project already provides a graphical designer to build composites, and SCA annotations for Java implementations. It will also soon propose editors (an XML editor and a form editor). For the deployment, this project already supports Tuscany platforms [1] and it is expected to support the platforms developed within the SCOrWare project [2] before fall. In fact, most of the aspects of the development of SCA applications will be covered by this tooling. The only unknown, IMO, is test. I know Tuscany provides some help with JUnit tests. In a more general view, I'd like to have your opinion about testing SCA applications. Which tools do you use and to test what, which tools you would need... Personally, I'm not really sure there is a need of new tools in fact... This is why I'm asking. Implementations can be tested as any other code. You can perform unit tests, integration tests and so on. Services used in a composite (e.g. through references) are harder to test. If they are web services, a lot of tools exist, like SOAPui or the Eclipse WTP project. If they are services you access with other protocols like RMI or JMS, test is much more harder but it is still feasible. But is it useful ? So, I wonder what we really want to test with SCA applications. I have thought to a tool proposing a form to call any SCA service (no matter its binding). It would allow you to test a service manually or to define more complex test scenarios for automated testing. But for which users ? For a developer, testing a composite service is the same thing than testing the component implementation promoted by this service. Automated scenarios execution could be used for performance measurement and load testing. But in this case, the user is not a developer anymore. I have also seen this message [1], but it is two years old. Maybe things have changed. So, what do you think about test for SCA applications ? I would be really curious to know what you think about this. Regards, Vincent Zurczak. [0] http://www.eclipse.org/stp/sca/index.php [1] http://incubator.apache.org/tuscany/ [2] http://www.scorware.org/ [3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg05814.html -- Vincent Zurczak EBM WebSourcing + 33 (0) 4 38 12 16 77
Re: Can't generate a Java interface from a WSDL portType
Scott Kurz wrote: Simon, The question is do we look at the definitions of the WSDL document defining the imported portType or the definitions of the document defining a WSDL service in terms of the imported portType (since the TNS of each are different). I haven't read all of JAX-WS either but agree that the CXF behavior makes more sense. If you consider the question which definitions? it seems you'd naturally pick the one in which the portType is actually DEFINED as opposed to merely IMPORTED From what I can see the WSDL spec doesn't say anything particular about the import behavior either. On the one hand this isn't too critical since, with either choice, we generate a just-as-legal @WebService(targetNamespace) into the Java to capture the original TNS. Doesn't this raise the same question? The @WebService annotation for the generated Java interface should have the targetNamespace of the portType. It seems an extremely reasonable assumption that this is the same targetNamespace of the portType (whatever that means) that will be used to derive the package name. I tried this with the Sun RI and was surprised that it took the targetNamespace for the @WebService annotation from the portType's wsdl:definitions, even though it took the targetNamespace for the package name from the service's wsdl:definitions. This inconsistency seems wrong to me. My conclusion is that CXF has got this right. On the other hand, JAX-WS could have been clearer on this... I agree. And this seems like a warning that in cases where the spec is ambiguous, we should not assume that we can use the Sun RI's behaviour to determine which interpretation is correct. Simon On Mon, Jun 9, 2008 at 4:45 AM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Scott Kurz wrote: Sebastien, I'm surprised the package names would be different.What is the namespace you're using that isn't mapping to the same package in each tool? Just curious... My app is an order processing app with the following: WSDL service namespace: http://sample/Order/Binding WSDL Order portType namespace: http://sample/Order The CXF tool generates interface sample.order.Order The JAXWS RI tool generates interface sample.order.binding.Order I gave the same WSDL file (containing the WSDL service) to both tools. One could argue that both are correct vs the JAX-WS spec as they generate a correct package name from the namespace of 'the' WSDL definition, but the funny thing is that they do not pick the same WSDL definition... JAXWS-RI picks the input definition given to the tool and CXF the definition that actually contains the portType... and the JAXWS spec doesn't seem to state which one should be picked (at least I couldn't find it). IMHO the CXF behavior is better, but I've not read all 150 pages of the JAX-WS spec so I may be missing something :) From section 2.2 of the JAX-WS spec: A wsdl:portType element is mapped to a Java interface in the package mapped from the wsdl:definitions element (see section 2.1 for a description of wsdl:definitions mapping). Section 2.1 says: A wsdl:definitions element and its associated targetNamespace attribute is mapped to a Java package. JAXB[10] (see appendix D) defines a standard mapping from a namespace URI to a Java package name. By default, this algorithm is used to map the value of a wsdl:definitions element's targetNamespace attribute to a Java package name. } Conformance (Definitions mapping): In the absence of customizations, the Java package name is mapped from the value of a wsdl:definitions element's targetNamespace attribute using the algorithm defined by JAXB[10]. So IMO the Java package name that's used to map the portType should be derived from the targetNamespace of the wsdl:definitions element. What was this targetNamespace? Simon
Re: Error seen when deploying a web service using tuscany
That tutorial only covers creating the service, it doesn't cover creating a client to use the service (maybe we should add to the tutorial for that?). We do have some samples which show WS clients, for example helloworld-ws-reference, see https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-reference/README. You should be able adapt that to work with the tutorial web service. ...ant On Mon, Jun 9, 2008 at 9:57 PM, Mohan, Mithun [EMAIL PROTECTED] wrote: Hi , Thanks for updating the tutorial I am able to access the page http://localhost:8080/HelloWorld?wsdl and retrieve the WSDL of the webservice . But how do I access the webservice ? I tried giving http://localhost:8080/HelloWorld but it gave me the below exception Exception org.apache.axis2.AxisFault: The endpoint reference (EPR) for the Operation not found is /HelloWorld and the WSA Action = null at org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:86). at org.apache.axis2.engine.Phase.invoke(Phase.java:308) at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:212) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:132) at org.apache.axis2.transport.http.util.RESTUtil.invokeAxisEngine(RESTUtil.java:125) at org.apache.axis2.transport.http.util.RESTUtil.processURLRequest(RESTUtil.java:119) at org.apache.axis2.transport.http.AxisServlet$RestRequestProcessor.processURLRequest(AxisServlet.java:799) at org.apache.axis2.transport.http.AxisServlet.doGet(AxisServlet.java:242) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:257) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.apache.tuscany.sca.core.work.Jsr237Work.run(Jsr237Work.java:61) at org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$DecoratingWork.run(ThreadPoolWorkManager.java:214) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) /Exception Can anyone tell me how to access the web-service which is created ? Thanks and Regards, Mithun From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sat 6/7/2008 3:52 PM To: tuscany-user@ws.apache.org; [EMAIL PROTECTED] Subject: Re: Error seen when deploying a web service using tuscany I have updated the tutorial to fix this issue and to work with the 1.2 plugin. On 6/7/08, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 6:54 PM, Mohan, Mithun [EMAIL PROTECTED] wrote: Hi, I am using the tutorial to create a web service using tuscany. Please find below the tutorial I am referring http://incubator.apache.org/tuscany/build-your-first-web-services-with-t uscany.html http://incubator.apache.org/tuscany/build-your-first-web-services-with-tuscany.html When I follow the same steps . I get the following error. SEVERE: Could not start composite org.osoa.sca.ServiceRuntimeException: javax.xml.stream.XMLStreamException: Non-default namespace can not map to empty URI (as per Namespace 1.0 # 2) in XML 1.0 documents at org.apache.tuscany.sca.workspace.admin.impl.DeployedCompositeCollectionI mpl.writeCompositeCollection(DeployedCompositeCollectionImpl.java:395) Please find the complete logs for more information. Please note that I am only using Tuscany with plugins for this .I am not using any server like Axis with Tomcat. It will be great if you someone can spare time and guide me in this . Thanks and Regards, Mithun What was the URL you used to install the Tuscany Eclipse plugin? That tutorial page you point to uses an old URL, the current one for the latest release of the Tuscany 1.2 code is
Re: Can't generate a Java interface from a WSDL portType
Folks, I tend to agree with Simon, that the package name would rightly be derived from the target namespace of the wsdl:definitions/ containing the portType definition, since it's the port type that defines the interface. So +1 to the CXF interpretation. On the other hand, there is a JAX-WS TCK. Does it test this piece of function I wonder...? Yours, Mike. Simon Nash wrote: Scott Kurz wrote: Simon, The question is do we look at the definitions of the WSDL document defining the imported portType or the definitions of the document defining a WSDL service in terms of the imported portType (since the TNS of each are different). I haven't read all of JAX-WS either but agree that the CXF behavior makes more sense. If you consider the question which definitions? it seems you'd naturally pick the one in which the portType is actually DEFINED as opposed to merely IMPORTED From what I can see the WSDL spec doesn't say anything particular about the import behavior either. On the one hand this isn't too critical since, with either choice, we generate a just-as-legal @WebService(targetNamespace) into the Java to capture the original TNS. Doesn't this raise the same question? The @WebService annotation for the generated Java interface should have the targetNamespace of the portType. It seems an extremely reasonable assumption that this is the same targetNamespace of the portType (whatever that means) that will be used to derive the package name. I tried this with the Sun RI and was surprised that it took the targetNamespace for the @WebService annotation from the portType's wsdl:definitions, even though it took the targetNamespace for the package name from the service's wsdl:definitions. This inconsistency seems wrong to me. My conclusion is that CXF has got this right. On the other hand, JAX-WS could have been clearer on this... I agree. And this seems like a warning that in cases where the spec is ambiguous, we should not assume that we can use the Sun RI's behaviour to determine which interpretation is correct. Simon On Mon, Jun 9, 2008 at 4:45 AM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Scott Kurz wrote: Sebastien, I'm surprised the package names would be different. What is the namespace you're using that isn't mapping to the same package in each tool? Just curious... My app is an order processing app with the following: WSDL service namespace: http://sample/Order/Binding WSDL Order portType namespace: http://sample/Order The CXF tool generates interface sample.order.Order The JAXWS RI tool generates interface sample.order.binding.Order I gave the same WSDL file (containing the WSDL service) to both tools. One could argue that both are correct vs the JAX-WS spec as they generate a correct package name from the namespace of 'the' WSDL definition, but the funny thing is that they do not pick the same WSDL definition... JAXWS-RI picks the input definition given to the tool and CXF the definition that actually contains the portType... and the JAXWS spec doesn't seem to state which one should be picked (at least I couldn't find it). IMHO the CXF behavior is better, but I've not read all 150 pages of the JAX-WS spec so I may be missing something :) From section 2.2 of the JAX-WS spec: A wsdl:portType element is mapped to a Java interface in the package mapped from the wsdl:definitions element (see section 2.1 for a description of wsdl:definitions mapping). Section 2.1 says: A wsdl:definitions element and its associated targetNamespace attribute is mapped to a Java package. JAXB[10] (see appendix D) defines a standard mapping from a namespace URI to a Java package name. By default, this algorithm is used to map the value of a wsdl:definitions element's targetNamespace attribute to a Java package name. } Conformance (Definitions mapping): In the absence of customizations, the Java package name is mapped from the value of a wsdl:definitions element's targetNamespace attribute using the algorithm defined by JAXB[10]. So IMO the Java package name that's used to map the portType should be derived from the targetNamespace of the wsdl:definitions element. What was this targetNamespace? Simon
Re: Can't generate a Java interface from a WSDL portType
On Tue, Jun 10, 2008 at 4:59 AM, Simon Nash [EMAIL PROTECTED] wrote: I tried this with the Sun RI and was surprised that it took the targetNamespace for the @WebService annotation from the portType's wsdl:definitions, even though it took the targetNamespace for the package name from the service's wsdl:definitions. This inconsistency seems wrong to me. My conclusion is that CXF has got this right. That's interesting. Seems like wsimport might have a bug then if they're not in synch with themselves. (And sorry my earlier comment here was meaningless.) On the other hand, JAX-WS could have been clearer on this... I agree. And this seems like a warning that in cases where the spec is ambiguous, we should not assume that we can use the Sun RI's behaviour to determine which interpretation is correct. Simon Good point. Scott
RE: Error seen when deploying a web service using tuscany
Hi , Thanks for the reply Ant . I am a bit confused now . I was having a look at the clients in those sample examples and tried to create on for this example (Please find HelloWorldClient attached) . Now I first run the composite file as per the tutorial to create the web service . Now when I run the client (HelloWorldClient ) as application , it throws up the following error . (Please note that I am using eclipse to run the files) Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor Jun 10, 2008 10:02:49 AM org.apache.tuscany.sca.http.jetty.JettyServer addServletMapping INFO: Added Servlet mapping: http://mmithun-lxp:8080/HelloWorld Exception in thread main org.osoa.sca.ServiceUnavailableException: Service not found for component default reference default (bindingURI=HelloWorldImpl operation=sayHello). Ensure that the composite containing the service is loaded and started somewhere in the SCA domain and that if running in a remote node that the interface of the target service marked as @Remotable at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:247) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:148) at $Proxy5.sayHello(Unknown Source) at helloworld.HelloWorldClient.main(HelloWorldClient.java:14) I am new to web services . It will be great if some one can spare some time and give pointers. After I get this thing working I will prepare a tutorial so that new users will face less trouble learning this wonderful tool. Thanks and Regards, Mithun From: ant elder [mailto:[EMAIL PROTECTED] Sent: Tue 6/10/2008 5:13 AM To: tuscany-user@ws.apache.org Subject: Re: Error seen when deploying a web service using tuscany That tutorial only covers creating the service, it doesn't cover creating a client to use the service (maybe we should add to the tutorial for that?). We do have some samples which show WS clients, for example helloworld-ws-reference, see https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-reference/README. You should be able adapt that to work with the tutorial web service. ...ant On Mon, Jun 9, 2008 at 9:57 PM, Mohan, Mithun [EMAIL PROTECTED] wrote: Hi , Thanks for updating the tutorial I am able to access the page http://localhost:8080/HelloWorld?wsdl and retrieve the WSDL of the webservice . But how do I access the webservice ? I tried giving http://localhost:8080/HelloWorld but it gave me the below exception Exception org.apache.axis2.AxisFault: The endpoint reference (EPR) for the Operation not found is /HelloWorld and the WSA Action = null at org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:86). at org.apache.axis2.engine.Phase.invoke(Phase.java:308) at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:212) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:132) at org.apache.axis2.transport.http.util.RESTUtil.invokeAxisEngine(RESTUtil.java:125) at org.apache.axis2.transport.http.util.RESTUtil.processURLRequest(RESTUtil.java:119) at org.apache.axis2.transport.http.AxisServlet$RestRequestProcessor.processURLRequest(AxisServlet.java:799) at org.apache.axis2.transport.http.AxisServlet.doGet(AxisServlet.java:242) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:257) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
RE: Beginner Question - Deploying components on the fly.
Thanks again, By including all of the Tuscany jars do you mean the runtime jars or the component jars (i.e. the web app and components need to be packaged together) Chris
