System iNetwork

General

June 3, 2007

Regretfully WDSCi 7 cannot be used for RCP development.

You can't use WDSCi 7 (Version 7 of Websphere Development Studio Client for System i) to develop RCP applications -- at least not without making compromises.

Close but no cigar. Maybe next time around.

This information is directly from IBM (the first two points), the result of two PMRs.

1. The javadocs for SWT and JFace are not included to save space.

2. The source for Eclipse is not included for legal reasons.

IBM / Rational doesn't knows what all the effects of leaving out the Eclipse source. For sure without the source the PDE is unable to generate XML code for the extension points. That was one of my PMRs. Anything that plugin development, or Eclipse, tries to build using the Eclipse source as a template is going to fail. There is no list of what is effected by the lack of Eclipse source code.

This is my conjecture

3. I am conjecturing that IBM / Rational does not test the functionality of of the Eclipse as WDSCi is developed. While the prespective "Eclipse Plug-In Development" is maintained, and plugin development is a install option, I don't see how it could have been fully tested and someone not notice the problems leaving the Eclipse source code out causes.

In fairness WDSCi is a huge product. Using WDSCi for Eclipse type development is probably not on the critical path. Perhaps the Eclipse source was left out in the final build and no one realized that would be a problem.

IBM / Rational provides a means to install WDSCi into your Eclipse and I haven't tried that.

My conclusion?

WDSCi is really super but I won't be using it to develop Eclipse RCP applications for the System i.

The Eclipse RCP wizards work and generate sample applications which work. When you to try to build on them the PDE problem comes into play. You can get around it by editing the XML of the plugin directly.

You can get around the lack of SWT and JFace documentation by linking to the Eclipse website.

I'll continue this blog using Eclipse 3.2.2 and borrowing from the iSeries toolbox and JTOpen as needed.

Posted by Bill Blalock on June 3, 2007 at 12:23 PM | Comments (0)

February 25, 2007

Preparing the ground -- the RPG and Java groundwork for discussing Eclipse RCP clients. Consider what needs to be done ...

So what if WDSc is a compelling demonstration of Eclipse's power build System i clients? Most of us are not paid to develop programming and management tools for the System i. We develop and maintain applications! Our concerns is what can Eclipse RCP do for our applications.

The end goal of the coming series of blog entries is to build Eclipse RCP client applications as a GUI front end for a System i application. But what needs to be done before developing a client for an application -- with or without Eclispe? To reach the goal, discussing Eclipse RCP client, these steps have to have been completed:
- describe a client-server model (MVC)
- create a demonstration server server for the System i using data queues
- create a test client for the System i
- explore data queues in Java through Java applications (not Eclipse or RCP)
- create test Java client applications which can run on a desktop or the System i
- create a data queue demonstration Eclipse RCP client to work with the demo server
- repeat this for message queues
- define an iSeries application, create a server for it and a test System i client
All this needs to be done before talking about Eclipse RCP clients for an iSeries application.

There will be something in this series for most SystemINetwork readers. This won't be simply hypothetical -- demos, examples and applications will actually work and source will be posted on CVSDude.

By the way, does anyone have an example application they can donate?

A mission of this blog is to explore aspects of building Eclipse RCP clients for a System i application. The foundation has to be in place before exploring how to build an RCP client. Before we can consider a desktop Java client which works with a System i application via queues ...
- the application has to be enabled to be served by non System i clients, any client -- not just RCP
- understand the use of Java toolbox classes for data queues and message queues beyond the the introductory documentation

To accomplish this the blog will follow this path:

• Propose an implementation of the Model or server portion of the Model-View-Controller design pattern using data and messages queues to communicate with the client. Chapter 5 of the IBM Redbook, "Who Knew You Could Do That with RPG IV? A Sorcerer's Guide to System Access and More" covers data queues and message queues. Data queues get application data between the client and server, message queues communicate problems back to the client. See the Redbook references if you want to know more.


• Develop a simple RPG "server" to simulate data queue communication between the server and its clients


• Develop an even simplier CL client to test the server, again using data queues


• Take a look at data queues in Java beyond the examples presented in the JT Open documentation.


