RunOfTheMillBlog

Architects...Who? - Part II

ramkoth — Tue, 14 Mar 2006 02:00:00 GMT

Let’s talk about architects in Microsoft. The architects in Microsoft I know grew threw the ranks as Software Design Engineers and are extremely technical in nature. If a normal programmer knows 10 things about a thing, then an architect for the thing knows 500 different things about the thing. For instance, Christopher Brumme probably knows 500 different things about GC than a competent .NET Programmer. Roughly, architects in Microsoft product dev team do the following things

- They usually own a specific area of a product and come up with complete design (to the level of lowest granularity). Their tremendous experience in software engineering and their ship record helps them to look around corners, optimize things based on the underlying platform and provide guidance for developers to implement a particular strategy in a most optimal way.

- They work with other feature teams and architects to make sure that whatever they design seamlessly work with other components.

- They are extremely technical. This cannot be stressed enough.

- They write code – a lot of code actually.

- They communicate really well – one thing I have appreciated and trying to learn over a period of time is the clarity these guys bring to table. It is as though they speak the language of context-free grammar. You can’t interpret a sentence in two different ways.

They have huge credibility and it is due to their proven technology depth, engineering skills and their vast knowledge.

Let me digress and talk about the other types of architects I encounter (outside product teams) on a daily basis.

Beware of VNAs

I keep hearing this new term called Vendor Neutral Architects. First time, when I heard this, I spilled the NaaN that I was eating. (NaaN is not ‘Not a Number’, this is an Indian bread type J.) From what I hear, these guys are supposed to know all the technologies provided by all the vendors at the goriest level of detail for a particular problem domain to help customers make a knowledgeable decision. For example, if the domain is Messaging, then the VNA should know Exchange, SendMail, Lotus Notes etc in all their gory details and help customers choose the technology based on whatever the customer needs are. From what I see, you can count people with deep skills in all competing technologies in any domain. For example, it must be easy to count the people who can compare and contrast CLR and JVM at the minutest level of detail (for instance how the JIT optimization works in CLR and JVM or the GC heuristics used by different runtimes) or for that matter people who knows how to compare SQL Server Query Optimization vs Oracle’s query optimization. It is of course obvious that a person who has this knowledge will be of tremendous value to any team, but it is just that they are very hard to find.

From my experience, the VNAs I have met are definitely vendor neutral – in the sense they don’t know any vendor technologies at any level of detail. These people seem to have all the other ‘right’ attributes like socializing, playing politics, playing golf, nice dress sense etc. I am not generalizing, but this has been my experience so far. Some of these architects hold a view point that they only design at high level (i.e., UML and Visio) and leave the details to developers. Hello? You can’t write code, you are not an architect. Sorry – you didn’t pass the necessary condition (at least not in MTC).

So, I am going to use two variations of architects - Architect with capital A to denote MS Software Architects type; and an ‘architect’ with small caps to represent the solution architect and VNAs as defined (or loosely defined J) by world at large.

We want Architects not architects. If we come up short, I would settle for experienced software design engineers with good customer handling skills.

PS: These are all my personal view points and doesn't reflect view point of my employer.

Architect...Who? - Part I

ramkoth — Mon, 13 Mar 2006 09:33:00 GMT

It’s been an exciting job building a Microsoft Technology Center from the scratch – all right almost from scratch. The most important job of creating and selling the business value prop behind setting up a MTC is done by my boss – Sheila Gulati. From that point, I was tasked with setting up the MTC in Bangalore and this includes logistics, hiring, marketing (internal as well as external), partner management, lab set up and budget management – basically the whole nine yards of setting up and running a business. Given that I have been a techie all along, it’s been a wonderful experience for me to learn about business side of things and needless to say, I am learning a lot these days.

Let’s talk about hiring for a moment. I have to hire a set of technology architects and a bunch of contractors for managing logistics part of MTC. Needless to say, hiring right technology architects is essential to survival. Basically, the technology architects in MTC Bangalore should own a particular practice – a practice could be Connected Systems, BI, SQL, Collaborative solutions, Infrastructure Optimization, High performance computing etc. Owning a practice means the following things

- Ability to map customer business problems and pain points to technical solutions. TA is not expected to be a domain expert and it is expected that Account Manager and field folks who are associated with that particular opportunity has to help our TA to understand business context. But, TA should be able to take the business problem and map it to MS technology/solution platform.

- Ability to design a solution (widely called as solution architecture) using Microsoft Platform. Oh, by the way, when I say Solution Architecture, I don’t just mean the routine ceremonial, hand-waving high level visio/UML type architecture, but the low level design that includes how exactly the solution be built with MS with focus on performance, security and extensibility.

- TA is considered the GOD of the practice. She is expected to be omniscient about the technology area that belongs to her practice that she owns. For example, if you are a TA for HPC, you are expected to know anything and everything about Beowulf cluster, MPI programming, HPC management, RIS etc. Customers expect you to know everything; we expect you to know everything about the area that you own.

- Needless to say, TA should have great communication skills and more importantly, great listening skills.

So, you can say it is all about technology depth, great design skills, great communication skills and customer empathy – and oh yes, little bit of experience is required (minimum 10 years).

