Agile Learning

Wednesday, July 16, 2014

Importance of DOCTYPE declaration in (X)HTML

From my experience, I can remember many cases where I knew for sure that I have written a HTML document correctly with Javascript and CSS, still it is not rendered properly in the browser. Few weeks back, I encountered the same problem and like every time it is the DOCTYPE declaration which is the reason for this mess. So. I thought of sharing my knowledge regarding DOCTYPE through this post. DOCTYPE is a declaration that we usually find in the very beginning of an HTML document (it applies to XHTML too). The first thing to remember here is that DOCTYPE is not a HTML tag. It provides some information to the browser regarding the version of HTML that has been used in the document. In other words, DOCTYPE is a meta-information for the HTML document.

What happens if we don’t specify the DOCTYPE declaration?

A DOCTYPE declaration tells the browsers to render a HTML document in standards and compliant mode. It ensures that the rendering of (X)HTML, CSS, and DOM is done in a standard way. Browsers make many assumptions and guesswork while rending a (X)HTML. If we do not specify any DOCTYPE declaration, browsers will use the “Quirks” mode and render the (X)HTML according to its own proprietary logic. Even if a (X)HTML has a valid DOCTYPE declaration but has validation errors against that DOCTYPE, the browsers may not complain and continue render it. For example, the (X)HTML below fails validation but it is rendered correctly in browsers.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title> Test </title>

</head>

<body>

<p>HTML content..</p></br>

</body>

</html>

Only if we have a valid DOCTYPE declaration and no validation errors with respect to the declared DOCTYPE, we can rest assure that the (X)HTML document will be properly rendered across browsers without writing any browser-specific tag. A list of valid doctypes can be found here.

DOCTYPE in HTML 5

The doctype declaration is significantly simplified in HTML 5. The valid declaration of HTML 5 doctype is:-

<!DOCTYPE html>

A simple (X)HTML document in html 5 will be as follows:-

<!DOCTYPE html>
<html>
<head>
<title>Document Title</title>
</head>

<body>
The content of the Document
</body>

</html>

Adding a DOCTYPE declaration to (X)HTMl documents is always the best practice. Most of tools we use to create (X)HTML documents do add a DOCTYPE declaration by default and also checks for the validity of the document against the declared DOCTYPE. The documents should only be published when there is no validation errors against a declared DOCTYPE.

Friday, July 11, 2014

From distributed caching to in-memory data grid

Distributed caching is around since the late 1990s and has been continually evolving since then. Many new features have been added to distributed caching frameworks but simply accessing data in key/value pairs from memory was not fulfilling the expectations of the customer. In fact, storing data in key/value pair does not add much value but processing of the data do add value. So the customers were expecting to move the computation of data closer to data itself. Data grids addressed this requirement by adding features to be able to do computations on the cached data. For example data grids provide feature like querying data in the memory using standard SQL syntax, data-indexing, providing map-reduce based processing, support for various complex data models (document, relational) etc.

Distributed Caching

Since late 1990s, distributed caching technologies evolved continuously by add more and more features. While the first generation distributed caching provided simple cache clusters with a sophisticated hashing algorithm to keep track of the data. In the next generation of distributed caches, we find advanced features like high availability using partitioned or replicated architecture, ACID transactions, distributed locking, asynchronous events and active backups.

Data Grid

Although, distributed caching has evolved and matured over the years, what was missing was to bring the computation of cache data to in-memory. Data has become more and more complex over the years. New requirements like providing dynamic scalability, database-like persistence, map-reduce based processing, SQL like querying features, support for different types of data model like document, json, relational etc were coming up. Data grids addressed these requirements and also provided additional features like capability for monitoring and management, policy and security enforcement, support quality of service and easy integration with existing enterprise applications. Growing adaption of data grid is bringing in more sophisticated requirements and higher customer expectations.

The important thing to note here is that Data Grid is not backed by any specification or industry standards. So the growth of Data grid is completely based on customer requirements. Few popular Data Grid tools in terms of customer adoption are:-

VMWare Gemfire
Oracle Coherance
Gigaspaces-xap

