home
Technology Articles
  Skip Navigation Links.  
Technology Articles
Tuesday, July 10, 2007
 

Adapt frameworks


Enterprise IT departments need a solid software infrastructure foundation to create feature-rich, scalable and maintainable products. This software infrastructure serves as the common foundation on which applications sit and grow. Building the infrastructure needs solid understanding of business needs, software architecture and market awareness. I prefer to call these software inftrastructure elements as frameworks.How do we go about doing it?:

Certain frameworks are needed regardless of the type of business problem IT is entrusted to solve. In a MVC architecture(hopefully that is a base standard), these include frameworks like backend database interfaces, business layer interfaces and front end navigation interfaces. Some of the other common requirements could be a caching layer interface or an interface to call legacy backend applications.

One mistake most architects do in implementing these frameworks is to first evaluate what is available(usually opensource) and see how it fits in the organization's/architecture's needs. A typical example is jumping to a technology like Hibernate, the moment a requirement for a persistence framework is metioned. Instead the approach should be:

  • Have an open brainstorming and blue sky discussions with all developers on what functional facilities would they like to have in the framework being designed. I usually open the flood gates and let them ask what they wish for. In case of building frameworks, developers are our clients :-)
  • Consolidate and finalize the requirements.
  • Evaluate what is available in the open source world. Usually we will find some base framework in the open source world which will have to be wrapped around in an interface layer. This is usually a good idea since it gives us the leverage to swap out the open source framework in future without changing the custom interfaces.
  • An important element of building frameworks is to make sure that it has an easy learning curve for developers. Again, a simple interface wrapper helps.

For application specific frameworks, the process needs to be similar. At the inception stage of product development, architects need to review the existing frameworks and if another one is required for this particular application, get involved with business analysts to understand the business requirements and then with developers to understand their perspective on what they need.


Sunday, April 8, 2007
 

OpenSearch sample code


Open search implementation is extremely simple with open source java libraries available. We need utilities for parsing and generating RSS and ATOM feeds and utility for parsing opensearch. Steps we take to implement open search:
  • Read the open search description document from the url posted by vendor:

    // jdom is used for parsing

    public static DescriptionDocument loadDocument(String descriptionLocation) throws Exception{

    Document document = DescriptionReader.readDescription(descriptionLocation);

    InputStream in = new URL(descriptionLocation).openStream();

    SAXBuilder builder = new SAXBuilder(false);

    Document document = builder.build(new BufferedInputStream(in));

    in.close();

    return getDescriptionDocument(document);

    }

    The getDescriptionDocument(document) method parses out the received document and creates an object (DescriptionDocument)with calls like:

    public static DescriptionDocument getDescriptionDocument(Document document){

    Namespace OS_NS = Namespace.getNamespace("opensearch", "http://a9.com/-/spec/opensearch/1.1/"); DescriptionDocument descriptionDocument=new DescriptionDocument();

    Element root = document.getRootElement();

    descriptionDocument.setDescription(root.getChildTextTrim("Description",OS_NS));

    List lElementUrlTemplate = root.getChildren("Url",OS_NS);

    // Get the template from list above and set it in descriptionDocument object

    descriptionDocument.setUrlTemplate(extractUrlTemplate(lElementUrlTemplate));

    return descriptionDocument;

    }
  • Fill up the UrlTemplate extracted into DescriptionDocument with values like the template, pageoffset etc from browser form and create a query string.

    protected String fillTemplate(String template,SearchRequestBean searchRequestBean) throws Exception{

    String keywords = searchRequestBean.getKeyword();

    try{

    if(searchRequestBean.getKeyword()!=null && searchRequestBean.getKeyword().length()>0){

    template = template.replace("{searchTerms",URLEncoder.encode(keywords,encoding));

    }

    template = template.replace("{count",String.valueOf(searchRequestBean.getItemsPerPage()));

    template = template.replace("{startIndex",String.valueOf(searchRequestBean.getStartIndex()));

    template = template.replace("{startPage",String.valueOf(searchRequestBean.getStartPage()));

    template = template.replace("{language",String.valueOf(searchRequestBean.getLanguage()));

    template = template.replace("?}","");

    template = template.replace("}","");

    return template;

    }catch(UnsupportedEncodingException uex){

    //throw exception here

    }

    }

  • Execute the query by opening a url stream
  • Parse the RSS/ATOM received with a utility like ROME
  • Parse the OPENSEARCH received with a opensearch ROME module