• Write Java applications (programs with a main() method started by java.exe) to demonstrate data queue techniques which interact with the dummy server running on the System i. This does not envolve Eclipse. These applications can run on the desk top or on the System i


• Develop an example Eclipse RCP client (view-controller) that communicates with the a demonstration System i server (model) using data queues.


• Repeat the test environment and exloration process for message queues.


• Develop an example Eclipse RCP client (view-controller) that communicates with the demonstration System i server (model) using message queues and message files.


• Implement the model portion of the MVC design pattern for a System i application

All the above needs to be in place before developing Eclipse RCP clients which implement the view-controller portion of the MVC design pattern on the desktop.

Notice that the actual System i application isn't encountered until well into the process, Implementing the model portion of MVC... step. I hope to find a System i application to use in this blog. If nothing turns up then we will use a hypothetical CUSTOMER target application and implement only the portions necessary on the System i.

Posted by Bill Blalock on February 25, 2007 at 5:00 PM | Comments (0)

February 18, 2007

WDSc and Eclipse RCP are two very different things

The perceived performance (or lack) of Websphere Development Studio Client (WDSc) is an insurmountable barrier to some System i professionals. It is certainly a source of annoyance to those who use WDSc. Some System i professionals may automatically be turned off, discount or dismiss Eclipse and anything produced by it because of the performance. Please don't make this mistake.

These performance traits are not inherent to System i client applications developed with Eclipse. Eclipse and Eclipse RCP, while based on the same technologies, are different.

Eclipse is an IDE which runs on the desktop. Basically Eclipse becomes WDSc from the contribution of plug-ins. These plug-ins make WDSc a System i client and expand its capabilities. WDSc retains its basic IDE nature.

Eclipse IDE is not Eclipse RCP. By extension WDSc is not an Eclipse RCP application.

Eclipse RCP is Eclipse stripped of its IDE nature. Eclipse RCP by itself does nothing, can do nothing. The IDE is removed leaving the user interface (UI) support. It is a platform to execute rich desktop clients. The developer creates an "Application" class which uses the UI features of the stripped down set of Eclipse plug-ins to make a rich client application. An Eclipse RCP application only has a modest set of initial plug-ins plus what the developer adds to support the application.

So don't confuse Eclipse RCP with WDSc. Yes, Websphere Development Studio Client is an Eclipse rich client application -- however it is not an example of Eclipse RCP. WDSc is an outstanding example of facilities an Eclipse rich client can provide for the System i.

Rich clients built with Eclipse RCP are very different from WDSc. The performance problem of WDSc is caused by the number of plug-ins it has to load and the need for WDSc to get incredible amounts of information from the System i during start up. Performance won't be a problem for your application unless it is really, really huge and needs that much information from the System i.

Except for performance, I think WDSc makes a compelling case for the potential of Eclipse based rich clients for the System i.

Posted by Bill Blalock on February 18, 2007 at 12:03 PM | Comments (3)

January 30, 2007

Ways in which a System i rich client application "talks" to its "server".

I believe that a System i rich client application should not be a GUI implementation of monolithic 5250 programs which we inherited from RPG III. In general the MVC (model-viewer-control) design pattern is an effective paradigm for System i rich clients. Programs running on the System i provide the business model or domain specific representation of the information which is acted upon. The rich client provides the view of the data / information and controls the user interaction with the model.

Given that you accept this premise, what are the ways in which the viewer-controller (rich client) "talks" to the business mode (System i programs)?

Initially SQL and the JT Open Java Toolbox relational / direct access data classes come to mind. Remember, the premise that rich clients are simple replacements for 5250 programs. The obvious approach to an old dog like me was to read and write files like I'd been doing for so many years. Avoid this trap!

There is plenty of information about the use of SQL in Java (JDBC) so I won't repeat it. The System i Information Center and all the "Java for RPG programmers" books cover the JTOpen relational (direct access) data classes. The JTOpen Java Toolbox also provides program calls (like the OPM model), data queue support and access to several System i APIs. These same knowledge sources cover these topics. In future entries I will show some rich client implementation of these tools.