Along with the previous 4 posts, I tried to cover as much as possible about caching. There are many specific areas which I'll address going forward like tools comparison. Please comment if you find anything missing or need more information and explanation.

Wednesday, June 25, 2014

Cache access patterns

Cache access patterns refer to how an application is going access the cache. There are primarily few strategies that all major cache providers like (EHCache, Infispan, Coherence etc) supports.

Cache aside

In this access pattern, the application will first search for the requested data in cache and if the data does not exist in cache, then it is the responsibility of the application to fetch the data from datasource and update the data into cache. Thus in cache aside access pattern, the application code directly uses the cache by invoking its API to add any missing data in the cache.

Read Through

In this access pattern, the application requests for a data from cache and if the data exist in cache, it is returned to the application. In case, if the data does not exist in the cache (cache miss), it is the responsibility of the cache provider to check for the existence of the data in the datasource. If data exist in datasource, the cache provider will fetch the data, update the cache and finally return the data to the application.

Write Through

In this access pattern, whenever the application updates any data in the cache, the operation will not be complete until the cache provider writes the data directly into the underlying datasource. In this case the cache is always in sync with the underlying datasource. This pattern is easy to implement but the disadvantage is that the write operation is slower due to latency because the datasource need to be accessed for every writes.

Write Behind

This access pattern is similar to Write-Through, the only difference being that the data is updated in the datasource asynchronously. Writes to the datasource can be configured to take place at a specific time, like after 1 hour or midnight or may be at weekends to avoid peak hours. While this pattern is hard to implement, the write operation is very fast and does not require dealing with latency. Another big advantage of this pattern is that many transactions can be grouped in one single transactions which will further reduce latency. The biggest challenge of this pattern is that the write to the datasource happens after the write to the cache and the data is written to the datasource outside the transaction. So there is always a risk of failure and transaction rollback has to be handled very efficiently. Compensating actions like retry counts are used by the cache providers to deal with transaction rollback. Another big challenge for write-behind pattern is that there is a time gap between the cache transaction and the actual datasource transaction which may lead to out-of-order updates. Proper ordering of update actions is required to mitigate this challenge.

Few other cache access patterns exists which are very specific to the cache providers which are basically a hybrid approaches of the above four patterns.

In the next post I'll try to share my knowledge on cache providers and try to do a comparison of the products.

Monday, June 23, 2014

Caching Topologies

There are some common topologies for caching used commonly by cache providers. They are:-

Standalone or in-process Cache

While using an in-process/standalone cache, the cache elements are local to a single instance of an application. In case of applications having multiple instances, there will be as many caches as application instances. Each individual cache may hold data in different states which may lead to inconsistency. However, with a cache eviction policy in place, the data in the cache will be eventually consistent. But this could pose a problem with applications with high volume of cache request and transaction. Standalone cache is a good choice for small applications or where the data in the cache is pre-fetched and seldom changes. So, standalone caches are good candidates for read-only cache with pre-fetched data. Google Guava library is a good example of standalone cache.

Distributed Caching or Partitioned Cache

In distributed or partitioned mode, cache is deployed on a cluster of multiple nodes and offers a single logical view of the cache. Since there is always a single state of the cache cluster, it is never inconsistent. Distributed cache makes use of hash algorithms to determine where in a cluster entries should be stored. Hashing algorithm is configured with the number of copies each cache entry should be maintained cluster-wide. Number of copies represents the tradeoff between performance and consistency of data. The more copies you maintain, the lower will be the performance, but there will be a lower risk of losing data due to server outages. Hash algorithm helps in locating entries without resorting to multicasting requests or maintaining expensive metadata. So, during a put operation, the number of remote calls will be the same as the number of copies maintained. But doing a get operation in the cluster would result in at most 1 remote call. Actually in get operation also the number of remote calls made is equal to the number of copies maintained, but they are made in parallel and whichever call returns first will be accepted. A good example of distributed cache is Memcache.

Replicated Cache

