Big Upfront Framework design (BUFD)

Recently I have been thinking is it really worth doing Big Upfront Framework Design(BUFD).
I have taken part in designing several frameworks in my past, but never thought(or didnt get a chance) the best phase to design frameworks. It is agreed by default that frameworks are designed upfront before product development begins. Many highly intelligent architects, designers sit together for days and nights without proper sleep and design meta data driven,XML based,database independent frameworks!!!. But if we carefully look into this, upfront framework design is not really agile, and secondly, ROI is also bad.


* Doing Upfront Framework Design(UFD), would force the designers and developers to design application or develop application to fit the framework, rather than steering the development effort in satisfying the customer's requirements.

* UFD, is not profitable to the customer, because frameworks are generally designed to be as generic as possible keeping future requirements in mind, and due to which, customer would be spending money on "future" requirements in the present!!!

In fact I was trying to think can UFD be applied to Project development scenario, where the project's duration is less than a year ???... Now I feel that it does not suit here too. The reason being, any framework design and development would take atleast 3-4 months, and I feel this effort is not worth spending for a shorter duration project !!

Ok, the best possible solution could be:

* Start thinking about framework from the beginning (dont stop yourself), but dont start the design until you pass the inception pase.

* Start laying the foundation from Elaboration phase.

* As the product development progress, design, tweak the framework iteratively.

* The Framework should evolve over a period of time, and at the same time ensure that is "usable" (need not be complete) before construction phase !!

* keep refactoring, evolving and be agile

Cleared SCEA Part 1 Exam

March 31st 2006: I cleared the Sun Certified Enterprise Architect exam. I was planning to take up this exam from some time, and in the last 3 days I really put some effort and passed the exam with good scores.

I have scored 100% in many of the following objectives, especially the ones that I am passionate about like Design patterns, EJB, Applicability of J2EE, Legacy Connectivity(even though I dont like this subject I know a bit), protocols, messaging.

Exam Objectives

Section 1: Concepts
* Draw UML Diagrams
* Interpret UML diagrams.
* State the effect of encapsulation, inheritance, and use of interfaces on architectural characteristics.

Section 2: Common Architectures
* Recognize the effect on each of the following characteristics of two tier, three tier and multi-tier architectures: scalability maintainability, reliability, availability, extensibility, performance, manageability, and security.
* Recognize the effect of each of the following characteristics on J2EE technology: scalability maintainability, reliability, availability, extensibility, performance, manageability, and security.
* Given an architecture described in terms of network layout, list benefits and potential weaknesses associated with it.

Section 3: Legacy Connectivity
* Distinguish appropriate from inappropriate techniques for providing access to a legacy system from Java code given an outline description of that legacy system

Section 4: Enterprise JavaBeans Technology
* List the required classes/interfaces that must be provided for an EJB technology.
* Distinguish stateful and stateless Session beans.
* Distinguish Session and Entity beans.
* Recognize appropriate uses for Entity, Stateful Session, and Stateless Session beans.
* State benefits and costs of Container Managed Persistence.
* State the transactional behavior in a given scenario for an enterprise bean method with a specified transactional deployment descriptor.
* Given a requirement specification detailing security and flexibility needs, identify architectures that would fulfill those requirements.
* Identify costs and benefits of using an intermediate data-access object between an entity bean and the data resource.

Section 5: Enterprise JavaBeans Container Model
* State the benefits of bean pooling in an EJB container.
* State the benefits of Passivation in an EJB container.
* State the benefit of monitoring of resources in an EJB container.
* Explain how the EJB container does lifecycle management and has the capability to increase scalability.

Section 6: Protocols
* Given a scenario description, distinguish appropriate from inappropriate protocols to implement that scenario.
* Identify a protocol, given a list of some of its features, where the protocol is one of the following: HTTP, HTTPS, IIOP, JRMP.
* Select from a list, common firewall features that might interfere with the normal operation of a given protocol.

Section 7: Applicability of J2EE Technology
* Select from a list those application aspects that are suited to implementation using J2EE.
* Select from a list those application aspects that are suited to implementation using EJB.
* Identify suitable J2EE technologies for the implementation of specified application aspects.

Section 8: Design Patterns
* From a list, select the most appropriate design pattern for a given scenario. Patterns will be limited to those documented in Gamma et al. and named using the names given in that book.
* State the benefits of using design patterns.
* State the name of a design pattern (for example, Gamma) given the UML diagram and/or a brief description of the pattern's functionality.
* Select from a list benefits of a specified design pattern (for example, Gamma).
* Identify the design pattern associated with a specified J2EE feature

Section 9: Messaging
* Identify scenarios that are appropriate to implementation using messaging, EJB, or both.
* List benefits of synchronous and asynchronous messaging.
* Select scenarios from a list that are appropriate to implementation using synchronous and asynchronous messaging.

Section 10: Internationalization
* State three aspects of any application that might need to be varied or customized in different deployment locales.
* Match the following features of the Java 2 platform with descriptions of their functionality, purpose or typical uses: Properties, Locale, ResourceBundle, Unicode, java.text package, InputStreamReader and OutputStreamWriter.

