GlassFish ESB BPEL cluster with correlation and appserver scripting

GlassFish ESB 2.1 will support GlassFish cluster. BPEL will also run clustered. Cluster support includes support for BPEL processes with correlations.

Once a BPEL process instance starts to wait for a correlated receive activity, the instance will be passivated. If the correlated input comes in to any instance of the cluster, the passivated process instance will be re-activated on that appserver instance, also if it is not the appserver instance where the original process was running, and continue where it left off when it was passivated.

To make this work, BPEL persistence must be enabled, and the BPEL engine must be running in a cluster in an appserver domain set up with the cluster profile.

I created a simple sample to show this cluster support with correlation in action. In the process of creating the sample, I also used GlassFish appserver administration scripting to create a Windows script that does:

• set up the cluster domain (called d-cluster)
• add the MySQL JDBC connector to the domain
• add a cluster (cluster1) to the domain
• add a node agent (nodeagent1) to the domain
• add two instances (instance1 and instance2) to the domain
• set up the JDBC connection pools (bpelseXA and bpelseNonXA) in the cluster, necessary for BPEL persistence
• set up the JDBC resources (jdbc/bpelseXA and jdbc/bpelseNonXA) in the cluster, needed for BPEL persistence
• install all JBI shared libraries in the cluster
• install and configure the BPEL engine in the cluster (persistence, monitoring, and KPIs are enabled by the script)

Another Windows script

• deploys and starts the sample service assembly (caBpelClusterTest)d yet another a script

Yet another Windows script

• displayer's the status of the service assembly in the cluster

And a last Windows script

• removes the cluster instances, node agent and domain created in the first script

To use the sample you should prepare your system by doing these things:

• install GlassFish ESB 2.1 (I used the nightly build of 2009-05-14)
• install SoapUI 2.5.1 (or another way to send web service messages to the service assembly)
• install MySQL server 5.1
• ensure that your MySQL server is running
• use the SQL scripts found here to create and initialise the MySQL database and user needed for BPEL persistence
• • first use the create_bpelse_user.sql script to create the database and the user
  • then log in as the user just created (bpelcluster/bpelcluster, database bpelclusterdb)
  • run script create_bpelse_tables.sql to create the BPEL persistence tables
  • run script create_bpelmonitor_tables.sql to create the monitoring tables
• download the GlassFish ESB sample scripts and other files needed here
• unzip this file in a directory of your choice
• open file file-store\files-to-put-here.txt and follow the instructions found in there to put the required files in there
• • these are some files you can download from the open-esb web site, they are not included to ensure that you use the correct version of those files and to make the zip file much smaller
• change the script files in the directory where you unzipped the GlassFish ESB sample scripts
• • change all occurrences of "c:\gf-esb" to the proper directory. This directory is used as the base directory for the scripts and for the GlassFIsh ESB installation
  • change the host-name and port number of the MySQL server if they are not the default values (localhost:3306)
• run the create-and-prepare-domain-d-cluster1.cmd script
• • follow the instructions displayed during execution of the script
  • when the script finishes, you have the new d-cluster1 domain, fully prepared as described above
• run the deploy-corr-cluster-test.cmd script
• • this will deploy and start the sample service assembly
• running script list-corr-cluster-test.cmd will display information about the service assembly (the deployment script also does that after deploying and starting the service assembly)
• once the service assembly is running, you can use SoapUI to test proper functioning. SoapUI (2.5.1) projects are found here

When you send messages to the various instances by using SoapUI, progress will be shown in the GlassFish log files of the instances. The BPEL process in the service assembly provides some logging to show what is happening. The messages to start the BPEL process and the correlated messages are InOnly, so SoapUI will not receive replies.

If you want to get rid of the domain created and everything in it, run the delete-domain-d-cluster1.cmd script.

A zip file containing the NetBeans projects for the service assembly can be downloaded here.

Posted at 12:55PM May 20, 2009 by marjo in ESB  |  Comments[0]

Distributed transaction sample - part 4 (the final part) - the samples

This is the final part of the Distributed transactions sample log. It gives you the sample projects, some ideas on running the sample, and some hints on tracing what is happening exactly.

Enabling persistence in Java CAPS

Before we continue with the samples: To enable transactional behaviour in Java CAPS 6 BPEL, persistence must be enabled. How to enable BPEL persistence in Java CAPS 6 is described here.

The .NET sample project

You can download the .NET sample project here. Unzip the downloaded file to a convenient place.

In the service part of the .NET sample project, in the App.config file you will find the XML that configures the service. The WSDL produced for the service is directly dependent on the information in this config file. To find information about the various parts of the XML, you can start at Microsoft's .NET documentation for this subject. This documentation contains a full reference of all elements in the XML file.

