Last post on this blog, starting my own at http://rajith.2rlabs.com/

I had some web space available for over an year and decided to use that space to run my own blog at http://rajith.2rlabs.com/.

I have imported all my previous posts into my new blog. I found Word Press easy to work with yet flexible and powerful enough to customize the way I want. I am using blueprint as my theme and found it to be very elegant. It's built on the Blueprint CSS framework. If anybody is interested you can download it from here.

Many thanks to the Blogger team for improving blogger over the last few months and I thorughly enjoyed my blogging experiance here. I like to be in control of my everyday life, including blogging. Hence my move to my own thing.

Scaling your system - What I learnt from Dan Pritchett's (eBay) talk

I was lucky enough to attend both talks given by Dan Pritchett during the Colorado Software Summit this year. The first one was, "You Scaled your what". If you want to know what scalability is, here is an excellent introduction by Werner Vogels. After listening to what Dan had to say, the following points stood out in my mind

• You need to understand and take complete control of your architecture. Read my post on Architecture is your responsibility for more thoughts on this.


• You need to have scalability in mind right from the beginning. Trying to achieve scalability later can be time consuming and very costly. Quoting from Werner Vogels post

Why is scalability so hard? Because scalability cannot be an after-thought. It requires applications and platforms to be designed with scaling in mind, such that adding resources actually results in improving the performance or that if redundancy is introduced the system performance is not adversely affected. Many algorithms that perform reasonably well under low load and small datasets can explode in cost if either requests rates increase, the dataset grows or the number of nodes in the distributed system increases.


• Transactional scaling is just one dimension. You need to think about Scalability of data, operational,deployment, power ..etc. This is a minimalistic set. Try to figure out what dimensions are important to your organization.


• All scalability dimensions are related and impacts each other. Any dimension ignored can could evolve into a problem for your application


• Prefer vertical over horizontal scaling. Vertical scaling is better for your vendors and is not a viable long term strategy. There is so much you can get by increasing memory, CPU etc..

Transactional Scaling
Usually measured in TPS and is a traditional indicator for application performance.

• Keep asking the question "How long can the business survive?" based on,
  
  
  
  • Time-to-live on current resources.
  
  
  • Time-to-live on maximum plausible configuration.


• These metrics should be taken regularly to anticipate possible production bottle necks and identify issues before they become a crisis.

Data Scaling
How well does your data scale? Think about,

• Functional Decomposition, group data by logical relationships, business importance,transactional volumes etc.


• Think about partitioning data (sharding).


• Is all data equally important? prioritizing your data and allocating resources accordingly will help you scale better.

Operational Scalability
How hard is it to run your software? Operational scalability is a software problem and you need to think about operational concerns right from the beginning. Pay attention to,

• Logging metrics, Monitoring.


• Controlling/updating/tuning live apps without disrupting traffic.

Deployment Scalability
You need to design/architect your systems while keeping the following in mind,

• Ability to do incremental roll outs (and rollback if there are problems) without disrupting live traffic.


• Managing component dependencies during deployment without disrupting live traffic.


• Your architecture shouldn't assume or decouple itself to any hardware,network topology or data center topology. This allows you to take advantage of new hardware, network topologies ..etc without significant changes.

Power Scalability
Power can be a limiting factor in a data center and may put bounds on transactional scaling.

• How efficient is your software?, wasted clock cycles == wasted watts.


• Consider vitalization for best utilization of your hardware resources.
  

Some good tips I managed to note down

• Run old and new schema parallelly and then take out the old schema after a while when you gain enough confidence.


• Prioritize services, willing to take a hit on certain services over others.


• Incremental rollouts is a very good way to roll out new features while managing risk and also prevents taking the system offline.


• Schedule deployment during working hours instead of weekends/nights as this enables your developers, support staff to attend to problems while they are alert and without being distracted by non work issues.If you do incremental rollouts this is possible as you are not disrupting traffic.

The value of principled design - REST is just one example

To me the value of Roy Fielding's dissertation goes beyond REST. Steve Vinoksi summarised it very well in one of his comments while answering a comment I made on his blog.

