Public Art Clustering

One problem with the map application is that there are tons of public art in any given area, and sometimes there are more than one public art in the exact same place. One way to solve this is to cluster the public art to not only speed up transactions but to create more readability.



Figure 1 -
This image depicts points within a certain radius being connected. From here we calculate how many other points each one touches.



Figure 2 -
The points are sorted by how many connections they have, and then for every point that one connects to, we disable so that another point may not connect to it, and so that it cannot connect to other points. Using this method we can group the most amount of points into each cluster, minimizing the number of clusters. The above image is 'unweighted' such that the circle or cluster point is not at the center of mass.



Figure 3 -
This image depicts the clusters at center of mass.

Venice Web Client Ported to Maven2

Formerly known as VeniceClient is now the new VeniceWebClient project. It has successfully been ported to the maven2 project. It uses the VeniceWebService to access the database through the framework. It can be accessed here as it has been deployed already here

Venice Web Service Project Ported to Maven2

Formerly known as VeniceFrameworkWebService is now the new VeniceWebService project. It has just been committed to the repository. We had been thinking about porting the Netbeans project to maven for a while now, seeing that there were two major problems with the status quo.

1. Integrating the framework and the webservice would be difficult if the projects were using different build tools (one Ant w/convoluted Netbeans artifacts, one with maven2).
2. The framework needed to be built seperately, copied over to the webservice folder. There was an anomaly which resulted in ~20mb war file even though the framework was only about 9mb

Since both projects are now maven2 projects, one can be the parent and the other a module. This way they can share dependencies as well as share each other's source files cross-project--which was exactly what we needed. This is also means that using one single maven command, the developer can build both the framework and the webservice and subsequently deploy them.

The VeniceClient is still a Ant/Netbeans project, we are hoping to port this over soon so that all three projects are under the same build tool.

The ultimate benefit is that all projects will be IDE independent as well as cross-platform.

Write once, run anyway anywhere!

Embeddable Public Art

An embeddable version of the Public Art application has been created, and it can be seen below!

One New Web Client

For this week's meeting with Professor Carrera, we made a couple of front ends to demonstrate the extensibility of our framework. The applications show different ways that Municipal Data Objects (Public Art in this case) could be displayed to varying end users.

One of the web clients that we made is a proof of concept of our web service. It is laid out in an archival format, and allows users to search through Public Art objects either by entering an ID or by hitting previous and next buttons. Upon clicking one of the buttons/links, an AJAX request is sent from the .jsp to a servlet (the server-side of the client...yes we know that is kind of confusing). The servlet parses the request and sends a SOAP request to the web service, which in this case is located on the same server as the Client but does not need to be as it is a wholly separate entity. The Web Service is an (proof of concept) application built using the Venice Framework, and thus calls methods in the framework to fulfill the SOAP request. The Web Service then takes the Java objects that it is returned, converts them to XML, and sends them off in a SOAP response to the server-side servlet of the web client. The servlet then parses the XML response and sends out a JSON-encoded AJAX response to the .jsp which displays the results.

This application can be accessed here. Please disregard the absurd loading .gif...it is in the wrong div.

VeniceClient updates

Today we made some progress with the VeniceClient web client. The front-end .jsp now communicates effectively with the VeniceTestServlet (kind of a stupid name in retrospect) using AJAX aided by the technologies JSON and Prototype. The client does not currently display anything, but we will have one or two front ends to demponstrate by the meeting with Professor Carrera tomorrow.

Solution to Blocked MySQL in University

We've had this problem for a while now. When we work in the IUAV, we have excellent internet connection but the MySql connections are blocked off. This makes it hard for us to do testing beyond using HSQLDB + DBUnit + JUnit. The first part of the solution is to tunnel the connection through SSH. In order to do this...

1. Ping the server (your.server.net), get the actual IP and copy it somewhere (this will be explained later)
   
