A Reusable Fuse Integration Services 2.0 Demo

Introduction

Recently a potential customer wants to see how FIS 2.0-based services and API Management can work together to replace the integration platform he is currently using. The customer has asked another vendor to do a PoC on AWS. Red Hat has been invited to do the same but called it a demo. Consequently, we set up Openshift on Google Cloud Platform for the demo. In this article, I am going to describe only the FIS implementation of the use case mandated by the customer. The FIS 2.0 and 3Scale integration is covered in another article. Continue reading A Reusable Fuse Integration Services 2.0 Demo

JBoss Data Virtualization Part 1 – Concept

Data Challenges

When you are only having a few applications, it is easy to integrate them using a point-to-point approach ie, each application connects to all the other applications directly to access the information. As the number of applications increases, using the point-to-point approach will result in a non-maintainable mess of spaghetti-like chaos as shown in the diagram below. You may reduce the integration complexity by either introducing an Enterprise Integration Bus (ESB) or by using Data Virtualization. It should be noted that this is not an either-or choice as ESB and data virtualization are the two sides of the same integration coin. ESB is used for application integration and data virtualization is used for data integration. They work together well. Complexity is not the only issue here, how about administering security? In using a point-to-point approach, you have to administer security or access control on each data source for each application. Also, many organizations store information eg, on a customer, using different applications and the information they store may differ slighly from application to application. This means that, depending on the system or application you query, you may end up with conflicting information on a customer. Continue reading JBoss Data Virtualization Part 1 – Concept

Building a BPMS Web Application Part 2: Remote Java API

(This article assumes some basic knowledge of the JBoss BPM Suite including using Business Central.)

In Part 1, I described how to make use of the BPMS form metadata, run it through a code generator to produce JSPs for the UI and Java ActionBeans to handle these JSPs (for process instantiation and manual task interaction). Although the code to integrate with BPMS eg, to kick off a process instance and interact with the human tasks can be found partially in the generated ActionBeans, how exactly it works is still shrouded in mystery. This article will solve the mystery. Continue reading Building a BPMS Web Application Part 2: Remote Java API

Building a BPMS Web Application Part 1: Code Generation

(This article assumes some basic knowledge of the JBoss BPM Suite including using Business Central.)

In a previous article, I described how to use the new jBPM Form API to build a BPMS web application. I also outlined a different approach in which code generation can be used to replicate the forms to the web application using the form metadata on the BPMS Execution Server. Although I provided a link to my OpenShift implementation of such a BPMS web application, the technical details on how this is achieved is still scarce. This article remedies that. Here is a recap on why we want to build a web front end to a business process. BPMS forms are generated and customised by business analysts when they create business processes. Few customers use the forms on the BPMS Execution Servers. They prefer to build a web application that interacts with the business process remotely running on a BPMS Execution Server so that fine-grained access control, consistent look-and-feel and better client interaction can be achieved. One way to do this is by using the new jBPM Form API and the other way is to use code generation to replicate the forms using the form metadata. Continue reading Building a BPMS Web Application Part 1: Code Generation

Using Odroid XU4 CloudShell as My Home Server

For those who are not familiar with Odroid XU4 and CloudShell, Odroid XU4 is an ARM-based Octa core single board computer based on the Samsung Exynos5422 2Ghz Cortex A15 and Cortex A7 cores with 2 Gbytes of memory. CloudShell is a compact case for Odroid XU4 with a 2.2 inch TFT LCD and a USB 3 to SATA bridge for connection to a 2.5 inch SATA hard disk. The assembled CloudShell is shown in the diagram below.

The ARM big.LITTLE technology is ideal for a home server in that when the cpu load is low, it uses the power efficient A7 core(s) and when the load is high, it switches to use the high performance A15 core(s). It may use 1 core, more than 1 core or all cores at the same time depending on the load. This means energy saving in the long run.

This article is not an Odroid XU4 review. For that you can read this in-depth review here. This article describes my experience in using this wonderful little device. Continue reading Using Odroid XU4 CloudShell as My Home Server