And I must say that I'm impressed!

There has been a huge speed-up in the most areas. It seems like all the different components have been integrated much more efficient. This is also reflected in the installation process: everything is much easier than with r8.1. Thereby not saying that it's easy, just that it's easier .

When that's said there are still some remarks. For instance there's no documentation how to protect the Management Console if Siteminder is not installed, and encountering the fact that Siteminder itself if a quite comprehensive product, that's not satisfactory! They could just as well include a small guide in protecting the JBoss directory/application - it's really just editing four files or so, but for JBoss-infamiliar people it can be quite disincentive.

In order to overcome the slow-down in TEWS, a threaded solution can be made. In r8.1 only 15 threads were stable (in our environment) - or else TEWS would crash. In r12 I've succesfully used as much as 30 without experiencing instability. That's quite impressive!

There are more praise and more criticism to say about the new release 12, but in general I'm happy with it.

The problem was that a SOAP-fault (this name avoids mixing up the concepts of SOAP- and run-time exceptions) occurred, but the actual description of the error in the SOAP-response was not deserialized properly and was therefore not included in the run-time exception. The SOAP-response looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<soapenv:envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns="http://tews6/wsdl"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope/">
	<soapenv:body>
		<soapenv:fault>
			<faultcode>soapenv:Client</faultcode>
			<faultstring>Error performing operation.</faultstring>
			<detail>
				<imsexception version="6.0">
					<exception>
						<name>CheckForDuplicates</name>
						<code>500</code>
						<description><!--[CDATA[User id johndoe is a duplicate. ProcessStep::BLTHValidate TabName:  ERRORLEVEL::Error]]--></description>
					</exception>
				</imsexception>
			</detail>
		</soapenv:fault>
	</soapenv:body>
</soapenv:envelope>

I read about this several places, and all these said that it was just the way .NET worked in that area. Sounds a bit odd, but nevertheless I instead started to figure out how to solve it.

The solution is actually quite simple, but it took some time to figure out how it should be done. It consists of three parts:

• A custom Exception so that it can be caught separately
• A SoapExtension that handled serialization and deserialization of the SOAP-messages and in that way were possible to intervene if a SOAP-fault occurred and throw the custom exception instead of a generic SoapException
  • It's worth noticing that I used the ProcessMessage-method and especially the SoapMessage stage BeforeDeserialize
• A SoapExtensionAttribute used to mark the web methods should use the SOAP-extension

It actually works very well! The only drawback is that every web method has to be marked with the attribute - but just another opportunity to celebrate sed!