The code for the sample service is found in file service.cs. The code is simple. As you will see, log messages are written to the command window where the service runs as soon as something arrives and is done. Stuff is also done in the Oracle database, so that transactional operation can be demonstrated.

The .NET sample project must be modified to fit your environment. Don't worry, the modifications are small and straightforward. To make the modifications start Visual C#, and open the .NET project in the location where you unzipped the downloaded file.

To change the port the sample service listens on (in the downloaded file it is port 9000), open App.config in the service part of the project. Perhaps you also want to change the host name (localhost in the downloaded file) to something else.

Another thing you will quite likely have to change, is the Oracle connectivity information (found on line 11 of the App.config file in the downloaded project). .NET uses sql*net, and therefore you will find a TNS name in App.config. You'll also find an Oracle user id and password. You must change these things to the values appropriate to connect to the Oracle database in your environment.

To build the service after making changes, right-click on service and select Rebuild.

To run the service in debug mode, right-click on service, select Debug, and then select Start new instance.

To run the service in non-debug mode go to the bin directory of the project and double-click sample-svc.exe. The messages appearing in the command window are the same when running in debug or non-debug mode.

To stop a running instance, press Enter when in the command window where the service runs.

Scripts to create, clear, and delete the user and table required by the sample in an Oracle database can be found in the file you can download here. This file can be unzipped at a convenient place. Quite likely you will need to make some (small) changes - such as the location of the datafile for the tablespace - before running the scripts.

Java CAPS sample project

The Java CAPS sample project (a NetBeans project) can be downloaded here. Unzip the downloaded file to a convenient location.

Start your Java CAPS GlassFish server and ensure that BPEL persistence is enabled (see earlier in this entry). Start NetBeans (the one that comes with Java CAPS 6), and open the downloaded projects. You will find several projects (refer to earlier episodes of this log for more information on how the project relate to each other):

• bp-transactional-bpmain: this is the main BPEL process, the one that calls the EJB web service proxy
• bp-transactional-bpproxy: this is the proxy BPEL process, used to ensure that bpMain runs in a transaction
• casa-transactional-bp-bp-ext-ejb: this is the composite application that contains bpProxy and bpMain and calls the EJB web service proxy as an external web service
• ejb-transactional-wsproxy: this is the EJB web service proxy. It accepts requests in SOAP 1.1 and calls the .NET service using SOAP 1.2
• ejb-transactional-wstest: this is a test EJB. It takes the same actions as the main BPEL process. This EJB can be invoked as a web service

To get going, you should try to get the ejb-transactional-wsproxy project working. This project can be called directly from SoapUI, because it has its own web service. To get started:

• ensure that the Oracle database is running
• ensure that the .NET service is running
• in NetBeans deploy the ejb-transactional-wsproxy project
• in SoapUI, create a new project from the WSDL created when ejb-transactional-wsproxy was deployed. By default you will find the WSDL at URL http://localhost:8080/wsProxyService/wsProxy?wsdl. If your Java CAPS GlassFish server listens on another port, you should use that port instead.
• in SoapUI you will now see the various operations provided by the wsProxy web service. You can fill in parameters for requests, invoke the requests, and see if the web service work

If you invoke requests and get good results back, the BPEL processes can be added. To add the BPEL processes:

• in NetBeans check the bpProxy endpoint in the CASA editor for the casa-transactional-bp-bp-ext-ejb project. If the port number specified in the endpoint for bpProxy is already in use change it to a port not in use at your system
• in NetBeans deploy the casa-transactional-bp-bp-ext-ejb project

To test the entire process with all components in place:

• In SoapUI create a new project from the WSDL created by deploying the composite application. By default you'll find the WSDL at URL http://localhost:23081/bpProxyService/bpProxyPort?wsdl. If you have another port specified in the endpoint in the CASA, use that port instead
• In SoapUI the operations with parameters will be present. Fill in parameters, issue requests, and see if it all works

Tracing and logging in MSDTC

When you are running tests to see if it all works, you may want to trace MSDTC and WS-AT.

This file contains some experimental scripts and other files to do this. Unzip the file to a convenient location. Some MSDTC and WS-AT scripts (from the downloaded zip file) and other stuff:

