This Demo Track illustrates 4 new Features.
The second feature is a
Polling client that issues regular
Web Service Requests
to the Post Office on a Topic asking to be sent any updates on the topic received by the Post Office since the
last request by this
Client Subscriber on this specific Topic. Any Delta files with new data are returned in the
Web Service Response as
SOAP Messages with Attachments
. The third feature
XSLT Processing that converts the raw XML used on the sender side of
the connection to HTML according to a Translation Template meeting the markup needs of this individual
subscriber. The last new thing in the demo is Logging Features of this framework. In the absence
of actual DataBase transactions that cover movement of distributed data, logging is very important
in maintaining the reliability of this framework.
Due to the constraints of the Demo and to restrictions on the scope of the software install, the topics and the subscriptions that you create with the demo Forms will not persist in a DataBase. Rather, each form submission binds the entities ( Topic, Subscription ) to your Session. For as long as your session lasts ( about 20 minutes ) you may run command line demos that trigger data interface activity on your new Topic and Subscription.
The First form binds a Topic to your session. One text field needs to be completed on the left of this
Enter a name for your topic.
When you have filled it in use the
submit topic button.
The URL for the real form is
The webapp requires authentication, so on a challenge, use the following for credentials:
successful creation of any
subscription is mirrored by a specific ChannelData Command (CDC) and that it's the
that actually gets connections and moves data. Whenever a
Publish Event occurs on your new topic, the Post Office dispatchs the
Channel Data Command as an
Event Handler to transfer data.
As in the Track 2 Demo, submission of the second form binds a Subscription to the session
only this time you complete 5 fields on the right hand side of this
form. Note that this demo and it's use
Polling as a Client Pull as opposed to a
Push by the Post Office Server, mean that only the
field is really important. However, the demo requires that they all be filled in.
Set Server IP Value to any valid IP Address where there exists an FTP daemon
for which you posess valid Credentials. As an example, you may use the
IP="184.108.40.206" for server, and the values
"yourmail@myIsp.com" for credentials.
Anything can be supplied for
File Name because this property is not used.
polling in the Protocol field.
A Calendar and Time chooser dialog operate along with the
Begin Time Select Log Records in the lower left and also operate with
End Time Select Log Records in the lower right. For
the purposes of the demo it is important that you select
values for a dateTime that is
older than CURRENT_DateTime. Similarly,
END values that you select should define a date
that is in the Future.
Successful submission of the form creates a CDC and returns it to the browser in this
Download this file remembering to save it to the
data/outbnd directory under the root where you did the
Your save as dialog should preserve the name of the downloaded file as this will
appear in a command line argument later on when you start up the
Web Services Polling Client.
This is the file that is
later in the demo.
This is a Client program that is to be run by Subscribers wanting control over the timeing
and processing which PULLS data to them rather than waiting for the normal Post Office
Distribution threads to PUSH the data. Since this client app. is a Console, Running things is a 2-step process. First you have to
Start the Console and it will come up with a prompt at which you must then enter
Get a command shell on your system and enter the command line below, adjust it to
the path requirements of your system, remembering Windows conventions require all the information
on a single line and with a "\" as the path separator.
Refer to help with
bin/b2bpoll data.topic.action=subscribe util.timer.poll.period=15000 file.io.output.rpc.attachment=testXsl data.source.filename= util.template.xsl=e:\po_1_2\sanchez_CSR_htm.xsl file.io.output.ctr.attachment=4 data.topic.name=yourtopic data.source.filesize.filter=120000
On launch, demo debug settings dump the entire properties list before the prompt is listed.
At the prompt line with the ">" below: type
and then press enter
-- listing properties -- file.io.buffer.length=1024 soap.rpc.methodname.polltopic=getFile data.source.filesize.filter=120000 data.topic.name=test2 util.timer.poll.period=15000 wsdl.service.addr.port.name=urn:EchoAttachmentsService ws.invocation.typ=soapconnparms data.source.filename=tm1102a.txt util.timer.poll.delay=15000 util.template.xsl=e:\po_1_2\sanchez_CSR_htm.xsl data.source.regex= rename.session.id.disp.from=0 data.topic.action=subscribe file.io.output.rpc.attachment=testXsl data.source.sourcedirectory=E:\po_1_2 wsdl.service.addr.axis.webapp=axis/services soap.rpc.methodname.attachment=getFile rename.session.id.disp.to=15 data.source.lastfile= file.io.output.ctr.attachment=4 wsdl.service.addr.host=http://localhost:80 Console deamon has started >
... Console deamon has started - use < start > and < stop > commands to proceed > start
... Console deamon has started > start > Clientcntrllr running callbacks on --TopicClient-- > TopicClient time is Wed Jan 07 16:52:52 PST 2004
The client starts cycling itself depending on the value you entered for the property
util.timer.poll.period. The values listed above will issue
a Web Service Call every 15 seconds that routes to the Post Office, requesting any updates
test2 TopicName. Asynchronously, any authorized publisher of the
test2 topic may be publishing to the Post Office. Then, for this specific subscriber, no more
than 15 seconds will elapse prior to the Poller issuing the next Call request for updates to
the Post Office. Any delta information will be returned in the Request Object.
Go to the Upload Servlet using the file chooser to open
the file prior to submit. Remember that in the demo, you must have completed the
step mentioned above. The
Submit Query button sends your XML data up to the
Post Office where it gets Queued to the Distribution Thread responsible for the Topic on which
you uploaded the data. In this specific case, because there are no active Subscriber Threads
handling your topicname, the Post Office dispatches
NO WORK to PUSH DATA
to any Subscriber. However, other client initiated activity will quickly result in your recently uploaded
Arrival of data on the Post Office, the result of the manual upload step, does not result in any
Synchronous distribution process. The Post Office does not work this way. The
Upload Unit of Work terminates with the upload files write copy on the File System of the
Post Office. A
TimeStamp attribute is associated with
that write. Another important TimeStamp is the
lastfile value in the
Channel Data Command. A CDC exists for each
subscription and, at the moment of the upload, the CDC for the Polling client reflects the fact
that the file just uploaded has not been received yet as a result of a Web
Service call requesting the new files on the topic. Specifically, lastfiles
value in the CDC is less than the uploaded file's TimeStamp.
As mentioned at the bottom of the
above, no more than 15 seconds will elapse between the reciept by the Post Office of the uploaded
file on this topic and the new Polling request on the topic. Each file that has not been received
by the polling client is added as an
SOAP Response Message and sent back to the client.
Activities on the local file system of the polling client are guided by some of the command line args used in the run command. Once received back on the client each Attachment Part from the SOAP Response is going to be written to the file system after constructing the proper name for the file.
testXsl4.htmlwill be the first file. Serialization will use the
number 5in the next file name and so on... If more than one uploaded file were to have been received by the Post Office in the interval since the Client's last polling request , then all such files would become AttachmentParts within the Response marshalled by the PostOffice. The CDC's lastfile value, updated on the server to reflect the state of the last set of transmitted data, equals the TimeStamp of the youngest file in the set sent to the client. Next time a polling request arrives on the topic, it will be this TimeStamp value that is compared to those belonging to the PostOffice's collection of files on this topic. If nothing new arrived, then the next Request will result in a Response with no attachments.
In this case the file published to the Post Office via
contained XML. However, the Subscriber preferred
HTML Format. These 2 links comprise the input and output sides of
a Transformation process occuring on the client after the Post Office returned the SOAP message
Response. Details of the conversion are guided by the collections of expressions in the
The command line argument used to convey this
information is actually the
template.xslproperty whose full command line value in
this demo is
for details on command line for starting the console.
Distributed messaging, a core feature responsible for reliable distribution of data,
goes hand in hand with Logging Features of this framework. Since there are no DataBase
transactions here, logging is very important to assure the proper completion of distributed work.
Messages like SOAP messages are often the
containers of data and files that are transiting amoung B2B partnering companies. In order to assure
proper diagnostics and sufficient troubleshooting capabilities, extensive and easily tweaked logging
is a component of every Java Class in the framework. In the section above, the HTML
link gives an idea of some of the
Message Archive Reporting Features
available from the Post Office based Logging Portal.
The portal combines organized archives of message activity with archive viewing tools like Chainsaw. Archive Drilldowns provide detailed history's at the session level or on the Messaging Topic level of information A standard manifest at the message level allows drilldown on the content of individual messages, in this case SOAP Envelopes and their contents.
Due to the number of Protocols that are implemented,
absolute consistency of logging across all implementations is not possible. Some Protocols like GridFTP
offer less frequent logging due to the fact that 3rd party open source is being used and that none of
the included classes were altered with respect to logging. Regardless of the protocol, when a CDC issues
a command to move a file on the connection, there is always a Return Code and a Success/Failure notice.
For example, the subscriber polling from this demo and the event driven Publisher from Track 2 demo use
Web Services , SOAP , and due to the present Post Office architecture that relies on JAX-RPC calls to layer the
messaging middleware onto a
Services oriented API where there is
no native SOAP code, the SOAP MEP is
synchronous. You are guaranteed a Response or a Failure code. There is no wait to match up an ASYNC response.
Details on the portion of the SOAP Spec invoked in collaboration with JAX-RPC are
here.The list below
gives a general idea of when logs are taken during processing:
get and putlevel are a function of the Globus Software package and the config settings used to launch the FTP daemon. The question of how to resolve these 3rd party logs with the reporting requirements of this framework are TBD.