Here are three other techniques for Java rich clients (and applications) to interact with System i resources that aren't as well document, which you may find useful. I am going to describe them in detail in future blog entries. I hope some of you will comment. Perhaps help make them better. Perhaps challenge them. They are:

- Remote method invocation (RMI) of Java classes on the System i by a Java rich client (or application)
- Remote method invocation (RMI) of Java classes which wrap RPG service programs (JNI).
- Create objects on the System i that represent parts of the business model and serialize them in the IFS. The Java rich client (or application) deserializes the objects and uses them.

Do you use other techniques? Have you other techniques to get data or information back and forth between traditional System i applications and Java programs (rich clients, System i applications or remote applications)? If so please feel free to add your comments.

Posted by Bill Blalock on January 30, 2007 at 5:55 PM | Comments (1)

January 21, 2007

Resources to learn about Eclipse RCP

I hope that some of the readers of this blog see potential for System i rich clients in their shop and that Eclipse is a good choice for building rich clients. Here are some suggestions for books I have found useful.

A side note first. A web article I read last week is good reading for those interested in arguments for the viability of rich clients. The article is on a Linux website, www.linux.sys-con.com. The title is "Eclipse: A Solid Desktop, Rich-Client, or Embedded Application Framework -- a general purpose platform".

I prefer a printed book to web sites, simply as a personal preference. Ed Burnette's tutorials provides several on line references for Eclipse RCP. These references are important as they cover very specific topics generally not covered in printed books (at least those I have reviewed).

My background and computer education is similar to many System i professionals, coming to Java from a procedural language background. My education was in Fortran and COBOL. First professionally programming in COBOL, I picked up who knows how many dialects of BASIC, Pascal and C along the way. Then I moved to the System 36 and in 1988 to the AS400 and found my professional home. Getting object oriented design concepts and programming into my head took a lot of effort. I hope my experience in learning to develop applications with Eclipse will save you some time and money.

Three books which I have found helpful for Eclipse RCP development are:

"Eclipse: Rich Client Platform" by Jeff McAffer and Jean-Michel Lemieux
"Eclipse: Building Commercial-Quality Plug-ins" by Eric Clayberg and Dan Rubel
"The Definitive Guide to SWT and JFace" by Rob Warner with Robert Harris

"Eclipse: Rich Client Platform" assumes you are somewhat familiar with the Eclipse IDE. It walks you through the development of a chat client in the first part (half of the book or so). The remaining parts cover RCP specific details of plugin development and reference materials.

"Eclipse: Building Commercial-Quality Plug-ins" introduces you to the Eclipse IDE then teaches how to build plug-ins to extend the Eclipse IDE. It introduces SWT and JFace and covers every part of plugin development.

I needed both books. RCP teaches how to write RCP but not plugins. Plug-ins teachs how to write plug-ins, from which RCPs are built, but doesn't got into RCP development.

My advice for someone who wants to quickly learn Eclipse RCP beyond Ed Burnette's tutorial is
- If you are starting with Eclipse then begin with "Eclipse: Building Commercial-Quality Plugins" and work through chapter 1. Continue with "Eclipse: Rich Client Platform" and work through part 1.
- If you are comfortable with Eclipse then start with "Eclipse: Rich Client Platform" and work through part 1, the hands on tutorial.
- Work through chapter 2 of "Eclipse: Building Commercial-Quality Plugins" which is a simple plug-in example. This goes much more quickly (a single chapter).
- Chapter 3 of "Eclipse: Building Commercial-Quality Plugins" explains the infrastructure of Eclipse, a different view of what was presented in "Eclipse: Rich Client Platform".
- Chapters 4 and 5 of "Eclipse: Building Commercial-Quality Plugins", introduce the Eclipse UI toolkit, SWT and JFace.

At this point you have the knowledge to start developing your own rich clients for the System i. This seems like a lot of preperatory work but it isn't. If you know the Eclipse IDE the tutorials move quickly. If you don't know Eclipse IDE you will learn a lot about it doing the tutorials.

Had I followed this advice instead of simply diving in after working through an Eclipse introduction tutorial I would have saved myself much time. The rest of these two books can be used as reference.

