Design Patterns: Double Edge Sword

While conducting interview for architect, in realized that in software architect means is just mugging more about patterns (and may be some tools that why we have WebLogic architect or WebSphere architects). Further pointed talk with fellow architects, designers and coders led me know that a software’s quality is measured in terms of patterns. That was a new revelation for me. After googling a bit, I was surprised that lot of persons are complaining about over usage of design patterns. At last, I was happy that I was not alone who is complaing about Design patterns.
I strongly recommend a read to Evil Design Patterns by Paul Wheaton, When Design Patterns Are Evil by Cameron McKenzie & Paul Wheaton.

Template Based Design Technique - Part 3

In the past I was talking about Template based design. Here is the last blog in that series which talk about giving facility to create Master template.

1. Template Based Design Technique - Part 1
2. Template Based Design Technique - Part 2

Design Approach

During designing various systems for small and large companies, we have faced constant challenge of scalability, flexibility, performance. To tackle few of these challenges, we have developed our own pattern. It is named as Template Driven Design or the Template Pattern.

In a template pattern, the model (data such as XML,) has no inherent knowledge of how it would be utilized. The actual algorithm is delegated to the views, i.e. templates. Templates are applied to the different set of data and produce different results. Thus, it is a subset of model-view-controller patterns without the controller. For example, different XSLT templates could render the different XML data and produce different outputs.

Let us take an example to understand the challenge and then ways to resolve the same. We are very familiar with Microsoft Word. The users of MS Word can create template and further they can create document using templates. Suppose I wish to create my resume, I can use one of the several resume templates it provides to make one of mine. So now keeping template creation facility in view the whole process can be depicted as:

In this process “Resume Template” and “Resume“ have separate and distinct life cycles. Destruction of Resume does not affect “Resume Template”. Similarly destruction of “Resume Template “ does not affect “Resume “ once it is created.

This design pattern can be further explained below as:

1. If God is imaginative enough, he can accommodate all type of fields in his template even those will be required in future. We can consider God’s creation as Master Template which gives wisdom to angels to create Templates. In this terminology the “Master Template creator” acts as God. Assuming that the GOD knows only present in that case list of attributes are not final and it will not remain same for ever. Since GOD learns various new tricks over time period, so Master Template is not fixed and it also evolves over time period.

2. God can appoint various Angels (Template Creators), who can use one of the “Master templates” and can create templates for specialized purpose.

3. Now Human Beings (Resume Creators) can use one of the “Resume Templates” and can create various resumes.

So now question arises on how to implement same design pattern in a business application which could be web based. Assuming that the application is a web application and it is user creation service. Now keeping Template creation facility in view, the whole process of user creation service can be depicted as:

Let’s assume that God creates Master Template “MT1” with the following fields:

1. User Name
2. First Name
3. Middle Name
4. Last Name
5. Remarks
6. Gender
7. Status

Now the Angel (Template Creator) chooses the above Master template “MT1” and the following page will be displayed. (The significance of the other fields as mentioned below in the page, will be explained later in the document)

Now the Angel creates User Template “UT1” as shown below, with all the fields as specified in Master Template:

The user now chooses the above template “UT1” to create a new user and following page is displayed.

The user now fills this form with the following values:

User Name: Shilpi
First Name: Shilpi
Middle Name: Asnani
Last Name: Asnani
Remarks: Form created
Gender: Female
Status: Active

When the user clicks on save button, the data is stored in database. The data can be viewed back in following form:

Implementations Details

The following diagram covers the flow explained above. Also the Create/ Read/ Update/ Delete (CRUD) operations on form and Templates are covered in following sections.

GUI Interface component, as specified in diagram below, is used to generate master template XML documents. The XML file is compliant with the Master Template Schema.

After generation of XML file, a XSL designed for the Master Template is used to transform this XML document into HTML (Master Template).

Now on this HTML page (Master Template) the values are entered and data is saved in a XML file. The XML file is compliant with the Template Schema. The XSL designed for Templates is used to transform the XML document into HTML (Template).

The values are entered on the HTML (Template) page. On the click of the ‘save’ button by the user, the values are stored in the in a XML file/ database. The persistent XML is compliant with the ‘Generic Form’ schema.

To update the values, the data is retrieved from the database and a XML file is generated. Further an XSL designed for generic form is used to transform this XML document into HTML (Generic Form).On this HTML (Form) the values are edited and data is saved back into database.

Functional details:

Pre-requisite
• Copy all the schema files and XSL from the zip file in the directory “C:\Templates”
• Deploy the project “TemplateApproachProj” on JBoss
• Restore the SQL dump from the zip file in MySQL

The whole process flow is divided into 3 parts:
• Generate Master Template
• Generate Template
• Generate Forms

Generate Master Template

When the project (TemplateApproachProj) is launched then following screen is displayed:

Fig:2.1

The screen is used to generate Master Templates. The functionality of all the fields are explained below:
Master Template Name: This is the name of the Master Template

Master Template Description: This is the description of the Master Template

Field Name: The name of the field to be displayed on the form (e.g.: username)