It’s(Roy's dissertation) not really primarily about REST; rather, it’s about principled design. Much of his dissertation is about architectural elements, principles, constraints, properties, and the relationships between them all. REST is used as a very clear example in chapter 5 of what principled design is all about.

Why can't we use a principled design approach when we do SOA or for that matter any other architecture?

When we add contraints or relax constraints we induce certain properties in our architecture. As an architect you make an educated desision as to what constraints make sense in your environment and what doesn't. When designing systems don't we go through decisions like "should we make these services stateless or statefull ..etc" during our design meetings ?

I think in what ever system you design as an architect you should think through and note down the constraints you want to impose on your system. This will provide a proper foundation to your system and an excellent guideline to your developers which will clearly communicate the desired goals of your system. Then later on when somebody else wants to relax any of these constraints or add more constraints they already have a guideline and can see how the "relaxing of an existing constraint" or the "addition of a new constraint" can impact the overall system.

REST is just a name coined by Roy to identify a set of constraints, and they are not the only constraints, nor the best combination of constraints in every situation. As Steve mentioned Roy spends the first few chapters providing an excellent analysis about "architectural elements, principles, constraints, properties, and the relationships between them all" and of course the value of a principled design approach.
To me the value of Roy's thesis goes beyond REST and I hope most people would realize the same.

Global Warming ...is it really?

Dwight Hornbecker, the only geologist I've even known, had some very interesting facts about global warming. They sound kinda crazy, but I wonder if they are true. Here is what he told.

• One volcanic eruption can contribute to global warming more than what humans can do in an year
• The earth was actually warmer than what it is now.

Dwight went onto explain that there is evidence to support that, a few million years ago the earth was a lot more warmer than what it is today. Then came the ice age. And he maintains that we are still recovering from the ice age and earth is slowly returning back to it what it was. Not sure whom to believe. Is it Al Gore and his crew or Dwight?

All I know is that humans haven't really figured it out yet. We think we do and try to mess around with nature, but I don't think we are even close at guessing/figuring out the real situation.

Architecture is YOUR responsibility

I read this post on Steve Vinoski's blog that quoted Ron Schmelzer of ZapThink, who makes an excellent point. "Architecture is YOUR responsibility". Well guess what, as much as vendors would like to say it is not, the reality is that you need to make the critical decisions about the architecture. Instead of some vendor, you need to be in charge of the direction and overall vision in terms of the architecture. Instead of choosing a vendor/product and building your strategy/architecture around it, you need to think through your strategy/architecture and choose the right vendor/product that can help you achieve your vision. If anybody was lucky enough to attend a talk given by Dan Pritchett (eBay), you would have realized that companies who understood this reality and took responsibility for the architectural decisions eventually made it big.

Dan's comments on architecture was very insightful (I want to write a separate post on what I learned from his talk at the recently concluded Colorado Software Summit). The underlying truth of everything he said, was that they understood and took responsibility for the architectural decisions they made, instead of relying on some vendor to provide direction and overall vision.

There is no vendor out there, that can provide you with some ESB that can magically transform your enterprise into a SOA platform or some messaging middleware that can help you scale your enterprise to whatever limits you want unless you know what you are doing and take ownership of the overall vision. You need to understand the overall architecture, make decisions and take responsibility for them. An ESB or a messaging middleware are merely a bunch of tools that help you get there or in other words they are just a means to an end not the end itself.

There is no framework out there that can force architectural decisions on your solutions that you are not willing to make yourself. During my REST in peace talk, there was a surprising number of folks who asked me about a framework that can help them develop RESFTful services. Guess what, the road to a RESTful approach (or for that matter any architectural style) starts with the architectural decisions you make (the way you think/design your services) and not with some framework where you have to flip a switch or use a bunch of annotations that turns your code into a RESTful service. That is precisely why the contract first approach is recommended over a code first approach when you do web services. You need to think about how you design your service first and then use some framework to generate your WSDL and your code from that, not the other way around.

We all remember how the EJB mania deceived us. Many companies paid millions of dollars to App Server vendors to solve their architectural problems. The whole notion of "you only need to think/write the business logic, and we will take care of the remoting, transactions, persistence, scalability ..etc" was just an illusion. Neither did it preclude people from making extremely stupid architectural decisions nor did it provide anymore scalability than the simple tomcat web server for most of the use cases.

You need to think carefully about the architectural decisions you make and understand the impact it has on the overall goals/vision of your enterprise. You need to be aware of operational, load, managerial and geographical scalability from day one. You cannot offset your lack of architectural vision by using some framework, product or vendor. It will only make your vendor happy, but not your customers.

Competition in open source is healthy

I read Sanjiva's post on the $subject and like to add my own observations. It is true that the Apache Web Server is the statue of liberty that stands tall among all the commercial web servers out there and has no peers in open source. However that is an isolated use case. We need to think more pragmatically. The predictions are such that, most companies, in the future will have some form of involvement with Open Source. Naturally there will be some form of competition, and it is unavoidable. But the more choice (open source or otherwise) a user has the better it gets, especially if there are several open source alternatives instead of one. If there is only one open source alternative and the user ends up with a bad experience with that solution, it can color the perspective of how that company, will look at open source in general.

Competition provides choice and facilitates continuous growth and innovation in open source solutions. It drives a community to be more responsive and responsible towards it's end users. This results in better support in the form of fixing bugs or answering questions on the list. Bcos if you are not growing or innovative or if you are not responsive or responsible towards the end users then they will look elsewhere. One could argue that there are companies that provide support. However one should not forget that these companies are built on top of the community and rely heavily on the community for it's success. And any fixes/patches they make usually go upstream. Companies that don't usually have problems and fade away.

Sometimes you would find that some community members are unhappy with the current direction of a project and they go ahead and form another project. The difference in direction or focus is perhaps an integral part of the evolutionary process. Some of these projects eventually create a company behind it. One could also argue that these companies fragment a community and promote competition. As long as this competition is both ethical and within the norms of standard industry practice, then the end users benefit from it. Why?? Bcos these companies will drive innovation, creativity and quality of the solutions they support, as their business model is based on it.

Therefore some form of competition that is ethical (not mud slinging or cut throat competition) is healthy for making open source a viable option in enterprise software. The process of evolution will weed out inferior solutions and ensure the survival of the fittest. However this should not be based on how much marketing muscle a project/company behind it has, but rather be based on the community aspect and technical merits.

AMQP in 10 mins : Part4 - Standard Exchange Types And Supporting Common Messaging Use Cases

AMQP defines four standard exchange types (routing algorithms) that covers most of the common messaging use cases. All AMQP brokers are required to support each of these exchange types and pre declare an instance of it identified by a standard name. The idea is to provide a simple out-of-the-box solution to most users. Users are free to create more instances of these exchange types with their own names. Also as mentioned in the previous post, users can create different exchange types and instances of them.

It is important to note that with any exchange type, a message can be matched with more than one queue if two or more queues are bound with the same routing criteria.

Direct Exchange
The exchange does a direct match between the routing key provided in the message and the routing criteria used when a queue is bound to this exchange.






(Click on image)

The most common use case is to bind the queue to the exchange using the queue name. However it is important to note that you could use any value for the binding.

A broker is required to provide an instance of this exchange named "amq.direct". The Nameless Exchange is a special instance of the above exchange type where all queues are bound to this exchange automatically using the queue name as the routing criteria. This exchange instance has no public name, hence messages sent without specifying an exchange name are directed to this exchange.

Topic Exchange
The exchange does a wildcard match between the routing key and the routing pattern specified in the binding. The routing key is treated as zero or more more words, delimited by '.' and supports special wildcard characters. "*" matches a single word and '#' matches zero or more words.

(Click on image)

A broker is required to provide an instance of this exchange named "amq.topic".

Fanout Exchange
Queues are bound to this exchange with no arguments. Hence any message sent to this exchange will be forwarded to all queues bound to this exchange.


(Click on image)

• One use case, is to use exchange chaining in a tree like hierarchy that can be used to push messages to a large number of subscribers.
• Another use case is where a direct exchange or a topic exchange can do the initial filtering which then forwards the message to a fannout exchange which will push the messages to all it's queues.
  

A broker is required to provide an instance of this exchange named "amq.fanout".

Headers Exchange
Queues are bound to this exchange with a table of arguments containing headers and values (optional). A special argument named "x-match" determines the matching algorithm, where "all" implies an AND (all pairs must match) and "any" implies OR (at least one pair must match).


(Click on image)

A broker is required to provide an instance of this exchange named "amq.match".

How AMQP Supports Common Messaging Use Cases
The most common messaging use cases are point-to-point (or store and forward) and publisher/subscriber models. These models can be easily built on top of AMQP.

Point-to-Point
routing_key == queue_name

Pub/Sub
routing_key == topic_heirarchy_value

Next Part : Part5 - Lets look at some code - Python examples

Prev Part : Part3 - Flexible Routing Model

AMQP in 10 mins : Part3 - Flexible Routing Model

Background
Most pre-AMQP models had several issues with their routing models.

• Opaque routing models that were not explicitly defined.
  
• Since the semantics are not visible or explicit manipulating the routing model through the protocol was difficult.
  
• Rigid monolithic routing engines that had limited or no extensibility or compose-ability.

The AMQP Routing Model
One of AMQP 's primary goals was to define a flexible, extensible and transparent routing model where the semantics are explicitly defined. This permits the definition of management commands to manipulate the routing model. The AMQP model consists of three components

• Exchange
• Queue
• Binding

AMQP defines a set of rules on how to compose these components in to processing chains. The routing model is analogues to how email works. The following diagram illustrates the routing model from a publisher and consumer's point of view.








(Click on image)

Exchange

This is analogues to a Mail Transfer Agent. Queues (or other exchanges) are bound to an exchange using a 'Binding'. A publisher sends a message to an exchange. The exchange will accept the message and routes it to one or more queues (or another exchange) based on the bindings. An exchange completely decouples a publisher from queues and the consumers that consumes from those queues.

An exchange type defines a routing algorithm to match the bindings with a given message. Hence an exchange type represents a class of routing algorithm. An instance of an exchange type can be thought if as an instance of a routing algorithm. A broker can have multiple instances of an exchange type which are identified by there name. An exchange instance can have the following properties.

• Durable/Temporary
• Auto-Delete
  

Queue
This is analogues to a mail box. A queue will store the messages in memory or disk and deliver them to consumers. A queue binds itself to an exchange using a 'Binding' which describes the criteria for the type of messages it is interested in. Queues can have the following properties,

• Durable/Temporary
• Shared/Private (exclusive)
• Auto-Delete
  

Binding
This is analogues to a Routing Table. A binding defines the relationship between an exchange and a queue. In other words it defines the routing criteria. The most simple case is where the binding equals the queue name. A binding decouples a queue from an exchange. The same queue can be bound to any number of exchanges using the same criteria or different criteria. Different queues can be bound to the same exchange using the same routing criteria as well.

Routing Key
Is a special field (Header) present in the Message Delivery Properties. It can be thought of as a virtual address, analogues to a 'To' field in an email. An exchange may use this field to route a message. The standard exchange types defined in AMQP use the routing key in different ways to route messages.

Standard Exchange Types
AMQP defines several standard exchange types that are described in detail in the next blog entry.

Extending The Routing Model
One can define new exchange types with arbitrary routing criteria (routing algorithms). For example one can define an exchange that routes messages based on content (content based routing). Thus AMQP provides a standard way of extending the routing model without impacting interoperability.

Next Part : Part4 - Standard Exchange Types And Supporting Common Messaging Use Cases

Prev Part : Part2 - Achieving Interoperability And Avoiding Vendor Lock-in

AMQP in 10 mins : Part2 - Achieving Interoperability And Avoiding Vendor Lock -in

Background
One of the key issues with any software is non-interoperability and vendor lock in. Most messaging systems prior to AMQP did not interoperate with each other. For example messages from Tibco's Rendezvous couldn't be routed through IBM's MQSeries. If two messaging systems need to be connected, there are two options.

• Using a message bridge you could convert from one format to the other. However a bridge would be slow as the conversion adds latency. Also you would need to understand the wire format of each of those systems.
  
• Replacing one system with the other, which is costly and risky. Downtime can have a severe impact on the company's revenue model.
  

Therefore once a messaging system is chosen, users are reluctant to change and locked in with the same vendor while spending large sums of money as licensing costs.

What if we have messaging systems(from different vendors) that can understand each other? If so connecting two messaging systems or replacing one system with the other can be done with minimum costs and risk. Since the semantics (behaviour) are the same the chance of something going wrong is relatively low. This is a key goal for the AMQP protocol.

So what does it take to achieve interoperability and avoid vendor lock-in?

• All brokers need to behave the same way
  
• All clients need to behave the same way
• Use a standard for commands on the wire
• Use a language neutral type System
• Use open standards and permit royalty free usage of such a protocol.
  

AMQP satisfies the above requirements by

• Defining a network wire-level protocol
• A defined set of messaging capabilities (The AMQP Model)
• A simple language neutral type system
• Using open, existing, unencumbered, widely implemented standards
• Providing royalty free usage of the protocol
  

Broker semantics are defined explicitly. One can partially imply the semantics from the wire-protocol. However we need to define the semantics explicitly in order to guarantee exact behaviour in each broker/client implementation. So the protocol defines a set of commands to manipulate state in a peer. These commands are grouped by functionality into classes. For example the Queue class has various methods to manipulate state within a broker.
Ex. queueDeclare, queueBind, queuePurge, queueDelete & queueQuerry

More details on the wire protocol will be discussed later on. The next few posts will focus on discussing the semantic model.

Next Part : Part3 - Flexible Routing Model

Prev Part : Part1 - Introduction

AMQP in 10 mins : Part1 - Introduction

Advanced Message Queing Protocol is a an open standard with royalty free use. It has a strong focus on the financial services industry and provides the performance and reliability required by the said industry.

AMQP Working Group
The AMQP working group is responsible for defining and maintaining the sepcification. The website www.amqp.org provides details on licensing, FAQ, JIRA and a list contributors and a download page.

Version Numbering
The AMQP Version Numbering scheme consists of a major and minor revision number. Ex: 0-10.
Major versions > 0 will provide backward compatibility between minor versions. The current version of the protocol is 0-9. The AMQP WG is expected to release the 0-10 version shortly. Currently the specification is in a rapid growth stage.

Interoperability
AMQP provides complete interoperability via

• A network wire-level protocol
• A defined set of messaging capabilities a.k.a AMQP model

One can partially imply the semantics from the wire-protocol. However we need to define the semantics explicitly in order to guarantee exact behaviour in each broker implementation.

Reliability
The 0-10 (in-progress) version has provided functionality to ensure Guaranteed Delivery to satisfy the level of reliability required by the financial services industry. I will cover this topic in detail in a future blog post as part of the AMQP in 10 mins series.

Full Transaction Support
The 0-10 spec also provides protocol level functionality for distributed transactions. This topic will also be covered in detail in a future blog post.

Security
Security is the main focus for 0-11 version of the protocol. Currently there is only rudimentary support provided via TLS. Planned features include but not limited to partial encryption and payload signing.

Known Implementations
AMQP is platform agnostic and language neutral. Currently we have implementations from a wide variety of languages from procedural to object oriented to functional.

The Apache Qpid project has broker implementations in java and c++ and client implementations in java, c++, python, ruby and .NET.

RabbitMQ provides a broker implementation in Erlang and a client implementation in java

Open AMQ provides broker and client implementations in C.

What about JMS?
JMS can be implemented on top of AMQP. The AMQP WG is also working on standardising the AMQP-JMS mapping and is scoped for 0-11 version of the protocol. This will enable two different JMS over AMQP implementations to behave exactly the same way.
The Apache Qpid project provides an implementation of JMS over AMQP.

Next Part : Part2 - Achieving Interoperability And Avoiding Vendor Lock-in

Prev Part : Part0

AMQP in 10 mins : Part0

From time to time people ask me what is AMQP? and how it is different from JMS? or why do we need another standard ..etc On the other hand the AMQP spec groups is finalizing it's work on the 0-10 version.

So I decided to write a series of blog posts titled "AMQP in 10 mins", where each part can be read and understood in 10 mins. I hope to write a part every working day, or more depending on my mood. Comments and criticisms are equally encouraged.

I am going to use the following terminology in my posts. Most of these terms have established definitions within the industry, but nevertheless I am specifying them for completeness.

Broker/Server :  Accepts connections and implements AMQP queuing and routing functionality

Client  :  Initiates a connection

Peer  :  Either party in a connection

Producer  :  A client that publishes messages

Consumer  :  A client that consumes messages

Message Queue  :  A named entity that holds messages in memory or disk

Message/Content  :  Application data

Durable  :  Entity survives a server restart

Transient  :  Entity doesn't survive a restart

Next Part, Part1 - Introduction.

Axis2 Clustering Support

Axis2 1.3 release has experimental clustering support enabling you to deploy your services in a cluster for Scalability, Failover support and HA. In simple terms, we provide replication for Service Context, Service Group Context and ConfigurationContext. This enables you to deploy your services in a cluster and share state. Please give it a spin and provide feedback via the mailing lists.
Please check the Axis2 Clustering Guide for a good introduction.



In Summary, here are a few points worth remembering

• For Stateful Web Services it is recommended to deploy in pairs using the primary/secondary model. i.e Each Node will replicate to one or more backups (secondary nodes) for failover.
  
• There will be only one active node at any given time. This is to avoid conflicts as we don't have a distributed locking mechanism.
  
• To achieve Scalability, you need to deploy several of these pairs. In other words your cluster will consist of multiple pairs with one active node in each - and your pairs are isolated sub groups with no replication between them.
  
• If your cluster consists of more than one pair, you need to use some sort of partitioning to avoid a user being serviced by more than one pair within a given session in order to avoid potential conflicts. You could use session affinity to achieve this.
  
• There is no such restriction for Stateless Web Services.
  
• If your Services read shared state more frequently and update very rarely, you could experiment with more than one active node. However conflicts are still possible.
  

Sanjiva asked me to help over a year ago and it got postponed month after month due to other commitments until I was finally able to produce a prototype. Many thanks to Afkam Azeez, Chamikara, Snajay and Sanjiva for the support they provided. Azeez and Chamikara was primarily responsible for bringing the clustering support to it's current state after I contributed an initial implementation. If not for those two it would have been next to impossible to get it included in the release. Special thanks to Philip Hanik for answering questions on Apache Tribes even while on vacation.

SCA vs Spring (A reply to Dan's post)

In Dans blog entry, he compares SCA vs Spring with an excellent example which highlights the similarities.

I do not view them as competing technologies rather complementing as I see some synergy between these technologies.

Clearly SCA and Spring share several design principles and it is no surprise that the SCA spec group views Spring as an implementation technology for components and composites. In fact the SCA spec group has gone as far as formalizing this approach with SCA Spring Component Implementation Specification

So Ke Jin's comment on InfoQ was right on the money when he said,

"As the matter of fact, the so-called SCA assembly model is merely a DSL (domain specific language) that can easily be realized on top of Spring or any decent POJO IoC containers, with few hundreds lines of code and half day of work"

On his InfoQ comment, Dan asks?

But why wouldn't I just use Spring to begin with?

The simple answer is that SCA could become a standard and the ability to deploy my composites in any SCA runtime. The other SCA runtime could be using Spring or the next great thing under the covers.

Mike Edwards points out on the same InfoQ thread

What the SCA Assembly model then brings to the party is a organized and standard way of describing how the different components in your (distributed) system are linked together to build a particular application.

This will only add value if and when SCA becomes a standard through OASIS and is adopted across different languages by the masses. Spring is great and I really like it. However distributed systems are not built only using java. It would be nice if we have a standard way of expressing how different components are linked together to build your application.

Also unlike the EJB's if SCA composites can be truly portable across different runtimes (Ex Tuscany java runtime to ABC java runtime) with zero code changes it can be a very good selling point. Vendors shouldn't spoil the party with vendor specific addons in their runtime which can lock-in unsuspecting users.

Dan asked

Someone show me where Ke Jin is wrong and where SCA expands on Spring capabilties.

Technically the capabilities are more or less the same, albeit spring being a more simple model. The standardization and portability of SCA (if achieved) is where it can exapnd or add value on top of Spring. I am not advocating to replace Spring with SCA. You can continue to use Spring to realize SCA. They are certainly complementary. This white paper explains how SCA can be used with OSGi and Spring.

P.S I conveniently ignored the complexity issue. IMHO it is a red herring.
Distributed systems are complex in nature. Thinking we can provide simple solutions is the biggest misconception.
EJB, WS-*, REST, SCA they all prove this one after the other. That's a good topic for my next blog entry :)

Being a single parent (for 2 weeks)

I had to go to Sri Lanka for my brothers wedding for 2 weeks. My wife was unable to make it due to exams as she is taking summer school. So I decided to go alone with my 3 yr old daughter. I survived the long journey to Sri Lanka thanks to my daughter putting up her best behaviour. The next day we had the wedding and again the little angle held her composure while wearing her dress in extremely hot weather during the photo shoot and church ceremony. We spent the next couple of days going shopping, a trip to the zoo and the beach. I had an extremely good time with my daughter and stayed away from my laptop (except during the Axis2 clustering hackathon at the WSO2 office in Colombo) for two weeks. I rarely checked email :) , instead I played with my kid and made the most of the time. She loved to go in three wheelers (tuk tuk) and insisted they were much more exciting than the kiddies roller coaster at Wonderland :). The return journey was a bit tough due to flight cancellations. We got stranded in Paris for a day, but used that time to relax and rest a bit before making it home.
I am well versed with diaper changing, feeding and putting her to sleep, as I take care of her when ever I work from home. But washing her at least 3 times a day and feeding 3 meals and putting her to sleep was extremely tiring. I wonder how my wife does it everyday while being a full time student. My daughter thinks Sri Lanka is much more exciting and charming with ants, flies and butterflies to chase around, cows and stray dogs all over the place, bumpy rides in three wheelers and grand parents who are ready to care for all her whim's and fancies. Sri Lanka is indeed a charming place.

