Aug 05

This document discusses how the SOAP/HTTP Binding Component can be configured, in a service provider and in a service consumer, to use WS-Security 1.0 (2004) Username Token Profile support. WS-Security 1.0 (2004) provided support for the Username Token, which could be sent over the wire in the clear. This was insecure but Sun JAX-RPC libraries allowed this, since the standard allowed this. Through Project Metro release 1.4 it was impossibly to formulate a WS-Security policy that decorated a SOAP message with the Username Token headers, without requiring to also encrypt parts of the message. This prevented solutions built on top Metro 1.4, or earlier, from supporting cleartext Username Token. Metro 1.5 relaxed this requirement. The WS-Security policy configured using the GlassFish ESB NetBeans WS-Security wizard will be modified to require and provide a Plain text Username Token.

The document is here: 02_Configuring_HTTP_BC_for_WS-Security_UsernameToken.pdf

The companion archive containing all projects is here: WSSecPolicies_PersonUsernamePlain.zip

Aug 01

In this walkthrough I will add a Google Map showing a Route between patient’s home address location and the location of patient’s facility of record, as well as directions to follow along this route, to the Visual Web JSF Portlet developed in “Patient Lookup Visual Web JSF Portlet with a nicer looking Google Map”.

The walkthrough document is here: 02_PatienLookup_VWJSFPortletGooRoute.pdf

The comnpanion archive with NetBeans project artifacts is here: PatientLookupGooRouteVWJSFP.zip

Jul 31

The previous blog, walked through development and deployment of the Patient Lookup Portlet with a basic Google Map centered at the location identified by patient address, if any. It was a fairly basic Google Map, as Google maps go. In this document I will add a better looking Google Map to the Patient Lookup Portlet, explicitly using Google Maps APIs to construct the map.

The walkthrough is here: 02_PatienLookup_VWJSFPortletGooMapFancy.pdf

The companion archive, containing the NetBeans project, is here: PatientLookupGooMapBetterVWJSFP.zip

Jul 30

Every now and then there arises a need to carry out-of-band information alongside the business payload but without disturbing or modifying it. Message Envelope Pattern is the Enterprise Integration Pattern label that is typically applied to solutions that address this issue. How the issue is addressed in practice varies depending on the technology in use. For JMS, for example, JMS Message Properties could be used to carry out-of-band information while the payload would be carried as the JMS payload. Web Services, typically using SOAP over HTTP, can address this requirement through the SOAP Header Extension Mechanism, whereby custom headers can be added to the SOAP Header while the payload is carried in the SOAP Body.

This document discusses construction of a WSDL that supports custom SOAP Header element and BPEL processes that are used to set and get custom header values in JBI and in eInsight. This mechanism is known to work in Java CAPS 5.x, Java CAPS 6 Classic and OpenESB / GlassFish ESB.

It is assumed that the reader is sufficiently familiar with the GlassFish ESB / OpenESB BPEL Service Engine and the SOAP/HTTP Binding Component, and / or Java CAPS Classic eInsight Business Process Manager and eDesigner IDE to be able to build projects without a step-by-step pictorial document.

The document is available here: 01_Handling_SOAP_Headers_in_BPEL_.pdf
The companion archive, containing WSDLs and projects, is available here: 01_Handling_SOAP_Headers_in_BPEL.zip

While the method discussed in this entry is still valid there is now a different treatment of the topic, using NM Properties, “GlassFish ESB v2.x – Reading and Writing arbitrary SOAP Headers in BPEL 2.0 using NMProperties“.

Tagged with:
Jul 24

This document discusses how to implement support for WS-Security 1.0 (2004) in Java CAPS 6 Repository projects without resorting to SOAP Message Handlers. This is an update to my 3 year old Java CAPS 5.1 document on this topic, “Java CAPS 5.1, Implementing WS-Security 1.0 (2004) with JAX-RPC“. In this “release” Access Manager support for Username Token Profile has been removed. Feel free to add it if you need such support.

Java CAPS 6 Update 1 supports a mechanism for hooking SOAP envelope handlers into the Java CAPS Web Services framework so what I did and described in this document can now be done differently – perhaps better. I had a look at how to implement SOAP Message Handlers and it looked like work so I did not go there.

This material is provided on “all care but no responsibility” basis. Sun Java CAPS Support will not support this and neither will I. JAX-RPC from JWSDP 2.0, which is at the heart of the implementation, is deprecated and has long since been replaced by WSIT/JAX-WS/Tango.

Here is the document: Implementing_WS-Security_1.3_for_JavaCAPS6U1Repository.pdf
Here is the companion archive with all the required material: WSSecSampleProject_1.3_JCAPS6U1.zip

The WSSecurity.jar contains both the binary classes and the Java sources.

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 30

This Quick Note discusses a simple solution to the use case provided by Leonard Barkley. The question goes like this:

“I dont have any idea how to implement BPEL process but the BPEL deployed as a subscriber of a topic. usually I implement the BPEL process and deployed it as web service.”

We produce a simple GlassFish ESB v2.1-based solution which reads a file, sends its content to a JMS Topic and another simple GlassFish ESB v2.1-based solution which subscribes to the same JMS Topic, receives the message and writes it to a file. Both solutions will use BPEL to implement the simple logic, though it is possible to implement both solutions without BPEL, so we have File BC -> BPEL SE -> JMS BC -> JMS Provider (Topic) -> JMS BC -> BPEL SE -> File BC.

Here is the note: QuickNote003_forLeonardBarkley.pdf

Hire is an archive with the project group containing all the projects developed in the Note: JMSTopicSampleProjGrp.zip

As Leonard Barkley pointed out to me, having implemented the sample, the Note is incorrect on Pages 23 and 24. The JMSSubscriber_JMSIn WSDL should use the Receive type, not Send type as the docuent states. The solution still works, it appears, but the configuration as documented is confusing. Thanks Leonard.

preload preload preload