Visibility: Two radio buttons indicating field’s display while creating a new form.

VisibilityInfoDisabled: If yes, then Angel can’t change the visibility status.

Mandatory: Two radio buttons specifying whether field is mandatory or optional while creating a new form.

MandatoryInfoDisabled: If yes, then Angel can’t change the mandatory status.

Input Type :Field on the form can be one of the 6 input types as listed below:
 TextBox
 TextArea
 RadioButtonGroup
 CheckBoxGroup
 SingleSelectDropList
 MultiSelectDropList

Specify Values for DropList: Specify the comma separated list of values for SingleSelectDropList, MultiSelectDropList, CheckBoxGroup, RadioButtonGroup input types.

JS File Required: If yes, then Angel can associate JS file.

Browse Button: Is used to select Master Template XML file.

Ok Button: Is used to create Master Template XML document with single element.

One More: Is used to create or add more elements in Master Template XML document.

Preview XML: Is used to view the elements of Master Template.

Let us create a Master Template. So specify the following details on the form (fig 2.1):

 Master Template Name as “MT1”
 Master Template Description as “Master Template added”
 Field Name as “UserName”
 Click “Yes” for JS File Required.
 Click “One More“ button
 Field Name as “Gender”
 Input Type as “SingleSelectDopList”
 Specify Values for DropList as “Male,Female,Not willing to reveal”
 Click “One More” button.
 Now the Master template file “MT1.xml “is generated at path “c:/Templates”.
 Click on browse button to select Master Template XML file “MT1.xml “created above.
 Click on “submit” button
 The (Master Template) HTML page (fig 2.2) is displayed.

Note:
1. The convention is that the name of the Master Template XML file is name of the
Master Template.
2. All the templates will be stored at location “c:\Templates”.

Generate Template

After clicking the ‘Submit’ button as mentioned above, following screen will be displayed

Fig 2.2

This HTML form (Master Template) is used to generate Template. The functionality of all the fields are explained below:

Name: This is the name of the Template

Description: This is the description of the Template

Visibility: Checkbox indicating field’s display while creating a new form.

Mandatory: Two radio buttons specifying whether field is mandatory or optional while creating a new form

Validation File: Specify the path of the js file. The convention is that the name of the function in js file should follow the following format.

function func_fieldname(fieldId)
{

}

*The fieldname is the name of the field with which js file is associated.
*The input parameter fieldId is the id of the fieldname.

Event :Specify the event, on which the function in js file will be invoked, for that particular field of the form

Let us create a Template. So specify the following details on the form (Fig 2.2):

 Template Name as “UT1”
 Template Description as “Template added”
 Validation File as “test.js”
 Event as “onchange”
 Click “Save” button.
 Now the template file “UT1.xml “ is generated at path “c:/Templates”.
 The below mentioned screenshot fig 2.3 is displayed
 Click on browse button to select Template XML file “UT1.xml “created above.
 Click on submit button
 The (Template ) HTML page (fig 2.4) is displayed

Note: The convention is that the name of the Template XML file is name of the Template.

Fig 2.3

Generate Object
After clicking the submit button as mentioned above following screen will be displayed

Fig 2.4

The values are entered on the HTML(Template) page. On the click of the ‘save’ button, a user is created.

The field username/Gender displayed on the above screen was specified in Master Template/Template.

Let us create a user. So specify the following details on the form:

 User Name as “Shilpi”
 Gender as “Female”
 Click “Save” button.
 Data is saved in database.
 The below mentioned screenshot (fig 2.5) is displayed
 Click on id (let say object id 47) created above.
 The data is retrieved from database and displayed on HTML page(fig 2.6)
 Change username as “ShilpiAsnani”
 Click on save button
 The data is updated in database and the below mentioned screenshot (Fig 2.7) is displayed

Fig 2.5

Fig 2.6

Fig 2.7

Pattern Service Discovery - Registration and Invoke

Pattern Service Discovery - Registration and Invoke v 1.0

Pattern Service Discovery - ESB and Registry

Pattern Service Discovery - ESB and Registry v 1.0 dated Oct 07 2009

Pattern Service Discovery - ESB

Pattern Service Discovery - ESB v 1.0 dated Oct 06 2009

Pattern Service Discovery - Registry

Pattern Service Discovery - Registry v 1.0 dated Sep 30 2009

Pattern: Service Discovery - Direct

Pattern Service Discovery-Direct v 1.0 Dated Sep 22 2009

SOA Pattern - Service Invocation – Asynchronous - PubSub

Pattern Service Invocation-Asynchronous-PubSub v 1.0 Dated Sep 13 2009

SOA Pattern - Service Invocation – Asynchronous - Queue

Pattern Service Invocation-Asynchronous-Queue v 1.0 Dated Sep 11 2009

SOA Pattern - Service Invocation - Synchronous

Pattern Service Invocation-Synchronous v 1.0 Dated Sep 10 2009

Template Based Design Technique - Part 1

Challenge of scalability, flexibility, performance and decoupling. To tackle few of these challenges, I have developed my own pattern. One of such pattern is Template driven design.

