Consolidated Court Automation Programs(CCAP)

Simple Transaction Exchange Protocol(STEP) Technology

Technical Overview

Introduction

The STEP technology is a system for exchanging eXtensible Markup Language(XML) messages between different organizations. This exchange of messages happens through the cooperation of a Publishing Client that creates and sends an XML message to the StepServer System, and a Subscribing Client that acquires that XML message from the StepServer System. Of course there is no limit to the number of Clients, Messages, or Message types that can be exchanged by the STEP Technology.

A Publishing Client is a computer program that prepares and sends an XML message to the StepServer System using SOAP. SOAP is the Simple Object Access Protocol (SOAP) and is a W3C standard. A Subscribing Client is a computer program that acquires that XML message from the StepServer using SOAP also. The StepServer System is a cluster of computers, each running the StepServer software, and all together providing the server side features and services of the STEP Technology. The server side services(StepServer System) represents a component of the STEP Technology. From now on, when I use the word StepServer, I am not implying a single computer, but rather the system of computers, i.e the cluster of computers, that makes up the StepServer System.

This overview describes in details components of the STEP Technology, i.e the Step Clients and the StepServer(StepServer System). It will not describe how to assemble the XML messages(data) that are to be sent to the STEP Technology system or what to do with the XML messages(data) once they arrive to their final destination. It is assumed that this overview is to be read by programmers who are interested in using and/or extending the Step Technology.

Features of the STEP Technology

The STEP Technology is a Java based messaging system that is Multiplatform(multi Operating System(OS)), Scalable, Secure, Persistent, and Reliable.

Multiplatfrom: The Publishing Client, the Subscribing Client, as well as the StepServer software itself can be run on any operating system( Windows, Mac, Linux, Unix, IBM Mainframe, etc..) that supports the Java 2 Virtual Machine. Also the exchange protocol used( SOAP ) is an OS and Programming language neutral protocol.

Scalable: The STEP Technology StepServers are only limited by the throughput of the Hardware( Computers ) that they are running on, and if one StepServer gets saturated with incomming and outgoing messages past the capacity of the OS and/or hardware, another computer can be added to the Cluster of StepServers effectively doubling the capacity of the StepServer System. We have not placed any limit on the number of StepServers that can exist in the Cluster of StepServers.

Secure: The StepServer to Step Client transport layer was designed to handle multiple transport protocols. Currently, two of these protocols are implemented and are in use; the Hypertext transport protocol(Http), the Hypertext transport protocol over the Secure Socket Layer(Https), and SOAP (using an HTTP or HTTPS transport). Thus data transmitted between a remote Step Client and the StepServer can be encrypted as it travels through the Internet preventing an eavesdropper from seeing the content of this data.

Persistent: All Messages sent to the StepServer( Published to StepServer ) are persisted on a database server so as to prevent any loss of data caused by either power failure or hardware failure. As a matter of fact, when a publishing client sends a message to the StepServer, the StepServer will not acknowledge its receipt until it has verified that the message was persisted on its internal database.

Reliable: The STEP Technology has been designed from its inception to tolerate and survive errors without causing any loss of data, i.e loss of XML messages. The type of errors vary from electric power failure, connection failure, failure while messages are in transit, failure due to services temporarily un-available, errors caused by duplicate data, errors caused by XML messages that are not true form, and other errors.

A Step Client

A Step Client is a computer program that is written in any programming language( Java, Perl, C, Visual Basic, any .NET language, etc..) that supports SOAP. Additional support exists for toolkits supporting WSDL. A WSDL-enabled toolkit can generate a proxy to deserialize an incoming message to native objects or classes as well as serialize an outgoing message to XML. A Step Client allows CCAP partners to use SOAP in their Step Publishing or Step Subscribing Client programs so as to take care of all communication between these clients and the StepServer System. For simplicity, we call these publishing and or subscribing computer programs; Step Clients. Programmers who are writing Publishing and/or Subscribing client would only have to learn and use a simple Application Programming Interface(API) to send and receive messages back and forth to/from the StepServer. This simple API is made out of 6 methods defined in the WSDL located at http://soap.wicourts.gov/services/RemoteServerService?wsdl. In general, all of these method are grouped and thought of as being STEP requests. creating a session is a STEP request, deleting a message is another STEP request, and so on. Even though I will be providing a brief description of the 6 methods, the reader should realize that the authoritative information about the API is described in the WSDL at the location mentioned above. The following method descriptions use the XML Schema type definitions as they appear in the WSDL. The following namespaces are assumed to be defined: xmlns:s="http://www.w3.org/2001/XMLSchema" and xmlns:step="http://soap.interfaces.wicourts.gov"