He was a visionary.....

I think Sanjiva already blogged on this, but I feel obliged to do so as well.
If not for his efforts and most importantly his vision, Sri Lanka would not have progressed this far in IT. Especially his efforts in the university circuit opened the doors for many kids who otherwise would have missed the opportunity to study IT. I have met him once or twice at (ICT) Institute for Computing Technology at the Colombo university while I was a student when we were organizing an IT exhibition. If I am not mistaken, the ICT itself was his brain child. He was a pioneer in getting the ".lk" domain name.
Sometimes his work was disrupted by political pressure from various sources which didn't like the contributions the he was making. However he continued to push towards his vision until his last breath.
Well done sir!!!! You made us all proud.

Mahela, I thought u will pull us through !!!

I know enough has been written about the world cup dissapointment, but sadly I haven't got over it yet. It was a very bad day for us. It started with rain and a shortened game which suited the aussi style of power hitting. The ICC which is quickly turning out to be a joke, and is run by a bunch of idiots who are pass their sell by date, should have postphoned the game. It's a shame that the 100 overs was not played in a world cup final !!!!
We were at a huge disadvantage with the light deteriorating by the minute and the batsmen under pressure to stay on top of the duckworth lewis score. But yet we displayed courage and fought till the end. However credit should be given where it is due and I have to say Gillchrist played a one of a kind ininings.
I knew mahela from school days and people thought he would be playing for Sri Lanka when they saw him batting at under 13 level. I was in a match with Nalanda college at under 15 level. And Mahela single handedly took that game away from us. He was always a big game player and thought he would pull us through, just like in the semi finals. But a bad umpiring decesion ended all that.
I am looking forward to 2011!!!!