The third book, "The Definitive Guide to SWT and JFace", is where to go if you need more help with Eclipse user interface classes than the JavaDocs and Eclipse help. SWT and JFace are too rich to really cover in anything but a book dedicated to the subject.

If you already know AWT and Swing you probably won't need "The Definitive Guide to SWT and JFace".

Posted by Bill Blalock on January 21, 2007 at 1:36 PM | Comments (1)

December 14, 2006

Do not be deafened by the fanfare..

In all the fanfare Eclipse RCP has received there are a few things to bear in mind that aren't obvious until you have worked with Eclipse RCP up close and personally.

First, doing things Eclipse’s way is in the best interest of the developer. Figure out how to frame the application design in terms which are compatible with Eclipse. If the design works with the patterns of Eclipse then Eclipse provides a lot of help, development moves right along. If the design works against those patterns then Eclipse can get in the way. The moral is “every rich client application is not a candidate for Eclipse RCP.�

In terms of program maintenance and enhancement the patterns and structures imposed by Eclipse RCP works to the developer’s advantage. An Eclipse RCP application is governed by structures following life-cycle. Plug-ins are loaded under known situations in a specified order. There is lots of structure. Certain Eclipse classes have to be implemented. A developer coming in to maintain or extend an application developed with Eclipse RCP has a roadmap of how it was put together. Consider a purely Java application, all you can say for sure going into it is that the class executed by java.exe must have a main() method.

Second, Eclipse RCP still shows its heritage as an IDE tool. The good news is that it gets better each release. Some examples:

- the “current directory� starts out as .metadata, you have a .metadata folder whether you want one or not
- the fonts of the menu and pull downs are fixed
- the Eclipse RCP is going to revert to logging events in .metadata/.log, those names are hard coded.

Some would argue that a third “downside� to keep in mind is Eclipse RCP UI is based on the Eclipse SWT and not JFC (Swing). SWT, Standard Widgit Toolkit, is the UI presentation layer IBM developed for Eclipse then donated. There has been much controversy and Swing vs SWT discussions. I won’t get into that UI toolkit battle here except to say I am on the Eclipse SWT side.

The concern is the developer has to learn a second UI toolkit. In the last two years Eclipse has made it easier to bridge this divide. The class SWT_AWT has been available since Eclipse 3.0. SWT_AWT supports embedding Swing/AWT widgets inside SWT widgets.

Eclipse RCP gives you tools to produce high quality rich client applications but it does place constraints on the developer. I think that those constraints are more than compensated by what Eclipse RCP provides.

What do you think?

Posted by Bill Blalock on December 14, 2006 at 6:07 AM | Comments (0)

December 10, 2006

Options for creating Rich Client applications

The term "rich client" does not imply a particular technology. "Rich client" only implies a modern desktop application development technology which can produce a client with a "rich" graphical user interface. Consider the choice before you when exploring "rich client options."

Java is not the only language for developing "Rich clients." Microsoft dot Net, C++ and Delphi are other options. But Java is a very appealing choice when you consider:

• complexity


• tools (IDEs and other development support software)


• open source and commercial resources (libraries)


• industry acceptance


• integration with the System i

"Rich clients" can be developed with just Java and Swing (Java user interface foundation class) or SWT (Eclipse standard widget toolkit). The problem is that the developer is responsible for everything! That is a lot of work to do it right. Hey, maybe that is why browser based applications so quickly overtook "fat" client -- server applications?

IBM is developing the "IBM Workplace Managed Client" under the Websphere umbrella to provide "rich" client – server applications. Interestingly enough, it is also based upon the Eclipse toolkit. See

http://www-128.ibm.com/developerworks/lotus/library/wmc-toolkit/

Then there is the topic of this blog, Eclipse RCP … Rich Client Platform. Look at either Eclipse or WDSc. Did you ever think "that would be a cool framework for my application X if it didn’t have all the IDE stuff?" Many of the early Eclipse adopted thought just that. By the time Eclipse 2.1 was released developers of the future Eclipse Foundation were reengineering Eclipse to separate the user interface and IDE parts. I believe this was in the 2nd half of 2004. In Eclipse 3.1 the separation was (mostly) made.

