Deploying Eclipse in IT

Posted by Documentation Tue, 09 Mar 2010 09:36:00 GMT

Integration of the HOB Windows Terminal Server clients HOBLink JWT and the 3270 client HOBLink J-Term in Eclipse

Originally, Eclipse was used in the development environment, i.e., as an application program for the development of software for the programming language Java. As the successor to IBM Visual Age for Java 4.0, the source code for Eclipse was released by IBM on 7 November 2001. On 2 February 2004, the Eclipse consortium, lead by IBM, decided to found the legally independent Eclipse Foundation, which since then has been responsible for the development of Eclipse. Eclipse is Open Source software and can be downloaded free of charge.

Due to its expansibility, Eclipse is also used for many other development tasks. There are many extensions from both open source and commercial providers.
Up to and including Version 2.1, Eclipse was designed as an IDE. Since Version 3.0, Eclipse is only the core that loads the individual plug-ins, which themselves supply the actual functionality. Eclipse and the plug-ins are completely implemented in Java. SWT is used to create the graphical user interface. For the display of the GUI components, SWT, similarly to AWT, uses the native GUI components of the corresponding operating system. The plug-ins can be installed either by downloading them directly from an update server or simply by unpacking them.

Increasingly more enterprises are deploying Java products and more and more often using Eclipse as the framework on the workstation computer due to the advantages thereof. A very popular and widely used application for deployment with Eclipse is Lotus Notes from IBM. With the Lotus Expeditor, the GUIs for Lotus Notes can be created and integrated on the basis of Eclipse (RCP, Rich Client Platform). Eclipse is itself written in Java and can therefore be used on any platform and on any client operating system.

The use of Eclipse as the framework on the workstation computers in an enterprise brings with it the following advantages:

  • A uniform base for the use of any application program as a Java plug-in in heterogeneous client environments

  • Very open and flexible design of the client’s GUI

  • All application programs used as plug-ins can be easily given a uniform display format

  • Standardized software interfaces allow the deployed plug-ins to be linked with each other, e.g., for data exchange, etc.
  • The integration of the individual application programs into the Eclipse framework simplifies the rollout to the work areas and, as a result, also the administrative work.

A disadvantage of this design is the fact that desired applications are not always available as Eclipse plug-ins. Early on, HOB recognized the need of enterprises for applications as Eclipse plug-ins and thus offers two important client applications as plug-ins for Eclipse:

HOBLink J-Term, the first and most performant 3270 emulations in Java
HOBLink JWT, the RDP client for Microsoft Terminal Server in Java

Both products are in use at well-known corporations. HOB has placed great importance on the providing the Eclipse plug-in versions with the same scope of functions as the native versions.
The “look and feel” and the performance range of the native versions and the Eclipse plug-in versions from HOB are absolutely identical. A user who has previously worked with a native version and switches to the Eclipse plug-in version can work with this version just as before.

For further information, please see:

25 February 2010

Klaus Weinbrenner



Posted in | no comments |

Our experience working with SSL VPNs and the integration of HOBLink JWT

Posted by Chipper Mon, 08 Mar 2010 13:35:00 GMT

As written in the previous entry, SSL VPN solutions have not entirely replaced IPSec VPN solutions. But they sure are trying hard to.

Where IPSec VPNs would open the entire network at once, SSL VPNs have slowly but surely undertaken the task of moduling the possibilities. Should a user only have access to an internal Web server, the administrator can limit him to just that. Should he only have access to a specific Terminal Server, or his office PC, he can also limit him to just that. But it also means that the SSL VPN must have the correct tools to make the connection to these allowed targets.

Imagine a restricted building where a card can either open all doors or be entirely rejected, that's your IPSec gateway. Imagine now an improved system where you can code each card to open certain doors, great! But what good is this if there is no elevator, or hallway to go the doors you have clearance to?


Where the IPSec solutions mostly rely on the software installed on the client computer for access (use your own feet, a climbing rope, or a flying jetpack if you can – clearance is there, you provide the connection), SSL VPN appliances want to provide this software itself. The goal is to limit the requirement on the client PC to what is probably already installed on it (namely a Web browser and tools like Java or ActiveX – we don't assume you have anything else than 2 legs, feet and well... some shoes). This makes the administrators' work easier (working on a single, familiar, accessible point) and the users' interface more independent of their PC. So these appliances come with plenty of tools which cover most of the needs of a regular user. But then some rooms are not used so often, or some client PC are even more different than your usual unusual PC, and these cases are not covered by the « out-of-the-box » appliance (« Sorry, you're too tall for this safety elevator and there's no stair »!). Then all of a sudden the advantages of the solution become a difficulty: The administrator is limited by the appliance's possibilities, and the user can't do anything on his homebrewed client system to change anything. The software on the appliance has to evolve.


It is this way that we are receiving more and more interest from SSL VPN customers in our Java RDP client: HOBLink JWT.

Most SSL VPN appliances come with a usual RDP client, Microsoft, Citrix, and an open source Java client. This basically covers the needs of Microsoft OS clients, and if ever you are connecting from a Mac, or a Linux, well this open source client should cover your basic needs until you can find better.

More and more customers' answer to this is “that's not good enough”. Surely it must be possible to connect from my Mac to my office PC without having to give up on my keyboard layout, printer, dual-screen, or any normal option you need to work correctly. What about 64-bit OS? they are not a rarity anymore and should be covered (The average human population is getting bigger with time and there is no doubt that the computer world is changing much faster!).

HOBLink JWT is our answer. A Java RDP client that can be hosted on a Web server behind your SSL VPN appliance (ie no installation either on the client nor on the Terminal Server / Office PC), with full functionality and running independently of the platform.


We followed the demand and started with the world leader of SSL VPNs: Juniper. More and more customers hosted HOBLink JWT on a Web server behind the VPN, and it would act as it normally does with a link (bookmark) on the users' interface. But we wanted to push it a bit further, using the possibility in the Juniper VPN to host Java applets directly on the appliance. This does not only save on a Web server, but also improves the speed of the connection. Working together with Juniper, this was made possible for JWT 3.2, and now further improved for JWT 3.3 on the Juniper releases 6.4R1+.

Soon HOBLink JWT will be integrated directly in the appliance, to ease the process for the end customers.

SSL VPNs are going one step further in replacing IPSec VPN solutions, and your elevators are about to become much more flexible – no less secure.



Laurent « Chipper » Vaucheret

Support Engineer, HOB Inc.

no comments |

tp://')) %>
Powered by typo