s:string createSession( step:AuthenticationInfo authInfo): The Publishing Client and/or the Subscribing Client can use this method to open a session to the StepServer. This method returns a sessionId String object. This sessionId would be used in all subsequent communications with the StepServer. This method should be considered deprecated. The AuthenticationInfo type provides support for session-less authentication which is the preferred authentication. See the examples for more information.

deleteSession(s:string sessionId): The Publishing Client and/or the Subscribing Client can use this method to close a previously openend session with the StepServer. I suggest that the programmer who gets this exception, when calling closeSession(), should act as if the Session has been closed and go about the normal flow of his/her software. This method should be consider deprecated. The AuthenticationInfo type provides support for session-less authentication which is the method of authentication. See the examples for more information.

long send(step:AuthenticationInfo authInfo, step:Message message): The Publishing Client can use this method to send an XML message to the StepServer. The StepServer in response would return a unique server side( generated ) messageId. This is not to be confused with the clientMessageId which is a unique client generated message identifier.

step:Message peek(step:AuthenticationInfo authInfo, s:string queueName): The Subscribing Client can use this method to acquire a copy of the oldest XML Message waiting for it in its assigned queue without deleting this XML Message from that Queue on the StepServer. This method returns a Message object which can be null if the queue happens to be empty. The user of this method should test for null and react by sleeping for a certain period of time before peeking again. A suggested amount of time to sleep is not less than 60 seconds, and maybe between 5 to 10 minutes. This reduced the burden on our StepServer. For time critical applications, the time to sleep can be reduced.

delete( step:AuthenticationInfo authInfo, s:string queueName): The Subscribing Client can use this method to delete the oldest XML Message in its assigned queue. This after having had a chance to examine this XML Message by using the peek() method. It is expected that a Subscribing client would peek() first, acquire the data stored in the XML message, persist, use, or consume this piece of data on the Client Side, then issue a delete() to remove the message from its assigned queue on the StepServer.

deleteWithCriteria( step:AuthenticationInfo authInfo, s:string queueName, Array of step:NVPair searchCriteria): The Subscribing Client can use this method to deletes a message on a particular queue of the Step Server and that matches the given array of name/value pairs. This method is less safe than delete(). Be as it may, it is here for flexibility.

If you are using the Apache Axis SOAP toolkit, all of the preceding methods may throw a org.apache.axis.AxisFault (which in turn extends java.rmi.RemoteException). If you are using .NET, all of the preceding methods may throw either a System.Net.WebException or a System.Web.Services.Protocols.SoapException.

The Publishing Client

All publishing clients are expected to set up an account with the organization hosting the StepServer( CCAP in our case ). Then, with the help of the STEP Technology staff at CCAP, the publishing client should agree on a unique client name to be used for identification, the message type, and the document content( DTD Format ) of the XML message(s) to be sent to the StepServer. This is also know as the SOAP message payload in a SOAP world. In addition, the Name of the Remote Client( subscriber ) that will be receiving the XML message is also required. After getting a copy of the latest WSDL and converting it to classes that provide the API, a publishing client is expected to build an XML message, construct a Message object for this XML message, use the API to send the Message object(s) using send()( or a cycle of send() methods). This cycle can be repeated for as many messages as required by the publishing client. A publishing client can publish messages with as many message types as agreed upon with the organization hosting the StepServer( CCAP in our case ). Each publishing client can publish messages with different message types as long as the client destined to receive the message( the subscriber ) is setup to receive messages of this message type.

