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.
Friday, December 14, 2007
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.
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.
Tuesday, November 13, 2007
Lab 4 Postmortem
To start, I grabbed the Java libraries for Akismet and SQS services. They were so simple that the submit process work first shot. WOW! I took me another 2 hours to shore-up the error checking.
Lab 3 Postmortem
UI Implementation
The templating engine I chose to use is Velocity. This is great because all I have to do is:
1) determine which objects will be visible to the velocity template and use it in teh html (actually *.vm) file to populate the dynamic data.
2) in the servlet, inject the Java objects I used in step (1) into the template context.
Getting the listings
Here, I used HttpClient to maje the "GET" calls.
Overall coding
This lab required a bit more programming than the previous labs. This was mainly because I wanted to add some smarts to the page navigation.
The templating engine I chose to use is Velocity. This is great because all I have to do is:
1) determine which objects will be visible to the velocity template and use it in teh html (actually *.vm) file to populate the dynamic data.
2) in the servlet, inject the Java objects I used in step (1) into the template context.
Getting the listings
Here, I used HttpClient to maje the "GET" calls.
Overall coding
This lab required a bit more programming than the previous labs. This was mainly because I wanted to add some smarts to the page navigation.
Lab 2 Postmortem
Mapping the URLs
The most complex part of this lab was matching the URL signatures. I played with Tomcat for a while, but realized that using mod_rewrite with Apache would be much easier. Here are the steps:
1) mod_rewrite comes with Apache 2.2 so just uncomment the module in the httpd.conf file.
2)add the following lines to the end of httpd.conf:
# Send cs462 labs to worker named default
JkMount /cs462lab2/* default
This will send all URI's which start with "/cs462lab2" to tomcat.
3) add the file ".htaccess" to the default docs dir of Apache. This file contains the regex rules for rewriting the URL.
4) add the following lines:
RewriteEngine on
RewriteRule ^index$ cs462lab2/SiteLister?option=index [NC]
RewriteRule ^domain/(([a-z0-9]([-a-z0-9]*[a-z0-9])?\.)+((a[cdefgilmnoqrstuwxz]|aero|arpa)|(b[abdefghijmnorstvwyz]|biz)|(c[acdfghiklmnorsuvxyz]|cat|com|coop)|d[ejkmoz]|(e[ceghrstu]|edu)|f[ijkmor]|(g[abdefghilmnpqrstuwy]|gov)|h[kmnrtu]|(i[delmnoqrst]|info|int)|(j[emop]|jobs)|k[eghimnprwyz]|l[abcikrstuvy]|(m[acdghklmnopqrstuvwxyz]|mil|mobi|museum)|(n[acefgilopruz]|name|net)|(om|org)|(p[aefghklmnrstwy]|pro)|qa|r[eouw]|s[abcdeghijklmnortvyz]|(t[cdfghjklmnoprtvwz]|travel)|u[agkmsyz]|v[aceginu]|w[fs]|y[etu]|z[amw]))/?$ cs462lab2/SiteLister?option=domain&domain=$1 [NC,L]
That's it!
Calling HTTP Get
Because I'm using Java and Servlets, I have the luxury of choosing from many open-source libraries.
1) To call S3 for the data, I used HttpClient which is great for Http Get and Post calls.
2) To convert the JSON data to Java types, I used json-lib.
3) To format the XML, I used JDOM.
These libraries minimized the code I had to write.
The most complex part of this lab was matching the URL signatures. I played with Tomcat for a while, but realized that using mod_rewrite with Apache would be much easier. Here are the steps:
1) mod_rewrite comes with Apache 2.2 so just uncomment the module in the httpd.conf file.
2)add the following lines to the end of httpd.conf:
# Send cs462 labs to worker named default
JkMount /cs462lab2/* default
This will send all URI's which start with "/cs462lab2" to tomcat.
3) add the file ".htaccess" to the default docs dir of Apache. This file contains the regex rules for rewriting the URL.
4) add the following lines:
RewriteEngine on
RewriteRule ^index$ cs462lab2/SiteLister?option=index [NC]
RewriteRule ^domain/(([a-z0-9]([-a-z0-9]*[a-z0-9])?\.)+((a[cdefgilmnoqrstuwxz]|aero|arpa)|(b[abdefghijmnorstvwyz]|biz)|(c[acdfghiklmnorsuvxyz]|cat|com|coop)|d[ejkmoz]|(e[ceghrstu]|edu)|f[ijkmor]|(g[abdefghilmnpqrstuwy]|gov)|h[kmnrtu]|(i[delmnoqrst]|info|int)|(j[emop]|jobs)|k[eghimnprwyz]|l[abcikrstuvy]|(m[acdghklmnopqrstuvwxyz]|mil|mobi|museum)|(n[acefgilopruz]|name|net)|(om|org)|(p[aefghklmnrstwy]|pro)|qa|r[eouw]|s[abcdeghijklmnortvyz]|(t[cdfghjklmnoprtvwz]|travel)|u[agkmsyz]|v[aceginu]|w[fs]|y[etu]|z[amw]))/?$ cs462lab2/SiteLister?option=domain&domain=$1 [NC,L]
That's it!
Calling HTTP Get
Because I'm using Java and Servlets, I have the luxury of choosing from many open-source libraries.
1) To call S3 for the data, I used HttpClient which is great for Http Get and Post calls.
2) To convert the JSON data to Java types, I used json-lib.
3) To format the XML, I used JDOM.
These libraries minimized the code I had to write.
Wednesday, September 19, 2007
Lab 1 Postmortem
As you all know, I took a different approach:
1) Java instead of Python
2) Apache Velocity for the Templating Engine
3) Tomcat for my HTTP & Servlet Server
Why Java?
1) My current employer is promoting Java as the language to learn.
2) I hope to qualify for a spot on the TurboTax Online development team. They use Java, JBoss and JavaScript. They are now porting the application layer to Flex.
3) Java has very mature IDEs (Eclipse and NetBeans) which integrate will with Tomcat and help developers write code quickly.
4) My time is limited due to employment and family commitments so I need to hit the ground running. I feel very comfortable with this technology (knock on wood).
Why Velocity?
1) Comes out of the box running
2) Easy to use
3) GREAT tools
4) Very active open source project
5) Slicker than snot
Why Tomcat?
1) Apache can't work with servlets
2) Easy to configure and run
3) Works well with Java, Velocity and Eclipse
Here is what I did:
1) Install Java. I basically followed the instructions on this link:
http://stanton-finley.net/fedora_core_4_installation_notes.html#Java
2) Install a non-Yum version of Tomcat 5.5.2.5. The following link shows the complexity of the directory structure for a Yum installation:
http://www.mksearch.mkdoc.org/documentation/tomcat-on-fc4/
I chose to download and install a custom version in /opt/tomcat5.5. In this way, I can control the locations of the directories and config files.
I then changed the listening port from 8080 to 80 as per the class requirements. This can be done in config/server.xml.
3) Remove HTTPD from chkconfig. Since I am using Tomcat as my HTTP server, I don't need Apache. There are drawbacks to this, but for this class, it should be fine. The command is:
chkconfig --del httpd
4) Create a Tomcat service. In /etc/init.d, I created a startup script called tomcat5.5. Then I set this to be run at startup by "chkconfig --add tomcat5.5" followed by "chkconfig tomcat5.5 on."
5) The last step was to create a Tomcat Project using Eclipse and to modify the Web.xml file for VelocityViewServlet. I won't go into details here since this is not a programming class.
Troubles:
1) It has been a few years since I last used Velocity. It took a while to set it up again.
2) The registration/deregistration with the loadbalancer gave me the most grief. There wasn't enough info to get it working on the first try. It was only by reading all your hints that I was able to get this working.
Conclusion:
All in all, things went smoothly. It's always hard to lay the foundation since that usually requires the steepest learning curve. There were holes in the info, but working with someone else in the class really helped. The lab instructions and notes were a bit scattered and incomplete. This was a plus and a minus: plus in that it forced me to work and minus BECAUSE it forced me to work! ;-)
1) Java instead of Python
2) Apache Velocity for the Templating Engine
3) Tomcat for my HTTP & Servlet Server
Why Java?
1) My current employer is promoting Java as the language to learn.
2) I hope to qualify for a spot on the TurboTax Online development team. They use Java, JBoss and JavaScript. They are now porting the application layer to Flex.
3) Java has very mature IDEs (Eclipse and NetBeans) which integrate will with Tomcat and help developers write code quickly.
4) My time is limited due to employment and family commitments so I need to hit the ground running. I feel very comfortable with this technology (knock on wood).
Why Velocity?
1) Comes out of the box running
2) Easy to use
3) GREAT tools
4) Very active open source project
5) Slicker than snot
Why Tomcat?
1) Apache can't work with servlets
2) Easy to configure and run
3) Works well with Java, Velocity and Eclipse
Here is what I did:
1) Install Java. I basically followed the instructions on this link:
http://stanton-finley.net/fedora_core_4_installation_notes.html#Java
2) Install a non-Yum version of Tomcat 5.5.2.5. The following link shows the complexity of the directory structure for a Yum installation:
http://www.mksearch.mkdoc.org/documentation/tomcat-on-fc4/
I chose to download and install a custom version in /opt/tomcat5.5. In this way, I can control the locations of the directories and config files.
I then changed the listening port from 8080 to 80 as per the class requirements. This can be done in config/server.xml.
3) Remove HTTPD from chkconfig. Since I am using Tomcat as my HTTP server, I don't need Apache. There are drawbacks to this, but for this class, it should be fine. The command is:
chkconfig --del httpd
4) Create a Tomcat service. In /etc/init.d, I created a startup script called tomcat5.5. Then I set this to be run at startup by "chkconfig --add tomcat5.5" followed by "chkconfig tomcat5.5 on."
5) The last step was to create a Tomcat Project using Eclipse and to modify the Web.xml file for VelocityViewServlet. I won't go into details here since this is not a programming class.
Troubles:
1) It has been a few years since I last used Velocity. It took a while to set it up again.
2) The registration/deregistration with the loadbalancer gave me the most grief. There wasn't enough info to get it working on the first try. It was only by reading all your hints that I was able to get this working.
Conclusion:
All in all, things went smoothly. It's always hard to lay the foundation since that usually requires the steepest learning curve. There were holes in the info, but working with someone else in the class really helped. The lab instructions and notes were a bit scattered and incomplete. This was a plus and a minus: plus in that it forced me to work and minus BECAUSE it forced me to work! ;-)
IP Information
Here's the link on how to find the internal and public IP addresses:
http://docs.amazonwebservices.com/AWSEC2/2007-03-01/DeveloperGuide/IP_Information.html
For those short on time...
1) To obtain the internal IP address:
curl http://169.254.169.254/2007-03-01//meta-data/local-ipv4
2) To obtain the public IP address:
curl http://169.254.169.254/2007-03-01//meta-data/public-ipv4
http://docs.amazonwebservices.com/AWSEC2/2007-03-01/DeveloperGuide/IP_Information.html
For those short on time...
1) To obtain the internal IP address:
curl http://169.254.169.254/2007-03-01//meta-data/local-ipv4
2) To obtain the public IP address:
curl http://169.254.169.254/2007-03-01//meta-data/public-ipv4
Subscribe to:
Posts (Atom)