System iNetwork

February 2007

February 28, 2007 8:20 PM

A quick review of MVC

MVC stands for Model-View-Controller. Desktop clients for the System i should be implemented with the MVC design pattern and not use the System i simply as a data base server.

Wikipedia defines MVC as

"an architectural pattern used in software engineering. In complex computer applications that present lots of data to the user, one often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface do not impact the data handling, and that the data can be reorganized without changing the user interface. The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction....

Model --
The domain-specific representation of the information on which the application operates. The model is another name for the domain layer. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes and shipping charges for shopping cart items).

View --
Renders the model into a form suitable for interaction, typically a user interface element.

Controller --
Processes and responds to events, typically user actions, and may invoke changes on the model. "

The Model runs on the System i, it is the business logic and data access of the applications. The Model, business logic, is easily kept separate from the presentation (view and controller).

The desktop client is the View-Controller. It displays the data and interacts with the user.

A View is not easily separated from the Controller. Consider two common views, a web browser and a 5250 display. The same Controller can't operate on both Views. The View part is defined by the physical and logical display. The Controller has to interact with the View. The Controller and the View need to "know" about one another. But both pairs of View-Controllers could work with the same Model.

Typically each View has its own Controller. The Controllers for separate Views may share logic and components but they are differentiated by the requirements of the physical view that they control, process events of and respond to.

Sometimes the View and Controller must be implemented separately. That is the case with a web browser. The browser is the view. The Controller can be a CGI program or web services on the server which generates the HTML for the browser and responds to the POST and GET from the browser.

In other cases, such as a 5250 display program, it makes sense to implement the view and controller together. We will combine the view and controller with the Eclipse RCP client.

It is easier to get and manipulate the data within the Eclipse RCP client using SQL or record level access of the Java toolbox. It is also easier to write a 5250 program which does its own data base IO and handles its own data base logic. Think carefully before taking the easy way.

Posted by Bill Blalock on February 28, 2007 at 8:20 PM | Comments (0)

February 25, 2007 5:00 PM

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 12:03 PM

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)

February 4, 2007 6:07 PM

Beyond JTOpen -- the iSeries Runtime API

Writing Java rich clients for the System i, or just plain Java application, you sometimes want more than what is available from the IBM Java toolbox. WDSc includes the iSeries Runtime APIs. I have found these useful in developing rich clients, particularly when the application needs the information about System i resources.

IBM Websphere Development Studio Client (WDSc) has a set of APIs tucked away that go beyond the Java Toolbox. The title of the javadoc overview page is iSeries Runtime API. This dates these java classes. The original Java toolbox classes incorporate "AS400" in the name of the classes. These APIs refer to the platform as "iSeries." I wonder how will future APIs refer to the platform ... Systemi ... System_i ... "System i?" Hmmm.

Anyway, I digress. This package of APIs can be used outside WDSc, at least as far as I have been able to tell. The README html of the communication package says:

"This package is designed to be standalone and not dependent on anything in the IDE or the systems packages. The idea is that this package constitutes the new AS/400 communication layer, leveraging only the AS/400 system APIs and commands executed via the AS/400 Toolbox for Java, which is the one single dependency of this package."

The author is decidedly old school.

The package has three parts:
- communications
- user interface
- utilities

The communication and utilities parts are in one jar file, iseriescomm.jar. The utilities are in iseriesut.jar.

The communication part is in three package
- com.ibm.etools.iseries.comm
- com.ibm.etools.iseries.comm.filters
- com.ibm.etools.iseries.comm.interfaces

The user interface is in the package
- com.ibm.etools.iseries.ui

The utilities is in the package
- com.ibm.etools.iseries.util

What is in these packages? Go look for yourself!

For WDSc versions 4.x or 5.x they in in this folder under the installation folder ...

install_folder/iseries/eclise/plugins/com.ibm.etools.iseries.toobox_version

For WDSc 6.x they in in this folder under the installation folder ...

install_folder/rwdi_shared/eclipse/plugins/com.ibm.etools.iseries.toolbox_version

For all releases the jar archives are in the runtime folder beneath this folder. The javadocs are in the file doc.zip file in this folder.

WDSc 4.x and 5.x default installation folder is
C:\WDSC

WDSc 6.x default installation folder is
C:\Program Files\IBM\Rational\SDP\6.0

If you ever need access to a System i resource that you can't quite get from jt400.jar try the iSeries Runtime APIs. For example, using jt400 you can get the names of database fields, their type and length. That is about it! With iseriescomm.jar you can get everything for the database which was defined in the DDS! Nice.

Questions or comments?

Posted by Bill Blalock on February 4, 2007 at 6:07 PM | Comments (1)