The Subscribing Client

All subscribing clients are expected to setup an account with the organization hosting the StepServer( CCAP in our case ). Then, with the help of the STEP Technology staff at CCAP, the subscribing client should agree on a unique client name to be used for identification, the message type, and the document content( DTD Format ) of the XML message(s) that are to be acquired from the StepServer. This DTD file is not necesseraly required by the StepServer, but could be useful to the subscribing client as a contract for the content of incoming XML messages. This is also know as the SOAP message payload in a SOAP world. After getting a copy of the latest WSDL and converting it to classes that provide the API, a subscribing client is expected to use the API to peek at the next available Message object available in his/her queue using peek() method, do whatever s/he desires with the content of this Message object, then using the messageId acquired from the Message object construct a request to delete this Message object from the StepServer using the deleteWithCriteria() method (see the RemoteClient class in any of the three examples, for the correct usage of this call). This cycle can be repeated for as many messages as are currently stored on the queue assigned for this subscribing client and with this particular message type. Each subscribing client can subscribe to messages with different message types as long as this client was previously setup to receive messages of this message type. If a subscribing client is setup to receive messages of different message type, s/he is in essence accessing different message queues on the StepServer, one for each ClientName/MessageType pairing.

The StepServer( StepServer System )

The StepServer is a component of the STEP Technology. While the StepServer is capable of being a single server side Java program that can be setup and run on a single computer, most of the time it is made up of a cluster of Java programs running on multiple computers.

The main role of the StepServer is to handle and process all STEP requests that arrive at its doorstep.

The Journey of a Message that is being sent to the StepServer(publishing to the StepServer)

The journey of an XML message that is to be sent to the StepServers from a hypothetical publishing client is described below. To give the reader a feel of the STEP Technology in a real production environment, the example below describes the journey of an XML message sent by a publishing client to CCAP's StepServer.

The journey starts by having the Publishing application fire an createSession() request to the WSDL generated API. This returns a sessionId object that can be used in the send() request. The send() method has 2 parameters the AuthenticationInfo object and the Message object. The Message object contains the XML message body as well as other pertinent information. The WSDL generated API marshalls the data into a STEP SOAP request and fires it against the specified StepServer. The StepServer handles the send() SOAP requests as described in a previous paragraph above and returns a response. The Publishing client can continue sending other messages using the same authententication information.

The Journey of a Message that is being acquired from the StepServer( subscribing from the StepServer)

The journey of an XML message that is to be acquired from CCAP by a hypothetical subscribing client is described below. To give the reader a feel of the STEP Technology in a real production environment, the example below describes the journey of an XML message acquired by a subscribing client from CCAP's StepServer.

The journey starts by having the Subscribing application fire a createSession() request to the WSDL generated API. The client passes authentication information to the peek() request. The peek() method has 2 parameters the AuthenticationInfo authInfo and a String representing the queueName. The authInfo object represents the previously acquired sessionId as well as the username and password. The WSDL generated API marshalls the data into a STEP request and fires it against the specified StepServer. The StepServer handles the peek() STEP requests as described in a previous paragraph above and returns a response. If the response is null then the queue is empty, otherwise a Message object is returned. If a valid Message object is returned, the subscribing client is expected to process, and consume the data in the Message object and then issue a delete() STEP request. This one gets handled by the same StepServer in a manner also described in a previous paragraph above. Again, If a null Message object is returned, the programmer should react by realizing that the queue is empty. If the queue is empty, the subscribing client should sleep for a certain period of time before peeking again. A suggested amount of time to sleep is not less than 60 seconds, and maybe between 5 to 10 minutes.

The subscribing client can continue firing peek() STEP requests, acquiring additional Message objects, followed by firing corresponding delete() STEP requests using the same authenticaiton information. This can go on until the queue becomes empty. The subscribing client should sleep for a certain period of time before peeking again as mentioned previously.

The StepServer Browser Based Web Application( the Human perspective ).

