Bean Description And Use

This project involved creating five beans using Java, and assembling them into two applications that transfer data through sockets.

Requirements

The implementation associated with this project shrank due to a need to spend increased effort on exploring different builder tools and Security manager functionality. As this happened, the requirements changed from specifying what each bean needed to provide to a more general requirement that the set of beans together provide enough functionality for proof of concept. The requirements became:

• Provide a set of beans that can be assembled into two applications: one that reads text from a file and sends the text to a socket, another that accepts a socket connection and writes any incoming text out to a text file.
• Make the design as general as possible to support: additional sources and destinations for data, and enhancements to the individual beans to make them more flexible.

Fortunately I had done significant design work before hitting the implementation crunch, so I was able to take the generality requirement to heart. This requirement is met primarily in the design for how the components communicate.

Bean Design

Five beans comprise the set of components for building the transfer applications. A description of each follows.

• FileReaderBean Opens the file specified in the fileName property for reading and calls the gotIStream() method on all listeners, passing the InputStream for the file with the event.
• Listeners: IStreamListener
• Public Methods: requestFile()
• FileWriterBean Opens the file specified in the fileName property for writing and calls the gotOStream() method on all listeners, passing the OutputStream for the file with the event.
• Listeners: OStreamListener
• Public Methods: requestFile()
• IncomingSocket Waits for connections on the port specified in the port property. Creates a socket when a connection is requested, and calls the gotIStream() method on all listeners, passing the InputStream for the socket with the event. This bean is really a server socket, specialized to only take incoming data.
• Listeners: IStreamListener
• Public Methods: requestConnection()
• OutgoingSocket Opens a socket connection to the server specified in the address property at the port specified in the port property. Calls gotOStream() method on all listeners, passing the OutputStream associated with the socket. This bean is a socket specialized to only send data out.
• Listeners: OStreamListener
• Public Methods: requestConnection()
• DataSwapper Requests an InputStream and an OutputStream from its listeners and when both are obtained, reads data from the InputStream and writes it to the OutputStream.
• Listeners: IStreamListener, OStreamListener
• Public Methods: performSwap()

Event Design

The events generated by the beans correspond to the methods in the IStreamListener and OStreamListener interfaces. Each bean allows registration of listeners that implement one or both of these interfaces.

• IStreamListener Beans which request or provide InputStreams allow registration of listener objects which implement this interface. This interface includes the following three methods:
• getIStream(StreamEvent e) This event is a request for the listening object to obtain an InputStream by whatever means it tends to do such things. For example, the FileReaderBean would obtain an InputStream by opening a file for reading.
• gotIStream(StreamEvent e) This event is a notification that an InputStream has been obtained. The new InputStream is encapsulated in the passed StreamEvent. Only one listener for this event is allowed, since having more than one would interfere with reading from the stream.
• doneWithIStream(StreamEvent e) This event is a notification that the InputStream is no longer needed by a listener that acquired it via a gotIStream(StreamEvent e) event. This allows the provider of the InputStream to clean up any system resources. For example, the FileReaderBean would listen for this event so that it could close the file when the user of its InputStream is done reading data.
• OStreamListener Beans which request or provide OutputStreams allow registration of listener objects which implement this interface. This interface includes the following three methods:
• getOStream(StreamEvent e) This event is a request for the listening object to obtain an OutputStream by whatever means it tends to do such things. For example, the FileWriterBean would obtain an OutputStream by opening a file for writing.
• gotOStream(StreamEvent e) This event is a notification that an OutputStream has been obtained. The new OutputStream is encapsulated in the passed StreamEvent. Only one listener for this event is allowed, since having more than one would interfere with writing to the stream.
• doneWithOStream(StreamEvent e) This event is a notification that the OutputStream is no longer needed by a listener that acquired it via a gotOStream(StreamEvent e) event. This allows the provider of the OutputStream to clean up any system resources. For example, the FileWriterBean would listen for this event so that it could close the file when the user of its OutputStream is done writing data.

Bean Communication

Beans communicate by sending events defined in the IStreamListener and OStreamListener interfaces. Figures 1 and 2 show object sequence diagrams for two sample applications using the beans described above. The diagrams are drawn using an attempt at Unified Modeling Language (UML), which has substantial documentation on the web 4 .

The sequence of events is initiated by the user pressing a button. This event calls the processSwap() method on the DataSwapper bean. This bean then requests an InputStream and an OutputStream from its listeners and waits until they are both obtained. When both an InputStream and OutputStream are received (by listening for gotIStream() and gotOStream() events), the DataSwapper reads text from the InputStream and writes it to the OutputStream until encountering the text "bye". At this point the DataSwapper generates doneWithIStream() and doneWithOStream() events that allow the listeners to free system resources.

 

 

Assembly And Use Of Beans

To create an application with the provided components, you need a bean that generates a user event, such as a Button, a DataSwapper bean, a bean that provides an OutputStream (OugoingSocket or FileWriterBean), and a bean that provides an InputStream (IncomingSocket or FileReaderBean). Drag one of each of these beans off the palette and make the following connections:

