JBossDeveloper

Hi,

maybe you could consider using the soapUI core also for submitting requests? That would give you direct support for authentication, attachments, MTOM, asynchronous requests, etc.. (soapUI uses HTTPClient as well..). Adding new protocols to the soapUI core is relatively easy as well.. (JMS?) I'd be glad to help out..

regards,

/Ole
eviware.com

Thanks Ole. That sounds like a totally logical way of doing it. I don't remember why I didn't do it this way to start with, but I do remember considering it at the time. I forget why I chose the route I did. I do think there was a reason but I just forget what it was off the top of my head. I'll look again.

If you're interested in poking about to see how I embedded soapUI, take a look at the "soapUI-client" service in the services folder. Maybe you can suggest from that how we might take the "soapUI all the way" route.

T.

cool.. I'll have a look over the weekend.. maybe one reason you decided not to go this route was the large set of soapUI dependencies !? (but you probably need the most of them for generating requests already.. )

/Ole

Thanks Ole :-)

I think I remember now...

We use the first Request (com.eviware.soapui.model.iface.Request) on the soapUI WsdlInterface Operation as a template for a SOAPClient request. On a per request basis, we create a DOM from the "template", clone parts of it etc (for collections) and then populate the DOM using an Object graph and the ? marks (that came from the template).

I think I thought (at the time) that to use soapUI would require either creating a com.eviware.soapui.model.iface.Request instance per SOAPClient (ESB) request, attaching that to the WsdlInterface Operation instance and working from that - coz I can't screw with my original "template" Request instance. I just was afraid of the cleanup involved and what this might result in from a soapUI perspective, say if the operation was hit by lots of requests. You'll know a way around this though :-)

Sorry Earnie, we haven't sorted this one out yet. It's not that it's big job to add this, just that we haven't had a chance yet. I think Ole was going to look into ways of leveraging soapUI to do this too.

Keep an eye on http://jira.jboss.com/jira/browse/JBESB-650. If it's not sorted out soon, rattle us again.

Hi all,

Actually, I might be able to have a look at this tonight.. could someone please point me to the right svn / trunk / branch / whatever etc so I don't have to go looking myself?

thanks!

/Ole
eviware.com

Hi Ole... so the main checkout is http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/ and the specific service (module) you're interested in is in product/services/soapui-client/.

Here is the steps to be done in order to fix SSL issue:

1. download latest SOAPUI 1.7.1 form http://downloads.sourceforge.net/soapui/soapui-1.7.1-bin.zip?modtime=1178619411&big_mirror=0

2. create soapui-client.sar folder under server\default\deploy

3. extract original soapui-client.sar file into this folder

4. delete soapui-client.sar/soapui-1.7.jar

5. Copy the following files:

- commons-httpclient-3.0.1-soapui.jar
- commons-ssl-0.3.4.jar
- soapui-1.7.1.jar

from soapui-1.7.1.zip\lib
to server\default\deploy\soapui-client.sar\lib

6. restart JBoss :-)

all works like a charm on my side, let me know if you have any questions/problems

up-s-s, sorry, it just solves SSL exception, but not HTTP BASIC auth.

It works for me only from within my version of the ESB I've patched based on Tom's guide. For now I've just hardcoded HTTP BASIC auth header value in the following way:

Authorization: a2VybWl0OnRoZWZyb2c=

OK, so I had a quick look at this over the weekend.

Webservices are connected to from 2 places:
1. By soapUI in order to load the wsdl (and related schemas etc).
2. By our SOAPClient action, in order to POST the SOAP request.

Therefore, if a webservice is secured and/or requires auth, we have to solve the issue in 2 places.

As far as the SOAPClient is concerned, I'd like to see it's use remain as straightforward as possible, so rather than having many many ssl+auth option on the action (and one big blob of code to support all that), I was thinking we should just allow it to be configured with a HttpClientFactory, to which SOAPClient delegates creation of the HttpClient instance. The properties that the factory impl requires could be nested inside this action property.

We can then ship with a few factory impls e.g. ClearHttpClientFactory (the default) and BasicAuthHttpClientFactory, but people can add their own implementations where they need something else. We simply can't support all the permutations and combinations out of the box right now. Hopefully people will contribute back some impls they create :-)

As far as soapUI is concerned, I need some input from Ole. I was intending on emailing him, but perhaps he's reading this :-) soapUI has a concept of a WsdlLoader. As its name suggests, it's used to load wsdls. I was hoping we could inject our own WsdlLoader impl that uses the above HttpClientFactory strategy (Vs writing separate code to configure soapUI through its existing security model). From what I can see, this would require changes to only a few classes in order to inject the WsdlLoader through the WsdlImporter. Might this be possible Ole?

T.

Hi Tom,

hehe.. I just 'happened' to see you post :-) I can refactor the WsdlLoader related code so it can be replaced be one that uses your httpclientfactory.. basically the WsdlLoader is an implementation of the javax.wsdl.xml.WSDLLocator interface (which is used by the wsdl4j api's), so if you provide an implementation of that I will find a way to hook it into the soapUI code..

regarding the use of the existing SOAPClient thats obviously a good idea! Maybe the default should support most of the standard HTTP-stuff out of the box (authentication, proxies, etc..), so you don't end up with a large number of "custom" factories, each for some specific combination of http-functionality. Also, I guess the possibility to send/receive attachments (both MIME and MTOM) should be centralized so this doesn't have to be reimplemented in all factories.. !?

regards,

/Ole
eviware.com

Regarding

so rather than having many many ssl+auth option on the action
?
I was thinking we should just allow it to be configured with a HttpClientFactory

<env:Header>
 <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
 <wsse:UsernameToken>
 <wsse:Username>???</wsse:Username>
 <wsse:Password>???</wsse:Password>
 </wsse:UsernameToken>
 </wsse:Security>
 </env:Header>