When we started implementing CCAP's STEP Technology, we realized that we needed a tool to soften the learning curve that our partners faced. We were motivated by the fact that Java, SOAP, Messaging Servers, and XML were not yet deployed and addopted by most of our partners, and thus, any support we would supply to ease the learning curve would be useful and appreciated. Our desire to soften the learning curve on our partner organization should not be construed to imply that the STEP Technology itself is difficult or hard to learn. We wanted to give our partners, those who will be using the WSDL generated API to build publishing and subscribing clients, a Visual tool that they can use in a manual fashion to open and close a Session to the StepServer. A tool to send messages, peek at them, and even delete them, and finally to give them a message count in their respective queue(s). Hence, the StepServer browser based web application.

Our StepServer also responds to manual querying using a web browser such as Netscape Navigator or Internet Explorer. A partner of CCAP can get a chance to give our STEP Technology a kick in the tire before writing a single line of code.

The following URL http://soap.wicourts.gov/index.html gives CCAP's Partners access to their queues on the StepServer. The image below shows the StepServer's Web Based Application that gives CCAP's partners a Visual View of their clients and queues as they reside on the StepServer. This is also very helpful for debugging when getting started on writing an inteface with CCAP. You can send() a message to the StepServer and watch it appear in the intended queue. Also you can visually confirm that a message exists on the StepServer before doing a peek() on it. The same is true with delete(), you can delete() a message using the WSDL generated SOAP API and confirm that it has been deleted.

By clicking your mouse on the "Step Server Admin" link you will get the following screen.

then click on the "connect" link, you will get the following screen.

Enter our testing User Name "example" and our testing password "testpass" then select "step0" for the Host then click on the "Connect" button. The StepServer will take you to the following screen:

For a starter, you can list the queues that the "example" user is allowed to access. So click on the "List Queues" link and you will get the following screen( or something similar based on the available queues and messages on particular queues).

Note that you have access to two queues, one is named "ExampleQueue" and the other is name "example-messageType". If a queue contains more than one message then you can "Browse" the list of messages and drill down and examine any one of them randomly. You can also "Peek" at the next available message on the queue. To "Delete" a message you need to browse the queue first then delete. Please note that there is no warnings for deletes, messages get deleted as soon as you click on the "Delete" link.

If you click on the "Peek" link, you get the following informative screen about the next message on that particular queue, we call it the "Message Details".

If you click on the "Browse" link you get the following screen. And if you click on any of the links for a particular row, you will get the Message Details shown in the image above.

In a nutshell, we have seen the images of the StepServer Web Based Application for the peek(), browse, delete(), list queues, and now we will examine the send() screen. If you click on the top-left portion of the above screen it will take you to the send() screen which looks as follows.

At a minimum, you need the following 5 fields completed before being able to send() a Message to the StepServer: 1) You need the "Destination" field for which we will choose the value of "ExampleQueue". 2) You also need the "Reply To" field for which we will choose "example-messageType". 3) You also need the "Body" field for which we will add "Hello world, I am alive...". 4) You also need to make sure that "Content Type" field matches the actual content of the text that we have placed inside the Body field. In this case, and considering that our message in not in XML, we will use "text/plain" for the Content Type field. Finally, 5) you need the Client Message Id which uniquely identifies a message from the perspective of the publishing client. The following screen is how the send() screen should look like just before hitting the "Send Message" button.

Here is another example of the send() screen where we send a valid XML message. Please note that the Content Type field contains "text/xml" and that the Body field contains a Valid Step Message in XML format. Also note that the XML Message uses a DTD for primary validation.

When the send() is successful( i.e after clicking the Send Message button), you get the following screen.

Programmatically, the send() method returns the Server Side Message Id, also known as Message Id. All of our StepClients( you the reader ) need to include a unique clientMessageId for each message to be sent to us. The clientMessageId is a number generated by you that is ascending, not necessarly contiguent, and that gets set in the Message object.

The 'clientMessageId' is an identifier that allows us to communicate with you about a certain message, or vice-versa, without having an inch of doubt about which message we are talking about. Also when we have problems with some of your messages for example, we can ask you to re-
send() messages that match a list of specified 'clientMessageId' numbers.

