|
|
A First Look into VisualAge for Javaby Bob Brodd and Mark Lorenz |
What is VisualAge for Java?
So, how does this differ from the many other products on the market? Past history of VisualAge products says that VisualAge for Java will reach more platforms, include more base product capabilities, and scale better than competitive products. Why should you consider VisualAge for Java?The following sections of this article will examine some of the unique aspects of the VisualAge for Java product. Visual programmingAs the name implies, the VisualAge family of products are designed around a visual programming paradigm of making connections between reusable parts. In the case of Java, these parts are beans (more about this later). The connections use the public property, event, and method features of the parts. Figure 1 shows an example of visual programming within a view part of an application package. The exact amount of programming that can be done visually versus through "scripting" (a generic name for coding in a target language) is debatable. However, connecting together parts through well-defined public features requires less skill and can be done more productively than coding by hand. Rapid development environmentThe VisualAge for Java tools are the closest thing to a Smalltalk development environment that I've seen (for you C++ developers - that's a compliment). You have incremental code compilation and immediate feedback (see figure 2). You can also change code in the debugger, visually set and clear breakpoints, write and execute code in the scrapbook (figure 3) (Smalltalk programmers can relate this to executing code written in a text window such as the Transcript), view the class hierarchy, create code via wizards (figure 4), and visually discern attributes such as public and static. And that's just a short list of some of the capabilities. One area worth taking a look at is VisualAge for Java's support for the Java 1.1 event model. VisualAge for Java generates all required Listener code for you as you go (you should review the Bank/ATM demo application that accompanies this article to see detailed examples). As events are promoted (made publicly available), this code is also generated in an Interface. Any client part that utilizes this part also has all appropriate methods generated to support the Listener Interface. Open architecture based on JavaBeansVisualAge for Java has an open architecture. For Java, this means that the product is fully bean-enabled. The VisualAge for Java environment, like all VisualAge products, is a construction-from-parts paradigm. This requires parts with well-defined public features. In Java, the parts are JavaBeans. The public features are defined by the JavaBean Application Programming Interface (API) and coding standards. What this means is that VisualAge for Java is an open environment, enabled to virtually any JavaBean built by anyone, anywhere. The bean architecture is designed to make it easy to build visual programming tools. VisualAge products that support other languages, such as Smalltalk and C++, have had to build these capabilities into the products themselves. That is why you find tools such as the Public Interface Editor (PIE) there, and you won't find them in the VisualAge for Java product. The Visual Composition editor adheres to the JavaBean naming conventions and event-handling mechanisms in its generation of code from the visual specification. It also includes the ability to customize the JavaBean interface through the BeanInfo editor (figure 5). The beta does not support the abilty to build Java Archive files from the visual parts. We hope to see this capability in the final product What are JavaBeans?Sun defines a JavaBean as: "A reusable software component that can be manipulated visually in a builder tool." - JavaBean API Specification version 1.00-A, December 4, 1996, section 2.1 Sun further stipulates that the defining features of a JavaBean are support for: · Introspection Introspection is the ability to find out a bean's public interface - its properties, events, and methods. Introspection is accomplished though explicit definition, such as through a BeanInfo class, or through low-level reflection, which uses implicit "design patterns." Don't get confused by the poor choice of terms. Design patterns, as used here, are nothing more than coding conventions. For example, to declare a property as part of the public interface, you simply define "getter" and "setter" accessing methods: public <type> get<Name>( ); // getter accessing method public void set<Name>(<type> aValue); // setter accessing method Similarly, boolean properties use is and set prefixes and events use add and remove prefixes. By default, all public methods of a bean are on the public interface. · Customization Customization means that support "wizards" can be provided to help with development-time use of the related bean. · Event Handling Event handling sets up a source-listener relationship between the bean servicing a request and interested dependent beans. Unfortunately, the event handling code is written by you, but the mechanism is in place to register and manage these dependencies. Often, this mechanism will be used to monitor state changes to properties that affect other processing. The event handling feature includes the requirement to work properly under concurrent, multi-threading situations. · Properties Properties are the state data that must be remembered by the bean in order to do its work. For example, a SavingsAccount must remember its balance. · Persistence Persistence is the ability of a bean to serialize and deserialize itself. This is a fancy way of saying that the object can save its state data as a stream of characters and reinstantiate itself from the same data later. All this capability can be packed into binary .JAR (Java ARchive) files to make it easy for clients to reuse. So, what does all this mean? It means that a standard way for you and I to work together exists. This opens up the possibility of a Java component industry. Team toolsTraditionally, developers have maintained their software assets in library systems, which worked separately from the development environment. Smalltalk developers have become accustomed to integrated team tools, such as EnvyTM. VisualAge for Java uses the Envy environment also, so editions of their projects, packages, classes, interfaces, and methods are kept in a repository automatically as they are changed. These editions can be versioned so they can't be edited again (but can be used to create another edition). A future release of VisualAge for Java will add the full group development support in a server-based repository. In the meantime, this release has a number of single-user development tools. Figure 6 shows how two editions of a method can be compared to see what was changed. You can also edit the editions or load either edition into the workspace. Reaching more platforms and productsOne of the advantages of the VisualAge family of products is the reach they have across platforms. In the beta, VisualAge for Java has the capability to generate code to access relational databases (RDB) and CICS transactions (see figure 7). In the 1.0 release, Java remote method invocation (RMI) will also be supported. If we look at VisualAge for Smalltalk and assume that, as is evident for many other parts of this product, VisualAge for Java will match capabilities, we can expect support for ODBC, MQ, ORBs, and many other industry standards. Distribution of processing - Java Remote Method Invocation (RMI)In distributed systems, communication is key. Java's powerful communication and networking features would seem to make it a natural for distributed computing. However, the problem with using native communication services in a homegrown distributed system is that each component of the system must adhere to an application-level protocol, architected for that particular system. Generality and extensibility are lost. More importantly, the ability to talk to arbitrary new systems is lost as well. CORBA provides the desired level of standardization for remotely accessing objects across a network. Unlike Java Remote Method Invocation (RMI), CORBA's IDL is language neutral. While language neutrality is good in mixed environments, it tends to lose some of the strengths of each language. This would be true of any CORBA implementation for Java. Java RMI addresses the issues of remote object access within the homogenous Java-only environment. By restricting the application to Java, RMI can leverage the Java language and object model. Overview of the RMI SystemThere are three layers in the Java RMI system (see figure 8):
Stub & Skeleton layerStubs or proxies are on the client side, and skeletons are on the server side (see figure 9). A remote object has a stub or proxy in the client's address space that carries out requests on behalf of the actual object in another address space. The skeleton intercepts requests from a remote object going to its local actual object. It will unmarshal the arguments, make the actual method call, and marshal the return value back to the requester. Remote reference layerThis layer abstracts some of the reference details on behalf of the server. It is this layer that is concerned with whether the server is daemon-like (always running, waiting for a request) or if it runs only when a request is made of it. This layer will also determine if the reference is to a single remote object or a replicated object at multiple locations. Transport layerThe communications details are abstracted and handled here. General responsibilities of the transport layer include connection setup, connection management, and target resolution. This layer maintains a table of all remote objects in the address space. Distributed garbage collectionThe Java RMI distributed garbage collection is not perfect. However, the algorithms and implementations will improve over time. The most significant aspect of the Java RMI distributed garbage collector is its mere presence. It illustrates clearly that RMI will not be language-neutral like CORBA, but rather it will build on Java's strengths in providing Java-to-Java object distribution. Java RMI uses a reference counting algorithm for its garbage collection. While there are known limitations to the algorithm, it is far better than not implementing garbage collection at all. The Java runtime keeps track of all local and remote references in each virtual machine. Generally speaking, an object will not be collected if it has either a local or remote reference to it. When the reference count drops to zero, it is placed on the garbage list and will be collected at the next invocation of the garbage collector. Java RMI in AppletsApplets are limited in a variety of ways, making them quite secure. Using Java RMI in the applet environment maintains this level of security. For applets, any class that is needed at runtime is loaded via the AppletClass loader. With the class loader comes the restriction that Applets may only make network connections to their originating host. For this reason, all classes, including the RMI runtime itself, remote user classes, and classes used in method calls or return values must reside on that host. This results in a very secure environment where all classes can be verified and trusted. Web browsers must be enabled for RMI. Since RMI is now part of the Java core, the ability to use RMI in applets across the web should become commonplace. Java RMI in ApplicationsApplications are not limited in their choice of host to make network connections. But the typical Java application does not remotely load classes. In the case of Java RMI, the RMI Stub class loader is used. The Stub class loader is similar to the AppletClass loader, but less restricted. It will not load any class unless a security manager is present in the system. An application's need for classes is satisfied first from the local file system. If not found, then the RMI runtime will attempt to load it remotely. To do this, either the application must know where the required classes are, or the server must tell the client where to find them. What's not so hotOK, so there are capabilities that are unique and valuable. But nothing's perfect, so what needs improvement? Quantity of partsFigure 10 shows the parts that are available on the palette in the beta version of VisualAge for Java. Granted, any JavaBean can also be used, but this is far less than is available in other VisualAge products, such as VisualAge for Smalltalk and C++. To be fair, this is the beta version of the first release, whereas those products are at their 4.0 and 2.0 versions respectively. Team supportThe product has no real multi-developer support built in. This is totally unacceptable in a commercial development product today, but is expected to be remedied soon. The upcoming release of VisualAge for Java, tentatively set to ship in December 1997, will add a much-needed set of team tools. These capabilities are supposed to be similar to those available for VisualAge for Smalltalk, which are based on the Envy tools built by IBM's subsidiary OTI. Conclusions and recommendationsHopefully, we've given you a idea of why you should consider VisualAge for Java. Being a 1.0 release, we fully expect better things to come. But, based on what's available in this release and the track record of the mature VisualAge products, including Smalltalk, C++, and COBOL, we expect VisualAge for Java to be the product to beat in the near future. Take a look for yourself and see if you agree. The beta is free at http://www.software.ibm.com/ad/vajava. Moving to VisualAge for JavaVisualAge for Java will import from .java, .class, and .jar files. In the upcoming team version, you will also be able to work through Envy .dat files. So, moving to VisualAge should not take any significant effort. Where to go from hereTo use VisualAge for Java, get the beta, import your existing Java code and/or beans, and organize a new project for yourself, and most of all … have fun! References"JavaBeans: Cross-Platform Components," Byte Magazine, January 1997. JavaBeans API Specification, SunSoft, version 1.00A, December 4, 1996. "JavaBeans 1.0," PC Magazine, February 4, 1997. Allen, Mitch. "Fresh Ground JavaBeans," Internet Java & ActiveX Advisor, May 1997, pp. 20-3. BDK, http://java.sun.com VisualAge for Java, http://www.software.ibm.com/ad/vajava Remote Method Invocation Specification, http://chatsubo.javasoft.com/current/doc/rmi-spec/rmiTOC.doc.html GlossaryBDK Bean Development Kit. The JavaBean development tools, including the BeanInfo class editor and .JAR file packager. IDE Interactive Development Environment. Introspection The ability to find out a bean's public interface - its properties, events, and methods. JAR Java ARchive. A compressed file format that contains JavaBeans and their related documentation. JavaBean A reusable software component written in Java that supports introspection, customization, persistence, and event handling. JDK Java Development Kit. The base Java development tools, including the class libraries, debugger, and compiler. RMI Remote Method Invocation. A Java-to-Java client-server software distribution strategy. Enjoy the article? Subscribe to Eye on Objects!
|
|
 |
isualAge
for Java is a development environment for building client-server applications
using the Java language and JavaBeans. It includes the Java Development Kit
(JDK), Bean Development Kit (BDK), and visual programming tools. An upcoming
release will include team tools as well.