Not too long ago I took a class for developing web services. The content of the class focused almost exclusively on developing SOAP based web services. While there is nothing particularly difficult about SOAP, it seemed to require a lot of steps; defining your data elements, creating a wsdl, and all the tools you had to use. While having a contract can be beneficial when the web service will be facing external clients, it seemed to be a lot of steps to go through to get a web service going and also heavy-weight.

Near the end of the class we briefly went over the RESTful web service philosophy. REST seemed, to me, to be a lot easier to use as it didn't require nearly as much setup, and it utilized the pre-existing http protocols (GET, POST, PUT, DELETE). Also with XML going only one way, a well designed RESTful web service should be faster than its SOAP counter part. The internet is a big place so there is plenty of room for both philosophies, but given RESTful's smaller learning curve and being seen as the "trendy" choice, I can see it continuing to increase in popularity, particularly among younger developers. Anyways I decided to do a some research on the subject and wanted to share what I have found.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest - An excellent article that gives a very good description of the two philosophies and their respective pros and cons. “Part 2” covers WSDL vs. WADL, which is also a really good read.
http://blogs.oracle.com/SOAandEDA/2009/04/soap_or_rest_its_about_your_pr.html – Horror of horrors, this article suggest to focus on business needs instead of technology.

Technorati Tags: Web development

I recently have been involved in a lot of refactoring work at my company. One issue we ran into was our usage of SQL in our applications, we had a habit of including a lot of business logic in SQL. To make the applications more maintainable we moved a lot of our business logic from SQL to Java. While I believe we made the right decision to remove the business logic from SQL I don't think it would be in all scenarios. In our situation we were not playing to the strengths of SQL, most of our developers do not have an advanced understanding of SQL, and using Java to handle the business logic allowed for more reusability. I did some research on this subject and wanted to share what I have collected. So should SQL be used for business logic or not?

http://martinfowler.com/articles/dblogic.html
http://blogs.msdn.com/rogerwolterblog/archive/2006/04/04/568351.aspx (an SQL server sales pitch, but informative none the less)
http://www.pbell.com/index.cfm/2008/3/21/Moving-Business-Logic-to-the-Database

Technorati Tags: Best practices, SQL

Like all developers I was always taught to use getter and setters to access the internal members of an external class, and up until recently I accepted this idiom blindly. Not too long ago I was on a discussion board when a young developer asked what the getters and setters were doing in a snippet of code. I proceeded to explain what each method did, I then was about to explain why getters and setters are used, but I couldn't. I know the old adages, hiding a class' implementation, data hiding, etc. But none of the explanations really “stuck” when I thought about them. After all I am de facto exposing a class' member to the entire world by creating a public getter method. I did a bit of researching and there is quite a bit of discussion on this subject, found these articles to very informative and do a good job of framing the subject:
http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html
http://www.darronschall.com/weblog/2005/03/no-brain-getter-and-setters.cfm

Technorati Tags: Best practices, Programming