Jul 21

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 with display a Google Map, centered at patient’s address, if one is available and is valid for the purpose of mapping. This Portlet will be deployed to the Sun FOSS Web Space Server 10 Portal.

The previous blog entry walked through development and deployment of the basic Patient Lookup Portlet. In this document I add a basic Google Map to the Patient Lookup Portlet.

Other blog entries in this series 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.

Note that this walkthrough builds on the Patient Lookup Portlet, built previously, but deals exclusively with Visual Web JSF portlet-related technologies, Java Script and Google Maps API.

The walkthrough document is here: 02_PatienLookup_VWJSFPortletGooMapBasic.pdf

The project archive is here: PatientLookupGooMapBasicVWJSFP_companion_archive.zip

Jul 19

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

Jul 05

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.

In this document I will implement a multi-operation Web Service that will allow patient information to be upserted into a database table and will return all patient details for a patient whose Facility+Local ID are specified in the request. This service will be used to populate the patient table and to implement patient lookup portlets, discussed in other writeups in this series. This is a basic Patient Service that hides the specifics of interaction with the patient data store form applications that need to interact with it, by providing a defined interface and web service-based implementation. Thus the data store may change but the service consumers need not. We use the Database BC with select, insert and update operations and Database BC with SQL File-based parameterized SQL prepared statement. We handle null value insertion on missing data. We also use the SOAP/HTTP BC and the BPEL SE.
The business idea is that patients are looked after in various healthcare facilities. Information about patients is stored in a relational database. This information must be inserted, for new patients, and updated, for existing patients, as required. Frequently applications need to search for a patient and display details to human operators. To shelter application developers from the details of the data store the upsert functionality and patient details lookup functionality will be made available as a multi-operation web service.

Walkthrough Document: 02_PatientSvc_GFESBv21.pdf
Companion Archive: 02_PatientSvc_companion_archive.zip

Jul 02

“Progress” notwithstanding, Healthcare environments still extensively use the HL7 v2.x Delimited messages for conveyance of patient and patient-related information between applications. The GlassFish ESB provides support for HL7 v2.x messaging in the form of the HL7 Encoder, which allows conversion between HL7 v2 Delimited and HL7 v2 XML message formats, and in the form of the HL7 Binding Component, which allow connectivity between the GlassFish ESB-based healthcare solutions and healthcare applications that support HL7 over TCP connectivity.

In this document I will walk through the process of generating HL7 v2.3.1 delimited messages from pipe-delimited records containing patient information, sending and receiving HL7 v2.3.1 delimited messages using the HL7 Binding Component, parsing HL7 v2.3.1 delimited messages and writing HL7 v2 delimited messages to a file. To create and process HL7 messages I show how create a custom ADT A04 XML Schema and a custom “any HL7 v2 message” XML Schema. This gives me an opportunity to use the File Binding Component (File BC), the HL7 BC, the HL7 Encoder, the Custom Encoder and the BPEL Service Engine (BPEL SE). This also gives me an opportunity to demonstrate a HL7 v2.3.1 delimited message sender solution and to demonstrate a HL7 v2.3.1 delimited message receiver solution. At the end of the process we will have a file containing HL7 v2 delimited ADT A04 messages, which we will use in related writeups.

Here is the document: 02_PatientSvc_MakeHL7v2DelimDataFromCustomDelimRecords_0.4.pdf

Here is the companion archive containing input files, the output file and the projects: 02_PatientSvc_MakeHL7v2DelimDataFromCustomDelimRecords_data.zip

The writeup document has been updated and version changed to 0.4.

Jun 27

The Portlet developed in the previous blog gives plain facility details. A richer Portlet could use the facility address to show the facility location on a Map.

Here I will walk through development of a Visual Web JSF Mashup Portlet, which will use a Web Service as a data provider to get facility details and a Google Maps REST Service to get the Google map displaying facility location. I use the NetBeans 6.5.1 IDE, part of the GlassFish ESB v2.1 installation, the Portal Pack 3.0.1 NetBeans Plugin and the JSF Portal Bridge provided by the Web Space Server 10. The Portlet will use JSF components provided by Project Woodstock. The Google Map service is integrated into NetBeans IDE. Technologies will be introduced in a practical manner.

It took me some effort to work out how to add a Google Map to a Portlet so I though I will share the experience.

This is not a tutorial on JavaServer Faces, Visual Web JSF, Project Woodstock, Portlet development or Google Maps usage.

Here is the document: 01_FacilityService_WebSpacePortletWithGoogleMap.pdf

Here is an archive containing all the projects developed in this and the last 3 blog entries: 01_FacilityService_all_project.zip