• script create-wsattrace-w.cmd: this sets up a trace logger for WS-AT. This script must be run once only
• script trace-msdtc.cmd: activates the trace and then pauses so you can run your test. When your test is done, press any key in the window where the script runs. The script will then stop the trace and deactivate the trace logger. The result of this trace is found in c:\logs\msdtc (if wanted, this location can, of course, be changed in the script). The traces created are stored in files with names like wsat-nnnnnn.etl files. These files can be opened by the Service Trace Viewer. This viewer is found at C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\SvcTraceViewer.exe (setting up a shortcut makes things easier). These files contain lots of information. If errors have occurred they are clearly shown in the System Trace Viewer. Those error entries can help to find out the reason why something does not work.
• script convert-dtc-log.cmd: read the dtctrace.log file produced by MSDTC and WS-AT tracing when enabled via MSDTC configuration (see the previous episode for how to configure MSDTC). The dtctrace.log files are found in C:\WINDOWS\system32\MsDtc\Trace.
  I have not found any useful information in this file up to now.
• The WsatTrace.etl file, found in C:\WINDOWS\system32\MsDtc\Trace, can be read by the Service Trace Viewer (see above). This file can contain useful information. Be sure to set the most extensive trace options in MSDTC and WS-AT configuration.
• Additionally, extra tracing can be obtained by doing the following:
• • open registry editor and navigate to
    Hkey_Local_Machine\SOFTWARE\Microsoft\WSAT\3.0\
  • Right-click value
    ServiceModelDiagnosticTracing
Or create this value if it doesn't exist (it is a DWORD value)
  • Change the value to
    31
(decimal) to get the most verbose tracing.
    

Tracing and logging in GlassFish

Of course you may also want to see some more details on what is going on at the GlassFish side. Here are some things you can do to get extra information:

• to get SSL handshake debugging information in GlassFish, add the following to domain.xml (add it where the other <jvm-options> are):
  <!-- Add for debugging ssl handshake -->
<jvm-options>-Djavax.net.debug=ssl,handshake,trustmanager</jvm-options>
• to see client/server messages after pipe processing add the following to domain.xml (add it where the other <jvm-options> are):
  <jvm-options>-Dcom.sun.xml.ws.assembler.server=true</jvm-options>
• to get more info on web services transaction processing:
• • in asadmin -> Application Server -> logging -> log levels, set:
    javax.enterprise.resource.webservices.jaxws.wstx FINEST (or FINE)

And, of course, you can add your own logging in the BPEL processes and EJBs. Some logging is already present in the sample projects.

Documentation starting point

For the JBI components in Java CAPS 6 you can find documentation on the OpenESB site.

A starting point for development information for .NET (the sample uses WCF, the Windows Communication Foundation) is found on the Microsoft MSDN site.

Finishing off

I am not a Microsoft .NET expert. The samples and remarks I make about .NET may not give the best way to do things in .NET. They worked for me when creating this example. If you know better ways of doing things in .NET, then, by all means, use them.

This concludes the Distributed transaction sample log.

I hope I did not forget too many things, and I hope this log will be useful to some.

Posted at 03:28PM Jan 09, 2009 by marjo in Distributed transaction  |  Comments[1]

Distributed transaction sample: part 3 - preparation

Preparing Oracle and Windows for the distributed transaction. There's also some talk about transaction coordinators in this entry.

note: The Java CAPS and EJB parts of the sample application run in Sun GlassFish Enterprise Server (which comes with Java CAPS 6). To save a lot of typing I'll refer to it as GlassFish. An open source version of GlassFish is also available, and the sample can be run with that server as well. The open source version of GlassFish is included in OpenESB. The sample presented here should also work with OpenESB, but I have not tested that.

SoapUI

In the previous entry, about software installation and such, I forgot to mention installation of SoapUI. SoapUI is a tool that can be used to initiate web services. It can be downloaded here. On my system I have installed version 2.0.2.