2. Start putty
3. Put the actual IP into the hostname field
4. Under the tree menu, goto Connection-->SSH-->Tunnels
5. For Source Port, put the "MySQL port" (default: 3306)
   
6. For Destination, put "localhost:MySQL port" (default: 3306)
7. Now connect to the server and login
8. Your computer's port MySQL port should now be the server's tunneled MySQL port. You can now connect to it using MySQL admin tools

This was all well and good that we could connect to localhost:3306 to access the MySQL database remotely, however, we this still meant we had to change all of our project configurations to adapt to the change of the hostname from your.server.net to localhost. This was feasible, but not practical. So instead, this is what we came up with.

1. For Windows OS', navigate to C:\windows\system32\drivers\etc and find the hosts file
2. Open the hosts file with notepad
3. Append "127.0.0.1 your.server.net" to the end of the file
4. Change all Non-tunneled connections to the actual IP address of your.server.net so as not to connect to yourself at 127.0.0.1 (e.g. pinging your.server.net would not work with the host file changed)

Since the change is made only in one place, it makes it much easier to do the testing and it means less errors switching around configurations all the time.

Photos up on the server

The photos have all be uploaded and made available on our server (slocketrocket).

http://slocketrocket.res.wpi.net:8080/photos/

We are working right now on getting photo information retrieved properly in our framework (hibernate issues) and we should have everything integrated soon.

Relating Photos and MDOs

We had to make a decision regarding MDO objects and how they would be related to pictures. We decided that pictures will be hosted on the server separately from the database. Each photo has have a unique filename. The Photo table in the database has a unique id, a description, and the unique filename. This table is related to MDO in a relational table that has both ids.

The issue we had was with the initial population of the relational table. Previously, PublicArt objects had a value called 'c2kid' which was also used for the names of the images. They still have this 'c2kid', but the id is no longer used directly to access the images. Instead, we inserted new Photo rows into the Photo table for each PublicArt row, using the 'c2kid' as the name. We then inserted a relation into the relation table for each matching pair of 'c2kids' (PublicArt and Photo).

Using this method, we were able to populate the database while keeping a general format for the relation between the two classes instead of using an arbitrary string ID that is unique to PublicArt.

Praha uno

A bit off-topic, but here are some pictures from our recent trip to Prague:

End to End Web Service Working

We were able to get the Framework all .jar'd up and put into the web service. We then did a bunch of compliance testing and got them communicating with each other. The web service can now retrieve data from the database. The client now allows a user to enter an ID, and it will retrieve from the database the PublicArt object of that ID. This marks a giant leap forward because it demonstrates how our framework will be implemented into applications, such as the PublicArt web service or the Admin Console.

The link for this functionality is here. Note that this overrides the previous web service, so you can no longer multiply numbers by two.

More work on the MQP report

A folder in SourceForge has been created to hold all of our documents related to the MQP report. I have uploaded drafts of both our Introduction and Background sections of the report. The Background section is still very rough and needs some expansion and reorganization. Right now it clocks in at around 8 pages. Both documents are in .doc format.

Building the Framework

Yesterday, we attempted to build the framework and include it in the web service project. We were able to get the .jar file just fine, but the web service would not deploy correctly. After hours of confusion, we gave up for the night. Today, we had a thought: perhaps the dependencies for the framework were not being accurately compiled into the .jar file. Upon further investigation, we found that this was indeed the case. It turns out Maven does not build the dependencies into the .jar by default. Some web research determined that there is a plugin that makes it easy for Maven2 to build the dependencies into the .jar. We found the link referenced here.

Web service deployed to development server

"Currently, the web service 'PublicArtByID' does nothing but take an int parameter, double it, and stick it in the id of an outgoing XML representation of a PublicArt object. The Client currently takes an integer parameter from the user (no checking or anything) and invokes the Servlet, which sends it to the service. When the Servlet gets a response, it prints out the result."

This functionality can be accessed here.

Finally implemented a client for the web service

