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.

One measure for a Service

Customer view the interface part of service. But from architecture and design perspective apart from interface quality of code is very important. Keeping in mind this picture I have developed one measure:

Quality of Code (in percentage) =100* (Volume of code implementing business logic of service)/ (total volume of code for service)

Here the basic question arises how to measure volume of code. The traditional approach is LoC. But in OO world this is one of the biggest problems.

The measure, Quality of Code is not measure of Quality of service but one of the several measure which gives indication on frameworks used to realize a service. In ideal case the peripheral code to create a service should come from the framework/platform.

Parameter

In this article I am trying to comprehend information available about parameters in the wild.

Let’s try to define what parameter is:

“Parameter is a software construct whose value decides behavior of a software component/system”

Now the next question arises then what is property. In my point of view property is again a parameter (here it is not class property from object oriented world). The word property got its prominence from Java property files which essentially store key value pair in ASCII file.

No we have clear understanding of parameter. Let’s try to understand what are the various attributes attached to a parameter.

1. Data type
a. Simple (primitive – like integer, character, etc)
b. Complex (like an object type in object oriented world, tree structure in XML world)
c. Binary ( e.g. image, audio, video, etc)
2. Value
a. Key Value (x = 10)
b. Key Values ( x = 10, 15, 20)
3. Default Value/s
4. Group it belong to
5. Location in hierarchy ( say Corporate, Regional, branch, etc)
6. Over riding in hierarchy ( say Corporate value of a parameter takes precedence over Regional)
7. Status in life cycle (active, suspend, deleted, marked to be deleted, mark to be suspended, marked for deleted, etc)
8. Effective from ( date and time)
9. In effective from (date & time)
10. To what state of SDLC it belong – design time, test time, complete time, build time, run time, etc)
11. Storage location ( RDBMS, File system, etc)
12. Serializable ( Yes or No)
13. Current value, historical values, future probable values
14. Range of possible values
15. Boundary conditions
16. Who can update it (Role or user)
17. Can it be updated at run time (Yes or No)
18. How to manage changes in parameter value/s if it is under transaction ( changeable at run time or not – both cases)
19. Remarks

SOA Pattern - TestMode

1. Pattern Name
Training Mode
2. Also Known As
N/A
3. Class Name SOA
4. Intent
Even in production environment, it is required to execute a service in testing mode to verify certain facts.
5. Motivation (Forces)
In production environment if some error is occurring which is hard to replicate in testing environment due to lack of proper infrastructure or data?
At the time of deploying a new service in production environment requires assurance due to its importance.
6. Applicability
Service under consideration is composing other services.
Service under consideration has high importance.
7. Structure
N/A
8. Participants
N/A
9. Collaboration
N/A
10. Consequences
1. Increased complexity
2. Ease in testing (especially QoS) in production environment.
11. Implementation
N/A
12. Sample Code
N/A
13. Known Uses
N/A
14. Related Patterns
N/A
15. Reference
N/A

Document at scribd

Web Services - Versioning Practices

Before jumping to versioning of web service, I like to point out that a service has two parts:

1. Implementation: This part may be Java/C#/etc code specifically written for a service under consideration or legacy code & wrapper written over it.
2. Interface: This part is WSDL file in WS* ecosystem or a simple HTML in case of REST world.

Keeping this background in view versioning of a web service can be done at two levels.

1. At implementation level
2. At interface level (This blog entry focuses on WS* complaint web services only. So WSDL versioning will be discussed).

With versioning comes compatibility. Compatibility should be considered from service view as well as consumer.

Compatibility from Service View:

1. Backward compatibility: New version of the service remains compatible with older consumers who were compatible with older version of the service.
2. Forward compatibility: New version of the service remains compatible with future consumers independent of their compatibility with older version of service.

Compatibility from Consumer View:

1. Backward compatibility: Customers of newer version of the service remain compatible with older version of the service.
2. Forward compatibility: Consumers of older version of the service remain compatible with newer version of the service.

Versioning of a service does not emerge from zero. The requirement of versioning of a service emerges due to change in some feature of it. This feature may be due to change in:

1. Functionality
a. Technical – enterprise is changing technology A to B
b. Business – Address Service supplies alternative address in addition of business & home address
2. Quality of service – add one more level of QoS service (existing one are Platinum & Gold; newer one is Bronze)
3. Deployment scenario – change in endpoint, out sourcing of service

These changes can be of following types:

1. Incremental : functionality & features are added to service
2. Decremented: functionality & features are deleted from service
3. Transparent: Consumer do not care about changes. They continue to live in their own cozy world without caring changes in services which they are consuming as they are not affected by changes in the services.
4. New Emergence: New service has arrived in the wild.

