Tag Archives: Java CAPS

GlassFish ESB v2.1, Web Space Server 10 – Creating a Patient Lookup Visual Web JSF Portlet

In some views SOA is represented as a series of 4 layers: Presentation Layer (SOA 1), Business Process Layer (SOA 2), Business Service Layer (SOA 3) and Technical Layer (SOA 4). Typically each layer higher up in the hierarchy consumes services exposed by the layer under it. So the Presentation Layer would consume services provided by the Business Process or Business Service Layers. Service interfaces are described using Web Services Description Language (WSDL), sheltering service consumers from details of service implementation. Web Services are seen as the technical means to implement the decoupled functional layers in a SOA development. Decoupling allows implementations of business functionality at different layers to be swapped in and out without disturbing other layers in the stack. The SOA 1, Presentation Layer, is often implemented as JSR-168-compliant or JSR-286-complaint Portlets, exposed through a standards-based Portal.

The business idea behind the functionality developed in this walkthrough is that patients are looked after in various healthcare facilities. Healthcare workers need to lookup patient details such as their identifier, gender, birth date or address. A relational database holds patient details as well as other information of relevance such as descriptions of various coded values. Patient details are available through a web service. Facility list and details, used to narrow down the search for patients to a specific facility,  are available through a web service. These web services will be used to construct the Portlet that will allow patient search and a display of patient details. This Portlet will be deployed to the Sun FOSS Web Space Server 10 Portal.

Previous documents in this series, see pre-requisites, walked the reader through the process of implementing GlassFish ESB v2.1-based web services which return facility list and facility details as well as patient details.

In this document I will walk through the process of developing a JSR-286-compliant Visual Web JSF Portlet, deployed to the Sun Web Space Server 10 Portal, which will use these Web Service as a data providers. We will use the NetBeans 6.5.1 IDE, which comes as part of the GlassFish ESB v2.1 installation, the Portal Pack 3.0.1 NetBeans Plugin and the JSF Portal Bridge infrastructure provided by the Web Space Server 10. The Portlet will be implemented as a Visual Web JavaServer Faces Portlet using JSF components provided by Project Woodstock.

Note that this document is not a tutorial on JavaServer Faces, Visual Web JSF, Project Woodstock components or Portlet development. Note also that all the components and technologies used are either distributed as part of the NetBeans 6.5, as part of the GalssFish ESB v2.1, as part of the Web Space Server 10 or are readily pluggable into the NetBeans IDE. All are free and open source

The walkthrough document is here: 02_PatientLookup_VWJSFPortlet.pdf
The project archive is here: PatientLookupVWJSFP.zip

NetBeans 6.5.1, GlassFish v 2.1, Web Space Server 10 – Creating a Healthcare Facility JSR286-compliant Portlet

In some views SOA is represented as a series of 4 layers: Presentation Layer (SOA 1), Business Process Layer (SOA 2), Business Service Layer (SOA 3) and Technical Layer (SOA 4). Typically each layer higher up in the hierarchy consumes services exposed by the layer under it. So the Presentation Layer would consume services provided by the Business Process or Business Service Layers. Service interfaces are described using Web Services Description Language (WSDL), sheltering service consumers from details of service implementation. Web Services are seen as the technical means to implement the decoupled functional layers in a SOA development. Decoupling allows implementations of business functionality at different layers to be swapped in and out without disturbing other layers in the stack. The SOA 1, Presentation Layer, is often implemented as JSR-168-compliant or JSR-286-complaint Portlets, exposed through a standards-based Portal.

The business idea is that patients are looked after in various healthcare facilities. Applications need to allow selection of a facility and to access facility details for display to human operators. A relational holds details of facilities which are a part of the healthcare enterprise. Facility list and details are available through a web service. This web service will be used to construct the JSR-286-comliant Portlet that provides a user view into the facilities and facility details. This Portlet will be deployed to the Sun FOSS Web Space Server 10 Portal.

Previous documents in this series, “GlassFish ESB v 2.1   Creating a Healthcare Facility Web Service Provider” and “NetBeans 6.5.1 and GlassFish v 2.1 – Creating a Healthcare Facility Visual Web Application”, walked the reader through the process of implementing a GlassFish ESB v2.1-based web service which returns facility list and facility details, and a Visual Web JSF Web Application which used that Web Service to display facility list and details.
In this document I will walk through the process of developing a JSR-286-compliant Visual Web JSF Portlet, deployed to the Sun Web Space Server 10 Portal, which will use the Web Service as a data provider. We will use the NetBeans 6.5.1 IDE, which comes as part of the GlassFish ESB v2.1 installation, the Portal Pack 3.0.1 NetBeans Plugin and the JSF Portal Bridge infrastructure provided by the Web Space Server 10. The Portlet will be implemented as a Visual Web JavaServer Faces Portlet using JSF components provided by Project Woodstock. The Portlet will introduce the technology in a practical manner and will show how a web service can be used as a data provider, decoupling the web application from the data stores and specifics of data provision.