Please send me an email for complete source code


Saturday, March 31, 2007
 

Federated search using opensearch api


Companies have a host of applications that make up for their complete offering on the web. Site search is required across all such applications some of which may even be vendor hosted solutions. Is a commercial federated search solution the answer?

Commerical federated solutions merge results from hetrogeneous content sources and apply filters before displaying results. A typical federated solution is an implementation and financial challenge.

Many business executives I have spoken with do not want a mesh up of results all in the same listing but would rather give the option to users for picking and choosing results from different databases and displaying them in separate sections of search results. In such a scenario, opensearch 1.1 specification provides a very viable solution to federated requirements. The implementation is simple and inexpensive and can bring results together from enterprise databases and from external sources.

If user interface is designed carefully and queries issued to enterprise databases using smart technologies like AJAX, we can offset issues like the network latency providing seamless experience to users. Because the databases and not indexed together in one huge index, we can also provide relational results as widgets at various locations on the website.

On the implementation side, we need to create a framework that can output results from different enterprise solutions in the open search format and a presentation framework for reading and displaying those results. There are plenty of libraries available to implement open search and I will give sample code in my next blog.


Thursday, February 1, 2007
 

Practical Applications of Polymorphism


Polymorphism is one of the most important concept of object oriented software design. Yet whenever I have asked questions about polymorphism during interviews, most candidates get confused while replying. The ones that do answer the basics lose it when asked about the practical cases where they have used polymorphism. Let us discuss some applications of polymorphism..

Polymorphism is the process of invoking methods on an object depending upon the type of that object as identified at runtime. Polymorphism is such a key concept that in practice it is applied in all scenarios where there is a need to generalize code so it can behave differently at runtime for specific implementations. It lets programmers code to abstractions like interfaces and abstract classes. References to interfaces can be used to invoke functions on concrete objects at runtime. This is extremely important while implementing software systems that need to have a scalable design and do not cater to one specific implementation. Some of the practical applications of polymorphism include:

  • All design patterns in any object oriented language like c++, java or smalltalk. I am hard pressed to find a design pattern that can be implemented without the use of polymorphism.
  • All IDEs like Weblogic Workshop, WSAD or Eclipse that discover components like page controls and generate code when those components are used in flows.
  • All frameworks like struts and spring use polymorphism.

For polymorphism to work, methods that get invoked at runtime must be declared as virtual. All methods are virtual by default in java but methods have to be specifically declared as virtual in C++. Let me take an example scenario in which polymorphism can be applied followed by actual code in java.

Problem Statement: Different workflows needs to be implemented depending upon an ID passed from front end. We need to design a system that can accommodate execution of different workflows and needs to be flexible enough to scale for new workflows that are added in future

public interface IWorkflow{

public boolean executeWorkflow(InfoBean infoBean);

}

public class Workflow implements IWorkflow{

public boolean executeWorkflow(InfoBean infoBean){

//logic for executing a workflow

}

}

public class Workflow01 implements IWorkflow{

public boolean executeWorkflow(InfoBean infoBean){

//logic for executing a workflow

}

}

public class WorkflowFactory{

public static IWorkflow createWorkflow(int workflowID){

Workflow workflowInstance = null;

try{

Class workFlowClass = Class.forName("Workflow"+workflowID);

workflowInstance = workFlowClass.newInstance();

} catch (ClassNotFoundException cfe) {

workflowInstance = new Workflow(); //workflowID will be invalid if default workflow is fine

//handle exception here

} catch (InstantiationException ie) {

//handle exception

}

return workflowInstance;

}

}

public class WorkflowClient{

public void invokeWorkflow(int workflowID,InfoBean infoBean){

try{

IWorkflow flow = WorkflowFactory.createWorkflow(workflowID);

flow.executeWorflow(infoBean);

} catch (Exception ex) {

//handle exception here

}

}

In the above example, all Workflow classes derive from IWorkflow interface and implement the executeWorkflow method. WorkflowFactory returns the object of type IWorkflow by dynamically creating a concrete class of type IWorkflow. WorkflowClient class invokes the executeWorkflow() method on IWorkflow interface but the right workflow object is invoked depending upon the runtime type of workflow. The solution is extremely scalable. As and when new workflows need to be added, we create a new workflow class. There is no code change required for any other class including the WorkflowClient. This is the power of polymorphism.


This page is powered by Blogger. Isn't yours?