Section 11: Security
* Select from a list security restrictions that Java 2 environments normally impose on applets running in a browser.
* Given an architectural system specification, identify appropriate locations for implementation of specified security features, and select suitable technologies for implementation of those features.

Who is an Architect ?

I found this interesting definition as per James Mcgovern:

think of a good architect as someone who really understands the systems they oversee - not just the classes and the collaborations but the real 'soul' of the system. They're the sort of person who, given a particular change in requirements for their system, will come up with three different solutions but will instinctively know which is the right one to go for (and will then find all the technical justification in terms of changability, performance, robustness, etc.) because they know the system so well. They probably love the system a bit too.

Interesting definition of Enterprise Architecture

I found this interesting definition of EA:

Enterprise Architecture is an infrastructure and a set of Machines constructed in order to manage a chaotic, dynamic, unpredictable, complex, organic, prone to error, frustrating, Enterprise IT, which has to support an ever increasing, dynamic portfolio of products and services, through constant "ASAP, Now, Right-Away" modifications of business processes.

What you choose

You can make it happen when you truly choose to do so. You always have, and you always will.
If something is important enough to you, you'll surely find a way. Look back on your life up to this point, and you'll see a manifestation of what you've cared most about.
Now take a look at what you care most about in this very moment. Those are the things you will give your energy and attention to, and those are the things that will surely happen for you.
You are plenty capable of pushing yourself relentlessly toward what you choose. For you do it every day and you've had a lifetime of practice.
The big question is this. What exactly do you choose?
Whatever it is, whatever you truly care about in your hjavascript:void(0);
Publish Post eart of hearts, you'll find a way to make it real. With that in mind, always choose the very best you can imagine.
-- Ralph Marston

Out of your vulnerabilities will come your strength.
-Sigmund Freud

Spring to implement Failover mechansim

<bean id="highAvailabilityBean" class="org.springframework.remoting.support.FailoverProxyFactoryBean">
  <property name="serviceInterface" value="com.x.MyInterface">  <property name="serviceBeans">   <list>   <!-- service beans are typically proxies to remote services  -->    <ref bean="primaryServiceProvider">    <ref bean="fallBackServiceProvider">   </ref>  </ref></list>