My take on JSR 311, Java API for RESTful Web Services

I think doing this inside the JAX-WS space seems to give the wrong impression. I heard that they were proposing to tunnel REST services through JAX-WS endpoints. But Dan sent me the following link to a blog post by Marc Hadley which gave me some hope.

Sun always messed it up with Web Services. JAX-RPC and JAX-WS were horribly complicated with no apparent benefit other than to say the implementer is J2EE compliant. What a price to pay to have that check box in your marketing literature. They may very well make the REST API equally useless by tying it to those JAX-WS API's.

Anyways we already have an API for REST in the form of servlets and JSP, but I agree that they weren't good enough. IMHO they should have improved these APIs and add REST support over there, not inside JAX-WS which will fuel the myth, that REST is an alternative to SOAP, instead of REST is an alternative to SOA.

All REST API's I have seen so far, are high level annotation driven API's on top of a HTTP binding (servlets). For example what Dan has in XFire. I strongly believe that REST support should go into an HTTP API (servlets) instead of a WS API.

Benchmark Wars

The recent posts by Paul, Dims and Dan have provided benchmarks pitting Axis2 vs XFire. I think that is a very good step and provides end users some good information. Also I would like if everybody provided the source code for these tests so non believers and end users can run it for themselves.

However, racist ranting with no performance numbers to back it up is not acceptable at all. If a person cannot explain a technical argument without subjecting him self to such a low level, then I don't think the rest of world should care.

