Friday Jan 29, 2010

GFESB v2.x – Using NMProperties in BPEL 2.0 to force the HTTP BC to send the “connection: close” HTTP header

In the major writeup called “GlassFish ESB v2.2 Field Notes - Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions”, at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-field-notes-exercising-load-balanced-highly-available-horizontally-scalable-hl7-v2-processing-solutions, in section called “WS Projects”, pages 35-36 , I discuss how NMProeprties in BPEL 2.0 can be used to force the HTTP BC to send the “connection: close” HTTP header, instead of the “connection: keep-alive” HTTP header, which it sends by default. Normally this does not matter but if a load balancer is to be used as a proxy, and a round robin load balancing is desired, the “connection: keep-alive” gets in the way. Rather then closing a connection after each HTTP request/response, as HTTP protocol was designed to do, “connection: keep-alive” HTTP header indicates to the server that connection is not to be closed in anticipation of another request coming form the same source “shortly”. Since the HTTP BC does not seem to have a place where this header can be removed or changed to “connection: close”, NMProperties in BPEL have to be used to force connection closure and enable correct load balancing behavior.

GFESB v2.x - Using WS-Addressing in BPEL 2.0 to implement the “Routing Ticket” EIP Pattern

In the major writeup, now called “CH05_WSSecurityExploration_r0.4.2.pdf”, at http://blogs.czapski.id.au/wp-content/uploads/2010/03/CH05_WSSecurityExploration_r0.4.2.pdf, in section 5.14.3, “Using WS-Addressing for Explicit Routing”, I discuss how WS-Addressing can be used to implement a variant of the “Routing Ticket” EIP Pattern. A one-way web service consumer sends a request to a request/reply web service, indicating, using WS-Addressing, the address of a one-way web service to which to send the response. 

GlassFish ESB v2.x - Reading and Writing arbitrary SOAP Headers in BPEL 2.0 using NMProperties

As I develop bigger prices of work, which have writeups associated with them, I inevitably have to solve small problems that crop up. The problems I solve I typically get written about in the corresponding writeup but may be missed by these who might need these kinds of solutions but who don’t have an interest in the major piece. For example, when writing about the HL7 HA solution, “GlassFish ESB v2.2 Field Notes - Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions” I had to work what host the instance of the business process was using and how to make the process instance wait for a random amount of time. I did separate writeups on these as “GlassFish ESB v2.1 - Using JavaScript Codelets to Extend BPEL 2.0 Functionality” and “GlassFish ESB v2.1 Field Notes - JavaScript Codelets to Make BPEL Process Wait for a Random Duration Up to a Maximum number of Milliseconds”.

Here I call reader’s attention to the problem of reading values of SOAP Headers in a BPEL 2.0 process. I discussed one method in “Java CAPS 5 / 6, OpenESB, GlassFish ESB - Handling SOAP Headers in BPEL”. In the major writeup, now called “CH05_WSSecurityExploration_r0.4.2.pdf” I am discussing, in passing, in Section 5.14.2, “Interacting with WS-Addressing Headers in BPEL”, a method that uses Normalized Message Properties (NMProperties) in BPEL 2.0, to access SOAP headers. While this piece discusses how to access WS-Addressing SOAP headers it is equally applicable to other SOAP headers. Similarly, in section 5.14.3, “Using WS-Addressing for Explicit Routing”, I discuss how arbitrary SOAP headers can be added and populated using NMProperties in BPEL 2.0. So if you need to manipulate SOAP header in BPEL 2.0, have a look a these sections.

The original article is available as GlassFish ESB v2.x – Reading and Writing arbitrary SOAP Headers in BPEL 2.0 using NMProperties, at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-x-reading-and-writing-arbitrary-soap-headers-in-bpel-2-0-using-nmproperties

Monday Jan 25, 2010

GlassFish ESB, v2.x - BPEL SSL Mutual Auth Mk.II and using JBI WS-Addressing for explicit routing - Exploring Effects of Security Policies, Rev.0.4.1