SoapUI comes as a stand-alone application (that's the version I use), and as a plug-in for various environments. As Java CAPS 6 comes with NetBeans, you can install the NetBeans plug-in if you want to. For the stand-alone version, download the installer, and run it.

Oracle database

The Oracle database on my system is running with instance name oradb. The database runs on the local system (localhost) on the default Oracle port (1521. The table needed for the sample is stored in schema log (Oracle user log). If you want to use another instance name, another user, or run with an Oracle database on another system or on another port, you will have to change the WCF service. If you set up your database with the same properties, you can use the provided WCF sample without change.

One simple table is needed in the Oracle database. In the zip file found here you will find database scripts to create the log user (with password log) and its table, to clear the table, and to remove the user and its table. Please note that you must edit the creation script to provide the correct location for the location of the file containing the Oracle tablespace for the log user. Of course you can also change other things in the script, such as the user name and password. If you do make such changes, you must alter the WCF service application to reflect those.

The scripts can be executed with the Oracle SQL Developer tool, installed as part of the Oracle client (see the previous log entry for more on installing Oracle).

Transaction Coordinators

The example distributed transaction demonstrates a transaction where the activities are operations invoked via web services. Transactional behaviour in this sort of system uses the WS-AtomicTransaction (WS-AT) coordination type. In this sample, web services run in several different software environments. Each of those environments has its own transaction coordinator as shown in the picture below:

When bpProxy invokes bpMain, it will first register a new transaction with its transaction coordinator (TC). bpProxy runs in GlassFish, so the main TC for this transaction is the GlassFish one. bpMain is an atomic BPEL process. That means that when bpMain starts, it enlists in (joins) the existing transaction. It becomes part of that transaction. bpMain invokes several operations in ejbProxy. Operations in ejbProxy are specified to require an existing transaction, and therefore each of these operations also enlists in the existing transaction. Because up to now all activities took place in the GlassFish application server, the GlassFish TC is used by all these activities.

ejbProxy invokes operations on the WCF service. Each of these operations enlists in the existing transaction. However, this time a different TC, MSDTC (Microsoft Distributed Transaction Coordinator) is used. When an operation is invoked on the WCF service, MSDTC detects that a transaction is already active. In the WCF application the operations are specified as requiring an existing transaction. MSDTC communicates with the GlassFish TC, and together the coordinators ensure that the distributed transaction is dealt with in the proper way, with the GlassFish TC as the main TC. If the transaction would have been started by a WCF component, MSDTC would be the main TC.

The WCF service invokes Oracle. The Oracle activities participate in the existing transaction. Because the Oracle Data Access Components were installed, as mentioned in the previous entry, Oracle uses MSDTC to participate in the existing transaction.

When the last request has been processed by bpMain, control returns to bpProxy. The transaction is ended. Depending on previous events, the transaction is either committed (made permanent) or rolled back. The main TC (the GlassFish one in this case) would communicate to all participating TCs to ensure that all activities that have been executed in the transaction are committed or rolled back.

If bpProxy, bpMain, and ejbProxy would run in several GlassFish application servers, each would have registered with its own GlassFish TC. If other systems and environments would participate in the transaction, their TCs would be used (of course only systems that adhere to WS-AT can participate). The TC where the transaction was started would become the main TC. No matter how many TCs are involved, they would communicate to ensure proper management of the distributed transaction.

Certificates

Transaction coordinators need secure communication to ensure that no illegal parties get unrightfully involved in a transaction. To facilitate this, they use SSL as their communication protocol. Each TC authenticates the one(s) it communicates with by X.509 certificates.

To make this authentication possible, the public keys of the TCs must be present in the keystore of their counterparts. In our case we have two TCs. The GlassFish TC needs the public key of the MSDTC, and MSDTC needs the public key of the GlassFish TC. Each environment also has its own private key. During the SSL protocol certificates are exchanged and authenticated. The TCs use mutual authentication. When SSL keys are exchanged, public keys are used to encrypt data. The private key matching the public one is the only key that can be used to decrypt the data encrypted by using the public key. A simplified picture of the use of certificates (see the SSL protocol for how it really works):

The keys for GlassFish where created automatically when the domain was created during Java CAPS installation. For MSDTC the key must be created. Creating keys in Windows is done with the makecert command. A complete key consists of a private key and a public one. The private key must not be shared with other parties.

In certificate systems, a certificate must be authorised by a trusted certificate. These trusted certificates are called Certificate Authorities (CA). In our sample system we do not have an external CA. We can work in two ways: we can create one certificate that can then must be stored in both the CA keystore and the certificates keystore. Or we can create an authoritative certificate for our own little sample world, and sign the other certificate(s) we create with this CA certificate. Now the authoritative certificate should be stored in the CA keystore. When that is done, all certificates signed with the authoritative certificate will automatically be trusted. In this example, we will use the second method.

Please note that the commands in the procedure below may not always fit on one line. Please ensure that you issue the complete command, ignoring any line breaks.

• open a command Window
• navigate to the directory where you want to store your certificate files (preferably an empty directory)
• to save ourselves a lot of typing, let's set the location of the Windows SDK binary directory in an environment variable:
  set EXEC_DIR="C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin"
• to create the authoritative certificate issue the following command:
  %EXEC_DIR%\makecert TempCA.cer -sv TempCA.pvk -a sha1 -n "CN=TempCA" -r -sky signature -pe -len 2048 -sr CurrentUser -ss My
• to create a certificate for msdtc, signed with the certificate created before issue command:
  %EXEC_DIR%\makecert.exe msdtc-ssl.cer -sv msdtc-ssl.pvk -a sha1 -n "CN=statler.muppets.local" -ic TempCA.cer -iv TempCA.pvk -sky exchange -pe -len 2048 -sr CurrentUser -ss My
  note: it is important to replace "statler.muppets.local" with the fully qualified domain name of he machine where your WCF service runs, because during the SSL handshake the FQDN of the machine sending the certificate and the CN in the certificate are compared, and the connection fails if they are not
• to package the msdtc certificate with its private key in a .pfx file (needed later) issue command:
  %EXEC_DIR%\pvk2pfx.exe -pvk msdtc-ssl.pvk -spc msdtc-ssl.cer -pfx msdtc-ssl.pfx -po changeit
  note: the password for the pfx file created will be "changeit"

The certificate for the GlassFish domain will also be needed in later steps. Portecle is used to export the certificate.

• start Portecle
• open the keystore for the GlassFish domain created when installing Java CAPS 6. The keystore and cacert files are found in the config directory for the domain (for example c:\jcaps6\appserver\domains\domain1\config)
  note: Portecle will prompt for the keystore password. The default password for the keystore is "changeit" (if you changed it during installation of Java CAPS 6, type your password instead of "changeit")
• right-click on the s1as certificate
• select export from the popup menu
• leave the dialog that appears unchanged, and click the OK button
• name the export file s1as.cer
• click the Export button to save the certificate in a convenient location (possibly the location where you created the msdtc certificates)

This looks like:

Now all certificates needed are stored in .cer files.

In GlassFish the MSDTC certificate (public key) is needed, and MSDTC needs GlassFish's public key and the key we created for MSDTC before (its private key).

While still in Portecle, we can import the msdtc-ssl certificate in the GlassFish keystore and cacerts files.

• open the keystore.jks file
• on the menu select Tools->Import Trusted Certificate...
• select the msdtc-ssl.cer file created earlier
• open the cacerts.jks file
• on the menu select Tools->Import Trusted Certificate...
• select the msdtc-ssl.cer file created earlier

The MSDTC certificate is now imported in the GlassFish keystore and root certificates file, ready for use by SSL.

To store the GlassFish public key and the MSDTC private key in MSDTC's keystore do the following:

• open the Certificates mmc snap-in (described in the previous entry)
• navigate to Certificates (Local Computer)\Trusted Root Certificate Authorities\Certificates
• right-click on Certificates (in the tree on the left) and select All Tasks -> Import...
• in the wizard that appears click Next
• click the Browse... button
• browse to the s1as.cer file exported before from GlassFish (using Portecle) and select that file
• click Next in the Certificate Import Wizard dialog
• without changing the options click Next again
• now click Finish
• click OK in the notification that the import is done
• right-click the newly added certificate. The name of the certificate will be the FQDN of your machine ("statler.muppets.com" in my case)
• select Properties
• set the Friendly Name to "s1as", type a description if you want to, and click OK
  note: this is an important step, because all certificates will be listed with the FQDN found in the certificate. If you don't change the friendly name, you'll not be able to tell the various certificates apart in several configuration tasks that follow
• repeat this procedure (from All Tasks -> Import...)
• this time select the TempCA.cer file, created earlier
• set the friendly name to "Temporary Certificate Authority"

This looks like this:

Setting the friendly name (and possibly the description) in the properties:

The Root Certificate Authorities are now imported and available to Windows. Now the certificates themselves must be imported. To import the GlassFish certificate, continue where we were before the pictures, and:

• navigate to Certificates (Local Computer)\Personal\Certificates
• right-click on Certificates (in the tree on the left) and select All Tasks -> Import...
• in the wizard that appears click Next
• click the Browse... button
• browse to the s1as.cer file exported before from GlassFish (using Portecle) and select that file
• click Next in the Certificate Import Wizard dialog
• without changing the options click Next again
• now click Finish
• click OK in the notification that the import is done

To import the MSDTC private key do the following (it s similar, but not exactly the same):

• right-click on Certificates (in the tree on the left) and select All Tasks -> Import...
• in the wizard that appears click Next
• click the Browse... button
• change "Files of type" to "Personal Information Exchange (*.pfx;*.p12)
• browse to the msdtc-ssl.pfx file created before and select that file
• click Next in the Certificate Import Wizard dialog
• type the password for the msdtc-ssl.pfx file ("changeit" if you did not change it), and check "Mark this key as exportable" (this last option is just for convenience) and click Next
• without changing the options click Next again
• now click Finish
• click OK in the notification that the import is done

All the necessary certificates are now available for MSDTC. Now MSDTC must be configured to use its certificate, and to allow GlassFish as its counterpart.

MSDTC configuration

To configure MSDTC, do the following:

• go to Start->Programs->Administrative Tools->Component Services (if you don't have Administrative Tools in Programs, you can enable it by right-clicking on the task bar and then customising the task bar)
• click on Component Services. A sub-entry called Computers will appear
• expand the Computers entry
• right-click on Computer and select Properties...
• in the window that appears, select the MSDTC tab
• click the Security Configuration... button
• in the window that comes up enable all check boxes (you can leave the Allow Remote Administration box unchecked if you want to)
• click OK
• if a message box appears that asks if it is OK to stop and restart the MS DTC service, click Yes
• select the WS-AT tab
• check the Enable WS-Atomic Transaction network support check box
• select a port that is not in use by other processes on your system (on my system I use 8001)
• click the Select... button for Endpoint certificate to select the endpoint certificate to use by MSDTC
• in the list of certificates, select the msdtc-ssl certificate (this is where the friendly name comes in handy! If you had not set the friendly name, you wouldn't be able to tell which if the certificates to select)
• click OK
• click the Select... button for Authorized certificates to select which certificates MSDTC will accept
• ensure that the s1as certificate is authorised (in the picture you will see all certificates authorised). Certificates are authorised by checking the check box in front of them. Friendly names allow you to distinguish the certificates.
• click OK
• if a message box appears that asks if it is OK to stop and restart the MS DTC service, click Yes
• click OK again
• if a message box appears that asks if it is OK to stop and restart the MS DTC service, click Yes

The windows described above look like this:

MS DTC is now configured, and ready to participate in our transactions.

Posted at 01:21PM Jan 05, 2009 by marjo in Distributed transaction  |  Comments[0]

Distributed transaction sample - question for you folks...

I have been quite busy with other stuff lately, so you haven't seen a new episode appear on the distributed transaction sample.

As it has turned out, the way I am logging about the distributed transaction sample takes a lot of time. I want to know if it is worthwhile. If no-one reads it or is interested in it, I can start to log about other things. The distributed transaction sample will take at least 2 or 3 more episodes before it is complete (and those episodes will take time to come into existence). It is also slightly out-dated, as OpenESB currently supports SOAP 1.2.

The way I started the distributed transaction sample log is also - in hindsight, and my opinion - not the right way to go about it. It is so detailed that perhaps a video would have been nicer. In any case, the story turns out to be way to long for a log, I think.

If I won't log about the distributed transaction sample - depending on the reactions I get to this post, I will write a summary of what I did and how it works, without all the details, and leave it at that.

Please let me know if you are interested in the follow on of the distributed transaction sample, or if you find a summary of what I did and how it works good enough. If you have anything to say about the way to log about these things, then please go ahead, post a comment and let me know.

Posted at 06:47PM Nov 26, 2008 by marjo in Sun  |  Comments[2]

Distributed transaction sample: part 2 - software installation and basic setup

Installing necessary software and performing basic set up of the environment for the distributed transaction sample application.

On my machine I created a VirtualBox image, running Windows XP SP3, with all updates applied. One disk is allocated to the virtual machine. It is 18 GB, using the NTFS file systems, and compression of all files enabled. Currently it has roughly 5 GB free space. The virtual machine has 1 GB of memory assigned to it. If you can allocate more memory, performance will be better.

Network setup

For reasons explained later, the fully qualified domain name (FQDN) of the machine is important, and it must be set before other products (especially Java CAPS 6) are installed. If your machine already has a proper FQDN and is connected to a name server so that lookups and reverse lookups are supported, you can skip the next few paragraphs. If that isn't so, you'll find here how the FQDN for a Windows machine can be set up:

• go to Control Panel -> System -> Computer Name
  (or My Computer -> Properties -> Computer Name)
• Click the Change... button
• Type the computer name. This will become the host-name part of the FQDN
• Click the More... button
• Type the Primary DNS Suffix of this computer. This will be the domain part of the FQDN.

The FQDN of the Windows machine will be <computer-name>.<primary-dns-suffix>

On my machine this looks like:

The FQDN of my machine is statler.muppets.local (don't use muppets.com, as that points to the official Disney Muppets site, and that's not what we want).

To ensure a consistent FQDN and enable lookups and reverse lookups, a name server was installed in the Windows machine. If your machine is already registered in a name server, and that name server can be used from your machine, you do not have to install your own name server. The name server I use is ntbind 9.3.2, which can be downloaded here.

Unzip the zip file found there in an empty temporary directory. Then execute BindInstall.exe, found in that temporary directory to install the name server. On my machine Bind is installed in directory c:\bind.
Here you will find the configuration files used on my machine to set up statler.muppets.local as the FQDN for the machine, which has ip-address 192.168.2.185. To copy this configuration to your Bind installation:

• empty (or remove) the etc and zones directories in your bind directory (e.g. c:\bind)
• unzip the configuration files in your bind directory, maintaining directory structure
  This will put the config files in your bind etc and zones directory.

If the FQDN of your machine is not statler.muppets.com, or if the ip-address of your machine is not 192.168.2.185, change the config files (in the bind etc and zones directories) accordingly.

Note: I tried to configure BIND to automatically go to the outside world if a host name is not found in its local configuration, but somehow I did something wrong there. If anyone spots the error, I am interested to hear how to configure it properly. Currently I configured my usual DNS server as the alternate one in network configuration (see below), and that also works.

Now configure your ethernet connection:

• in Control Panel -> Network Connections, right-click your ethernet connection and select Properties
• select Internet Protocol (TCP/IP) in the list of protocols, and then click the Properties button
• now configure the connection:
• • set your chosen ip-address and the correct subnet mask
  • if you have a connection to the outside world, configure the Default gateway with the address of your router
  • set the Preferred DNS server to the ip-address of your machine. This will ensure that the Bind server will be used to resolve names.
    If your machine is reistered in another name server, configure this name server as the preferred one
  • if you want to be able to connect to the outside world, set the Alternate DNS server to the server you usually use as your name server. Quite often this is the address of your router
  • click the Advanced... button
  • go to the DNS tab
  • ensure that the DNS suffix for this connection is properly set to your domain name

Here is the configuration of the network on my machine:

Visual Studio, .NET, and other Microsoft Windows tools

If you want to be able to change the WCF samples I will provide later, you must install Microsoft Visual Studio 2008. A free version (Microsoft Visual Studio 2008 Express) is available for download here. The sample WCF client and service are both in C#, and SQLServer is not used, so the only component you have to install to be able to change and rebuild the sample is Microsoft Visual C#. On my system I installed all Visual Studio components.

Now download and install the latest update for .NET. On my system .NET 3.5 is installed. .NET 3.5 can be installed through the Windows update site. If Windows Update does not list it, you can find it here.

Download and install the Windows and .NET SDK, which is found here.
Please note that even for Windows XP, you should choose "Windows SDK for Windows Server 2008 and .NET Framework 3.5".

Install Windows Support tools if they are not yet present on your system (if they are installed, they should be in Program Files\Support Tools). These tools are found on the Windows XP installation cd in directory Support\Tools In this directory, execute suptools.msi.

Install the certificate management snap-in:

• Click on Run (in Start menu) and type mmc. Then press Enter
• In the mmc go to the File Menu and select Add/Remove Snap-in
• In the dialog box that pops up click the Add button
• From the list select Certificates and click OK
• On the dialog that appears, select Computer Account and click the Next button
• On the next dialog ensure that Local Computer is selected and click the Finish Button
• Click the Close button in the Add Standalone Snap-in dialog
• Click the OK button in the Add/Remove Snap-in dialog
  Now you will have a certificate management tool for Windows
• When closing the management console, save the settings as Certificates.msc

This looks like:

You can start the tool via Start->Programs->Administrative Tools (if you don't have that you can enable it by right clicking on the task bar and then customising the task bar). For your convenience you can also create a shortcut to the certificates management console. Create a new shortcut, and in the location field type Certificates.msc.

Install the WS-AT management user interface:

• Start a command window (DOS prompt)
• Navigate to directory C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin
• Now register the WS-AT management user interface by executing command:
  C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm /codebase WsatUI.dll

Oracle

Oracle Database and Client software must be installed. This software can be downloaded from the Oracle site. To run the sample you must also install the Oracle Data Access Components (ODAC). The Oracle .Database Extensions for .NET and the Oracle Data Provider for .NET are used in the sample.

On my system I installed Oracle's 11g Enterprise Edition (not all features installed) and Client. The specific versions are: Oracle Database 11g version 11.1.0.6.0, Oracle Data Access Components for Oracle Server 11.1.0.6.21, Oracle Client 11.1.0.6.0, and Oracle Data Access Components for Oracle Client 11.1.0.6.21. In both the ODAC installations I installed all available options. Other versions that support .NET should also be alright.

Don't forget to run the necessary scripts to set up ODAC in your database.

Java JDK 1.6 and JCE unlimited strength security jurisdiction policy

Download the latest Java 6 JDK from here. Install Java JDK 6 by running the downloaded program and following the instructions.

Download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6. The download needed to install this policy is found here (near the bottom of the page). Unzip the file in a temporary directory. The read-me file in that temporary directory explains the (simple) steps to install JCE unlimited strength jurisdiction policy.

Portecle

To make handling of certificates in Java keystores easy (with a GUI), download and install Portecle, a key management tool. It can be found here. After download do the following to install and run:

• Installation is done by simply unzipping the files in a convenient location
• Run the tool by executing javaw.exe -jar portecle.jar in the directory where you unzipped Portecle.
• For your convenience you can create a shortcut with this command, and put it somewhere in the start menu or the quick launch tool-bar. In the directory where you unzipped Portecle, you will also find an icon (portecle.ico) that you can associate with the shortcut.

If wanted/needed you can replace the Bouncy Castle jar file of Portecle with a newer version (found here). If you do this, just replace the bcprov.jar file in your Portecle installation directory (where you unzipped Portecle) with the bouncy castle jar you downloaded (rename the downloaded jar file to bcprov.jar if needed)..

Java CAPS 6 (GA version)

Install the GA version of Java CAPS 6 (see here on how to get it if you don't have it yet). Run the installer and follow the instructions. On my system the default values for port numbers and such have been used.

The sample discussed in these log entries should also work with OpenESB, but I have not tested that.

Your environment is now prepared to set up and run the distributed transaction sample.

Posted at 12:02PM Sep 01, 2008 by marjo in Distributed transaction  |  Comments[1]

Distributed transaction sample: part 1 - introduction

This and the next couple of entries in this log are about execution of distributed transactions involving Java CAPS BPEL, EJB web services, WCF (.NET Windows Communication Foundation) web services, and an Oracle database. System and environment setup and creation and running of a sample application will be discussed.

Java and WCF interoperability is the subject of Web Services Interoperability Technologies (WSIT) (previously known as Project Tango), a Sun-led project in which Microsoft and Sun work together to ensure web services based interoperability between the two environments. You can find more information on WCF and Java web services interoperability on the WSIT web site.

What is a transaction?

Just as a short recap:

• Atomic means that the transaction is executed entirely or not at all.
• Consistent means that the data underlying the transaction is in a consistent state before the transaction and when the transaction has finished (successfully or not).
• Isolated means that the actions in the transaction are executed in isolation. The outside world doesn't see the results until the entire transaction has finished.
• Durable means that the effect of the transaction is persistent. It does not disappear, it survives system restarts, and will not be undone (unless by another transaction).

The sample

The sample application that will be dealt with in these log entries does not do anything useful, except demonstrate transactional capabilities involving Java CAPS 6, EJB web services, WCF, and Oracle.

The example application looks like this:

The BPEL process starts the transaction and, when all required actions are executed, ends it. The transaction can be ended successfully, in which case it will be committed, or it can be terminated with an error, in which case it will be rolled back.
The actions to be executed by the BPEL process are determined by values in the WSDL used to invoke the BPEL process. Transaction commit or rollback is also determined by a value in the WSDL.

Working around some limitations

The resulting application looks like this:

The next couple of entries in this log will talk about how to set up a system and environment to run this application, and how to create the application itself.

Posted at 12:01PM Sep 01, 2008 by marjo in Distributed transaction  |  Comments[2]

Blogging with Zoundry Raven

To make my blogging life easier, I have been looking into a couple of free offline blogging editors. Looked at, among others, Ecto (for Windows) (a version is still available here), Qumania, w.Bloggar, Windows Live Writer, and Zoundry Raven. Raven seemed to be the most fitting for me. It has a nice editor, and nice blog management features. The editor is claimed to be WYSIWYG, but that is only true in preview mode - where editing is not possible. The editing window does not show my blog according to the template. However, by selecting an editor font close enough to the one used in my template, editing is WYSIAWYG. Good enough for me.

When I installed Raven, it refused to download posts, templates, and such from my log. Contacted the Zoundry guys, and they were very helpful and responsive in solving the problem. I now have a working Raven offline blog editor, and am very happy with it.

One thing to note is that, even though my local timezone is configured correctly in Raven, I have to manually set the posting time to 9 less than local time to avoid the post being scheduled for posting 9 hours after I post it from Raven. This is not a problem in Raven, as it converts the time to UTC in he correct XML date-time format (checked with the Charles Web Debugging Proxy, a very nice tool). It looks like our Roller server does not convert the UTC time correctly to its local timezone, but keeps the time and date unchanged. Because I live 9 hours in the future, from our server's perspective, my posts are scheduled for later posting, unless I set the date-time manually. And therefore that is what I do.

Another note is about tags. The blogs.sun.com web site has its own tagging mechanism. This mechanism is not supported in the MetaWebLog API does not support this tagging mechanism. I came to the same conclusion as David G. Simmons, and have given up the use of tags until a mechanism becomes available where I can set them up in Raven.

Posted at 11:00AM Aug 22, 2008 by marjo in Blogging  |  Comments[0]

introducing: the dutchman

Posted at 03:52PM Aug 08, 2008 by marjo in Personal  |  Comments[0]