Dan I welcome your effort to work out the performance numbers. That is the right approach. Healthy competition will only promote WS-* and help dispell the myth that SOAP is slow. If either Axis2 or XFire is slow in this round then let the respective teams make sure that they make an effort to beat the other in the next round. Now that is whats going to make each other better, not unwarranted racist comments that shows your sorry upbringing and publicly disgracing your parents.

However Dan I believe that most enteprise systems do care about RM and Security (Addressing too). So there will be SOAPHeaders. With more SOAP stacks supporting these specs there will be an increase in the adoption of these standards in the enterprise world and so IMHO the SOAPHeaders should be part of the performance tests. However I also recognize the need for being efficient in the POX case too. As Dan said the POX use case maybe a popular one with SME's. If Axis2 is lagging behind in that area then we as a team can work on the performance.

As for Hani, he is still motivated to spew out his garbage for the very same reason why Howard Stern is still in business. There is and will always be an audience for these type of people. Some would call it "Freedom of expression", others like me would see it as an abuse of the that very sacred principle.

I am gratefull to see the new year !!! (Please wear seat belts)

I am extreamly gratefull and feel blessed to see the new year considering the motor vehicle accident, I was involved with on the 30th Dec 06. It a was multi-vehicle accident (1 van and 3 cars) that was nothing short of a miracle considering every person involved made it through with only whiplash and one person with mild shock.
It was a routine grocery trip to costco and we were heading back home. I stopped at the lights with just one vehicle in front of us. I heard a bang behind us and before I could even think about it there was a massive bang and our car was violently thrust forward and rear ended the car in front of us. As it turned out a van had rear ended the car behind us and that in turn rear ended our car.
When I looked around I saw the car that hit us has rolled into the ditch beside the road. The car was squashed so bad I was expecting the worse. The van was thrown on to the lane right of us and has stopped parallel to us with the engine collapsed and fuel leaking towards our car.
I quickly got out and yelled to my wife to take the baby out of the car seat and we all moved on to the ditch as there was a risk of fire. The ememergency vehicles arrived in 5 mins and the firefightes took control of the situation.
All passengers were saved bcos of seat belts and considering the damaged to the rear of my vehicle I am glad that my daughter and wife were ok. Three vehicles including ours were totaled. Property can always be replaced but not human lives. So please wear seat belts and be alert when you are on the road.

Last year was the toughest of my life so far. It was also the year which I learned so much about life and realized how precious your family is. But I am proud of my fighting sprit and the effort to keep the ship steady through all the troubled times. Humans have a remarkable ability to adapt and fightback when the going gets tough.

Wish you all a Happy and a Blessed New Year.