• Connect the user event to DataSwapper.processSwap()
• Connect the DataSwapper to the bean providing an InputStream:
• Connect DataSwapper.IStream.getIStream to (InputStreamBean).request[File | Connection]()
• Connect (InputStreamBean).IStream.gotIstream to DataSwapper.gotIStream()
• Connect DataSwapper.IStream.doneWithIStream to (InputStreamBean).doneWithIStream()
• Connect the DataSwapper to the bean providing an OutputStream:
• Connect DataSwapper.OStream.getIStream to (OutputStreamBean).request[File | Connection]()
• Connect (OutputStreamBean).OStream.gotOIstream to DataSwapper.gotOStream()
• Connect DataSwapper.OStream.doneWithOStream to (OutputStreamBean).doneWithOStream()

Click on each of the beans and set any properties that need to be configured. The following beans have properties that can be set:

• FileReaderBean
• fileName: The name of the file to open for reading.
• FileWriterBean:
• fileName: The name of the file to open for writing.
• IncomingSocket:
• port: The port number at which to have a socket server wait for connections.
• OutgoingSocket
• address: The text address of the remote machine to connect with.
• port: The port number to connect with on the remote machine.

Software Process

The software process for this project was complete chaos. I started out with a pretty good set of requirements from which I created the design I presented in my 12 March 1998 Status Report. I drew diagrams of this design by hand using a mix of OMT 5 and Booch 6 notations. I was intending to formalize the requirements at about the time that I felt inclined to do a test implementation to head off any major roadblocks. At that time I encountered my first frustration with the Java security model which continued for a solid four weeks. I spent all my resources figuring out a solution to the security problems, and software process suffered.

I think it's worth mentioning that it's very hard to maintain a formal software process in the face of the unknowns and lack of support that accompany immature technology. Spending time on formalizing requirements, design, implementation, integration, and testing doesn't make any sense if an unexpected roadblock exists that prevents integration. It makes me wonder if the move towards software "engineering" was to some degree made possible by using languages and development environments that were more or less known quantities. The formalization of the software development process may have to backstep somewhat when new technologies and new paradigms for programming are introduced.

The immature quality of the Java technology also affects the size of the increments in which I develop. During MP2 for this course I first did enough work with beans to get a sense for how they work, then coded up a large portion of my solution. I had to undo all that work and come up with a new design because a bug in the BDK didn't allow the serialization of arrays of objects. For this project I never took that risk -- I developed in very very small increments and fully tested each addition by assembling the changed components into an application. This approach is very slow, but it's faster in the long run if a problem arises.

Java Experiences And Frustrations

My struggles with Java during this project were primarily associated with the security model, as I was never able to create an applet or stand-alone application that included my socket beans. Instead, I ran my applications directly from the BeanBox, because it circumvents the security model limitations.

The following items enumerate my attempts to create applications which include the socket beans, and the reasons I gave up on each:

• Run Applet Generated From BeanBox

This approach does not work because applets are not allowed to connect with any host other than that from which the applet was downloaded.

• Use AppletViewer

This approach allowed me to run an applet which included an IncomingSocket bean. But as soon as a client connected to the port where the IncomingSocket was waiting, the applet exited with the exception: "sun.applet.AppletSecurityException: checkconnect.networkhost1." This is related to the relationship between applets and network connections mentioned above.

• Convert Applet To Standalone Application

I tried at least two different ways of converting applets generated from the BeanBox to applications. Both of them failed with the following exception: "java.net.MalformedURLException: systemresource:/ZIP5/+/: java.lang.SecurityException: systemresource:/ZIP5/+/ refers to a non system resource." My impression is that the BeanBox does something fancy when it creates applets that does not lend them to conversion to applications.

The two approaches I tried for converting the applets to applications were: 1) adding a main() method to the applet, and 2) wrapping the applet in an extension class that instantiated the applet within a frame 7 .

• Use Netscape Capabilities API To Enable UniversalConnect

This attempt represents many long hours that ended in a dead end that I suspect is purely due to encountering something that has not yet been implemented. I downloaded Netscape's Capabilities API from their web site and embedded code in my applet to enable the "UniversalConnect" privilege. I ran my applet through Netscape, and when the applet was loaded a dialog appeared to prompt me whether I wanted to enable this privilege. I responded positively and the applet failed with a security exception.

I suspect that this privilege is not yet implemented in the Capabilities API, but I couldn't find any information on the web about it. People I have spoken to have used the Capabilities API to successfully allow applets to write to local disk.

• Use HotJava To turn Off Security Limitations

I downloaded HotJava 1.1.2 and looked into using the security manager to allow my applets to connect to remote hosts. The only way to do this seems to involve using signed applets, for which HotJava allows you to enable certain privileges. I spoke with people who had spent a lot of time trying to get a universal signature for some of their own applets, and abandoned this approach.

• Use JavaWorkshop To Build Stand-alone Applications