In this document I explore the effects of selected web services security policies on SOAP message exchange in the GlassFish ESB v2.x.

This is a work-in-progress document, now at rev 0.4.1.

To provide early access I intend to release revisions of this document as significant new sections become available.

Rev 0.1: Content
•    Assumptions and Notes
•    Person Service XML Schema and WSDL Interface
•    Common XML Project
•    PersonSvc BPEL Module
•    PersonCli BPEL Module
•    JBI-based Person Service – Plain End-to-End
•    JBI-based Person Service – SSL with Server-side Authentication

Rev 0.2: Additional Content
•    JBI-based Person Service – SSL with Mutual Authentication (broken)
•    EJB-based Person Service – No security
•    EJB-based Person Service – SSL with Server-side Authentication

Rev 0.3: Additional Content
•    EJB-based Person Service – SSL with Mutual Authentication
•    JBI-based Person Service - Exploring WS-Addressing

Rev 0.4: Additional and Changed Content
•    Modified sections 5.8 and 5.9 (SSL Server side and mutual authentication)
•    Using WS-Addressing for Explicit Dynamic Routing
•    Pre-requisite Cryptographic Objects [TBC]
•    Upgrading Metro to version 1.5 [TBC]
•    Username Token Profile 1.0 (2004) Policy [TBC]

The original article is avilabe as GlassFish ESB, v2.x – BPEL SSL Mutual Auth Mk.II and using JBI WS-Addressing for explicit routing – Exploring Effects of Security Policies, Rev.0.4.1 at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-x-bpel-ssl-mutual-auth-mk-ii-and-using-jbi-ws-addressing-for-explicit-routing-exploring-effects-of-security-policies-rev-0-4-1

Sunday Oct 11, 2009

GlassFish ESB, v2.1 - EJB SSL Mutual Auth and JBI WS-Addressing - Exploring Effects of Security Policies, Rev.0.3

In this document I explore the effects of selected web services security policies on SOAP message exchange in the GlassFish ESB v2.1.

This is a work-in-progress document, now at rev 0.3.

To provide early access I intend to release revisions of this document as significant new sections become available.

Rev 0.1: Content
•    Assumptions and Notes
•    Person Service XML Schema and WSDL Interface
•    Common XML Project
•    PersonSvc BPEL Module
•    PersonCli BPEL Module
•    JBI-based Person Service – Plain End-to-End
•    JBI-based Person Service – SSL with Server-side Authentication

Rev 0.2: Additional Content
•    JBI-based Person Service – SSL with Mutual Authentication (broken)
•    EJB-based Person Service – No security
•    EJB-based Person Service – SSL with Server-side Authentication

Rev 0.3: Additional Content
•    EJB-based Person Service – SSL with Mutual Authentication
•    JBI-based Person Service - Exploring WS-Addressing


More in CH05_WSSecurityExploration_r0.3.pdf at http://mediacast.sun.com/users/Michael.Czapski-Sun/media/CH05_WSSecurityExploration_r0.3.2.pdf/details

The original blog entry is located at http://blogs.sun.com/javacapsfieldtech/entry/glassfish_esb_v2_1_ejb
I make this material available to help others work with the software, not to help others make money by syndicating my blog. This material can only be reproduced on Sun Microsystems sites. Other sites that reproduce this blog entry do so without permission and contrary to my intent.

Saturday Sep 19, 2009

GlassFish ESB, v2.1 - Exploring Effects of Security Policies, Rev.0.2, More SSL and EJB-based projects

In this document I explore the effects of selected web services security policies on SOAP message exchange in the GlassFish ESB v2.1.

This is a work-in-progress document, now at rev 0.2.

To provide early access I intend to release revisions of this document as significant new sections become available.

Revision 0.1: Content
    \* Assumptions and Notes
    \* Person Service XML Schema and WSDL Interface
    \* Common XML Project
    \* PersonSvc BPEL Module
    \* PersonCli BPEL Modules
    \* Person Service – Plain End-to-End
    \* Person Service – SSL with Server-side Authentication