Note that this document is not a tutorial on JavaServer Faces, Visual Web JSF, Project Woodstock components or Portlet development. Note also that all the components and technologies used are either distributed as part of the NetBeans 6.5, as part of the GalssFish ESB v2.1, as part of the Web Space Server 10 or are readily pluggable into the NetBeans IDE. All are free and open source.

Here is the document: 01_FacilityService_WebSpacePortlet.pdf

Right tools for the job? – Interesting discoveries when processing large volume of data

Just now I had an occasion to work with an integration solution intended to process lots of records. By lots I mean over 1 million smallish records. My customary platform to experiment on is Windows XP. Lots of reasons for that, most of them historical – I have tools I know and like and so on. While trying to work with such a volume of data I noticed a number of “interesting” things, which I thought I should share. These things are related to both the platforms (Windows vs. Linux), the tools and the architectural decisions.

I needed lots off data to test the solution I was contemplating, which involved XML processing, to see how constructing and parsing XML affects solution performance. To make it easier to compare timing differences I though I should use lots of records.

The discoveries are discussed in Right tools for the job.pdf.

Getting Hundreds of Files using Batch Local File eWay in Java CAPS 6

Occasionally one needs to pick up and process a large number of files, on the order of hundreds or thousands. With the Batch Inbound eWay/JCA Adapter it is not possible to pick up more then one file per poll. The Batch Local File, if triggered by some event other then an appearance of a file in a directory, perhaps a Scheduler trigger or a manual trigger, with correctly designed logic, can process many files in a single invocation.

The document, ProcessingHundredsOfFileWithBatchAdapter.pdf, discusses how Batch Local File-based solution can be constructed to effectively process hundreds of files in a single pass.

This article references a ZIP archive “ProcessingHundredsOfFileWithBatchAdapter.zip“.

Sending Secure Electronic Mail (S/MIME) in Java (CAPS) the Easy Way

Every now and then one needs to secure communications between parties. Some would say it is necessary to do that all the time and perhaps it is. The issues are the complexity and expense. The complexity comes from having to configure a bunch of tools to support things like encryption and digital signatures for more then a single party. The expense comes from typically having to purchase cryptographic instruments from well known Certification Authorities, and keep on purchasing them all over again every 1 or 2 years. This discussion introduces a class library that offers a set of simple methods for constructing and sending secure electronic mail using the Secure Multipurpose Internet Mail Extensions (S/MIME), the Bounce Castle Cryptographic Libraries and the Java programming language. The intent is to allow a Java CAPS developer, or a Java developer, to add Secure Electronic Mail functionality quickly and easily, and without having to make too much of a time investment learning about PKI-based security and related matters. This addresses the complexity issue. The expense issue is addressed in my Blog Entry, “Producing Free, Private X.509 Certificates for use with PKI-based Solutions”, at http://blogs.sun.com/javacapsfieldtech/entry/producing_free_private_x_509. That blog discusses how to roll out a private Certification Authority and obtain X.509 Certificates., and other cryptographic objects, for free.

This document discusses the use of cryptographic software and manipulation of cryptographic objects. Using or discussing cryptography software is illegal in some parts of the world. It is you responsibility to ensure that you comply with any import/export and use laws that apply to you.

SendingSecureEMailUsingJavaCAPS.pdf

The ZIP archive, referenced in the document, is SecMail_and_extra_libs.zip

Reference is also made to the article “Producing Free, Private X.509 Certificates for use with PKI-based Solutions”.

Java CAPS Quick Note 002 – JCA Transform HL7 Delimited to Custom XML

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.

Java CAPS Quick Note 001 – Split file into multiple files

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.

Java CAPS 6 – Providing Policy-driven Web Services Security support using a XML Security Gateway

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

Java CAPS 6 Update 1 – Invoking MTOM Web Service using Java CAPS Classic Web Service Client

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

Java CAPS – Exposing MTOM-capable Java CAPS Classic Web Service

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