Tools to test SCA applications

[Vincent Zurczak - EBM WebSourcing]

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

[Jean-Sebastien Delfino]

Simon Nash 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].


Yeah I read that too. Again, both implementations comply with that text 
but pick different definitions. That's all.



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?


See above: http://sample/Order




  Simon



--
Jean-Sebastien

RE: Error seen when deploying a web service using tuscany

[Mohan, Mithun]

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 
 

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)

 
 
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
>>
>> 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
> http://archive.apache.org/dist/incubator/tuscany/java/sca/1.2-incubating/updatesite/(you
> can find this from the Tuscany downloads page at
> http://incubator.apache.org/tuscany/sca-java-releases.html.
>
>...ant
>


--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Can't generate a Java interface from a WSDL portType

[Scott Kurz]

Simon,

The question is do we look at the  of the WSDL document
defining the imported portType
or the  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 ?" 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.

On the other hand, JAX-WS could have been clearer on this...






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: Beginner Question - Deploying components on the fly.

[Simon Laws]

Hi Crhis

snip...

>
>
> I can see how the samples are working, as Tuscany has automatic access
> to the files required as they are included within the same jars, but
> assume I have a DAO component which implements a service
> HibernateProductDAO which provides a Hibernate specific implementation
> of the ProductDAO interface. If our full application is deployed in a
> component oriented fashion, then ideally I would like to be able to
> say... ok this single component needs a bug fix. Fix the bug and
> repackage this single component and redeploy.


At the moment our deployment granularity is at the composite level rather
than the component level. As long as you build a composite with just the
HibernateProductDAO component in it you will be able to deploy this
component in isolation. You are not restricted to any particular number of
composites in your application. Components from one composite can reference
components in another composite, composites can be included in other
composites, composites can be assembled recursively using
implementation.composite.



> So say
> HibernateProductDAO_1.5.jar is sitting with component contained within
> (and a composite mapping?) and I would like to get this into my
> application. Would it be as simple as dropping it within the shared
> lib/classpath of the webcontainer and will Tuscany be able to find it?


Replacing a component with a bug fixed implementation implies stopping and
restarting the component. As your component is wrapped in a single composite
this can be as simple as stopping and restarting the node that is running
the composite that holds the HibernateProductDAO component. This will work
today if you are running Tuscany from some command line launcher. It may
even work if you are deploying as a webapp. The deep integration isn't done
yet so the webapp will have to include all of the Tuscany jars.


>
>
> Thanks again
>
> Chris
>

I think we should start to get a little more specific...

A) We might have a composite for the DAO...

http://www.osoa.org/xmlns/sca/1.0";
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0";
targetNamespace="http://test";
xmlns:test="http://test";
name="dao">





http://myhost:8080//ProductInfo"/>




B) And another composite for the client app

http://www.osoa.org/xmlns/sca/1.0";
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0";
targetNamespace="http://test";
name="client">







 http://myhost:8080//ProductInfo";>
 



C) And some javascriptin the browser which exercises this



Store

Tools to test SCA applications

[Vincent Zurczak - EBM WebSourcing]

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: Beginner Question - Deploying components on the fly.

[Miles, Chris]

Hi,

Thanks again for the reply. I think we are nearly reaching a point of
agreement on this; however I am still unsure of how some of the
intricacies will work. 

I can see how the samples are working, as Tuscany has automatic access
to the files required as they are included within the same jars, but
assume I have a DAO component which implements a service
HibernateProductDAO which provides a Hibernate specific implementation
of the ProductDAO interface. If our full application is deployed in a
component oriented fashion, then ideally I would like to be able to
say... ok this single component needs a bug fix. Fix the bug and
repackage this single component and redeploy. So say
HibernateProductDAO_1.5.jar is sitting with component contained within
(and a composite mapping?) and I would like to get this into my
application. Would it be as simple as dropping it within the shared
lib/classpath of the webcontainer and will Tuscany be able to find it? 

Thanks again

Chris

Re: Can't generate a Java interface from a WSDL portType

[Simon Nash]

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: Beginner Question - Deploying components on the fly.

[Simon Laws]

Hi Chris

Some more thoughts and some comments in line..

A service is defined by a contract/interface and collects together a set of
related operations. A service may provide an endpoint through which remote
clients can access it over the network
A component provides the implementation for one or more services and in
doing so can define references to other services
A composite assembles together components into a working application by
wiring references to services
A contribution is the deployment packaging for a composite and can collect
together the composite and all of the artifacts it requires to run, e.g.
.java, .xml, .xsd. wsdl files etc.