Revision 0.2:Added Content
    •    JBI-based Person Service – SSL with Mutual Authentication (broken)
    •    EJB-based Person Service – No security
    •    EJB-based Person Service – SSL with Server-side Authentication


More in CH05_WSSecurityExploration_r0.2.3.pdf at http://mediacast.sun.com/users/Michael.Czapski-Sun/media/CH05_WSSecurityExploration_r0.2.3.pdf/details

Monday Sep 07, 2009

GlassFish ESB, v2.1 - Exploring Effects of Security Policies, Rev.0.1, SSL with Server-side Authentication

In this document I explore the effects of selected web services security policies on SOAP message exchange in the GlassFish ESB v2.1.

This is a work-in-progress document.

To provide early access I intend to release revisions of this document as significant new sections become available.

Revision 0.1: Content

  • Assumptions and Notes
  • Person Service XML Schema and WSDL Interface
  • Common XML Project
  • PersonSvc BPEL Module
  • PersonCli BPEL Modules
  • Person Service – Plain End-to-End
  • Person Service – SSL with Server-side Authentication

More in CH05_WSSecurityExploration_r0.1.pdf

Friday Sep 04, 2009

HL7 Processor Demonstration - GlassFish ESB v2.1

This Note walks the reader through development of a GlassFish ESB v2.1based 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 to the business problem.

We will use the HL7 Binding Component, the File Binding Component, the JMS Binding Component, the SOAP/HTTP Binding Component, the BPEL 2.0 Service Engine, the JavaEE Service Engine, the HL7 Encoder and EJB-based Web Services in a JBI-based solution. 

This note is an update, for GlassFish ESB v2.1, of the original note  "HL7 Processor Demonstration - Java CAPS 6/JBI and OpenESB".

Updated note is available at http://blogs.czapski.id.au/2009/09/hl7-processor-demonstration-glassfish-esb-v2-1

Monday Jul 06, 2009

GlassFish ESB v2.1, MySQL v5.1 - Creating a Patient Service Web Service Provider

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

Friday Jul 03, 2009

GlassFish ESB v2.1, MySQL v5.1 - Make HL7 v2.3.1 Delimited Messages from Custom Delimited Records with HL7 Encoder and HL7 BC

“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. 

The article and referenced materials are available at http://blogs.czapski.id.au/2009/07/glassfish-esb-v2-1-mysql-v5-1-make-hl7-v2-3-1-delimited-messages-from-custom-delimited-records-with-hl7-encoder-and-hl7-bc

Thursday Jan 08, 2009

HL7 Processor Example - Development Screencast

The Note at http://blogs.czapski.id.au/2009/01/hl7-processor-demonstration-java-caps-6jbi-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 and releated informaiton are available in the blog article at http://blogs.czapski.id.au/2009/01/hl7-processor-example-development-screencast

Thursday Jan 01, 2009

HL7 Processor Demonstration - Java CAPS 6/JBI and OpenESB

This Note 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 to the business problem.



Updated note, where GlassFsish ESB v2.1 is used instead of Java CAPS 6, is available at http://blogs.czapski.id.au/2009/09/hl7-processor-demonstration-glassfish-esb-v2-1



We will use the HL7 Binding Component, the File Binding
Component, the JMS Binding Component, the SOAP/HTTP Binding Component, the BPEL
2.0 Service Engine, the JavaEE Service Engine, the HL7 Encoder and EJB-based
Web Services in a JBI-based solution.


In the process we will create XML Schema Documents (XSDs),
Web Services Description Language Documents (WSDLs), a BPEL 2.0 Business
Process, an EJB-based “Implementation First” web service, an EJB- and
WSDL-based “Interface First” web service, a bunch of Composite Applications,
BPLE 2.0 mapping, BPEL 2.0-based Web Service orchestration, on-the-fly
conversion of HL7 version 2.3.1 delimited messages to their XML equivalents. We
will get a pretty good exposure to what OpenESB and Java CAPS 6/JBI components
look like, how they work and how they can be used to create real business
solutions. Above all, we will develop and test a solution that is more
sophisticated then the customary “Hello World” examples but not so complex as
to take too long to build and become too hard to comprehend by a novice user.


