Hi All,

When the ACL was set to Anonymous the consumption of the WSDL generated for that service from XML SPY [ 5.0] was pretty straight forward. But when I set a some non-anonymous I see no apparent way from XML SPY to pass username password. It just errors out
-with HTTP 500 -the soap details contain -
<webM:exception>
<webM:className>com.wm.app.b2b.server.AccessException</webM:className>
<webM:message xml:lang=“”>[ISS.0084.9004] Access Denied</webM:message>
</webM:exception>

Any idea how to consume a service with ACL defined to non anonymous. I am using the default soap processor.

Shashwata

Not sure what capabilities XML Spy 5.0 had to set authentication credentials. I believe that XML Spy 2006 and 2007 Enterprise allow you to do that, but it’s not immediately obvious how to accomplish this.

You might want to take CrossCheck Networks SOAPSonar Personal Edition for a test drive for testing web services.

Mark

Hi Mark,
This is not a issue with XML SPY. When I consumed basic authenticated webservices hosted on Oracle 10G appserver or Weblogic via XML SPY the pop up for user password came up.

In those environments they first send HTTP 401 [ auth error] which prompts the popup. But in WM it sends HTTP 500 [ internal server error].

I had to set up a custom access controlled soap processor exactly as per
steps -[see chapter 7 in soap develepor guide] which returns 401 first.

Good thing there was no other impact except setting up the above and changing from default URL.

But I wonder why the default behaviour of WM is different from other servers ! I checked some watt.server.soap properties …nothing seem relevant

Shashwata

Can’t answer the “why does it work this way question”, but there are many advantages to using a custom soap processor over either of the two defaults.

Since I have exclusively used custom-developed document/literal soap processors on recent projects I don’t run into this issue.

In my opinion, not being able to choose authentication approach before a request is submitted is a limitation of XML Spy. For example, what if your tests need to read various user credentials from a database or text file? What if they need to use a keystore instead of manually entered credentials? That is a limitation of the tool that you won’t find in more advanced testing products such as Parasoft SOATest, CrossCheck Network’s SOAP Sonar, iTKO’s LISA or HP / Mercury Interactive’s ServiceTest.

IS is not a J2EE app server. Projecting expectations of app server behavior onto IS is not particularly beneficial.

Mark

Mark,
“In my opinion, not being able to choose authentication approach before a request is submitted is a limitation of XML Spy.” I agree. Also since we are always passing user/password in AXIS-WSDL2JAVA generated java client there is no issue there.

We plan to upgrade to XML SPY 7.0 soon and don’t know yet if they will address this . I will update more on this thread as I get more answers.

But the other key point was why IS returns HTTP-500 when it should have returned HTTP 401 which makes more sense. This is about HTTP protocol not appservers.

Thanks for your comments.

Shashwata

Shashwata,

I have a four-year long list of requested improvements for the web services / SOAP functionality in Integration Server. This one related to the HTTP-401 is on the list but is way, way at the bottom compared to other needed improvements. Nonetheless, I’ll concede the point that it does create problems especially for .Net clients requiring special attention to the preauthenticate property of the web request.

The good news is that IS 7.1 is only a few months away from release (yeah, I know a few more months until ready for prime time production use). Many items on my list are supposed to be addressed in that release.

WM affirmed on both its customer and partner webinars, that they will stick to the already announced release milestones for the Fabric 7.0 and 7.1 products (including IS 7.1) which was welcome news.

Mark