A contribution in SCA can be any hierarchical mechanism the we use today for
collecting artifacts together, e.g. a directory on a file system, a zip, jar
or war etc. A contribution does not define a new format for storing
artifacts.

Hope this helps

Simon


On Fri, Jun 6, 2008 at 4:29 PM, Miles, Chris <[EMAIL PROTECTED]>
wrote:

> Simon,
>
> Thanks for the response again.
>
> I understand a little better now; however some parts of it still leave
> me a little stumped. How these physical units would be packaged and
> moved around.


They should be packaged in whatever schemes you are familiar with today for
collecting together application artifacts for deployment. The exact
mechanism chosen will depend on which container is going to run the SCA
application. E.g. if its going to run in a web app container the
contribution is likely to be a war. If its going to be run using a command
line based Tuscany runtime then the contribution could well be a directory
structure or a jar.


>
>
> If I have a webapp with JSP, Servlets and the other usual bits and bobs.
> This would be packaged in it's normal war and deployed to the server
> (which happens to be OC4J just now).
>

Yep


>
> I then want a business layer as a component. If this was being deployed
> somewhere there would need to be some sort of intelligent process which
> picks it up and registers it somewhere. I suppose a quartz job or a
> timertask running checks against the file system could do something to
> this effect, but it feels I would then be adding extra layers of
> complexity to my application.


Are you suggesting here that components are deployed and activated in the
same way that  wars are activated,  for example, in Tomcat by dropping the
war into the tomcat/webapps directory.

There are two approaches.

1. add the Tuscany and dependency jars to the war itself. This should work
today. See samples/calculator-webapp
2. do some deep integration with the web app container so that the Tuscany
and dependency jars don't have to be added to the war. Ant is looking at
this for Tomcat at the moment but it's not done yet.

It's not the only way of working with Tuscany though. For example, you can
just run Tuscany from the command line and ask it to run up a named
composite, This works because if Tuscany is not running within a webapp
container it will fire up its own web server (tomcat or jetty) to service
web service style requests. See samples/calculator for our most basic sample
and samples/helloworld-ws-service and samples/helloworld-ws-reference for a
reference that talks to a service remotely over web services.



>
> The way I feel something like this should work for my purposes is a
> standalone daemon running which manages services and components etc (I
> am not completely understanding of the exact difference in definition
> between components, service and contributions I will be honest).


See above:-)

The standalone daemon I think is catered for by running Tuscany from the
command line. This doesn't support the hot deploy options (although again
there has been some work on this in the past). You basically run Tuscany
given the composite when you want to start a composite application and the
stop the program when you want to stop the application.

This
> daemon would be have a store of components which it loads when it runs
> or they are hot deployed and then any other application or web
> application through the use of the Tuscany library can then start
> creating objects which this server will provide. This standalone server


"Start using services" is probably a better phrase that "start creating
objects".  Using a service may or may now involve creating new objects. This
depends on the scope of the component and the type of processing the
component does. In the case where you are reading business object from a
database I can imagine that the business object we be created when you make
a request for information. The component instance may or may not be created
afresh depending on whether you want the component to display some stateful
behaviour, for example, so that you can hold a conversation with it.


> may be some other application which could be deployed to the web
> container/sever instead of a separate running process.


Yes, once you have  defined your composite application you should be

[ANNOUNCE] Apache Tuscany SCA Java 1.2.1 released

[ant elder]

The Apache Tuscany team are pleased to announce the 1.2.1 release of
the Java SCA project.

Apache Tuscany provides a runtime environment based on the Service
Component Architecture (SCA). SCA is a set of specifications aimed at
simplifying SOA application development. These specifications are
being standardized by OASIS as part of the Open Composite Services
Architecture (Open CSA).

This 1.2.1 release is a maintenance release over the 1.2 release, see the
RELEASE_NOTES and CHANGES file for details, and to download the
distributions please go to:

http://incubator.apache.org/tuscany/sca-java-releases.html

To find out more about OASIS Open CSA go to:

http://www.oasis-opencsa.org

Apache Tuscany welcomes your help. Any contribution, including code,
testing, contributions to the documentation, or bug reporting is
always appreciated. For more information on how to get involved in
Apache Tuscany visit the website at:

http://incubator.apache.org/tuscany

Thank you for your interest in Apache Tuscany!

The Apache Tuscany Team.