Friday, December 14, 2007

Final Notes

Since my last post, I discovered a few errors in my Lab 3 & 4. The error reporting from the submit server (lab4) was not according to specs. Therefore, lab3 did not function for error conditions. Once I fixed that, I discovered that the format of the actual message was also not according to specs.

The lesson to be learned here is 1) read the lab specs often and 2) to stick to the specs even if you see something better. The mindset which is needed in enterprise computing is that you are building components that will function in a collective. Therefore, there is an intrinsic coupling which cannot be broken if you intend to function with your neighbors. This coupling is the interface.

My errors weren't because I ignored the requirements, but that I am so used to being autonomous that it did not occur to me that I am dependent on other systems or that I support other systems. Once you understand the collaborative nature of the pieces of the enterprise solution then your approach to solutions will reflect the entirety of the solution and not only the piece you are working on at the moment.

I still believe Java was great to use because it taught me skills and methodologies specific for my job. But if you do not have this requirement, PHP & Python may be a better solutions because 1) the Python libraries are more useful and 2) it is more web-centric versus Java which is more processing centric.

Wednesday, December 5, 2007

Lab 5 Postmortem

Well, my first mistake was electing to write the client in Java+Swing. That took a bit longer than perhaps a Flex or Web approach. But, with a nice Eclipse plugin from Instantiations called WindowBuilderPro, things didn't get as messy as writing pure Swing code.

Once I had the shell of the client done, it was time to retrieve the submissions from the SQS queues. Amazon recommends using Typica, a Java-based lib for manipulating SQS. All went well, except for the fact that nobody else could read my submissions. It turned out that there was a bug in Typica rev. 0.8 which caused the submission to be encoded in bin64. I fixed that bug and now have a custom copy of Typica!

With that done, I next tackled the WhoIS web service. Eclipse also has a plugin called SoapUI that works beautifully to generate Java classes from WSDL files. Actually, Apache Axis does all the work (WSDL2Java), but the SoapUI Eclipse perspective makes the work easier. All this took about 3 days.

All looked ok except for the fact that I was always hitting my list, webapp and submit servers. When I checked, to my chagrin, I have all my URLs hardcoded to my servers. When I pointed them to the load-balancers, all heck broke loose. Now the real fun began. Testing became difficult because others were taking my submissions. When I made a change, there was no guarantee that I would hit my server. So, I externalized all the links to properties files so that I can update at runtime.

It took me an extra day to get things in order. Now I am at the state where when I am hardcoded, all works, but when I am connected to the collective, the submissions do not enter the queue. When I examine the output of the sslb loadbalancer, I get a screen-full of Python errors. Will update y'all when I finally get things working end-to-end.