Comments on OSS/J Initiative in a Letter

Hi …,

I have been more or less following OSS/J since its very beginning. It is not really what they try to achieve that captures my attention (in fact, in this direction, the effort is pretty much a failure up to this point). The interesting things in OSS/J are on two aspects, in my opinion:

(1) The architecture side. The idea of exposing system interface in both a standard API way and a message way (and making those two approaches equivalent) is very important in the OSS domain, because OSS components must be built with integration in consideration from the very beginning and a message interface is essential to get integration successful in most scenarios. Also, if you look at the design guideline document in OSS/J, you can find that the architects driving OSS/J tried very hard to have reasonably generic domain object model so that it not only captures known business logics, but also is equipped with a pretty rigorous mechanism to allow extension and customization of those domain objects to accommodate unexpected future requirements. For software product architecture, this is always a very challenging job for architects and designers. The question here is how to make sure the product can be used in so many different contexts with all the different requirements.

At this moment, the second point discussed above is still valid; but the first one is more or less out of date, and WSDL, JAX-RPC 2.0 and the WS-* family of technologies provide better solutions and, more importantly, already gained the whole industry's support.

(2) The domain knowledge side. There may be other efforts in the OSS industry that I am not aware of, but OSS/J seems to be the first initiative to capture the body of knowledge in OSS through a set of open specifications and characterize it in current enterprise information technology context. If we look at the specifications on QoS, IP Billing, Service Activation and others, it really tells a lot on what OSS really means and what features are expected in such systems. The overall architecture provides organized structure showing how OSS is actually working. This kind of knowledge can be critical for lowering the barrier of entry to OSS industry.

In summary, my thought is that OSS/J is not something we can propose as a whole for solutions meeting the OSS challenges faced by telecom industry. But there are definitely a lot of things in OSS/J we can learn from, particularly on OSS middleware architecture and on domain knowledge.

The fates of technology initiatives in telecom such as OSA/Parlay/JAIN, SIP and OMA etc. are not all clear to say the least. The convergence of IT and telecom is yet to be well understood. This is an emerging domain. Business conditions are still evolving and keep changing very quickly. It needs some real vision and guts from the senior management teams of OSS middleware providers to do things right.It is not always a technical issue.

Best,

Young

A Letter on Light-Weighted Framework and Others

Hi …,

I guess it is the same in any large corporate. People spend more time on meetings than on doing real work. There are some sound reasons why people need to communicate frequently in those industry giants, but in most of cases I believe those meetings are completely un-productive, if not, counter-productive. This may explain why Louis Gerstner list "strong bias for action" as one of "what it takes to run IBM". Those companies may be able to afford to such a waste of resources; if a small startup is also run this way, it will be destined to fail.

But anyway, enjoy it!

Here come my thoughts on light-weighted and EJBless framework.

Hibernate cannot be regarded as a framework in the same sense as Spring. It is more a tool for OR mapping. Although system concepts and services in Hibernate such as caching, session, concurrent and transaction control may also be helpful to application logics, it still mainly focus on object persistence. I am yet to use this tool in my projects, but I am pretty much sure that there is no issue of performance or threading in Hibernate. Clustering deployment may be a valid concern; however, load-balance and high- availability of the persistence layer is a challenge that the whole industry is currently facing. If you look at Weblogic's document, for the so-called read-write Entity Bean, Bea's claim is "load balancing and fail-over occur only at the home level". This does not really contribute much for application operations. The only solution in this front that I am aware of is c-JDBC from ObjectWeb. The architecture of c-JDBC looks to be sound, but the tricky part is implementation and I do not have knowledge on how it performs. You may know that the still-debated EJB 3.0 specification follows closely the architecture of Hibernate for EJB persistence. I personally believe that is the right direction.

About Spring framework. I read Rod Johnson's first book "J2EE Design and Development" immediately after it was published. That is a good book, particularly when compared with the others on the same topic available at that time in the bookstore. Lots of insights in the problems he chose to discuss and in the solutions he advocated, and all of them apparently came from long time real-life experiences. He did talk in the book about development without EJB. But most of the contents are about good practices in J2EE (including EJB). He came up a configuration framework based on JavaBean and following IoC principle. This can even be thought of as innovative. I always believe that development in Java without EJB can be the right thing for some projects; and my impression from reading Rod Johnson's first book is that he held the same opinion. Hence when he and people around him push the slogan "J2EE Development without EJB", and advocate removing EJB from J2EE in the industry, I think this is more a marketing and sales strategy than a sincere technical pursuit.