I downloaded Java-WorkShop2.0 from the SunSoft site and tried to use it to create some stand-alone applications with my beans. This worked fine until I went to connect two beans together in the GUI builder. At that point I discovered that Java Workshop uses some Paleozoic event model to connect components. To make the connection I desired, I would have had to call a method on a global "group" object in the application. I would also have had to register all my components with the group object. From the group object I would have to look up the bean that I was trying to send a message to, and call a method on it. None of this is supported in the GUI builder -- I would have had to implement it by writing code. This was such a radical departure from my goal to "rapidly develop custom applications" that I gave up on this approach.

Had I more time, I would have done more research on GUI builders that support the BeanBox-style assembly of components. Oracle's AppBuilder apparently has a nice interface for this kind of assembly, but it is very expensive. SuperMojo has some sort of support for this, but I downloaded a trial copy of the software from Penumbra's site and had little luck exploring its functionality. SuperMojo is written all in Java, but for some reason runs only in Windows (?), and it died three times on me before I gave up and decided to keep my $99.99 in my pocket.

New Skills And Knowledge

This project provided great opportunity to learn new skills and gain knowledge of Java. These range from practical, concrete skills to very abstract skills in learning new languages and environments.

The most high-level personal benefit from this project was the reminder that learning languages/development tools can be a real struggle. Though this idea isn't new to me, I have definitely gotten used to knowing the details of my primary programming language (C++) and have a well-established support structure for when I run into difficulties. I have a new appreciation for how easily and why people get entrenched. It's much more challenging to work with a language that is still in its formative stages, looking at tools to quickly assess whether they are suitable for an intended project. At a minimum these unknowns have to be factored in to estimates for accomplishing the intended project, something I failed to do.

On a more applied level, I finally learned portions of UML to draw the figures in this summary. I had used UML documents to understand designs before, but had never constructed them myself. I made the effort to learn this symbolic language because I was struggling to find a way to represent the interactions between beans in my applications. UML seems awkward to use with threads, because the notion of a single control no longer exists. It was fine for my relatively simple sequence diagrams, but in complex systems I don't think it would be very helpful.

I also gained a much more in-depth familiarity with Java beans. After completing MP2, I had a basic knowledge of the bean model, but this project solidified that knowledge. Now I have a much more intuitive feel for how to design event sets that make sense, and for when threads are necessary.

This project rejuvenated my faith in the web as a source for information to solve problems. In the past my success with using the web to solve problems has been about 50% or less. I mostly resorted to news groups and list servers for this kind of information. But given the broad interest in Java and the rate at which information is being added to the web, I had much more success during this project.

Finally, I learned a huge amount about the Java security model, the intents for tools that provide greater flexibility within this model, and just how many of them are not implemented yet. See the previous section "Java Experiences And Frustrations" for more details on this.

Proposed Improvements

Given the somewhat skeletal implementation that came from this project, there are many things that could be improved. But two improvements come immediately to mind because they were on my wish list, so the design of the beans would easily allow them.

First, the IncomingSocket and OutgoingSocket should be generalized to allow bidirectional data transfer. This would result in two different beans, a SocketClient and a SocketServer, which could each provide both an InputStream and an OutputStream. In the current implementation, the OutgoingSocket is a SocketClient arbitrarily limited to providing an OutputStream. The IncomingSocket is a SocketServer that only produces an InputStream. There is no reason for these restrictions, except lack of resources to implement the more general solution.

Second, the DataSwapper should be generalized so that user action is not needed to initiate a data transfer. I can see a total of three paradigms that the DataSwapper could operate under:

• Transfer Initiated By User Action

This is the current implementation. The user must press a button to initiate a transfer. The DataSwapper then requests an InputStream and an OutputStream and performs the swap when both are acquired. When the transfer is complete the DataSwapper waits for user action again to initiate another transfer.

• Transfer Initiated By Acquiring InputStream

This would be very useful for the IncomingSocket transfer bean. In this case, the DataSwapper would ask for an InputStream on start-up, and wait for that InputStream to be acquired. When the InputStream became available, it would request an OutputStream and transfer the data.

• Transfer Initiated By Acquiring OutputStream

This would be very useful for the IncomingSocket transfer bean when it is generalized to be a SocketServer. In this case, the DataSwapper would ask for an OutputStream on start-up, and wait for that OutputStream to be acquired. When the OutputStream became available, it would request an InputStream and transfer the data.

20% Implementation Of Proposed JavaBeans Components

10% Implementation Of Proposed Data Transfer Applications Or Simple Test Application Using New JavaBeans

70% Written Final Project Summary

10% Technical Documentation Describing Functionality And Use Of Beans.

10% Software Process Description -- Design Process And Tools, How Design And Implementation Fit Together, Proposed Improvements For Future Projects.

20% Enumeration Of New Skills Acquired Through Completing This Project.

20% Specific Statement Regarding Applicability Of Socket Components With Generalized Interface.
NOTE: I would like to replace this item with a detailed description of obstacles and attempted solutions for getting the sockets to work within the security model. This seems more useful to the intended readers.

10% New Insights On How Work Might Be Improved, How Java Tools Could Be Improved To Make Implementation Easier, And My Personal Reaction To Working With Beans.