In replicated mode also cache is deployed on a cluster of multiple nodes but any entries added to any of these cache instances will be replicated to all other cache instances in the cluster, and can be retrieved locally from any instance. Replication can be synchronous or asynchronous. Synchronous replication blocks the caller when there is a write operation like put, until the modifications have been replicated successfully to all nodes in a cluster. Asynchronous replication performs replication in the background (the write operation returns immediately). Asynchronous replication is faster since the caller is not blocked. However, when a synchronous replication returns successfully, the caller knows for sure that all modifications have been applied to all cache instances, whereas this is not the case with asynchronous replication. Products like Terracota and Infispan can be configured to run in a replicated mode.

Here is a comparison of the above topologies:-

	Replicated Cache	Partitioned Cache	Standalone
Fault Tolerance	Extremely High	Extremely High	No fault tolerance
Read Performance	Extremely fast	Extremely fast	Instant
Write Performance	Fast	Extremely fast	Instant
Typical Uses	Metadata	Read-write caches	Local data

There are some other types of topologies which are basically a hybrid of above approaches. Those approaches are very specific to cache providers. Next I'll try to share my thoughts on different cache access patterns.

Tuesday, June 17, 2014

How does a cache works

In this post, I’ll try to share my understanding on how cache work and how a caching framework can be integrated in an application. From an implementation perspective cache is nothing but an interface with methods to get/put/remove a cache object. A sample cache interface is as follows:-