Let us take an example to understand the challenge and then ways to resolve the same. We all are very familiar with Microsoft Word. It provides ways to create a document-using template. Suppose I wish to create my resume, I can use one of the several resume templates it provides to make one for mine. Essentially this process can be depicted in following picture:



Figure 1

In this process “Resume Template” and “Resume” have separate and distinct life cycles. Destruction of “Resume” does not affect “Resume Template”. Similarly destruction of “Resume Template” does not affect “Resume” once it is created.


Now let us take the same argument a bit further. The advance users of MS Word are also aware that they can make template itself. Essentially they can act as Angle for resume creators. So now keeping Template creation facility in view the whole process can be depicted as:



Figure 2

The “Template creator” acts as Angle for resume creators (assuming template creator can not add fields which go beyond imagination of “Template creator”). The benefits of this pattern are very straightforward.

1. If God is imaginative enough he can accommodate all type of fields in his template. We can consider God imagination as Master Template, which gives wisdom to Angles to create Templates (Essentially we need mechanism to add fields in God’s Master Template as GOD can also lean new tricks over time period).
2. God can appoint various Angles (Template Creators) to create templates for specialized purpose.
3. Mortals (Resume creators) can use one of the “Resume Template” and can create various resumes.

So now question arises how to implement same design pattern in an business application which may be web based or not. For simplicity purpose let us assume the application is a web application and again it is again a resume making service.

So from process perspective this application can be depicted as:



Figure 3

This picture shows only simple flow. In real life there should be ways to perform CRUD operations on resume templates as well as on resumes. In truly flexible application even God’s list must be updatable.

So, how to resolve these challenges?

I will prefer step approach. In first step I will go with all knowledgeable God. List of attributes is final; it will remain same for ever. No changes in this list. In programming terms if any change is required in “Master Template” you need a developer.

So God decided that in resume you can have following fields at the most

1. Name
2. Physical Address
3. Telephone Number
4. Education
5. Employment History

So Angles (Template creators) will see following page:



Figure 4

Now template creator creates two templates, which have following values:

First Template

Template Name: Template-1
Template Description: Resume for fresh graduates
Candidate’s Telephone Number: Yes
Candidate’s Education History: Yes
Candidate’s Employment History: No

Second Template

Template Name: Template-2
Template Description: Resume for experienced
Candidate’s Telephone Number: Yes
Candidate’s Education History: Yes
Candidate’s Employment History: Yes

Now a candidate visits our Resume Service application. He sees two pages, which essentially show two templates created so far.



Figure 5



Figure 6

Suppose candidate who is visiting our application is fresh graduate so he fills up resume template for fresh graduate (Template-1) with following values:

Resume Name: FirstResume
Resume Description: Raj’s First Resume
Name: Raj
Physical Address: B-24, Block 13, Sector 86, Delhi 201001
Telephone Number: 987-654-3210
Education History:



Figure 7

When our candidate have looked at his resume he sees following:



Figure 8

To realize this application, traditional approach of storing data in RDBMS and creating dynamic HTMLs (using JSP, ASP, PHP, etc) will be quite difficult due to real life complexities of Master template and templates.

So what is the answer??

I will cover solution of this challenge in my one of future post.

Separation of Service Implementation and Service Interfaces – Service Design Pattern

While analyzing the numerous several services implemented across business domain using various technologies, I observed few that there is clear distinction between neatly designed and messy services. In clean services there has been effort to separate implementation and its interfaces while in not so clean, implementation and interfaces are coupled.

While designing the service most of the time developers have forgotten the concepts of decoupling.

This pattern can be explained in form of picture as:

Software: Architecture and Product Design

Yesterday, I had an interesting discussion while sitting at the bar with fellow architects and product managers. The discussion was about Software Architecture and Software Product Design. From the discussion I have drawn following observations:

Software Architecture governs fundamental structure, communication model among components/module and non functional aspects like: scalability, resilience, reliability, deploy-ability, maintainability, security, standard compliance, technology base, etc.

Product Design determine observable aspects of an software product like feature set, usability, visual aspects, installation ease, configure-ability, business model support, etc.




Certainly these observations were made after a couple of drinks.

Single Service: Multiple Interfaces – Service Design Pattern

In one of my recent project, I encountered an interesting challenge. There was couple of services. Each of these services needs to serve various consumers which have diverse background. Few of the customers were interested in one type of interface (Web Service) while other set of consumers were demanding SOAP over JMS, CORBA calls and few more. This was interesting situation. My SOA instinct told me to look for solution in ESB. But none of ESB was able to provide such diverse channel transformation. Then I discovered that solution lies some where else.

“A service should have multiple interfaces in terms of technology & business needs if ESB fails to provide.”

I realized from analysis of various other projects that this is a pattern which is quite prevalent but not explained in detail. I call this pattern Single Service: Multiple Interfaces.






Discovery of this pattern also leads to another pattern – Separation of Service Implementation and Service Interfaces. I will discuss this pattern in detail in some future post.