After 4 long days of attempting to use the nuSOAP PHP library to create a client, we stumbled upon this gem of a tutorial on creating Java EE web service clients. It is so darn easy. Our test web service client project, VeniceClient, has been uploaded to the SF repository. Creating a basic barebones client for a web service (or several web services) takes under 10 minutes.

Currently, the web service 'PublicArtByID' does nothing but take an int parameter, double it, and stick it in the id of an outgoing XML representation of a PublicArt object. The Client currently takes an integer parameter from the user (no checking or anything) and invokes the Servlet, which sends it to the service. When the Servlet gets a response, it prints out the result.

This functionality can be accessed here. That is running on our development server in Worcester.

SOAP and REST

Over the last iteration, we have relieved numerous questions regarding which web service technology is more appropriate for use with the Venice Framework. We decided to take a day to research the technologies, and produced the document available here. In short, both technologies have their advantages and disadvantages. In terms of what we see as being the end product, we have decided that SOAP more appropriately fills our needs because it allows for more complex communication between the service and the client.

Web Service Work

Today, we were able to successfully get our Web Service working and tested in soapUI. The Web Service itself still had some very annoying namespace issues to work out, but after that was cleared up, our test of the service worked perfectly. Justin is now working on getting a simple php application to interact with our service remotely, since this is likely what we will be doing when we develop our proof of concept application (which will show off both our framework and web service layers).

More posts to come later.

Tests for PublicArt

We have just completed the various tests for PublicArt which completes all of our trackers. We have been thinking what the best way to write the tests are. The recommended way that DBUnit does is to have a sample dataset, run some tests that will change the dataset, then use an "expected" dataset and compare them with the methods DBUnit provides to compare two datasets. The problem with this approach is that for each test we would have to generate an XML file to compare the resulting dataset. This would end up generating literally hundreds if not more xml files that need to be uploaded into the SVN. This may make sense for a large test that represented a complete use case, but not small tests of functionality. The second problem is that it would not really test our model/framework. As per the Hibernate article here http://www.hibernate.org/109.html on Equals and Hashcode, we implemented the methods for eaach model object so that duplicate objects are not generated as well as providing a explicit way for our tests to compare objects. The general manner in which the tests are written are as follows:

1. Generate a PublicArt Object
2. Start a Transaction
   
3. (optional) Save the PublicArt Object
4. Commit the transaction
5. Open a new Transaction
6. Load a new PublicArt Object from the database
7. Compare the two objects to each other
8. End the Transaction

This ensures that the object saved and the object loaded are one and the same in terms of both hashcode() and equals(). We are considering other methods of testing that we may need in order to cover more ground in terms of stressing the framework and testing it's versatility.

Calling SOAP Web Services

Today was the first day of Iteration 2. Since our meeting with Fabio isn't until tomorrow, we took it upon ourselves to work on the trackers that absolutely must be in with this iteration. One such tracker is here. this tracker deals with creating a skeleton client that will access our web service.

We found an article, located here, that gives a good tutorial on how to call SOAP-based web services using straight-up HTML and JavaScript. There is another library, used here, that we found to be of interest as well. We have begun creating a simple web application based on the examples provided in those article.

Work on second section of report

One of the things that we worked on today was organizing for the second section of the report, which we hope to write this week while we are also working on the framework. I've uploaded our two-page outline of the second section of the report to SourceForge here

Comments are welcome since we are going to be writing the document during the rest of the week. We have also been trying to get academic resources as reference through the WPI library site, although it is difficult to find good resources on there.

Wrapping up Iteration 1: Web-Service portion

This week we successfully completed 35 units of work for iteration 1. This closed 5 trackers.

On the Web Service Layer, we were able to create a skeleton Web Service built on the SOAP xml protocol. Netbeans has a generator for projects like this, but it took a lot of customizing to get it to fit our project. We had to write our own WSDL and XSD files. The WSDL describes the service itself, and the XSD describes the data returned by the service. The service successfully builds and deploys in GlassFish, and we are currently looking for a good web service tester to simplify the testing process.