Eclipse RCP is the set of plug-ins which are necessary for the workbench and user interface. The developer creates plug-ins for application logic which make use of the RCP plug-ins for the user interface. The functionality of menus, status lines, editors, views and much more are provided. The developer focuses on the application specific code.

Anyway, enough said. For more information see:

http://www.eclipse.org/home/categories/rcp.php

Posted by Bill Blalock on December 10, 2006 at 11:25 AM | Comments (1)

December 4, 2006

Welcome to the Exploring Eclipse RCP Blog

I started on the AS/400 in 1988 and have worked continuously on the platform. The bulk of my experience is with RPG and System i integration. I started working with Java on the System i in 2001. I missed Visual Java and used CODE as my IDE. I started using Eclipse 2.0 for Java development in early 2003.

I am not claiming to be an expert on Java, Eclipse, or Eclipse RCP. Each time I have a new application, I find myself on the Sun and Eclipse forums along with my visits to System iNetwork. Frankly, at age 54, I find learning and applying Java quite a challenge. But I have spent time in the trenches and deployed Java applications.

My BS is in accounting, University of Kentucky, 1976. My MBA is from the University of Dayton, 1985 (not that either make much difference after all this time). I currently work for a System i company in the financial services sector. This blog represents my views and not necessarily those of my employer.

As I humm the tune "Everything old is new again," I'd like to begin with a question:

Do "Rich Clients," aka "Fat Clients," have a place in the tools available to the System i shop to extend selected functionality to the desktop?

Obviously I think so or I wouldn't be putting time into this blog. Or has the browser triumphed? Are "Fat Clients" that access functionality of the System i relics of the past? Am I wasting my time and yours as you read this blog?

Please notice that the initial question is "extend selected functionality of the System i to the desktop?" It took a while to compose that sentence.

"Selected functionality" is not "provide a GUI interface to a 5250 display." Certainly there are better tools than a desktop client to GUI-ize a 5250 display, and most of them are browser based.

Consider two tool sets that provide us the means to create System i programs: PDM and WDSc. PDM is 5250 based. The processing, member updating, syntax checking, compiling etc. takes place on the iSeries. If a GUI presentation of the PDM 5250 displays were required then a browser-based solution would be just the ticket. The browser on the desktop handles the user interface, replacing the 5250 display. The rest remains as it is.

WDSc is a completely different approach to a similar task. In addition to moving the user interface from 5250 displays WDSc moves much of the function from the System i to the desktop. WDSc is a "fat client." A client which "extends selected functionality" of the System i to the desktop."

Most GUI interfacing tasks for System i applications are done well, perhaps even best done, with some type of browser based technology.

But I argue that a "Rich Client" should be considered when an application is to be developed which can make good use of desktop capabilities for the benefit of the user or business. The "desktop capabilities" I refer to are
- functionality of the OS and desktop
- the processing power and memory of the desktop platform
A browser-based approach does not make use of the power of the desktop platform and provides only some of the functionality of the OS and desktop, but not all or even most. Again, consider WDSc. Imagine what it would look like, and perform like, if it were browser based?

Browser based applications certainly have many advantages of a desktop client. These advantages are overwhelming when the application is to give 5250 displays a GUI interface or simply to provide a GUI front end to a System i application. Still "Rich Client" applications have these advantages over browser-based applications:
- "Richer" functionality, browser-based applications are limited by HTML standards and components.
- More components to choose from (tables, calendars, dialogs, built-in editors and even operating specific capabilities such as Active-X controls)
- Better usability: menus, hover help, icons, multiple buttons and control styles
- Can have multiple GUI tasks are going on at the same time, or be multi-threaded from the end-user perspective
- Browser-based applications generally require server applications and some infrastructure on the System i which may not be a cost effective solution if only a limited set of System i functionality needs a GUI presentation.

These advantages give "Rich Clients" a place in the System i tools.

In this blog, I want to explore with you using Eclipse RCP for making "Rich Clients." I want to have a place where that small group of us who both develop Java client and System i applications can meet and share our experiences with the Eclipse tools. I invite your active participation!

Posted by Bill Blalock on December 4, 2006 at 4:53 PM | Comments (5)