As provided, the ui_facility table has a bunch of addresses which are fairly silly and will never get a proper map. This MySQL script has a bunch of SQL update statements to replace these addresses with real addresses that are mappable.

Jun 24

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

Jun 23

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 business idea is that patients are looked after in various healthcare facilities. Frequently applications need to allow selection of a facility and to access facility details for display to human operators. A relational database is used to hold the details of facilities which are a part of the healthcare enterprise. To shelter application developers from the details of the data store facility list and details are made available as a multi-operation web service. This web service will be used to construct the web application that provides a user view into the facilities and facility details.

The previous document in this series, “GlassFish ESB v 2.1   Creating a Healthcare Facility Web Service Provider”, walked the reader through the process of implementing a GlassFish ESB v2.1-based, multi-operation web service which returns facility list and facility details. In this document I will walk through the process of developing a Visual Web Application 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 application will be implemented as a Visual Web JavaServer Faces Application using JSF component provided by Project Woodstock. This application will introduce the technology in a practical manner and show how a multi-operation 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 Web Application 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 or are readily pluggable into the NetBeans IDE. All are free and open source.

It is assumed that a GlassFish ESB v2.1-based infrastructure, supplemented by the Sun WebSpace Server 10 Portal functionality and a MySQL RDBMS instance, are available for development and deployment of the web application discussed in this paper. It is further assumed that the web service, developed using instructions in “GlassFish ESB v 2.1 – Creating a Healthcare Facility Web Service Provider, is available and deployed to the infrastructure. The instructions necessary to install this infrastructure are discussed in the blog entry “Adding Sun WebSpace Server 10 Portal Server functionality to the GlassFish ESB v2.1 Installation”, supplemented by the material in blog entry “Making Web Space Server And Web Services Play Nicely In A Single Instance Of The Glassfish Application Server”.

Here is the document – 01_FacilityService_WebApplication.pdf

While I am migrating my blog to blogs.czapski.id.au some links in older posys may be broken. For as long as it works, go to the http://blogs.sun.com/javacapsfieldtech/ find the post with the identical title.
Jun 22

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.
In this document I will walk through the process of developing a SOA Composite Application, exposed as a Web Service, which will make available simple business functionality using a multi-operation service. We will use the GalssFish ESB v2.1 infrastructure. The service will use the SOAP/HTTP Binding Component, the Database Binding Component and the BPEL 2.0 Service Engine. This simple service will introduce the components and discuss how a multi-operation web service can be constructed using the GalssFish ESB.
The business idea is that patients are looked after in various healthcare facilities. Frequently applications need to allow selection of a facility and to access facility details for display to human operators. A relational database is used to hold the details of facilities which are a part of the healthcare enterprise. To shelter application developers from the details of the data store facility list and details will be made available as a multi-operation web service. This web service will be used elsewhere to construct a portlet that can be used in an enterprise portal.

The document is available as 01_FacilityService_GFESBv21.pdf

Late breaking news: The MySQL JDBC Driver, which I used in the example, mysql-connector-java-5.1.7-bin.jar, and which is distributed with the GlassFish ESB v2.1, causes connection pool exhaustion and other issues with the example. If you experience these issues pleases download the latest MySQL JDBC Driver, mysql-connector-java-5.1.11-bin.jar as at now, from http://dev.mysql.com/downloads/connector/j/5.1.html and replace the original in domains/domain1/lib/ext.

Jan 08

The Note “HL7 Processor Demonstration – Java CAPS 6/JBI and OpenESB” walks the reader through development of a Java CAPS 6/JBI-based / OpenESB-based solution that addresses a Healthcare-related business problem. The Note elaborates on the healthcare background necessary to get a notion of what is being done and why, and provides detailed steps required to implement and exercise the solution.

I recorded a screencast of a session during which I discuss the business side of the Note, then discuss, implement, deploy and exercise all components of the solution documented in the Note.

The screencast is here: HL7Processor_Exercise_Screencast.avi. The associated archive, 00_HL7Processor_example_screencast_companion.zip, contains code fragments and other bits and pieces which are used, or referred to, in the screencast. Of some interest are the Note itself, in documents/00_HL7_Example_Development_Instructions_Final.pdf, and the brief example implementation instructions, in documents/00_HL7_ExampleBrief.pdf. I followed the brief instructions while I was building the projects when recording the screencast.

The screencast, which is over 320 Mb in size and takes 2 hours and 50 minutes to play, may require a TechSmith Compression Codec on your machine to allow your player to play the media. You can get one from the TechSmith site: http://www.techsmith.com/download/codecs.asp. Information on the codec can also be found here: http://www.movavi.com/codec/TSCC.html. If you prefer, and you are on Windows, you can get the CamPlay.exe from here: CamPlay.zip and use it instead.

Tagged with:
preload preload preload