When the send() method completes successfully, it will return the 'messageId' which is not to be confursed with the 'clientMessageId'. The messageId is the server side unique message identifier. You may choose to persist and save the returned messageId or not. If I was in your shoes, I would elect to store and persist it on my database. You can relationally link your clientMessageId with the returned server side messageId. By having both the messgeId and the clientMessageId, we can be 100% sure that the message in question has been sent, and is humanly identifiable( we like using belts and suspenders if you will ).

Now we can go back and peek at the 2 messages that we sent() successfully by clicking the "List Queues" link and then the "Browse" link for the "ExampleQueue". Sure enough, towards the end( bottom of the listing - end of the queue ), you can see the following message list screen. Notice how the bottom row contains a newly created( fresh ) link that hasn't been accessed before. ( we should have seen 2 fresh links, but I had clicked on the link prior to last out of curiosity before capturing this screen -- sorry ! ).

Now if you click on the bottom most row, on the link with Message Id = 19956732, you will get the following message details screen which is the last message we sent to the StepServer. This is as expected in that our StepServer queue are First In First Out( FIFO ) and similarly Last In Last Out( LILO ), i.e it get placed at the bottom. Note the Peek link and the Delete link always work on the first Message( first row ) of the list.

Now if you go to the row before the last, on the link with Message Id = 19956722, you will get the following message details screen which is the "test/plain" message that we sent just before sending the XML message.

Now that we have seen from a human perspective what the StepServer is all about, let's look at the StepServer SOAP API. In other words we want to see how computer programs written by CCAP's external partners can talk to the StepServer using SOAP and the WSDL generated API.

The StepServer WSDL generated SOAP API( programmatical perspective ) -- The Step-Example project.

As mentioned before in this document, the current incarnation of our WSDL generated SOAP API is made out of 6 methods usually defined in the WSDL located at http://soap.wicourts.gov/services/RemoteServerService?wsdl. We have built a small example project that allows a programmer to get a feel of this API from within their preferred programming language.

Step-Example in Java
Step-ExampleAndAxisZip.zip

The Step-Example in Java is made out of 2 classes created by a human being( RemoteClient.java and STEPExample.java ) and 7 classes generated by a WSDL to Java tool. It also requires the Apache Axis Project jar files. The Step-ExampleAndAxisZip.zip file contains version 1.2.1 of the axis jar files. Together, the axis/lib *.jar files as well as the 9 classes mentioned before allow you to createSession(), deleteSession() and send(), peek(), delete() a Message to/from the StepServer using SOAP. Here is an image that describes our project configuration using the Eclipse Integrated Development Environment(IDE).