package org.springframework.remoting.support;import java.lang.reflect.InvocationTargetException;import java.util.Iterator;import java.util.List;import org.aopalliance.intercept.MethodInterceptor;import org.aopalliance.intercept.MethodInvocation;import org.springframework.aop.framework.ProxyFactory;import org.springframework.beans.factory.FactoryBean;import org.springframework.beans.factory.InitializingBean;import org.springframework.remoting.support.RemoteAccessor;/*** Factory bean for proxies to redundant services. Behaves like theproxied* service when used as bean reference, exposing the specified service* interface, but with transparent fail-over. All call to the proxy are* delegated to the first object in the list of service providers (@see* #setServiceProviders(List)). When this delegated call fails, thenext* provider in the list will be called, etc.** @author be324288**/public class FailoverProxyFactoryBean extends RemoteAccessor implementsMethodInterceptor,InitializingBean, FactoryBean {private Object serviceProxy;private List serviceProviders;/*** The list of (redundant) objects that implement the interfacespecified* with {@link RemoteAccessor#setServiceInterface(java.lang.Class)}** @return*/public List getServiceProviders() {return serviceProviders;}/*** @param serviceProviders*/public void setServiceProviders(List serviceProviders) {this.serviceProviders = serviceProviders;}public void afterPropertiesSet() throws Exception {if (getServiceInterface() == null) {throw new IllegalArgumentException("serviceInterface isrequired");}if (serviceProviders == null || serviceProviders.isEmpty()) {throw new IllegalArgumentException("serviceBeans isrequired");}for (Object o : serviceProviders) {if (!getServiceInterface().isInstance(o)) {throw new IllegalArgumentException(o.getClass()+ " does not implement the serviceInterface: "+getServiceInterface());}}this.serviceProxy =ProxyFactory.getProxy(getServiceInterface(), this);}public Object getObject() {return this.serviceProxy;}public Class getObjectType() {return getServiceInterface();}public boolean isSingleton() {return true;}public Object invoke(MethodInvocation mi) throws Throwable {Iterator iter = serviceProviders.iterator();while (iter.hasNext()) {Object bean = iter.next();try {returnbean.getClass().getMethod(mi.getMethod().getName(),(Class[])mi.getMethod().getParameterTypes()).invoke(bean,mi.getArguments());} catch (InvocationTargetException e) {// try next bean or throw exception if this is the lastbeanif (!iter.hasNext()) {throw e.getCause();}}}return null;}}

Failover mechansim using Spring

Here is a sample code snippet about how spring can be used to handle fail over mechansim: (Ref: from a Spring framework discussion forum)


class="org.springframework.remoting.support.FailoverProxyFactoryBean">











package org.springframework.remoting.support;

import java.lang.reflect.InvocationTargetException;
import java.util.Iterator;
import java.util.List;

import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;
import org.springframework.aop.framework.ProxyFactory;
import org.springframework.beans.factory.FactoryBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.remoting.support.RemoteAccessor;

/**
* Factory bean for proxies to redundant services. Behaves like the
proxied
* service when used as bean reference, exposing the specified service
* interface, but with transparent fail-over. All call to the proxy are
* delegated to the first object in the list of service providers (@see
* #setServiceProviders(List)). When this delegated call fails, the
next
* provider in the list will be called, etc.
*
* @author be324288
*
*/
public class FailoverProxyFactoryBean extends RemoteAccessor implements
MethodInterceptor,
InitializingBean, FactoryBean {

private Object serviceProxy;

private List serviceProviders;

/**
* The list of (redundant) objects that implement the interface
specified
* with {@link RemoteAccessor#setServiceInterface(java.lang.Class)}
*
* @return
*/
public List getServiceProviders() {
return serviceProviders;
}

/**
* @param serviceProviders
*/
public void setServiceProviders(List serviceProviders) {
this.serviceProviders = serviceProviders;
}

public void afterPropertiesSet() throws Exception {
if (getServiceInterface() == null) {
throw new IllegalArgumentException("serviceInterface is
required");
}
if (serviceProviders == null || serviceProviders.isEmpty()) {
throw new IllegalArgumentException("serviceBeans is
required");
}
for (Object o : serviceProviders) {
if (!getServiceInterface().isInstance(o)) {
throw new IllegalArgumentException(o.getClass()
+ " does not implement the serviceInterface: "
+
getServiceInterface());
}
}
this.serviceProxy =
ProxyFactory.getProxy(getServiceInterface(), this);
}

public Object getObject() {
return this.serviceProxy;
}

public Class getObjectType() {
return getServiceInterface();
}

public boolean isSingleton() {
return true;
}

public Object invoke(MethodInvocation mi) throws Throwable {
Iterator iter = serviceProviders.iterator();
while (iter.hasNext()) {
Object bean = iter.next();
try {
return
bean.getClass().getMethod(mi.getMethod().getName(),
(Class[])
mi.getMethod().getParameterTypes()).invoke(bean,
mi.getArguments());
} catch (InvocationTargetException e) {
// try next bean or throw exception if this is the last
bean
if (!iter.hasNext()) {
throw e.getCause();
}
}
}
return null;
}

}

Tao of Software Architect

The Tao of the Software Architect

I read about this article from one of the architect’s discussion forum

Lao-Tsu, revisited by
Philippe Kruchten
This is a very liberal reading of Lao-Tsu’s Tao Te Ching for the use of software architects, based on various French and English translations. The number refers to the original tablets.
The architect observes the worldbut trusts his inner vision.He allows things to come and go.His heart is open as the sky. (12)
The architect doesn't talk, he acts.When this is done,the team says, "Amazing:we did it, all by ourselves!" (17)
When the architect leads, the teamis hardly aware that he exists.Next best is a leader that is loved.Next, one who is feared.The worst one who is despised. (17)
A good traveler has no fixed plansand is not intent upon arriving.A good artist lets his intuitionlead him wherever it wants.A good scientist has freed himself of conceptsand keeps his mind open to what is. Thus the architect is available to everybodyand doesn't reject anyone.He is ready to use all situations and does not waste anything.This is called embodying the light. (27)
If you want to shrink something,you must first allow it to expand.If you want to get rid of something,you must first allow it to flourish.If you want to take something,you must first allow it to be given.This is called the subtle perceptionof the way things are.The soft overcomes the hard.The slow overcomes the fast.Let your workings remain a mystery.Just show people the results. (36)
When the process is lost, there is good practice.When good practice is lost, there are rules.When rules are lost, there is ritual.Ritual is the beginning of chaos.*(38)
The architect concerns himselfwith the depth and not the surface,with the fruit and not the flower. (38)
The architect allows things to happen.He shapes events as they come.He steps out of the waysand let the design speak for itself. (45)
The architect gives himself upto whatever the moment brings.He knows that he is going to leave,and he has nothing left to hold on to:no illusions, no resistance in his mind.He holds nothing back from the project,therefore is ready for departure†,as a man is ready for sleepafter a good day's work. (50)
The great way is easy,yet programmers prefer the side paths.Be aware when things are out of balance.Remain centered within the design. (53)The architect's power is like this.He let all things come and goeffortlessly, without desire.He never expect results;thus he is never disappointed.He is never disappointed,thus his spirit never grows old. (55)
Those who know don't talk.Those who talk don't know. (56)
Alternate:
Those who do not have a clue are still debating about the process.Those who know, just do it. (56)
The architect is contentto serve as an exampleand not to impose his will.He is pointed, but doesn't pierce.Straightforward, but supple.Radiant, but easy on the eyes. (58)
If you want to be a great leader,stop trying to control.Let go of fixed plans and concepts andthe team will govern itself.The more prohibitions you have,the less disciplined the team will be.The more coercion you exert,the less secure the team will be.The more external help you call,the less self-reliant the team will be. (57)
————* Sounds a bit like the SEI CMM! Jim Archer said: "First you pay for results, Then you pay for effort, Finally you pay for attendance."† Especially when he’s only a Rational consultant.