The particular business problem and the particular solution
came about because once upon a time there was intent to build a series of
related OpenESB projects – HL7 Processor, MDM Processor and IEP Processor -
that would:



  • receive HL7 v2.x delimited messages

  • convert HL7 v2.x messages to their equivalent XML format

  • split message stream into ADT A01s, ADT A03s and other

  • convert A01s to an abbreviated Custom Patient XML format

  • convert A03s to an abbreviated Custom Discharge format

  • send Custom Patients to a JMS Queue for processing by a MDM solution

  • send Custom Discharges to a JMS Queue for processing by an IEM solution

  • have the MDM process Custom Patients into a Master Patient Index

  • have the IEP process Custom Discharges to flag excessive length of stay


The MDM Processor and the IEP Processor made it to the Sun CEC
2008 as demonstrations, with associated Tutorials by Tom Barrett, and
demonstration recordings by me. The HL7 Processor did not make it. With the
appearance of Java CAPS 6 Update 1 more JBI components made it into the
officially supported Sun product. While the HL7 BC and the HL7 Encoder did not
make it into this Update they will, eventually. Both components are already
available from the OpenESB site and can be installed into the Java CAPS 6
Update 1 installation as unsupported components. This is what we will do for
this Note.


The article with the complete note and referenced links is available at http://blogs.czapski.id.au/2009/01/hl7-processor-demonstration-java-caps-6jbi-and-openesb


For these interested in processing HL7 using GlassFish ESB v2.1 there is a blog entry, "GlassFish ESB v2.1, MySQL v5.1 - Make HL7 v2.3.1 Delimited Messages from Custom Delimited Records with HL7 Encoder and HL7 BC", at , which discusses, amongst other things, how to create a custom HL7 v2 ADT A04 XSD and a "match any" XSD.

Wednesday Jul 23, 2008

Java CAPS 6, Scheduler for JCA and JBI Projects, Note

Java CAPS 5.x used to have a Scheduler eWay. Java CAPS 6 also has the Scheduler eWay but only on the Repository-based side. At this point in time there is no Scheduler JCA Adapter or a Scheduler Binding Component. Why would one be bothered by that? One would be bothered because there are business requirements that call for scheduling of activities. The one that comes to mind immediately is polling an FTP server for a file which to transfer. For polling the local file system there is the Batch Inbound JCA, which was used in solutions discussed in JCA Notes 2 and 3. For Batch FTP JCA there is no such thing.
Rather then ignoring the issue of lack of the Scheduler JCA Adapter I determined to see what can be done to provide this functionality for non-Repository-based Java CAPS 6 solutions.
When asked, one of my colleagues in the US suggested that EJB Timers are the way to go and provided the links to the material. I looked at what was discussed, threw up my hand in the air and exclaimed. I will not quote what I said. In short, EJB Timers may be all very well for a competent Java EE developer but not for a regular Integration, or SOA, developer. EJB Timers are, in my view, way too complex to implement and do not offer sufficient advantage over a Scheduler eWay to make it worth while to spend the time developing a solution that uses them.
The next thing I looked at was the open source Quarz scheduler, which also turned up to require more effort then I considered worth while for the Notes.
I felt that the simplest thing to do will be to use an external scheduler, a native one, provided by the OS. For Windows, on which I develop for the Notes, there is the “Scheduled Tasks” scheduler. For Unix there are Cron facilities. Both are well know and typically good enough in terms of timer resolution and scheduling flexibility. Above all else, using one does not require me to write scheduler code myself, merely write the code that triggers my solution when the scheduled event fires.
So, this Note walks through implementation of a Scheduler solution, which can be used to trigger a Batch FTP JCA solution or any other JCA-based or JBI-based solution that has to be triggered to some schedule.


Document 00Scheduler.pdf contains the entire Note.

Friday Jul 18, 2008

Java CAPS 6, Using JCA and JBI, Note 3, Batch Inbound, through Batch Local File to BPEL 2.0