An SOA or Service architect has to deal with all of these parameters which can affect service or consumer and which lead to versioning.

The easiest way to handle versioning of the services is to “not to care about it”. Just create a new service every time. This approach seams simple but will lead to the situation where enterprise will host several service which essentially giving same output with slight variation. Consumers are confused; they do not know which service to call. Bloated maintenance and support staff. Ever increasing service portfolio, without significant increase in functionality to be offered via services.

If business users of your organizations are happy and content with case, STOP reading, you do not need to know the details to avoid this mess.

Let us list all possible combinations.



To handle versioning in WSDL there are two approaches

1. Context based
2. Content based

The consolidated list of changes which can occur in WSDL is:

1. Change in the operation/s parameter/s of a Web service.
a. Addition of new input parameter/s (this will affect the current consumers)
b. Change in existing input parameter/s
i. Change in an XML document that might be used as a message parameter in a Web service. The changes in an XML document may involve the addition of optional elements or attributes (this might affect the current consumers) or of mandatory elements (this will affect the current consumers)
ii. Change in data type or order (this will affect the current consumers)
2. Addition of operation/s
3. Deletion of operation/s (this will affect the current consumers if deleted method is under use by any of existing consumer)
4. Change of the name of operation/s (this will affect the current consumers)
5. Change in structure of complex data type
6. Addition/Deletion of elements to existing response message
a. Required elements (this will affect the current consumers)
b. Optional elements (this might affect the current consumers)
So, how to do versioning?

1. Place the version number in the WSDL target name space.



2. Version the import types in WSDL



3. Embed versioning info in the interface (portType) name



4. Embed versioning info in the service name



5. Use UDDI as a Version aware registry
6. Provide one operation per WSDL which returns info about
a. Version of called WSDL
b. Status of current WSDL (deprecated or otherwise)
c. End point of latest WSDL
d. Version of latest WSDL

To handle versioning challenge following patterns can be used

1. Consumer binding pattern
2. Layer of indirection pattern
3. Adapter pattern

SaaS Pattern - SecureMyData

1. Pattern Name
SecureMyData
2. Also Known As
In house encryption & decryption service
3. Class Name
Architectural: SaaS
4. Intent
In SaaS environment security of customer specific data in multi tenant as well as non multi tenant environment is one of the most crucial concerns.
5. Motivation (Forces)
Alleviation of data security breach of customer data
6. Applicability
This pattern is applicable in SaaS environment.
7. Structure & Implementation
When end user asks for data.



When end user supply data.



8. Participants
N/A
9. Collaboration
N/A
10. Consequences
a. Increased traffic over network.
b. Additional infrastructure at customer site.
c. Additional implementation of message splitter and aggregator
d. Complex logic at user interface layer.
e. Customer satisfaction


11. Sample Code
N/A
12. Known Uses
To be find out
13. Related Patterns
This pattern is special case of Division of Labour (A-SOA-0001) pattern.
14. Reference
N/A

Download PDF from Scribd

Book Review: Applied SOA: Service-Oriented Architecture and Design Strategies

Book Review: Applied SOA: Service-Oriented Architecture and Design Strategies by Michael Rosen, Boris Lublinsky, Kevin T. Smith, Marc J. Balcer: Publisher- Wiley: ISBN- 13: 978-0470223659

As name suggest Applied SOA covers wide array of topics from SOA ecosystem. This book starts with introduction to SOA and then penetrates deep into SOA details. I found this particularly useful due to its practical approach while discussing details of SOA.

Most of the SOA books talks about web services but seldom talk about their implementation and architectural aspects.

Applied SOA is divided into three parts Understanding SOA, Designing SOA and Case Studies. Part one covers basic concepts about SOA, part two covers architectural consideration about SOA ecosystem and last but not least covers two detailed case studies. One case study covers integration using SOA while second talk about general SOA.

The book is a long one, but it is worth the read


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: There are numerous competing books. My list:
1. Service-Oriented Architecture (SOA): Concepts, Technology, and Design by Thomas Erl
2. Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services by Thomas Erl
3. Enterprise SOA: Service-Oriented Architecture Best Practices by Dirk Krafzig, Karl Banke, Dirk Slama

One can get more information about book and related topics from:

1. Amazon USA
2. Amazon UK
3. Publisher – Wiley
4. Interview with Boris and Book Review
5. Book Store for Buyers in India Indiatimes
6. One more book store from India Flipkart
7. At Diesel eBooks
8. Review at BPMInstitute.org