With this idea, I set about to hire technology architects for MTC. The experience has been illuminating.

Architect…Who

We did receive whole bunch of resumes. The resumes roughly fall under following categories.

A) Project manager. Typically has been handling a mid-large sized team (25-100). The resume is all about how he/she built a practice, enabled his/her reports to do whatever they are set out to do..blah blah. They don’t have any hands-on experience of late (that means 2-5 years). Majority of the resumes belong to this category. These ends up being paper rejects because of wrong fit.

B) Developers with a difference – and the difference being that they have been developing similar apps for 10 years. They typically build in-house apps for IT dept for large customers for quite sometime. Typically (not always), they wouldn’t have designed large scale apps and hence doesn’t know some of the fundamentals related to scalability, transactions (yes sir, it is true), basic algorithms etc. Their title is architect, simply because of their experience. Most of them are paper rejects because of lack of designing large scale apps, some of them get rejected in the first round after stumbling upon cursive questions on transactions and scalability.

C) Individual contributors – These people have been designing and developing large scale apps for quite sometime. They like being individual contributors (good fit) and they want to remain technical (good fit). In this case, people with good communication and consulting skills (apart from technical skills) proceed to next round. We’ve had some success here. But, unfortunately, we don’t get a lot of these.

Here is an interesting statistics about the source of resumes. Usually, type A and type B come from System Integrators and Customer IS departments. Type C typically comes from ISVs and some SIs. So, you may wonder why we are getting type A (project management folks) when it is very clear what we want is some one with deep technical, hands-on and consulting skills. The problem is because of the nebulous definition of the word ‘Architect’ in the context of IT industry.

Let’s look at the definition of an Architect from the following sites

http://www.bredemeyer.com/pdf_files/role.pdf

http://www.agilearchitect.org/agile/role.htm

http://www.artima.com/intv/architect.html

http://www.certmag.com/articles/templates/CM_gen_Article_template.asp?articleid=1406&zoneid=225

If you look at the definition of ‘Solution Architect’ in many of these sites, they go beyond the role of solution architect (i.e., to build a solution architecture) and cross over into many of the project management functions (like political handling (for god’s sake how is this part of architect’s job. Actually every role has some politics associated with it. What’s new here), little bit of project management like managing budget, ROI calculation etc). The agile folks seem to have a much more pragmatic view of Solution architects as opposed to others. I think the problem seems to be more like the confusion of different roles such as architects, project management, portfolio management etc. It is entirely possible a single person may be doing all the roles, but it is important to cleave them apart.