In my opinion, EJB as a technology is a great advance in programming paradigms. With EJB, developers are released from the error-prone developments on remoting, transaction, security and persistence. Since EJB container handles those system level requirements, developed code becomes purely business logic focused. And this is a big thing for software industry. There are issues with EJB. In my mind, first, the programming model (local or remote home, ejb interface with ejb-jar.xml) is obviously not clean enough. Security service is obviously not robust or rigorous particularly when we consider the fact that session beans are handling business level logics, entity beans are associated with data access and all of those are points where security requirements are high-lighted. Persistence service in EJB can be regarded as a failure if we compare the purposes of EJB and its usage in reality. Writing solid entity bean code (with fine-tuning carried out in ejb-jar.xml and other proprietary configuration files) is even more difficult than implementing persistence directly with JDBC. Also, abstracting system services from business code need to sacrifice flexibility to certain degree, and need to pay a price on performance in some cases. But with all of those shortcomings, I still believe EJB is a good technology. I am recently reading some scholarly books on concurrent, transactional and distributed systems development. The reading experience only makes me believe stronger that EJB technology does a lot of good to the software industry. In practice level, the issue with EJB is really when and how to use it.

Back to Spring framework. I completely agree with you on that OO is lost in J2EE. Looks to me Spring is not helpful either on bringing back OO or some other primitive programming elements. I am thinking Spring more as a toolkit for effectively developing Java application than as a completely new paradigm that is at the same degree of importance as EJB. Spring framework is something that may be marketed as "bringing technologies closer to the domain of business problems". Getting it wrong can cost those good developers a lot. J2EE technology and application servers are already well established and successful in business. A new revolution may come, but it will not have the flavor of Spring. Service delivery platform (or other things following the spirits of OSGi, Service Integration Bus etc..) has a better chance to replace the application servers. The concept of autonomic computing can also become an essential part in application server architecture in the future.

I am now reading Rod Johnson's second book, "J2EE Development without EJB". His points for the problems in current J2EE development practices are all sound; but the approaches he recommends to replace some of the services in J2EE are just not very convincing. Most of the solutions provided in Spring framework for specific problems are nice. I certainly think I can and should use them in my projects. However, suggesting building a carrier-strength systems relying on Spring framework is a totally different issue.

This is already a long email. Let me briefly share my ideas on logging/tracing/auditing for systems transaction. In business transaction systems, this is usually a requirement and we, as architects, usually do not have a choice. The real question is how to implement this such that it has minimal performance overhead. What I suggest is to isolate the persistence part of logging/tracing/auditing from the executing thread, and put it into a separate process. This can be achieved by a messaging mechanism. If data access performance is a concern, a different database should be used just as OLAP is never carried in operational data store.

I am not doing further work on OAM. It is a big disappointment to me that not all the features I planned for OAM were implemented, and the current implementation was messed with some non-essential stuff. Or else, this solution can be something really good. It is model-driven. With it, configuration and management become an orthogonal concern; therefore OAM is completely separated from business logics. In fact, when the implementation was finished, an article appeared in Bea dev2dev proposing an idea similar to the model concept in OAM architecture. ...

It is good to discuss with you.

Regards,

Young

Technical Supports for Software Development Life Cycle

There are several aspects in software engineering that do not get enough attentions in software industry. I believe consulting opportunities exist on those places, software solutions may be welcome from vendors, and more books are needed to educate developers and managers.

(1) Project Automation: version control system set up and administration, push button build and scheduled build implementation, build and unit test integration practices, build, deployment and integration test consolidation. Project automation should also be more closely integrated with project management
(2) Release Management: there is a need to help vendors to package software components in different ways to support different business engagements. A different approach is features enabling or disabling. This is an orthogonal concern, and should be released from the system developers.
(3) Deployment Management: solutions are needed for carrying out flexible deployment of software for various clustering requirements and for a standalone case.
(4) Issue Management: it can be divided into internal issue management and customer issue management. Software exists for such solutions, but setup, administration and education should be emphasized in the skills set of a developer.
(5) Patching and Upgrade Management: patching should also be an orthogonal concern, and a solution is needed for major software development paradigms. Leading vendors have powerful software upgrade management solution, such as versioning, internet-based upgrade etc., but they are not well understood in the industry.
(6) License Management: there are two issues here, one is licensing terms enforcement for installed software; the second is to easily change license models for packaged applications. Both of them are critically important for software providers. Developers should be released from messing codes for licensing management with those for business logic.