public interface Cache<K, V> {

/**

* Returns a cached value associated with a key.

* @param key the key

* @return the cached value

public V get(final K key);

/**

* Puts a value associated with a key in cache.

* @param key the key

* @param value the value to cache

* @return the cached value

public V put(final K key, final V value);

/**

* Removes a cached object.

* @param key the key

public void remove(K key);

}

A concrete implementation adds many more methods as well. A cache always store data as key-value pair in memory. Applications need to send the key to retrieve a value from cache. Caching follows a very simple workflow. It lookups up for an value using the key and if value is available, it is returned else it will lookup for the value in the primary storage (database, files etc) to get the value and then update the cache memory before returning the value to the user.

Typically, we use caching frameworks like Ehcache, which integrates with the application to get the data from cache. Applications should not put data directly into cache and should let the framework handle it. An typical example of how an application interacts with a cache framework is as follows:-

Cache Integration architectures

A caching framework could be standalone or distributed (I’ll cover it in a separate post). Distributed caching is used in enterprise applications. Distributed caching enables cached data to be shared across multiple nodes thus providing better performance, high availability and scalability. A cache framework can be integrated with an enterprise application in a number of ways. I'll try to cover a few of them here.

Cache Integration using an independent Cache Server

This integration styles uses independent cache server spanning across nodes. The application server connects to the cache server and the and the application servers connect to the cache server. The advantage of this architecture is that it can be scaled vertically as well as horizontally without any dependency of the application server. Memcache is used in enterprise application using this architecture. The diagram below is an example of such architecture.

Cache Integration using an Application Server

In this architecture, applications use the cache associated with the application server. In this case the cache server is "tied" to the application server. Websphere Dynacache is an example of utilizing the following architecture. Using this type of architecture requires very little configuration as the application takes the responsibility of it.

Cache Integration using an Independent Server and a local cache

In this architecture type, a local cache reside in the application server while the main cache server stands independent of the application server. Here actually, the cached data is moved closer to the application requiring cache which will further improve the performance. ObjectStore is an example which utilizes this kind of architecture.

Among all the above architecture, the first is simple and my preferred approach. The next one is dependent on the application server. Not all application servers available in the market comes with an caching solution. So if my application uses the 2nd approach and if I consider changing my application server, my choices will be limited. Although, the last approach is a very elegant solution for caching, there are very few such solutions available in the market and they are very expensive too.

In the next post, I'll try to share my knowledge on distributed caching topologies.

Wednesday, June 4, 2014

Cache Replacement Algorithms

Since last few days, I was studying cache replacement algorithms. After going through a lot of documents and papers, I thought of summarizing what I have read and understand about cache replacement algorithms in last few days. Although there are lot more algorithms, I am summarizing onlya few of the popular algorithms.

LRU (Least Recently Used)

In case of a cache hit, the cache returns a reference to the object and object gets moved to the first position in the cache (the most recently used object). On the other hand, if it is a cache miss, then the object needs to read from the primary storage (or some other source) and then puts the object in to the first position of the cache. If the cache is full, the last entry (the least recently used one) in the cache will be removed before a new object can be added.

LRU2 (Least Recently Used 2)

This algorithm is a development on the LRU algorithm. In this case, the algorithm replaces the object whose penultimate (second-to-last) access is least recent among all penultimate accesses. The objective of this algorithm is not to find and evict an object since it is accessed once but to find out how frequent the object is accessed over time (popularity) and to evict the less popular one.

MRU (Most Recently Used)

MRU algorithm is most useful in situations where the older an item is more likely to be accessed. When we need to get rid of a object in cache, we trash the one we just recently accessed. This algorithm has very specific use, for example, a photo gallery. Users who have already viewed a photo has less chance of viewing it again.

2Q is similar to LRU2 but improves upon it making it better and adaptive cache replacement algorithm. When an object in cache is first hit, 2Q place it in a special buffer, which is managed as a FIFO queue. If the object is referenced again while in the special buffer, the object is moved into another list which is managed as LRU. If a object is not referenced while on the special buffer, removed from the buffer.

LFU (Least Frequently Used)

In this algorithm, each object in cache has a corresponding counter associated with it. The counter counts how many times an object is accessed. As a replacement policy, the objects that are access least number of times are first to be replaced. So if an object is accessed a lot number of times, it is going to stay in cache.

FIFO

First-In First-Out (FIFO) is considered as the oldest cache replacement algorithm. It simply maintains a list of all objects in the cache such that head of the list is the oldest arrival and tail of the list is the most recent arrival. FIFO has a poor performance compared to LRU and is seldom used today in its original form.

Second Chance

Second Chance (SC) is an enhancement to FIFO. In SC, a reference bit is maintained for each object in cache while maintaining the objects as a FIFO queue. When a new object is fetched from a primary storage, it is appended at the tail of the queue. The reference bit for the new object added is set to zero. When an object in cache is accessed then its reference bit is set to 1. The replacement policy in SC checks the object at the head of the FIFO queue and replaces it if its reference bit is zero else the object at the head is moved to the tail and its reference bit is reset to zero. The policy keeps checking the objects at the head until an object is found with a zero reference bit. Once it finds an object with zero reference bit, it will be replaced. SC has a overhead of moving objects from head to the tail of queue which makes it a bit inconsistent.

CLOCK

CLOCK is functionally very similar to SC. The difference being in CLOCK uses a circular queue instead of FIFO and the replacement algorithm cycles through the queue like a arm of CLOCK. By default, the clock hand points to a object and whenever a replacement is needed the policy starts checking the object, pointed by the hand, in the same as SC. Clock eliminates the need to move a object from head to tail thus providing a better performance.

ARC (Adaptive Replacement Cache)

ARC is considered to be one of the best cache replacement algorithms. ARC uses 2 lists, L1 ans L2. The first list contains objects that have been seen only once recently, while the latter contains objects that have been seen at least twice recently. So the List L1 captures recency while the list L2 captures the frequency. The replacement policy is based on constant reshuffling of the L1 and L2 lists. ARC also adapts based on workloads. It is fast and self-tuning.

CAR (Clock with Adaptive Replacement)

This algorithm CAR is inspired by the Adaptive Replacement Cache (ARC) algorithm, and inherits all advantages of ARC including its high performance. CAR maintains four doubly linked lists, say, T1, T2, B1 and B2. The lists T1 and T2 contain the objects in cache, while the lists B1 and B2 maintain history information about the recently evicted objects. The CLOCKS T1 and T2 contain those objects that are in the cache and the lists B1 and B2 contain history objects that were recently evicted from the cache. The CLOCK T1 captures “recency” while the CLOCK T2 captures “frequency.” The lists B1 and B2 are simple LRU lists. Objects evicted from T1 are placed on B1 , and those evicted from T2 are placed on B2.

Sunday, June 1, 2014

Caching basics

Caching

Caching is the technique of storing data temporarily (frequently used data) which are expensive to fetch every time. Fetching the data from caching is much faster compared to fetching it from the source.

Cache Hit:

Simply put, if the cache contains the data being looked up, it is known as cache hit.
The percentage of requests that result in cache hits is known as the hit rate or hit ratio of the cache.

Cache Miss:

When the data being looked up is not available in the cache, then it is known as cache miss. In case of a cache miss, the data is fetched again from the primary storage and put into cache.

In case of cache miss there can be two scenarios:

Free Space available

In this case the object will be fetched from primary storage and added to the cache.

No Free Space available

In this case the object will be retrieved from the primary storage and will replace an existing entry in the cache. Now, the entry to be replaced is governed by a cache replacement algorithm (LRU, MRU, LRU2 etc, details of which I’ll share in a later post).

Storage Cost

When a cache miss occurs, data will be fetch it from the primary storage, load it and place it in the cache. Also data can be prefetched at application startup. Here what is important is how much space to be used by cache (space versus time tradeoff)

Miss Penalty

And when we need to load the data we need to know how much does it take to load the data. This is known as Retrieval cost

Replacement Policy:

When cache miss happens, the cache ejects entries in order to make room for the newly fetched data from primary storage. The heuristic used to select the entry to eject is known as the replacement policy.

Average memory-access time = Hit time + Miss rate x Miss penalty

Hit time – time to access the cache

Hit ratio -- percentage of time the data is found in the cache

Miss ratio -- (1 - hit ratio)

Miss penalty – Time to access the primary storage

Sunday, April 13, 2014

My Learning activities going forward

After researching a lot in last few days, I decided to learn the following the technologies:-

Cloud Basics
Cloud Computing Technologies like Hadoop, Map Reduce, HBase
Mobile Application Development using Android, iOS and HTML 5
Using Social APIs
Functional Languages like Groovy and Scala using Grails and Play Framework
(No)SQL DB like MongoDB and Cassandra
Business Analytics using R, SPSS etc.

The basis of my decision off-course come from various job posting sites, communities and Google Trends. I would like my friends to provide me more inputs into the choice of technologies. Learning all these technologies would be a mammoth task and would take a long time. The best way would be to approach my friends, encourage them to take a technology each and start a collaborative approach to learning. So my next steps will be to approach my friends and encourage them to take up one technology area. Before that, I need to finalize which technology area I would consider for myself to start with. Then comes the question of selecting the right book. I plan to finalize things by the end of next week and start learning the week after. Let's see how it works out.

Sunday, April 6, 2014

After 3 long years..Blog 2.0

After 3 long years of silence, I finally thought of coming back. Certainly it is going to be my Blog 2.0. During the last few years, I've always referred to blogs whenever I required any specific information about any technology area. Thus I have always left that blogs do provide very targeted and specific information. Going forward I'll try to add new posts which are going to be very targeted only. I have plans to learn a lot of things in the coming days and keep sharing my knowledge. I also intend to share my learning plan too. Hope it will be fun.

Monday, January 3, 2011

Cloud computing - A new trend in IT

Cloud computing has become the buzzword of IT industry. Recently I found a very interesting line at Sun's blog site. It says:-

"It's easy to get lost in all the talk about cloud computing. Everybody seems to have a cloud, connects to the cloud, is cloud-enabled, or at the least, is cloud-ready."

I never knew what cloud computing is all about. Reading the line above, I felt that I should at least try to get an overview of cloud computing. I searched the internet for articles on cloud computing to get an overview. By now, I do have an idea of what cloud computing is and want to document my thoughts.

In simple words, to me, cloud computing is all about moving applications outside the firewall of the enterprises to be hosted by third party. Users can access the applications via their browser or any other interface. The applications will be available to the users as a service over internet. Thus we can have any IT resource deployed as a service in a cloud computing system, be it applications, storage, networking, office tools or any other utility softwares. In a cloud computing system, the softwares like mail client, word processors, spreadsheets etc will all be loaded from the remote system. Users will be able to access and log into their system anytime, anywhere as they will be accessed via internet.

Now what is the important are the key benefits of cloud are computing. The most important of the key benefits is cost savings. It will bring down the hardware and software licensing costs largely thus saving capital expenditure for the enterprise. It also saves costs on infrastructure support staffs and space as the enterprises are not owning the infrastructure but renting them. Additionally it gives the enterprise users location and device independence. Users can always access their applications and on any device apart from laptops or desktops, like smartphones. On the flip side there are huge concerns regarding data security.

With whatever knowledge I’ve gained by reading through cloud computing articles, I do have some observation from my perspective. They are:-

· I believe cloud computing is the latest trend in IT industry and not a hype.

· It will take another 7-8 years for cloud computing to take-off.

· Successful implementation of cloud computing depends heavily on high-speed internet/telecom networks.

· Cloud computing can add great value to SMBs and startups (cost savings maximum).

· Cloud computing may turnout to be more expensive than what it promises to be.

Google and IBM seem to be leading the race in cloud computing space. Few sites that I found helpful in understanding cloud computing are:-

http://communication.howstuffworks.com/cloud-computing.htm

http://www.infoworld.com/d/cloud-computing/what-cloud-computing-really-means-031?page=0,0

http://blogs.sun.com/startups/entry/what_is_cloud_computing and download the guide.

Wednesday, December 29, 2010

Mashups - Most promising aspect of Web 2.0

Web 2.0 has opened the door for a new breed of web applications. Mashups, like Wikis, blogs and social networks are a part of Web 2.0 but mashups continues to grow faster. A mashup is an application that combines information from different sources and integrate them to deliver content for a specific purpose or a new functionality. The purpose of mashups are to create a new class of service or functionality that is convenient, more user specific and generate new business opportunities. For instance, a mashup application can combine service from a mapping application and apparel store to locate all the branches of the store in a city. There is a huge possibility for mashups in today’s world. Forrester Research predicts that mashups will be a $682 million industry in the next 5 years. Mashup promises cost effective solution that add a great value both at user as well as at enterprise level. Few more examples of mashup are Amazon Light and ActorTracker. Amazon Light contains listings of products sold by Amazon.com and combines them with data from Google, Yahoo, Del.icio.us, Blogger and others. ActorTracker combines Amazon, eBay, and other movie data. BizRate, PriceGrabber, MySimon, and Google's Froogle used combinations of business-to-business (b2b) technologies.

Architecturally, a mashup is comprised of three layers:-

Datasources/Content Providers layer – A mashup application can get data from diversified data sources. It could be a XML feed (RSS/Atom) or by calling external APIs exposed by third parties like Google Maps API, APIs from Microsoft (Virtual Earth), Yahoo (Yahoo Maps), AOL (MapQuest) or Flickr APIs. A detailed list is available at http://www.mashupfeed.com.

Transformation Layer – This layer basically transforms the data by filtering, sorting or by performing any custom operation on the data to create something useful.

Front-End/UI layer – Mashup is all about creating rich user experience which can be created using tools like Google Mashup Editors or IBM’s Lotus Mashups.

From implementation perspective mashups can be enterprise or non-enterprise. An enterprise mashup is created in a server while a non-enterprise mashup is created within the browser. Most of the mashups available today are browser based. They query the data sources/content providers, transforms the data and render it in a browser. Browser based mashups extensively use AJAX which allows pages and data used for the mashup to change without the page being refreshed, thus, making the tool very efficient for the user. Tools like Google Mashup Editor can be used for creating browser based mashups which can be created by end user with limited programming knowledge. Thus they are extremely useful for creating situational application quickly by the end user without incurring an overhead on the existing IT infrastructure. But browser based mashups have limitations. Browser based mashups cannot provide much option to the user and has large dependency on sources. Again, browser based mashups are created using javascript which has limited ability to perform complex operations\

On the other side enterprise mashups are more robust in nature. They can address the features of security and governance. Mashup server provides visual drag-and-drop interface for mashing services together. Common functions like merging, filtering and even custom functions such geocodeing are built into the server toolkit. The mashup server can safely perform and store authentication and authorization information for external services. It can also be connected to the enterprise's own authentication and monitoring toolsets.

A tutorial for creating mashups using GME is http://code.google.com/support/bin/answer.py?answer=71042&topic=12044

Few available Mashup editors are:-

· IBM Mashup Center

· Yahoo Pipes

· Google Mashup Editor

· JackBe

· Lotus Mashups

· Microsoft Popfly

· Mozilla Ubiquity

To me mashups are all about innovation. Services are available, so it is upto an user or an enterprise to mix and match the data or functionality from different sources and create applications that adds value. IBM is leading the mashup race with wide range of tools and editor. More information about mashups are available at http://w3-03.ibm.com/software/developers/page/1117

Tuesday, December 28, 2010

Mobile 2.0 - The future of mobile internet

Nowadays, there is a lot of buzz around the word Mobile 2.0. Some prefer to use the term Mobile Web 2.0. But the question is what is Mobile 2.0? To me, Mobile 2.0 is the next generation of mobile internet services that will completely transform the web and mobility space that we're currently witnessing. I always believed that mobile devices can change our life dramatically. The reason being, nowadays, a standard mobile come with the features like camera, FM, Maps etc. So there is always a possibility that we can take a photo or video and share it instantly with others. We can download a song from my favourite radio station and share it with others. With rapid penetration of 3G and other Wi-Fi technologies we are fast moving towards using internet technology on our mobile. Mobile 2.0 is designed for two way communication. Instead of distributing ringtones, wallpapers, music, information and videos to the consumer by telecom operators, Mobile 2.0 will enable users to have instant access to wide range of data services that includes blogging, wikis, Flickr, Youtube or social networking. Thus Mobile 2.0 is the convergence of mobile device with next generation of data service. Going forward Mobile 2.0 is going to be dominant access method with mobile devices, having more features and networks more powerful and robust.

Key drivers to Mobile 2.0 are:-

· Low cost of mobile devices compared to PC or laptop

· Mobile devices are portable and always with us.

· Rapid penetration of Wireless Technologies like 3G

· New Business opportunities

The big question with mobile 2.0 is whether the web 2.0 applications will go mobile or there will be mobile specific applications. Before finding the answer, we need to understand that a mobile device is not a PC. It has a small screen and users have a different way of interaction with a Mobile device. Most of the standard mobile devices available in the market have a web browser with Java and Flash support. So accessing a Web 2.0 content in mobile is easy, but the scope of Mobile 2.0 goes much further. Mobile 2.0 is about delivering mobile content, which is personalized as well as localized. An example would be like a Mobile 2.0 enabled social networking site will be able deliver the content as well as able to locate me where I am and will ensure that I can be reached instantly via text message.

A very interesting development in the mobile device space is that many Internet players are entering the market. Apart from the handset manufacturers like Nokia, Motorola, Sony Ericsson or HTC, companies like Google, Apple (iPhone), Microsoft (Zune) and HP are also entering the market. They are also coming up with their own set of APIs which can be utilized for creating Mashups like iPhone SDK, Mobile Ajax, Nokia Web Run-Time, Google Gears, Android, Yahoo! Blueprint. Today there are many Mobile 2.0 applications in the market mostly built on J2ME, Flash or Ajax based frameworks. J2ME based Mobile Services Architecture (MSA, JSR 248) is now supported by most of the standard mobile devices. Rich Internet/Interactive Applications (RIA) is being used extensively in mobile web browsers. Many frameworks are available for creating RIAs like Adobe’s Flash / Flex, Microsoft’s Silverlight, Sun’s Java FX, AJAX or Laszlo’s OpenLaszlo.

Few key challenges ahead of Mobile 2.0

· There is a plethora of phones, multimedia formats and network configurations that needs to be standardized.

· Finding the right advertising model for facilitating ad-sponsored content.

· Quality of service by telecom operators for multimedia content which are usually bandwidth intensive.

· High cost of advanced multimedia handsets

A simple, futuristic example of Mobile 2.0 could be:

I traveled to another city. On my way I took pictures and video using my mobile phone. I instantly uploaded them to Flickr/Youtube to share them with my family. So they can now track my trip in pictures and videos. On my way, I can access a mashup application on my mobile to tell me the places worth visiting which being integrated with a map application will guide me to those places. The same application will also give me some background information about the places. Using the same application, I can find the nearest coffee shop, ATM or mall based on my current location. A chat and email client will also enable me to be connected with my friends and colleagues. I can also have an application to pay my bills and trade online. These new class of data services leveraging mobility is surely going to change our life.