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!

The IM is erected upon a product called SiteMinder and gives the possibilities to make the IdM-part far more dynamic than "just" the static construction achieved by using Admin only. Not only does the property of dynamics make it smart - there are several more improvements to the product. As a developer I especially like the TEWS (Task Execution Web Services) where every action within the console has a web service counterpart.

Not all thrilled of excitement, since it's still quite clear that the IM and Admin are two different products with all the cons as a consequence hereof, but in the next release these two products should be more integrated.

As a comment to the course, it was actually ok, although the course material wasn't the best seen ever. Some minor errors (and they really was minor) caused a lot of trouble; some not discovered until too late. But still, we all gained a lot of knowledge about IM.

Finally, the IM-part together with the already matured Admin is like having chocolate-sauce and sparklers on your ice cream, and hopefully the next release makes it out for a starter (or even a main course) with ancillary wine ad libitum.