July 2006

Monthly Archive

July 2006 IASA Puget Sound Chapter Meeting

Posted by on 21 Jul 2006 | Tagged as: IASA

The Puget Sound IASA (Int'l Assoc. of Software Architects) welcomes Kim Cameron, Chief Architect of Identity from Microsoft, presenting on the topic of “The Identity Metasystem and Cardspace”. Details on this topic may be found at http://groups.yahoo.com/group/iasa-pugetsound-members/files/InfoCard.ppt.

The meeting will be held on Wednesday, July 26th at the following time and location:

EVENING:
6:30pm – 9:00 pm
Microsoft
15700 NE 39th St
Building 43, Room 1560
Redmond, WA 98052
Directions

These meetings are open to the public so please join us and bring your friends and colleagues. We hope to see you there.

The Tradgedy of ORM

Posted by on 16 Jul 2006 | Tagged as: Software Architecture

Ted Neward has comprehensively described the issues revolving around Object/Relational Mapping (ORM) issues that are quite apparent in most enterprise application development these days. Although there may be some feelings surrounding Ted‘s comparison of ORM with Vietnam, I can not see how this analysis of ORM can be argued. For any development team which is evaluating an ORM, relational database, OODB, or other application data storage solution this article is a must read.

As I have probably given away in past blog entries, I tend to stay away from relational databases if I can. Unfortunately, I have found that I am not able to stay away most of the time due to customer constraints. My tendency is to use OODB and tuple space solutions for moving and storing data within my personal applications. In the OODB space I have used JDBM and db4o along with personal serialization solutions. In the tuple space arena I have predominantly used JavaSpaces implementations for my application messaging. I have tested TSpaces as a messaging platform but found it to be less effective for me than JavaSpaces.

Looking at the evolution of the enterprise towards Service-Oriented Architecture (SOA) I believe that data persistence can be reconsidered. There may be less of a need to develop our services with relational database storage. The reason for not using a relational database is to limit the specific knowledge of RDBMS platforms, consistency between application and stored data, ease caching, performance, and integration of data into the application development department.

On top of the article and further explanation by Ted Neward, TheServerSide reference to the article has interesting comments to chew on.

Throwing Away Software is Good

Posted by on 07 Jul 2006 | Tagged as: Software Architecture

Richard Cowin describes an often overlooked concept "Disposable Software" in a recent blog entry. In my opinion, this seemingly basic concept that software is not forever is integral to making good architecture and product development decisions.

I believe that the idea "software is temporary" increasingly rings true in the world of Service-Oriented Architecture (SOA). Jini incorporated this into it‘s programming paradigm with the incorporation of the "lease" concept. A service or client leases an amount of time with it‘s software dependencies as an expected lifespan, duration to use a service, or renewal period. Services are likely to be available if a lease is active for that service. We can download the binding to that service based on a contract and decide what to do when the lease for that service is expiring. If the contract does not change then a new version of the service may be deployed and when the old version‘s lease expires all of the consumers of that service may get the new version‘s binding. This allows reasonably granular services to be upgraded easily upon lease expirations.

Even in the XML web services world there is this thought of decommissioning software. Multiple vendors have developed strategies for registering, instrumenting, monitoring, advertising, and removing services based on web services. I have listened to discussions on the use of COBOL transaction services deployed to mainframes which paralleled the SOA concepts of granular services with specific operational goals. I heard that there may still be print jobs generated from these deployed services. The developers and business owners of these services are no longer available to convey a strategy for removal. Those services which are running without any currently identifiable business value are operational debt for the businesses in which they are deployed. Many established SOA strategies have taken this into consideration. Services at the right granularity can be tracked with metering which could lead to eventual removal of a service based on Service Level Agreements (SLA).

When consulting customers on introducing SOA to the organization, service removal is a high priority topic to help drive a successful SOA initiative. Services in most good SOA strategies map to a business value. When the business value is no longer relevant we must be able to remove the service effectively in order to cease further operation debt. You may even deprecate a version of your service and later remove it when all of the consumers of that service no longer use it or employ more drastic strategies to remove services. Operational costs in maintaining software is usually the biggest cost of all for large organizations. We must do what we can to make sure these costs are controlled effectively.

Presentation on Space-based Architecture

Posted by on 01 Jul 2006 | Tagged as: IASA

We had a great presentation for the Puget Sound chapter of the IASA this month from Owen Taylor on the topic of “Space-based Architecture and the End of Tier-based Computing”.  What a great topic name!  I think that many of us out there know that the tier-based solutions were just a stepping stone to a new way of developing cost effective software architectures.

Many of my colleagues over the years know that I am quite taken by the power of the Jini/JavaSpaces programming paradigm.  Whether they agree or not (or even want to hear it again from me) I try to present how testing, development, versioning, and deployment are made easier with service-orientation.  GigaSpaces definitely grabbed the attention of those who attended (although attendance was low for each meeting, unbelievable since it was a sunny day in Seattle :).  By incorporating the service provisioning power of Rio into their product, they not only make Jini/JavaSpaces development easy but also gives enterprise class dynamic service provisioning.

The demos that Owen showed during the presentations were amazing, even though I have done similar things with Rio in the past.  I believe that Owen and GigaSpaces have told the story of the Jini/JavaSpaces programming paradigm incredibly well.  Something that I don't believe I have been able to do as effectively in conversation.  The throughput of the product and dynamic provisioning capabilities really stood out.  I want to thank GigaSpaces for giving such a compelling presentation to our local community.  Give it up for “Linear Scalability”!