Java CAPS 6 has the 5.x compatibility infrastructure which allows one to import 5.x projects right into Java CAPS 6, build, deploy and run without changes. One can also develop repository-based projects in Java CAPS 6 – that’s the 5.x-style projects.  This is the old way of developing Java CAPS solutions – still good and valid.

If one were to decide to not use the old way there is the JBI infrastructure, which allows development of solutions that use BPEL Service Engine, XSLT Service Engine, IEP Service Engine, Java EE Service Engine, etc., and a variety of Binding Components. The implication is that business logic is implemented in BPEL 2.0, which is used to orchestrate other services and resources, including interaction with external systems through Binding Components. This is the new way of developing Java CAPS solutions – 100% compatible with the Open Source OpenESB project since it uses the OpenESB project-developed container and components.

Someone might ask “so what happened to eGate?”. “eGate” meaning Java Collaboration Definition-like logic components, eWays and the JMS messaging backbone.

While the facility seems underadvertised/downplayed, Java CAPS 6 provides a number of 5.1 eWay-based JCA Adapters and a moderately easy means of developing JCA Message-Driven Beans that can use these adapters to implement JCD-like logic components and, effectively, eGate-like solutions that do not use BPEL or the JBI infrastructure.

This Note discusses and illustrates the implementation of a mixed Java CAPS 5.x-like integration solution that retrieves a file from the local file system using JCA Adapters and passes its content to a BPEL 2.0 process executing in the JBI container. This requirement I have seen and heard of being implemented in 5.x many times by many customers.

Most of the material in the first 16 pages of this Note is the same as in Note 2.

The JCA Message-Driven Bean, the piece of JCD-like Java logic, will be triggered by a Batch Inbound Adapter (what one would have called the Batch  Inbound eWay in 5.1), will read the content of the file using the Batch Local File Adapter (eWay) and will send the payload as a string to a BPEL 2.0 Business Process, which will be triggered by this message and will execute in the JBI container. The batch Inbound Adapter will be configured to use a regular expression to match the name of the file. Once it finds the file it will rename the file by prepending the GUID to the name and will pass the new name, the original name and the directory path to the Java code. This is exactly what the 5.1 Batch Inbound does. The JCA MDB will use the new name, the original name and the directory path to dynamically configure the Batch Local File Adapter to retrieve the file content and rename the file (post transfer) to the original name with some string appended to indicate that the file was processed. This, too, is exactly what one would do in a 5.1 JCD in the same circumstance. Once the payload is available the JCA MDB will use the OneWay WSDL interface and the JBI NMR to send it, as a String, to a BPEL 2.0 process.  Both the JCA MDB and the BPEL process will be a part of the same JBI Composite Application and will communicate with one another using the Normalized Message Router (NMR).

The entire Note is available in 03JCA-BInboundThroughBLFToBPEL2.0.pdf

Tuesday Jul 15, 2008

Java CAPS 6/JBI, Note 5 - HTTP BC to SMTP BC, No BPEL


Someone
asked a question along the lines of “Is it possible to develop a solution in
OpenESB where the HTTP BC receives a request and the SMTP BC uses it to send
electronic mail with no BPEL logic to tie the two together”. I though that the
answer was “Yes” but I felt I had to verify it. Vishnuvardhan Piskalaramesh
from Sun, who is looking after the SMTP BC, and Sherry Weng from Sun, who is
looking after the HTTP BC, helped along and here is the result.

This note
describes, with illustrations, a mini integration solution wherein an appropriately
formulated HTTP GET request is used to submit an electronic mail to a SMTP server,
using the HTTP Binding Component and the SMTP Binding Component, without the
need to provide any transformation logic. This is another example where a
practical JBI-based integration solution can be constructed in minutes.

05JBI_HTTP2SMTP_NoBPEL.pdf provides the illustrated discussion.

About

In this Blog I post abstracts of articles / writeups / notes on various aspects of Java CAPS and SOA Suite including solutions, discussions and screencasts. The links to the referenced material are included in the bodies of the abstracts.

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today