And I am not sure why we take these definitions as god’s gospel. Where are the proof points that this model has worked? Given that overwhelming of the software projects are failure (http://www.agilefactor.com/stats.aspx), what you have, in fact, is the counter-proofs that these models never worked. I personally feel closer to agile approach.

There is an interesting aside. In India, most of the IT population works for system integrators. In the Indian Sis, it is (at least it used to be) very difficult for a techie to have a career as software engineer. This is not because the SIs don’t want to promote individual contributor role with technical focus, but because of the ‘time and material’ business model they all follow. In this model, ROI of a ‘resource’ is directly proportional to how much they can be billed in a specific time. If you remain as an engineer for quite sometime, the ROI (of you) will be diminished over time as your pay increases over time, while your billable amount remain constant (or near constant). I guess this is changing now as the customers also recognize the word ‘architect’ and willing to pay a little bit more. Also, there are few companies in Pune that truly value Software engineers and have built career plan for them as individual contributor role.

In the next blog entry, I will talk about architects in Microsoft and how different they are from the architects as understood by outside world.

PS: These are all my personal opinions based on my observations and it doesn't reflect my employer's view point.

2005 Cyber security bulletin by CERT

ramkoth — Tue, 10 Jan 2006 07:52:00 GMT

CERT has published an Cyber security bulletin for Year 2005. Here is the snippet

This bulletin provides a year-end summary of software vulnerabilities that were identified between January 2005 and December 2005. The information is presented only as a index with links to the US-CERT Cyber Security Bulletin the information was published in. There were 5198 reported vulnerabilities: 812 Windows operating system vulnerabilities; 2328 Unix/Linux operating vulnerabilities; and 2058 Multiple operating system vulnerabilities.

Here is the link - http://www.us-cert.gov/cas/bulletins/SB2005.html

They do have a disclaimer that states that the result is aggregation of reports from various sources.

Building Colloborative Solutions Content released

ramkoth — Fri, 02 Dec 2005 16:46:00 GMT

We have been running a series of Architecture Workshop under the theme of 'Solution Architecture Series'. The idea behind the SA series is to create a workshop that is focused on building a specific type of applications - for example, apps like typical web based OLTP application or a Business Intelligence App or High performance App or Service enablement etc.

For the first workshop, we chose Colloborative applications as the theme and you can find the content and presentations here in the GotDotNet workspace. Your comments are appreciated.

Microsoft Technology Center in Bangalore

ramkoth — Thu, 28 Jul 2005 10:27:00 GMT

I am happy to announce that we are building a Microsoft Technology Center (MTC) in Bangalore. MTC is a world class facility that offers several services to customers and partners (ISVs and SIs) to architect and build high quality, world class, robust applications using our technologies. The services offered are free of charge and the main motivation here is to help customers and partners build high quality apps and infrastructure using our technologies.

We offer whole suite of things ranging from a quick 2-4 hours strategy briefing to 2 days architecture design sessions to 2 weeks POC.

We provide world class facilities for doing a POC (proof of concept) in our MTC. As a customer/partner, you can bring in your development team and technical architect from MS will work closely with that team on the architecture, design, development and testing the POC. We will provide a dedicated work spaces and lab resources for developers and architects from our customers.

We are expecting the MTC Bangalore to become operational by November 2005. We are looking for solution architects who can survive in an high-octane intellectual environment. We are interested in folks who can button up and do strategy briefings for CIOs and at the same time, can also roll up your sleeves to design and build (meaning writing code) a solution. We are looking for both IT architects and solution architects. What we are looking for is passion to help customers, passion for MS technologies and passion to learn and lead. If you think you are the right person, please feel free to contact me through the contact form. Looking forward to hear from you.

SQL Server Architecture Workshop content posted

ramkoth — Thu, 28 Jul 2005 10:06:00 GMT

The content for the SQL Server Architecture Workshop (decks + samples) have been posted in a Gotdotnet workspace called .NET Architecture Workshops. Please follow the link to register yourself with the workspace to download the content.

I will post the CLR Architecture workshop content soon.

I am also looking forward to hear from you regarding the future workshops and the subject areas of interest to solution architects. Please use the 'Contact Form' to directly send an email to me. Thanks.

Performance Clinic Content posted

ramkoth — Mon, 30 May 2005 01:57:00 GMT

I and my colleague Govind Kanshi have been going around India talking about performance tuning as part of the Performance Clinic Workshop. The content for the workshop (decks + samples) have been posted in a Gotdotnet workspace called .NET Architecture Workshops. Please follow the link to register yourself with the workspace to download the content.

BTW, we also did SQL Server 2005 internals workshop and CLR internals workshop earlier. We will be posting the content for those workshops in the same workspace in the near future. Govind maintains an excellent blog that contains tons of pointer to interesting database related articles that formed the basis for our SQL workshop.

An Ode to interop

ramkoth — Sat, 12 Jun 2004 00:20:00 GMT

Pat’s obsession has caught up with me as well…My daughter was singing this all the time after we visited Disneyland... I nspired by 'Small World' song of Disneyland It's a small world after all Hence we should Inter...op It...(read more)

An Ode to Interop

ramkoth — Fri, 11 Jun 2004 23:15:00 GMT

Pat’s obsession has caught up with me as well…My daughter was singing this all the time after we visited Disneyland...

Inspired by 'Small World' song of Disneyland

It's a small world after all

Hence we should Inter...op

It's a small world after all

Make sure we can interop

(IBM Interop)

It's a world of CICS and a world of queues

It is a world of Bigs and a world of blues

We can screen scrap you; to get to guts of you

So that we can Inter…op

(It's a small world after all…)

(Apps interop)

It's a world of Apps and a world of Silver bullets

It's a world of COTS and world of stove pipes

Wrap with services; talk with adapters

So that we can inter…op

(It's a small world after all…)

(J2 Inteorp)

It's a world of objects and world of messages

It's a world of Transaction and world of resources

There is so much we share; that we should be aware

That we should inter…op

(It's a small world after all…)

You can extend this with (DB Inteorp), (Directory interop) etc. Very extensible song :)

EVMs and Indian Elections

ramkoth — Tue, 01 Jun 2004 05:02:00 GMT

India, world's largest democracy, just recently successfully completed the general election for its parliament. For the first time in its history, India has successfully used EVM (Electronic Voting Machines) for the polls in all the constituencies.

Obviously, usage of EVMs have been the highlight of the election. Obviously, it didn't get the attention it deserves, because media doesn't care about things that work. Here are some of the requirements for EVM system.

600 Million possible voters (380 million actually voted in this election)
Million election booths.
Each constituency will have different set of candidates. Some constituency may have up to 100s of candidates standing in the election - which is an unlikely thing in west (of course, California is the exception.)
EVM should support 18 different official languages. For example, I hail from a state called Tamil Nadu and voters belonging to this state understand only Tamil.
~15-20% of the voters are illiterate - can't read and write. It adds an interesting perspective to the usability aspect of EVM.

Here are few facts.

One million EVMs have been manufactured for this election.
There was virtually no complaint about usability of EVMs. In my opinion, this is the greatest achievement. If you ask why, just think about all the hoopla around Florida episode during last USA presidential election.
Each EVM is shipped to the local booth via appropriate transport mechanisms. I am sure you have seen photos of elephants carrying EVMs to the remotest corners of India. This is a logistical nightmare at the best of times. This is one of the reasons (apart from security) as to why the election was conducted over a period of three weeks.
All votes were counted. (sorry mate, couldn't avoid taking a pot shot :) Honestly though, I have a huge respect for US electoral process. IMO, contrary to popular opinion, it is really efficient. It could be made better, by buying EVMs from India. :))
Here is the counting process: All the EVMs are brought to a centralized place and they were connected to the network. Counting is a matter of just summing up the votes for individual candidates from different EVMs. All said and done, the whole process takes up to 2 hours. Before the usage of EVMs, the whole process takes up to 2 days and is error prone as the votes were counted manually.
Millions of trees were sparred from extermination.

The cool thing about this election is this: If EVMs work for India, it should work for every democratic country for conducting polls (and it will work for china too, if and when china becomes democratic.) When it comes to polls, India should be the benchmark, just by its sheer size and the population. Folks who designed this system should be really proud about what they have achieved.

So, next time when you think of India, please think about the EVMs and not call centers and snake charmers. :)

Entity Aggregation white paper released

ramkoth — Wed, 26 May 2004 08:24:00 GMT

In my earlier posts, I was talking some of the real world challenges that an architect face while trying to implement SOA in their enterprise. Entity Aggregation is one of those problems. You can read more about entity aggregation here.

Integration Patterns preview released

ramkoth — Sat, 15 May 2004 18:38:00 GMT

PAG has released the preview of integration patterns which can be found here. I contributed/co-author of the Entity Aggregation pattern which can be found here. My solo paper on Entity Aggregation will be released in MSDN sometime soon.

Moving to India DPE

ramkoth — Sat, 15 May 2004 18:36:00 GMT

I haven't been able to post for a long time as I was involved in too many things - one of the things happen to be my move to India DPE as an Architect Evangelist.

I am really excited about the opportunity to interact with developers and architects in India. Every Indian professional in USA has this dream of going back to India and work there and I am really glad that this is becoming true in my case. I am starting my new job on May 24th of this month and like I said earlier I am super excited to be transferred to the 'front-line'. (Actually, I see that more of a love front rather than a war front. Not sure why people characterise field as a 'war front'.)

I will continue to post my views on SOA, Data and other such things in my blog.

SOA - Real World Challenges reposted

ramkoth — Tue, 16 Mar 2004 16:18:00 GMT

I guess I shouldn't post a blog during mid-night. Here is my second try. My views on real-world challenges can be found here

BTS 2004

ramkoth — Mon, 15 Mar 2004 13:44:00 GMT

IMHO, Biztalk Server is the only team in Microsoft that understands integration issues. They have delivered a product that in my opinion provides complete solution for the B2B as well as EAI scenarios. The two things I love about the product are - Orchestration and Business Rules Engine. BTS architecture is really elegant and it is built for customization from the ground up. It is possible mainly because, various components like (Pipeline components, Adapters, Ports, Message Bus etc) are loosely coupled. I could have done certain things differently - like keeping orchestratin little bit loosely coupled from the messaging etc. But, I was the first one to bitch about loose integration between orchestration and messaging in the previous version.

They really worked their tail off to deliver a quality product; their perseverance and hard-work deserves a round of applause.

While we are it, please bookmark Scott Woodgate's blog. I am sure he is interested in your feedback.

SOA Real-World challenges

ramkoth — Mon, 15 Mar 2004 13:30:00 GMT

This post discusses some of the challenges architects/designers face while trying to implement SOA in their Enterprise. Our team has been working with customers for the past two and half years to implement SOA. This post reflects collective experience of our team.

Most of the discussions around SOA revolves around basic issues as RPC vs Doc/Lit, Remoting vs Web Services, usage of WS-* protocols etc. These are relevant issues and has to be discussed in detail. But, there are other important issues that needs to tackled in order to implement SOA in an enterprise. In my opinion, WS-* is necessary, but not sufficient. So far we have been talking about the necessary part. This post will cover the sufficient part.

Today, SOA is mainly used in connecting applications. In other words, the sweet spot for SOA is primarily in the integration space. If you look at the solutions that are built in a typical enterprise today, they fall into two classes of solutions - Service Delivery and Information Analysis. Service delivery - as its name suggests - is about delivering services offered by business systems (like ERP) to end-users directly. Self-Service solutions such as Employee Self-Service portal falls into this category. Primary motivation for self-service type solutions is to reduce the cost by dis-intermediating the interaction between user and system.

Let's take Employee Self-service portal as an example. Building this portal involves integrating multiple systems - HR System, Payroll system and Benefits system. Usually, these are separate systems and are autonomous in nature. Some of these systems may even be outsourced. For example, Payroll capability is usually outsourced.

Now, let's look at the challenges involved in building a self-delivery application.

Identity management - Usually, every business system maintains their own identity profile. They also define their own authorization realms - they define roles specific to the business functionality they expose. So, managing identity across multiple systems is a major challenge. Some of the issues you have to resolve are

Single Sign-On (both web-based SSO and system level SSO)
Federation - For example, Payroll systems and benefits systems may be managed by a different enterprise. How do I federate identities across organization boundaries.
Provisioning - When a new identity is created (during hiring for example), what is the process involved in creating appropriate identities in other systems.
Synchronization - Usually Single-Sign on solution requires some sort of credential mapping. How do we make sure when password changes occur in a business system and how do we synchronize that SSO credential mapping store.
Authorization - How do I authorize in this world?

EII (Enterprise Information Integration)

Every system maintain its own view of employee. For example, payroll system defines the payroll specific view for the employee entity, benefits system defines benefits specific view for the employee entity etc. But, building a service-delivery application requires a unified view of employee. A better example would be 'Single view of customer' issue that every enterprise faces.
Horizontal partition - There are cases where entity instances are partitioned across multiple services. How do we present an aggregated view.
There are cases where your solution requires cross join of entities encapsulated by different systems. In that case, you have no choice but to bring those entities to a central store. Cross-join scenarios are so devastating that your mind set will shift from service-orientation to data-orientation. I have gone through that experience :)

Schema Harmonization - Every service maintains its own view of an entity. How do we harmonize the schematic differences between services? Canonical schema is one practical way to harmonize the differences. But, the real challenge is to get all the stake-holders to agree on the schema. This is where a strong enterprise architecture team can make a difference. Another challenge is - would you go for a big-bang approach with enterprise modeling or would you go for incremental approach. Current thinking is to go with incremental approach. Start with few commonly used entities such as Customer, Product etc and then add more stuff later on.

Service Management - How do I manage, bill, meter, provision, de-provision services?

There are more issues. But, these are the primary challenges one would face while trying to design a solution based on services. In my future posts, I will spend some time on each of these issues and share with you some of our experiences and key learnings.

I would love to hear your opinions on this subject. I am sure some of you may have implemented SOA in your IT and faced similar challenges. I am also sure that you may have come up with better solutions and have a better insight into this problem. Please, please share your learnings. We can all learn from each other.

Making Services Idempotent - Part II

ramkoth — Sat, 13 Mar 2004 16:27:00 GMT

I have created this as an article. Please follow this link.

Making Services Idempotent - II

ramkoth — Sat, 13 Mar 2004 16:24:00 GMT

This post covers the scenarios where you are building web-service gateway over legacy applications. In my previous post we covered the basic implementation for making services idempotent. We talked about the notion of persistent log that keeps track of unique request messages and the necessity to scope processing of request and log update in an atomic transaction. To re-cap, here is the pseudocode that we have seen in the earlier blog.

[WebMethod]

ResponseMessage DoRequest(RequestMessage)

{

Extract the request identifier from the request.

Check if the request has already been processed by querying the persistent log.

If (request processed) then return response

Else

{

//The transaction object need not be ITransaction. It could be

//ISqlTransaction or IOleDbTransaction or whatever depending on

//the resource manager you use.

ITransaction trans = CreateTransaction()

ProcessMessage(RequestMessage, trans);

//Store the response along with the request identifier the persistent log

UpdateLog(responsemessage, request identifier, trans)

trans.Commit();

Return responsemessage;

}

What if the ProcessMessage step is simply nothing but delegating the request to some legacy system (of course after doing appropriate message transformations)? If this is the case, there is no way you can scope the two steps (ProcessMessage and LogUpdate) in an atomic transaction. Here are some tips that may help you.

Approach 1: Delegate the responsibility to legacy system

In this approach, you don’t have to do anything special in the web service layer. You just pass on the unique request identifier to the legacy system and let the legacy system do the work. But for this to work, the legacy system should have been designed for this up-front. If that is not the case, you may have to tweak the legacy system which may be impossible.

Approach 2: Keep track of the communication state.

This approach is really useful, when you are using queues to communicate with legacy system. In this approach, you have to keep the state of communication with the legacy system in question. Following are the valid states: {RequestSent, ResponseReceived} – where RequestSent implies that the request has been sent to the legacy system, but response hasn’t been received. ResponseReceived state implies that the response has been received from the legacy system.

Now, let’s see the pseudocode for this approach

Extract request identifier from the request

Check the state of request by querying the persistent log

If (state == ResponseReceived)

{

//This implies that the message has been processed and the response has been received.

//Just retrieve the response from log and return.

ResponseMessage = FetchResponseFromLog()

Return responseMessage;

}

if (state == ResponseSent)

{

//This means that the service crashed before the response was received.

//implying that the response is out there in the response queue to be picked up.

Goto ReceiveResponse;

}

BeginTransaction1

TransformMessage();

EnqueueMessageToLegacySystem(requestMessage);

UpdateLog with the state = RequestSent

CommitTransaction1

ReceiveResponse:

BeginTransaction2

ResopnseMesage = WaitOnResponseQueue(RequestIdentifier)

UpdateLog with the state = ResponseReceived. Also save the responsemessage in the log.

CommitTransaction2;

Return responseMessage;

</PseudoCode>

Main difference is that there are now two distributed transactions (I am assuming that the queue infrastructure supports XA style transactions.)

This algorithm can be extended for the general case.

PS: One reader, by the name of David Taylor, mentioned that in their domain they follow a different approach to implement idempotent behavior. Apparently, in their domain, most of the messages contain some unique message identifier. For instance, they have used timestamps as a means to uniquely identify the message. Here is his message.

In my industry, we use an API called EPP for Domain Name provisioning (an IETF standard). In that case the protocol has been designed to be idempotent purely by API design (rather than sending unique identifiers).

An example being that when you renew a domain, you need to supply the current expiry date, so if you send a command to renew for 1 year (and then repeat the message) you dont end up with a 2 year renewal.

So the API designers have specifically designed each operation as idempotent without requiring a unique client or server identifier. It words quite well because you dont have to cache the unique ids.

PS: Timestamps are notoriously unreliable. So, be careful when you use timestamps.

Make Services Idempotent

ramkoth — Sat, 13 Mar 2004 03:31:00 GMT

In the brave new world of service orientation, service requests may fail due to different reasons that may include network connectivity, resource failures (like db failure) etc. When a client receives a failure, all it can do is to retry for a while and then give up. This implies that the request may actually arrive more than once due to un-reliable nature of protocols like HTTP. Let's take an example

[WebMethod]

ResponseMessage DoRequest(RequestMessage)

{

ProcessMessage(RequestMessage);

Return responsemessage;

}

Failure can happen at any time. Failure can happen

before the message has been processed,
during the processing of message,
after the processing of message but before returning the response.

Let's assume the third case. When a client re-sends this message again, then the message will be processed again. This may cause problems in many scenarios. For example, think of DebitTransaction as a service operation. You don't really want your debit transaction to be processed twice.

One of the important design principles of service orientation is that the service should be made idempotent. Idempotent means 'it is okay if the requests arrive multiple times'. As a designer of the service, you should expect the messages to be delivered more than once and you should process the message only once.

Unique Request Identifier

Traditional way to make a service idempotent is to create unique request identifier and pass the request identifier along with the message. When the client retries, client uses the same request identifier rather than creating new one. On the server side, service should inspect the request identifier, check if the request has been already processed and if so, return the response; if not - process the message, store the response in the persistent log along with the request identifier, indicating that the request has indeed been processed. Here is the pseudocode

[WebMethod]

ResponseMessage DoRequest(RequestMessage)

{

Extract the request identifier from the request.

Check if the request has already been processed by querying the persistent log.

If (request processed) then return response

Else

{

ProcessMessage(RequestMessage);

Store the response along with the request identifier the persistent log

Return responsemessage;

}

Will this algorithm work? Not quite. For example, consider the scenario where server crashes after processing the message and before storing the response in persistent log. This means that the request is not logged in the persistent log, even though it has been processed. So, when the request arrives again, you will process it because the request is not present in the log.

So, how do we solve the issue? The key is to use transactions. Both processing of message and log updates should happen in a single atomic transaction. Here is the modified logic.

[WebMethod]

ResponseMessage DoRequest(RequestMessage)

{

Extract the request identifier from the request.

Check if the request has already been processed by querying the persistent log.

If (request processed) then return response

Else

{

TransactionObject trans = CreateTransaction()

ProcessMessage(RequestMessage, trans);

//Store the response along with the request identifier the persistent log

UpdateLog(responsemessage, request identifier, trans)

trans.Commit();

Return responsemessage;

}

If your persistent log store is different from your application data store, then you may have to do distributed transaction - which is really costly. So, it is better to keep the log store and your app data store to be one and the same.

How do you pass the unique identifier?

Use SoapHeader to embed request identifier related information. Service can obtain the SoapHeader using the ASMX programming model. Please refer to ASP.NET documentation for using SoapHeaders.

If you are using WSE2.0 for the client, then you don't have to generate message id elements. It will be generated for you automatically.

What if the service implementation is simply a façade to legacy system? In that case, you can't really do a distributed transaction between legacy system and persistent log. How do you solve that? I will cover this in a later blog. It is not as difficult as you may think.

Do all the service requests need to be idempotent?

No. Certain requests are implicitly idempotent. For example, read requests are implicitly idempotent. Certain updates are also idempotent. For example, changing an address is idempotent - it doesn't matter how many times you process the request, end result is still the same. (think of it as an assignment statement i=2. This statement is idempotent.)

I will also cover how this topic is related to WS-ReliableMessaging in a later blog.

Service Boundaries, Business Services and Data

ramkoth — Tue, 09 Mar 2004 04:44:00 GMT

One of the core tenets of SOA is that the services have a clearly defined boundary. Services explicitly choose to expose certain (business) functions outside the boundary. Another tenet of SOA is that a service - with in its boundary - owns, encapsulates and protect its private data. But, there are not too many guidelines out there that talks about what should be exposed and how the boundaries should be drawn.

Keep an eye on 'Data cohesion' when you are designing the service boundary. I will give you an example. A while back, I was involved in architecting a product that has many different modules - like sales, finance, inventory, CRM, billing etc. Our natural instinct was to define each of these modules as a 'Service'. So, we went ahead and defined a Sales service, CRM service, Finance service etc. We defined the entities that are required for each one of these apps and designed the database schema etc. Also, following SOA's design principles, we defined the contracts for the services and exposed different functionalities. Finally, we used web services as a implementation mechanism to expose the services. At the end of the day, we thought we had a pretty good design.

But, things started falling apart the moment we started integrating different services. The main problem we faced was that the 'Customer' entity is required by all the systems. This entity can be updated by all the services. So, we had to implement a nasty 'merge replication' like infrastructure over web-services in order to keep the customer data in sync. To avoid building merge-replication infrastructure across service boundaries, we decided to remove the so called common entities (customer, product etc) and created a separate module or service for them - conveniently named common module. The idea here is that the common module provides services that abstracts the common entities and exposes operations for CRUD behavior (I know…CRUD is a bad word). There is another way to do that as well. For each entity, designate a service as a owner (a.k.a., System of record). You can think of Common module as a system of record for the common entities. So, in theory, both the approaches are equivalent.

So, we went down the path of building a common module (system of record) for common entities. Things worked for a while, before we got into implementing a scenario that actually required a cross-join between product entity and a related entity owned by order management service. Mind you, this is really not a business intelligence scenario. This is a simple search screen that should go to database, do the search and show the results for end-user to pick an item. Performance will go down the tube, if you implement a cross-join between entities owned by different services. So, you have to build EII (Enterprise Information Integration) like solutions, which will most probably replicate related entities, so that joins can be done efficiently in database. And, we all know that building an EII solution is a costly affair.

So, what is the solution? Here is a practical one. "Try to share the database between related services.“

But, 'wait a minute', you may ask - 'you are saying something heretic. Services are not supposed to share data between them'. Well, you are right. But, remember the problems created by simply adhering to core tenets of services. One of the problem with the core tenet of services is that the boundary tenet doesn't talk about data, it only talks about what should or should not be exposed. Since it doesn't talk about data, it is very easy draw service boundaries that may create data related problems later on.

If we still want to remain a purist, we have two choices: 1) re-interpret/relax service boundary rule 2) define a new type of service called business service. I believe option 2 is probably the best path.

Think of business service as a software system that automates one or more business capabilities. A business service may expose one or more services that correspond to each business capability. But, all those services share a logical data model. In other words, boundary is defined at the business service level and not at the individual service level. This is an important lesson we learnt.

For example, think of your favorite ERP system (SAP, Peoplesoft etc) as a business service that exposes one more services - one for HR management, one for Inventory, one for Order management, one for Accounting etc. But, they all share single logical data model. Ever wondered, why big ERP systems such as SAP have a single database that contains the tables required by all the modules? I tend to think this is the reason why they did it. But, I may be wrong.

So, here is the summary of key practical learnings

Define boundary at the business service level.
Business service may contain one or more services, but share data.
If you have legacy systems that you have to integrate, then you can't do much. Business services and their boundaries have been defined for you.

Mike is Modelling

ramkoth — Wed, 04 Feb 2004 18:55:00 GMT

Mike platt is running interesting posts in his blog.

He recently posted a blog on modeling. This is a must read. He says,

“I do feel very strongly that the concept of a general purpose transformation from one domain or level of abstraction to another will always yield a sub optimal solution unless there is a transform algorithm. I suspect this is why the CASE tools industry died and why O-R mapping technologies (and the upcoming O-XML mapping technologies) are also doomed to provide poor performance in the general case. I do feel very strongly that the concept of a general purpose transformation from one domain or level of abstraction to another will always yield a sub optimal solution unless there is a transform algorithm. I suspect this is why the CASE tools industry died and why O-R mapping technologies (and the upcoming O-XML mapping technologies) are also doomed to provide poor performance in the general case. “

How true. That's actually summary of my five prior posts.

SOA and OO contd...

ramkoth — Sat, 31 Jan 2004 18:25:00 GMT

When I looked back at my last blog on SOA and OO, I figured out I digressed a little bit from the topic that I wanted to address. It was late in the evening and my mind was as quiescent as the little stormy weather that we were encountering in Redmond. In that post, I talked about first class abstractions required to build business applications or services and how OO fits into scheme of things. Simon Guest also has an interesting post on this topic.

In this post, I want to stick to the original topic of SOA and OO. SOA’s basic premises are

· Business systems are autonomous. They evolve independently of each other. They protect their internal state. For example, most enterprises use Siebel for CRM, Peoplesoft for HRMS and SAP for others.

· Corollary 1- Heterogeneity is the reality.

· Corollary 2 – Loose coupling is necessary for interaction between these systems. Otherwise, a change in one system (like upgrade) will have serious consequence on other systems.

· This one is little bit controversial. Business systems don’t trust each other and hence doesn’t support Atomic transactions.

When you are building a system that automates certain business capability, it is better to expose them as services as at some point of time, this system needs to be integrated with other systems. SOA talks about variety of design elements such as Service contracts, granularity of the service request, service agents, business process that span services, messages as a means to carry the request, canonization of schema as lingua-franca between services etc. You can read all about that in this primer.

OO for service implementation

Consensus among various people I talked to is that OO can be used for implementing the service. I have seen approaches that uses a service facade which then internally uses business components to fulfill the service request.

But, you still have to think about the top level abstractions that are listed in my previous post.

I have been asked if SOA can be realized using Distributed objects technology. Yes, it is theoretically possible to build SOA based apps based on ORB technologies like COM or CORBA(yeah, yeah, i know CORBA is a 'standard' - a standard not followed by too many people). But, what you lose is loose coupling - which will come back to bite you after a while. You are better off sticking to a standard such as SOAP/XML/WS-* specs.

Another frequently asked question is: Isn't it the case that the usage of web services impede performance due to XML payload crap? Wouldn't it be better that the wire-format can be chosen using policy assertions? Well, Indigo will definitely help you there. But to start off with, i don't think that the performance degradation due to XML payload is really significant for most business applications, unless ofcourse you are building a real-time system that has to handle thousands of messages/sec.

Disclaimer

ramkoth — Fri, 30 Jan 2004 21:10:00 GMT

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion. All code samples are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

SOA and OO

ramkoth — Fri, 30 Jan 2004 20:38:00 GMT

Finally, I am back from a long vacation/business trips. Happy to be blogging again.

Recently, some heated discussions are going on around the subject of SOA and OO. There are different schools of thoughts about this subject. Here is few of those

SOA will make OO obsolete/redundant.
SOA is just a marketing hype where as OO is real thing
SOA and OO can peacefully co-exist

I subscribe to peaceful co-existence of SOA and OO. Both SOA and OO has their sweet spots. Both define a set of abstractions that can be used to solve a particular problem. It is really up to designers/architects to use the right abstractions to solve the problem at hand.

It is a well known fact that abstractions are useful in managing complexity and building an application that can be manageable etc. There can be multiple levels of abstractions. Lower levels of abstractions can be considered as 'details' or 'implementation details' of higher level.

The issue is: if you pick the wrong abstraction level as the top level abstraction, you will get into serious mess later on in the project. For the purpose of this discussion, let us call the top level abstraction as 'First class' abstractions.

Let's get back to OO. OO has its roots in real-time systems where the concepts of objects, encapsulation etc made real sense. These concepts are at the core of those systems and hence they fit the bill of Top level abstraction. Sure enough, you may need domain specific abstractions etc on top of the top level abstractions. Let's leave the domain specific abstractions out of this discussion for now.

But, somehow, we generalized this and thought that OO can be used as 'First class' abstractions for building any software application. In my opinion, this is where we went wrong. OO is definitely not the top level abstraction for building business applications. OO appears in second or lower levels of abstractions.

To illustrate this idea, let's take the example of compiler. The first class abstractions required to build a compiler are: lexical analysis (tokenizer), syntactic analysis (Parser), AST, semantic analysis, back-end concepts(optimizer, code gen etc). Once you understand the top level abstractions and associated formalisms (like regular expressions, LALR Grammars etc), then you can choose the right implementation based on your project constraints. If you take parser as an example, you can either hand-write the parser using OO or you can write the grammar using LALR(x) syntax to generate code using tools such as yacc or bison or whatever.

Same holds good for database implementations. First class abstractions in the database are defined by relational calculus. The abstractions are Relations, relational operators, relational query etc. Each operator (like Join for example) can be implemented using many different mechanisms or algorithms (such as Hash join, nested loop join etc). Finally, a developer may choose to implement an algorithm using OO. So, in this case OO appears at third level of abstraction.

Let's turn our focus on business applications.

First class abstractions required to build business applications

Following are the top level abstractions required to build business app

Business concepts such as customer, employee etc.
Business rules - Structural, Validation, Policy etc.
Business process: both with in and between systems
Human workflow: How do tasks flow between different actors?
Presentation Layer

UI Process - Ability to define user activity flow

There may be few more. But, these are the things that developers should think about when building business applications as these abstractions map directly to business requirements. SOA defines additional abstractions on top of these. It includes

Service boundary
Service contracts (Service definitions)
Service Agents

At this point, some may argue that OO is absolutely required to implement any of these abstractions. I dispute that too. For example, there are many different ways to implement business rules. One such implementation is forward chaining/backward chaining algorithms used in AI. In fact, this is a preferred and elegant way to implement business rules than its OO counterpart (recently some one mentioned about the AOP way of implementing business rules).

Today, Microsoft already has modeling tools that support few such abstractions such as Business process (Biztalk orchestration) and Business rules (Business Rules Engine/Designer). In future, Whitehorse - modeling tool that will be shipped with VS.NET, will surface all the above mentioned first class abstractions to developers and architects alike and generate appropriate code.

Note: Speaking of modeling, I don't think UML is adequate to express first class abstractions. The reason is this. UML defines a set of fixed models (like class diagrams, sequence, activity, state etc) and a limited extension mechanism (such as stereotyping etc). Now to model first class abstractions for compiler such as Lex analyser or parser, one has to use one of the static models to express these concepts. It is like you are starting from implementation (like class diagrams) and going up the abstraction level (like stereotyping) to define the higher level abstractions. I believe, that is not the optimal way to do things. In essence, premise behind UML is that any model can be reduced or derived from the set of core models UML provides. I think this approach will not work and that's precisely the reason, folks are finding UML so difficult to use in practical scenarios.

Vacation

ramkoth — Wed, 31 Dec 2003 18:37:00 GMT

I am going on vacation from tomorrow. I will have intermittent connectivity and i hope to post some of the things that i was thinking for the past few days.