For just a moment I would like to step away from the main topics of recent posts and comment on a recent posting by Don Box. I actually found Don's posting from Stefan Tilkov and I would like to add my two cents to the discussion. But, before I do, let me please make it clear that these are not comments on Don or Stefan's quest for a programming language. As father to a home schooled son I have spent some time thinking about how to bring the subject of computers and programming up and I had the desire to teach programming because, well because I enjoy it.
But, let's take a step back; why do we program? Well a program is the embodiment of the solution to a problem, and thinking back to learning programming at school it was a horrible experience because the problems were for the most part pointless. Also we have to realize that most people around us are using computers to solve problems without formal "programming", financial analysts building complex models with spreadsheets would probably be mystified if you told them they were programming. So, we have chosen to use Squeak here at home, and specifically we are using the educational packaging provided at Squeakland. Squeak is a fantastic environment for the Smalltalk programmer, but more importantly this package provides a kid-oriented package, and for $18.95 a book with progressive lesson plans for learning with Squeak. We have had great success building and racing cars, and all with drag-and-drop actions that build easy to understand scripts that our 6/7 year old son was able to extend himself. In fact, we even introduced negative numbers, degrees of a circle and more not formally in terms of mathematics but simply by watching the way the properties of his "car" changed as he moved it.
For me, this has been a fantastic tool, it is easy to use, it is very engaging and it is backed by research and practice as an educational tool. The interesting moment was, having developed a script to draw different sized polygons, to click a button and see the code behind that script, there it was, just a Smalltalk method, and you can switch back and forth. I would recommend Squeak to all of those technically minded parents looking to interest their children; it truly is a problem solving environment that you can program, or not, if you want. I also no a number of folks who have successfully introduced Squeak to their school and it has a built-in collaborative aspect to share work with other kids.
So while, I can understand the draw for those of us in computer science to look at languages that appeal to us, let's remember that kids (of all ages!) love to solve problems and Squeak is a wonderful environment to play and learn.[Read More]
Tooling platforms and RESTful ramblings
skjohnston 120000GMPN 300 Visits
Loosely Coupled has this article in review of an article in ACM Queue by Roger Sessions. I was interested by the review, and specifically the quoted comments, including the following.
He goes on to map out a pyramid to demonstrate the inevitability that objects will always be more numerous than components, and that there will always be fewer services than components.
Well, this is an enlightening comment, I would refer Roger to the paper Alan Brown, Kevin Kelly and I wrote about two years ago titled Using Service-Oriented Architecture and Component-Based Development to build Web Service Applications where we discussed both this observation as well as some of it's drivers. The review at Loosely Coupled goes on to argue against another comment made by Roger that systems design tries to minimize the connections between components and argues that such connections and distribution are exactly the purpose and value of SOA designs.
I would like to echo the sentiments expressed at Loosely Coupled and hope that we can further investigate, as a community, these aspects of SOA in a dispassionate way and analyze some of these value propositions such that we can assist both modern service developers as well as the "classic" developers in building systems from disparate and distributed services effectively.[Read More]
skjohnston 120000GMPN 434 Visits
In reference to Aaron Skonnard's November 2004 blog entry on reuse I would like to express an idea that adds somewhat to his arguments. The origin of the thread is in an Opinari newsletter from David Chappell which puts forward the idea that reuse in business applications is more likely to occur successfully with services than with object technology. I tend to agree, although I think both David and Aaron miss a key and vital issue in the reuse battle.
Today, if I look to reuse a component for, say, customer address validation I have to answer a number of questions, such as:
Interestingly, the first and second criteria will always be an issue regardless, no good buying a shipping calculator if our business problem is address validation and no good buying a $10,000 per year license for a component to address a one-off $200 problem! Now, we all know that the third criteria is one of the primary advantages of current web services technologies and standards (WS-I aside) we can easily integrate services with complete disregard of the technology and platform used in their development. Interestingly the last critera listed here is actually addressed, not necessarily by services themselves but by the infrastructure commonly used in service oriented application development. In integrating tightly coupled services interface/data mismatches are a serious issue and we have to code our way around the problem, in the integration of loosely coupled services the injection of mediators can be easily accomplished by platforms such as BizTalk as Aaron mentions or an ESB.
But, it is these fourth and fifth criteria that seem to have had less attention generally, but specifically in David and Aaron's discussion on reuse. Today, if I am looking for an address validation component I might turn to Component Source or Flashline, browse the catalog and purchase a component. I have to look at my existing application infrastructure, I am developing for WebSphere so am looking for an Enterprise Java solution, a nice C# .net solution is not very helpful. Then, I download the component binaries and installation documentation, I deploy the Jars and (in this case) I have to create certain tables in my database and configure my new components to access my existing database instance. This has now put certain costs on me for managing the deployed component, managing replication and availability of the component as well as the database. However, if I look to a services world these very significant issues are addressed by the fact that in general I do not download and install the service locally, I am using a service that is hosted by it's provider and I use it remotely.
Reuse often fails not because of the direct costs but through the indirect costs such as those identified for internal deployment and hosting. Whereas service orientation may help with the organizational issues identified in David's original work it really helps in addressing these indirect costs. We might also point out that there is also potential cost benefits for the service provider in supporting a service in that they do not have to diagnose issues in a customer's installation of a service, they own the service and it's deployment. It is also possible for the service provider to deploy new versions of the service (considering the usual aspects of interface compatibility) to all subscribers easily.
So, having seen a number of reuse projects fail over the years it is not the right time to underplay the benefits of service orientation, used correctly, to provide the right platform and environment for reuse.