There are some others. But those are issues encountered by software vendors very frequently, and good solutions are not always presented. For software developed in Java, some of those issues are addressed by Bugzilla, Jira, and complicated Ant and Maven scripts etc., and solutions for others involves architecture concerns. More unified and steam-lined solutions may benefit all parties in the industry.

Project Automation from pragmatic programmer’s toolkit and Beyond Software Architecture from Martin Fowler’s signature series are good (and only) books on those topics at this moment.

The Goal and Theory of Constraints

I was checking at the University of Toronto bookstore on Friday afternoon to see if there is any new interesting book coming out. It is now the time when students pick up textbooks for the coming semester. Lots of students were there and shelves for textbooks were all full. Looking through those for business and management, I found The Goal by Eliyahu M. Goldratt . Rotman School is using a novel as a textbook on management. Amazing… I thought.

I spent this past weekend and completed the reading. Nice book. Innovative approach to propagate ideas first; and of course, the ideas are interesting by themselves.

The book is about Theory of Constraints. TOC in essence, is based on a simple observation: the strength of a chain is dictated by its weakest link; therefore, the performance of any value-chain is dictated by its constraint. To maximize the performance of a value-chain, we need to make changes centralized with the constraints. The book suggests a 5 steps implementation of TOC:

1. Identify the constraint.
2. Decide how to exploit the constraint.
3. Subordinate and synchronize everything else to the above decisions.
4. Elevate the performance of the constraint.
5. If in any of the above steps the constraint has shifted, go back to Step 1.

The motivating purposes for this 5 steps approach are:

• Understanding the interdependencies between and across processes that contribute to delivering a product or service,


• Understanding the impact that those interdependencies and normal variability have on their combined, overall performance, and


• Appropriately buffering for interdependencies and normal variability so that that performance can be predictably and consistently high.

Most of specific issues discussed in this book were well or better systematically explored and treated in literatures on lean development, pull, flow, JIT and systems thinking etc.. But the Thinking Process initially advocated in this book and further pushed by people in this TOC movement looks like to have more profound and more lasting impact on industries. The TOC Thinking Process is built upon a framework consisting of three questions: What to Change?, What to Change to?, and How to Cause the Change? As summarized in a white paper from Dr. Goldratt consulting firm,

“The Thinking Processes are a set of tools and processes that allows an individual or group to solve a problem and/or develop an integrated strategy using the rigor and logic of cause-and-effect, beginning with the symptoms and ending with a detailed action plan that coordinates the activities of all those involved in implementing the solution.”

Clarifying the real goals of an effort, from here identifying the constraints in existing process that hinder achieving the goals, and concentrating on changing of those constraints: this is what Alex Rogo’s approach is really about. But just as the story looks like to be more on measurement, motivated professionals who have a clear understanding of the problems in the reality of their companies seldom are puzzled with what are the right things to do; the issues are more on getting people to understand what are the ultimate goals, to walk safely through the politics water and to overcome the obstacles to change.

“Common sense is not common at all”, Mark Twin said. Tracking to the end, we find lack of common sense is the real source for many problems existing in various human efforts. The Goal tried to demonstrate how powerful is common sense and has done a good job.

I plan to read in the future more books by Dr. Goldratt such as It's Not Luck, Critical Chain and Necessary but Not Sufficient.

The Journey Starts Now ...

Here is my plan on how to use this space:

(1) Keep records of occurences of significance. It may be an announcement if it is about myself or my family.
(2) Share my thoughts with the communities with which I am associated, this way or that way. The contents may range from technologies, management, history and politics, maybe.
(3) I may also use this to formally publish articles I wrote on various topics; if they are published elsewhere, this may be just a link depending on my agreement with the sepcific publisher.

Welcome to my place in the internet!