Feb 28

This Quick Note discusses a solution to the use case provided by Marcus Davies.

I am trying to read HL7 from JMS (preferably stcms) and populate an outbound XML data structure (different to the XML generated by the decoder).
I have been thinking of doing one of the following […]:
1.    Use a Concrete JMS WS using the HL7 encoders to unmarshal the HL7 and use JAXB to populate the outbound XML.  Unfortunately this does not appear to connect to the stcms queue as I can not see any receivers
2.    Use a JCA MDB to read from the stcms JMS queue – this works but I don’t think I can use the HL7 encoder like this
3.    Use and MDB to read from JMS, manually unmarshal the HL7 and use JAXB to populate the data structure
Ideally I would like to use the HL7 encoders.  Do you think the first approach should work?

Number 1 will not work as at end of February 2009 because the JMS BC does not properly decode the HL7 delimited message. This is a know issue. I don’t know what the status of this is. The only BCs that know how to deal with HL7 delimited, that I know of, are the File BC and the HL7 BC.

Number 2 should work. I did not personally try it. You can invoke an encoder library from Java. Have a look at http://wiki.open-esb.java.net/Wiki.jsp?page=UseEncodersInJavaSE.

Number 3 should work but it will be very laborious.

I have a Number 4, which uses a HL7 OTD and a custom XSD-based OTD in a JCA EJB. You may or may not like it but it’s the best thing to do if you can not use BPEL 2.0 to do the mapping and you don’t want to build a repository-based solution (which would be the best for your case anyway).

The solution involves the use of:
1.    HL7 2.3.1 OTD Library (Java CAPS 6 Repository)
2.    JMS JCA to trigger a MDB with a HL7 Delimited message
3.    JMS JCA to write result message out
4.    JCA MDB to do the processing
5.    OTDImporter to provide HL7 2.3.1 OTD and custom XSD-based OTD to the EJB for “convenient” mapping

Brief steps to implement this solution are given in Quick Note 002 at QuickNote002_For_Marcus_Davies.pdf. Archive containing project exports and sample data is provided at QuickNote002.zip. The code will work in Java CAPS 6 Update 1.

Tagged with:
Feb 27

This Quick Note discusses a solution to the use case provided by Richard Kuiter.

An input file contains the following records:

H100000000000014099120ASN00507
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
L1140991200000008261850826185738
H100000000000014099126ASN00531
L1140991260000008262690826269662
L1140991260000008262690826269662
L1140991260000008262690826269662
L1140991260000008262690826269662
L1140991260000008262690826269662

It is required that each block of records starting with the H1 (header) record and containing all the following L1 (line) records, be written to a different file.

The solution involves the use of:
1.    Batch Inbound eWay to locate the input file and provide its name and location to a Java Collaboration Definition
2.    Batch Local File eWay to provide an Input Stream to the Batch Record eWay
3.    Batch Record eWay to break up the input stream into records delimited by carriage return+new line
4.    Batch Local File eWay to write each block of records to a file with a distinct name

Brief steps to implement this solution are given in the full Quick Note as QuickNote_001. The collaboration code will work in Java CAPS 5 and 6 Repository.

Feb 23

Securing web services, to be invoked over the Internet, is both essential and difficult. Using appropriate tools and technologies makes it easier to accomplish the task. Developer-dependent solution, where security is embedded directly into consumers and providers, is inflexible and labour-intensive. Gateway-based solutions are more flexible, more dynamic and easier to manage. In this note Java CAPS 6-based web service consumer and provider pair are developed. The solutions are exercised first without, then with the web services security gateway. This enables demonstration of how web services can be secured, how policies can be developed and propagated and how WS-Security-mandated XML markup can be dealt with outside the development shop. The Layer 7 SecureSpan XML Gateway, and its oft forgotten companion, the SecureSpan VPN Client, are used to explore the topic. The reader should be able to acquire enough knowledge to obtain and deploy the SecureSpan XML Gateway, and to use its basic functionality to implement gateway-mediated secure web services solutions.

The full text of this Note is available from: WS-Security_for_Java_CAPS_the_Gateway_Way_1.0.pdf

Feb 14

If we overlook the fact that using web services to transfer large payloads is a very stupid idea, we will be faced with the need to implement the optimisation mechanisms to make transfer of large payloads using web services a little less inefficient from the stand point of the size of the over-the-wire data to be transferred. The standardised, supported mechanism for this is the Message Transmission Optimisation Method (MTOM), http://en.wikipedia.org/wiki/MTOM. Java CAPS Repository-based Web Services don’t offer a convenient mechanism to provide MTOM support.

This note walks through the implementation of a Java CAPS Repository-based, eInsight-based web service consumer and the implementation of the EJB-based Web Service Wrapper Consumer for this service, which provides support for MTOM. The Note discusses how to exercise the wrapper service using the NetBeans web services testing facilities, how to trigger the Java CAPS Repository-based web service invoker and how to observe on-the-wire message exchanges. The invoker implementations discussed in this Note will invoke the web service providers discussed in an earlier Note, “Java CAPS – Exposing MTOM-capable Java CAPS Classic Web Service”, http://blogs.sun.com/javacapsfieldtech/entry/java_caps_exposing_mtom_capable.

The note is available as Invoking_MTOM-WS_using_Java_CAPS_Classic.pdf

Tagged with:
Feb 12

If we overlook the fact that using web services to transfer large payloads is a very stupid idea, we will be faced with the need to implement the optimisation mechanisms to make transfer of large payloads using web services a little less inefficient from the stand point of the size of the over-the-wire data to be transferred.

The standardised, supported mechanism for this is the Message Transmission Optimisation Method (MTOM), http://en.wikipedia.org/wiki/MTOM. Java CAPS Repository-based Web Services don’t offer a convenient mechanism to provide MTOM support.

This note walks through the implementation of a Java CAPS Repository-based, eInsight-based web service and the implementation of the EJB-based Web Service Wrapper for this service, which provides support for MTOM. The Note discusses how to exercise the services using the NetBeans web services testing facilities and how to observe on-the-wire message exchanges.

The note is available as Exposing_MTOM-capable_Java_CAPS_Classic_Web_Service.pdf

Tagged with:
preload preload preload