Please note that eventhough we list the 7 classes that are generated by WSDL to Java tool, it is not safe to assume that these classes are going to stay constant. It is always safer to use a WSDL to Java tool to re-generate them every now and then when you are programming/compiling your project. For your convenience, we have a zip file that contains the Axis-*.zip installation, the Step-Example project, and some additional lib/*.jar files( to be added to your classpath if you are using JDK 1.3). The complete zip file is only for convenience and you should always check on the latest news/bug fixes about the Apache Axis project from their web site listed above. The zip file that bundles everything is: Step-ExampleAndAxisZip.zip. Here is the content of this zip file:

Please note the 3 items inside the extracted zip file. If you are using JDK 1.2 or 1.3, then you need to include the xerces-2_0_1.jar ( Xerces XML Parser ) and the xml-apis.jar( W3C XML API ) in your classpath. Also for consistency you can extract the axis-1_1-src.zip to your C:\ drive and this will produce a C:\axis-1_1 folder, similar to our own setup. The Step-Example can be placed in the same folder as your other eclipse( or other IDE ) workspace projects.

From the above image( previous to last ), please note that we have defined a classpath variable AXIS_LIB that maps to C:\axis-1_1\lib\. It is not that important to do it that way though as long as all the axis *.jar file in the axis-1_1\lib directory are on the classpath. Note also that we have a README.txt file as well as build.xml and build.properties files that can be used with Ant to generate Java classes from WSDL, compile the Step-Example project then run it. The doc directory contains the javadoc files for the Step-Example human created classes( RemoteClient.java and STEPExample.java). The build folder contains the *.class files generated from compiling as well as a src directory that contains the WSLD generated *.java classes. When compiling the project, we want to compile the 2 human created classes as well as 7 WSDL computer generated classes. For the compile to succeed, we need to have as mentioned before all the axis-1_1\lib\*.jar files in the classpath. And again, if you are using JDK 1.2 or 1.3 in lieu of JDK 1.4, then add xerces*.jar and xml-apis.jar to the classpath. Voila, you are almost done.

By now you should be able to compile the project, and with the following System Properties( i.e properties passed on to the Java Virutal Machine(JVM) from the command line), you should be able to run Step-Example. Here are the JVM System Properties:

-Dexample.username=example
-Dexample.password=testpass
-Dexample.service.location=http://soap.wicourts.gov/services/RemoteServerService

Using the main() method from STEPExample, the output from running the Step-Example, is the following System.out log:

If you get something similar to the above image, then congratulation, you have successfully established communication with the StepServer using SOAP and successfully sent() a messsage, then peek()ed at it, and delete()ed it. The RemoteClient.java class is a wrapper for simplifying the API to the StepServer. The STEPExample.java class is where everything happens. Here is a quick code walkthrough of what is happening:

Everything revolves around the runExample() method. We first create a Message, then we get a feedback of the content of the Message using dumpMessage(), then we send() it to the StepServer, then we peek() at it, then if the peek() returned null, then we know that the Queue is empty. Otherwise, when peek() returns a Message object, we display it using dumpMessage() again, and then we delete() it. Voila !! No big whoop heh !!

A quick look at the createTestMessage() method( see image below ) shows that we just need to setup the Message object and configure it with the Destination Queue name, the Reply-to queue name, the Message Body, the Encoding, the Priority, and the Content Type, and an agreed upon type code if at all. Please note that the Message.setClientMessageId() is required where as Message.setExpiration() is not and could be dangerous if the subscriber( receiving end of your messages) doesn't get to it fast enough. So please coordinate with the subscribing agency about setting expirations for messages.

For JDK 1.2, and 1.3 I noticed that the forDisplay() method used in the dumpMessage() method was causing some exceptions, so for now, I want to ask those of you using JDK 1.2, or 1.3 to comment out 3 lines( green lines ) of time related fields as shown below.

Voila... We are done.

Step-Example in .NET (C# and Visual Basic .NET)

Click Here to download STEP server examples using .NET technology. Both examples were developed using Visual Studio 2002. Opening them in Visual Studio 2003 will automatically convert the projects.

If you are using Visual Basic, navigate to the stepexamples/vb/STEPServerExampleVB directory and double-click on the STEPServerExampleVB Visual Basic project. If you are using C#, navigate to the stepexamples/csharp/STEPServerExample and double-click on the STEPServerExample C# project. The following paragraph applies to both the Visual Basic and C# examples.

Simply go to the Debug menu and then Start (or hit F5) to see the example in action. If you have been provided with a different username, password, or service location, open the Example.vb or Example.cs file and change the constants at the beginning of the Example class to the values you were provided. The RunExample method in the Example class (Example.vb or Example.cs) contains the meat of the example. You will use similar code when you are writing your production application. Note however, that any SOAP call may throw a WebException or a SoapException. You should always handle those two exceptions in production code (perhaps by pausing for a minute or two and retrying the request). The .NET examples use a Web Reference to communicate with the Web service. If you wish to update your Web Reference, browse to the Solution Explorer, expand the Web References tab, right-click on the STEPServer item and choose Update Web Reference. If you are using an alternate service URL, you may need to update the Web Reference URL property which appears in the Properties view below the Solution Explorer (assuming you have not customized your Visual Studio workspace).

Transaction Semantics and Random Access Isssues on our StepServer.

A concern that many of our partners had relates to transaction semantics. The concern is that an agency needs a guarantee to ensure that a message is grabbed and is committed to its database before it is deleted off of StepServer. Well, the current StepServer system satisfies ALL the Transaction concerns of the IJIS subcommittee on Standard Technical Transport Mechanism, eventhough we could NOT verbalize this during that meeting. We feel that we didn't have a chance to take the time and explain things as we should and hence we are doing it in the following pragraph. We hope that other agencies would take a look at the Step Technology as it is currently implemented in production.

Let's look at 2 scenarios: 1) Receiving a Message From the StepServer, and 2) sending a Message to the StepServer. With respect to item 1), the CURRENT implementation of the StepServer forces a subscriber interested in receiving a message from the StepServer, to FIRST issue a peek() request and acquire a copy of the message locally, then persist that message on his/her local database, THEN issue a delete() request to delete it. As you can see there is no room for transaction error here. Only when the subscriber has validated that the message has been persisted on his/her local database, should s/he issue the delete() request. The subscriber is NOT limited to one request of peek(), s/he can peek at the same message for as long as s/he wants to. As you can see, there is no Transaction Semantics gap here.

With respect to item
2) i.e sending a message to the StepServer; the CURRENT implementation of the StepServer forces a publisher interested in sending a message, to compose the XML message by acquiring the data from his/her database, then issuing a send() request to the StepServer. The send() request is a BLOCKING request, in that it won't return until it succeeds or fails, which would imply either success or failure, the publisher can then mark the data in their database as DELIVERED or NOT_DELIVERED, respectively. The StepServer was designed to deal with the remote possibility that there was a connection failure in the middle of the send() request( i.e after the message has been persisted on the StepServer but before an acknowledgement is received by the client), and that the publishing client does NOT know whether the message was received or not by the StepServer. In this case, i.e when the time comes for the same publishing client to send() the same message again, the StepServer would accept the same message, eventhough it is being sent twice, and would prevent the duplication of that message. The StepServer, when faced with the same message from the same client, would acknowledge its receipt, but does not duplicate that message. This is a design feature of the StepServer from day one( June 1999 ).

With respect to the StepServer Queues, giving a client organization RANDOM access to its messages in its queue(s) instead of the current SEQUENTIAL access represents a design choice that CCAP wanted to stay away from. This is because if you allow a client organization to pick and choose messages, then where is the incentive for that organization to delete messages in its queue(s)?? The StepServer queues would become Data Warehouses rather than the intended Temporary Transit Facilities that they are. For example: a client that can access at random the 3rd message in a Queue of 6 messages would not be motivated to delete it or delete any message for that purpose. This, rather than proceeding with the first message, processing it, then deleting it, then processing the second message, then deleting it, then arriving at the third message, then deleting it, and so forth.

Another Important aspect is that Queues and messages that they contain are sequential and are intended to be that way by design. For example information about a certain Court Case can be updated(edited) in the morning and that would trigger a StepServer message by the publishing organization. Later on in the afternoon of the same day, that same Court Case gets updated again, so we want you to receive the new updated( Latest ) message after receiving and applying the previous update. And hence the IMPORTANCE of the sequential manner in which queues are accessed. From a philosophical design aspect, sequential access to Message queues is a desirable feature because it enforces a certain level of responsibility and accountability by the subscribing organization. In other words, if an organization wants to receive data in a publish/subscribe manner, it is not unreasonable to ask that organization to acquire the data and store it on its own database, and then have the luxury of accessing it in a RANDOM access manner. If an organization still feels that RANDOM access to message queues( or to Data in general ) is needed, then may be the publish/subscribe model is not the appropriate choice for that organization. A better choice would be a request/response( a.k.a query/response ) method of acquiring the data. Some of our partners have chosen this Random Access method of accessing our data by using our Wisconsin Circuit Court Access(
WCCA) application http://wcca.wicourts.gov. Also similar to Step, the WCCA has a SOAP component described in http://wcca.wicourts.gov/soap.xsl