I recently stumbled across this great video “Wikis in Plain English”. It aims to explain they key benefits for a Wiki to new users or non tech-savvy users.

Its great because it highlights some key benefits to the average user such as reducing emails, coordinating tasks, retaining knowledge and just simply being cool

I’m amazed at how many shortcuts or different ways there are of doing things in Eclipse.

Recently I kept hitting an issue of Eclipse not recognising my imports (even though they were there). I was always getting the message:

import ClassName cannot be resolved.

Where ClassName was my imported class. I’m using the MyEclipse Workbench 5.5.1 on Eclipse 3.2. Here are a few tips on how you can fix this (some worked for me, some didn’t):

• ‘Clean’ Your Eclipse Project: Go to Project > Clean in Eclipse [This seems to work for me]
• Refresh your project folder (right click on your project > refresh)
• Re-build your project
• Clean your builds (If using Ant or Maven - clean your builds)
• Recreate your project in Eclipse
• ‘Switch’ Workspace - then Switch back (Eg Change to Debug, then switch back to Java)
• ‘Switch’ Workspace - then Switch back (Eg Change to Debug, then switch back to Java)
• Remove and re-add your JRE:
  1. Right Click on your project > properties
  2. Click on the Libraries tab
  3. Click on the JRE
  4. Click remove, then OK
  5. Repeat 1-3 again, but add the JRE again

Hope at least ONE of those tips help!

So I’ve been working on a project to migrate my old Ant build script into a Maven one. Whilst there is a lot of good Ant-to-Maven documentation out there, I had a few issues migrating a few simple Ant tasks I had. One of the things was I was trying to figure out how to replicate in Maven was the Apache Ant “exec” task.

In my Ant build file, I was making some “exec” calls in some tasks to execute a file via the command line. I wanted to do this to install and un-install my software, as part of the build process. I wanted to do the same thing in Maven.

So, here is the problem:

Snippet of my old Ant build.xml, which I want to ‘mavenise’ (if thats a word):

...
	<target name="unininstall">
	  <exec dir="${install.dir}" executable="cmd">
	  	<arg value="/c"/>
	    <arg value="UninstallMyProgram-NT.bat"/>
	  </exec>
	</target>
	<target name="install" depends="unininstall">
	  <exec dir="${install.dir}" executable="cmd">
	  	<arg value="/c"/>
	    <arg value="InstallMyProgram-NT.bat"/>
	  </exec>
	</target>

In the example above, I have two tasks. One to install ‘MyProgram’, and the other to uninstall it. If you are aware of the JavaServiceWrapper, you might have guessed that I’m actually trying to install my java program as a Windows service.

After doing a bit of research, it appears Maven does not have a direct equivalent. You can, however, use the Maven AntRun plugin to achieve the same affect. So in your Maven pom.xml, you will need the following:

     <plugin>
      <artifactId>maven-antrun-plugin </artifactId>
        <executions>
          <execution>
            <phase>install </phase>
            <configuration>
              <tasks name="Install MyProgram Windows service">
                <!-- Uninstall the old one first (if there is one) -->
                <exec
                  dir="${basedir}"
                  executable="${basedir}/bin/UninstallMyProgram-NT.bat"
                  failonerror="true">
                  <arg line=""/>
                </exec>
                <exec
                  dir="${basedir}"
                  executable="${basedir}/bin/InstallMyProgram-NT.bat"
                  failonerror="true">
                  <arg line=""/>
                </exec>
             </tasks>
            </configuration>
            <goals>
              <goal>run </goal>
            </goals>
          </execution>
        </executions>
      </plugin>

There you have it. For more information on the Maven AntRun plugin - check out the Maven site.

Disclaimer: I am no Wiki expert, the below article reflects my experiences of Wiki adoption within the enterprise.

At my current work I’ve had the privilege to administer a Wiki which one of my good friends put in here a while ago. The Wiki we used was primarily for our small team within a very large organization (thousands of employees). It was setup for our team to collaborate, share thoughts and retain IP. Working in IT, most of the information we had on there was related to systems, projects or other techy kind of stuff. As someone who worked in production support, the Wiki was like stumbling across gold. It empowered us to respond to incidents quicker, document and retain knowledge of specific systems or processes.

I’ve been amazed at the growth patterns that I have observed with our corporate Wiki. Its essentially grown from 30 to 550 users in less than 12 months. Our user base has grown from just IT into all our business units. Its growing at an average rate of 18 new users per week, hundreds of page views per day, and averaging around 45 contributions (new content or edits of existing content) per day.

The other thing that stood out was our contribution percentage. The contribution percentage is a percentage figure that tells you given the total amount of users you have registered, how many actually contribute. I had read theories that suggested wiki growth is generally quite slow, and is initially built on a small number of people contributing. For example, the 90-9-1 Theory:

The 90-9-1 theory explains the percentage of a wiki’s participation, breaking it down as readers being the highest percent, with minor contributors composing the 9 percent and enthusiastic and active contributors composing 1 percent of the total participants in a wiki…..
…
When studied, it was found that user participation generally follows a 90-9-1 Rule:
* 90% of users are “lurkers” (i.e. they read or browse but don’t contribute)
* 9% of users contribute from time to time, but other priorities dominate their time
* 1% of users participate very often and account for most of the contributions
Source: Wikipatterns

Whilst this theory was valid for the first few months of our Wiki, I’ve come to find that is no longer the case. Around 40% of our total users contribute and 60% are, what you could call, ‘lurkers’. Out of the 40%, my estimates would be 20% of those users would participate very often and 20% on an irregular basis. Our Wiki statistics also help tell us something with regards to user contribution. If I look at our top wiki contributer stats - it changes every month with someone different.

You often hear how ‘Enterprise 2.0 Adoption‘ is generally much slower than the ‘Consumer 2.0′ adoption. Whilst that is defiantly true, there are many ways that you can speed Enterprise 2.0 adoption within your workplace. I had read lot about Wiki adoption techniques, and there are some great resources out there. One which I got lots of ideas from is Wiki Patterns. It is a great resource. Check it out. There are many other resources that can assist, which I will mention at the end of this article

So what’s worked for us? I’m not too sure if I can pin it down to just one or two key things. Many factors go into something like this getting off the ground. Below is my small list. It’s a summary of what I’ve seen and learned along the way of Wiki adoption:

1. Pick a good Wiki
The product has to be functionally good. Might not necessarily visually be the best, but functionally. Don’t think you have to spend too much time on this. A couple of things to note about good Wikis:

All good Wikis will let you ‘port’ your data into another product

All good Wikis have, to some degree, for ’self-serve’ support (You don’t want too much manual intervention in getting users contributing)

All good Wikis have API’s. A must if you plan to integrate it with other products, or want to do stuff with it. (Eg Write scripts to automate documentation of application builds)

Given that are many wikis out there that are extremely cheep and a lot are actually free - don’t spend too much time over analyzing Wikis, just ensure it has all the important stuff. Ensure it meets your basic functional requirements - as many wikis will have many ‘extra’ features you wont necessarily use. Just get what you need.

If I had to recommend you one for the enterprise, we use Confluence as our Wiki, by the guys at Atlassian. Its by far the best and most extensible Wiki software I have ever used. If you don’t believe me check out the others and try it yourself.

2. Let your Wiki ‘virally’ grow
Similar to the likes of Gmail, and its success, letting something grow virally can be a good thing.

It’s amazing what people do when they find out they can get something for free! We promoted the Wiki as a free service provided by our team. To get a new team started on the Wiki, we made the customer contact an administrator and request to get a space created for their team. Why didn’t we allow them to create spaces themselves? We did this because it allowed us to control at a very high-level the structure of the Wiki - so it was easier to find stuff. We followed a convention for setting up teams. Within a period of a few months, we would often get several requests of teams calling up or emailing saying ‘Hey, I heard you guys have a Wiki, and its free - can I use it?’. We would then setup a space for their team, and they would get started straight away.

We didn’t have a ‘formal process’ for doing it - it was just email or call us, and we will give it to you on the spot. The business love this. In my experience, we would often see the business hesitant on engaging IT. Why? Well lets face it, all the gates, processes, account managers, project managers are just overkill for what we are trying to do here. Keep it simple - or else it wont grow. Avoid formal process where possible!

3. Find and empower ‘Wiki Champions’ in each team
Don’t do it all yourself. If anyone shows a lot of interest - make them an administrator of the Wiki for their team’s space. We essentially created a quick and effective support and growth model for the Wiki. For each team that came to us wanting their own Wiki, we asked them to nominate one or two ‘Wiki Champions’ within each team. Here is a sample of the support setup we deployed:

These ‘champions’ were generally the people that were contacting us on the initial engagement, showing interest. The role the ‘Wiki Champions’ play is critical:

They promoted and ‘evangelized’ the Wiki to people within their team

They where the ‘Support Contact’ for their team.
For things like 1st and 2nd level support tasks. Such examples are users with some ‘how-to’ questions, or administering groups and permissions within their own wiki.

They contributed to the overall Wiki growth and adoption.
This was done with suggestions, requests for cretin plugins or extensions on the Wiki. So in-directly here you are empowering your end users to have a say in the direction of where the product is headed. You could say they were the ‘representatives’ of the Wiki from their Team or Department.

We also found that building relationships with these users also plays a Key part in IT’s role working side-by-side with the business to empower business users to meet their goals. Not only that, but it has been great for overall the relationship between IT and the business.

4. Start off as open as possible, worry about guidelines later
The frustrations of an worker in the enterprise. You need to find a document for something. So you go check out your DMS, and you know its in there somewhere - but you can’t find it. You don’t have the right permissions setup, you then contact someone else to grant you access, and the waiting game begins. Frustrating isn’t it?

Most of the Wikis I’ve played with, by default tend to be more ‘open’ than your traditional DMS. Try to keep it that way where possible. For example, every new team that came to us wanting a wiki - we created a space for them. This space, by default was open to the public. If they then wanted to secure off a page or a sub-set of pages, they would do this themselves. Its essentially working the other way around to a DMS. This has worked really well for us.

Now what other guidelines did we have? Well, only one more - we still wanted to encourage users to utilize our DMS where possible. We didn’t want to create a big divide between our DMS and the Wiki. To do so, we created a Wiki Macro that allowed our users to create a shortcut link to a formal document in our DMS. This encouraged a balance between the Wiki and our DMS.

Why bother with a DMS at all? Some would say that almost all things should be in the Wiki, rarely using the DMS (this too is my preference), but we are far from this. One step at a time, besides, thats another blog post for me - lets leave that one for later!

5. Refer people to the Wiki where you can
If you can’t use the Wiki practically in your job - no one can. Here are some really good tips to refer people to the Wiki;

Put your meeting Agenda, action items and minutes on the Wiki. Get people to update their action items on the Wiki page.

Use it as a starting point for all documentation. You might have a wiki page setup for a project. From there you could link to the key contacts, key documentation and project timelines etc. Or, you might have a wiki page for processes. From there you can link to various spreadsheets, forms and documents around your organisation.

Use it as your notepad - take notes there and share them with others

If you are a manager - next time before you send a bulk-email to your teams distribution list, why not post it as a Wiki or blog item? Then email everyone from the team a link to it

Get the idea? There are many more tips for this. Ill link to some good sites with tips at the end of the article.

In general, we have found our wiki to reduce our email communication by quite a bit. More often people will now collaborate over a wiki page instead of emails going back and forth. That way all history is tracked and it saves you on the emails!

6. Bottom up, not top down
I mentioned earlier how people came to us for requests. Almost all these people were in non-manager positions. The requests had come from the day-to-day workers. Very rarely did it come from the managers or directors of business units. Its the people that use it every day that want to drive it. Most people probably don’t want to be told to document because they have to. If workers have a need to collaborate and document, they will go and look for a solution that will allow them to do that. This one really speaks for itself. If you want to encourage people to document - put some incentives, like recognizing the top contributors. Less governance, bottom up - not top down.

7. Training should not be more than one hour demo
Two really bad signs when starting a Wiki:

Your end-users want to go on a training course for it.
That might mean that your Wiki is too hard to use. If a user can use MS word, they should be able to use your Wiki. Have a look why that might be the case.

Your end-users want someone to put things in the Wiki for them.
Don’t let this start happening. This will just encourage users to fork out requests to someone who will become a full-time ‘content manager’ - doing all the updates on behalf of the team. The idea is that everyone contributes. A good way to think of it is “If you can forward an email to someone asking them to put the attached document or test on the Wiki - why can’t you do it yourself?”. So encourage users to put content in the Wiki themselves, otherwise they never will.

Most of the Wiki training we did was roadshow in a 40 minute presentation what the Wiki can do, its features, and how to get started. I would say most teams that have started to use the Wiki, haven’t even requested a demo - they are happy to just run with it themselves. Usually the Wiki champion within each team will assist if an employee wants some training.

Conclusion
I’m not sure if you can pin down Wiki adoption to a few things. Its really a mixture of variables. The above reflects whats worked for us - whats worked for you? Are you just getting started? If you are, there are some great resources out there. Here are some that have helped me along the way:
- Wiki Patterns
- Atlassian Makers of the best Wiki software Confluence (No bias - I don’t work for these guys…. yet!)
- 21 days of Wiki adoption
- iWiki.org - Wiki consultants
- YouTube Presentation: Wiki Adoption

I read a good article recently on testing web applications on multiple browsers. The following comments are derived from that article as well as my own personal experience. Hopefully they help you in some good points to take into consideration when doing browser compatibility testing on your web applications.

1. Figure out what browsers are out there - and what the trends are.
Check out TheCounter browser stats. This gives you a good framework to work from - in terms of what key browsers are used out there. It breaks it down by month, by browser, and is updated every month. It’s a great resource to work out trends in browser growth in the market. For example, if I look at November 2007 , Firefox was at 13%, and IE 6 was at 38%. Compare this to today we can see that Firefox usage is up to 17% market share, and IE 6 still remains steady at 38%. This can help us in:

Knowing what are the major browsers out there.
This should direct our efforts in terms of how much time we focus when trying to ensure our site is compatible with browser X or Y.

Observing trends.
From the example I gave above - Firefox is on the rise (and its not just from that source). So, thinking that we don’t have to spend lots of time on Firefox compatibility will come back to haunt is, especially if it’s growing at that rate.

2. Simple and manual tests are the best
Installing multiple versions of browsers on different operating systems is the best way to test your website for browser compatibility. However, this isn’t necessary the most effective way (in terms of time and resources) - but it yields the best outcome. Check out browsers.evolt.org . This site provides a great archive of all browsers and all versions (yes even the text browsers out there). This would be a good start in getting the browsers you want to test – old and new versions.

3. Virtualise where possible
To save costs on running multiple computers with multiple operating systems - run virtual machines on one box, with many browsers installed on different operating systems. Check out VMWare or Microsoft’s Virtual PC to get started on this.

4. Use tools and products that already exist
There are some tools that try to help you with this:

BrowserShots.org 
This is a free service that lets you test your site on multiple browsers. It simulates a browser on the web for you, and all you have to do is key-in your URL. However, this won’t work for internal sites - only sites facing the web.

BrowserCam
This is a commercial service that has similar functionality as BrowserShots, but also lets you test mobile devices and PDA compatibility as well. Additionally, it lets you test your site on different operating systems, unlike BrowserShots.org. If you have money to spend on browser testing, consider something like this

Adobe Dreamwever
If you are working on a basic / small website, browser compatibility testing with Adobe Dreamweaver can be relatively easy. Dreamweaver has a built in feature that scans your code for things such as JavaScript that might work on IE but not Firefox. It then produces a simple report summarizing issues that may arise between platforms.

5. Don’t forget mobile and other devices
Because mobile usage on the web is on the rise. Far to often, web developers just develop sites for PC’s and not mobile devices. This poses heaps of challenges in terms of site design, especially what you do with your JavaScript and CSS layout for various platforms. The DotMobi is an awesome resource that has great bits of information on testing and developing for mobile devices.

Google has just made it easier to find out movie times in Australia. All you have to do is go to Google.com.au, and search for your movie and the suburb where the cinemas are in. For example do you want to see American Gangster at Hurstville Greater union or in the city?

Awesome stuff Google!

If you don’t already know, Google has announced they will be bidding for the 700Mhz frequency that is going up for sale in January 2008 by the Federal Communications Commission (FCC). This has caused a lot of press to come out in the media, with both positive and negative views to the idea. A lot of people are starting to ask the question - Does Google want to become a telco provider? Is that why they are doing this?

In Google’s official press release it says:

“We believe it’s important to put our money where our principles are,” said Eric Schmidt, Chairman and CEO, Google. “Consumers deserve more competition and innovation than they have in today’s wireless world. No matter which bidder ultimately prevails, the real winners of this auction are American consumers who likely will see more choices than ever before in how they access the Internet.”

If you mix that with the recent news of Google who recently launched Android - a new open platform for mobile devises which they want to roll out to as many mobile devices as they can then - The is BIG news for AT&T and Verizon.

Is Google playing a game? Are they just trying to send a message to the big guns? “Open up the platform… or else”

I was reading this interesting article today titled ‘Google Shrewdly Plays Wireless Bid‘. This article suggests just this - that Google has already won the bid.

No, not physically wining the bid, but rather, they have obtained the goal they set themselves when they said they were going to bid. Why are they bidding? In my opinion, they want to open up the networks. I really don’t think Google has an interest to be a telco provider, but they would do it, if the telco’s don’t clean up their act.

Its no secret - Google’s ‘vision’ is to make the world a better place. “Don’t be evil” is their motto. Believe it or not, they have lived up to the statement thus far.

In my opinion, Google has already won.

It is no mere coincidence that Verizon and AT&T are opening up their networks: See Verizon Wireless Says ‘Bring Your Own’ Device or Verizon Wireless Opens Up Its Network. Who’s Next?. I think TechCrunch sums it up nicely:

In what is either a response to Google’s Android mobile operating system or an attempt to butter up the FCC for the upcoming 700 Mhz spectrum auctions or just a smart business move, Verizon Wireless is opening up its cellular network to any device or application that meets the “minimal technical standard” to run on its network.

That means pretty much any CDMA device or application, even ones that are not officially offered by Verizon. The devices and apps will have to be tested and certified in a new $20 million Verizon lab being set up for that purpose, but by early next year if you don’t like the phones that Verizon sells, you will be able to bring your own unlocked CDMA phone to the network—maybe one you bought from Sprint or overseas.

This move could help Verizon in its bid for the upcoming 700 MHz spectrum auction, which will require that any winners allow open access to devices and applications on any resulting wireless network. By adopting those same principles for its current network, Verizon is showing a lot of good faith that could win it points in Washington.

Amazing what the power of one corporation with a lot of money can do. The funny thing is - they haven’t even spent it yet on the bid, and I think they are getting the results they were after. This really is a win-win situation for consumers.

Mashups. It’s a term thats been heavily used in the Consumer and Web 2.0 space, however has been lightly thrown around in the enterprise space with claims that its lacking standards and maturity.

For a long time, I’ve been thinking where this is all headed. There are two main conclusions I would like to draw at the end of this:

1) In terms of how this is going to affect IT in the enterprise, I think whats going to happen is we are going to see two types of ‘developers’ emerge as a result of what is happening in the Web 2.0 space. The ‘Mashup Developer’ (which generally might be a business user, or a slightly tech-savvy person), and the ‘traditional developer’ (your true nerd). However, it is important to note that you will still need both!

2) In terms of how this is going to pan out and the Maturity of Mashups - I think ‘RESTful Web Services’ will play a critical part in boosting the state of Mashups, and this is yet to come a long way. As this happens, I think you would start to see a trend - in the increase of Enterprise Web 2.0 adoption. At present, I think we are a very long way off this.

Let met take a few steps back so we are all on the same page…

Mashups
What are Mashups?
I’d point you to Wikipedia for this, the source of all truth :-), but to put it in simple terms: A Mashup is a new service, that combines functionality or content from existing sources. These existing sources can be Web Services (through the use of API’s), RSS feeds or even just other Websites (by screen-scraping).

What are some examples of Mashups?
Mashups on the haven’t really been around for too long. A quick trend analysis on Google, and you will see, they have only really come into the scene last year:

However, there are some excellent examples Mashups today, I’ve listed some of my favorites below:

• chicagocrime.org - This was one of the first to come out. It displays a website with crime stats in Chicago and maps then on a map. It’s very detailed and lets you even drill down to the crime type, and the exact street that crime was committed on.(Police Stats + Google Maps)
• housingmaps.com - Displays hose prices for various states in the USA (Real Estate + Google Maps)
  feedmashr.com - The most popular content from various websites (Digg, del.icio.us, reddit…)
• flickrvision.com - Google Maps + Yahoo! Flickr Photos to display live photos of peoples location around the world as they upload.

As you can see Mashups produce some amazing results, especially when it comes to trend analysis or getting the best content you can from various sources. What more examples? Checkout the Mashup section on Programmable Web Blog.

Some would argue the concept of Mashups has been around for years - and this ‘hype’ over Mashups is over the top. For years we have been getting data from other systems and combining data with the existing systems to produce a result. This is true, however, I think the hype over Mashups over the last year or so has clearly been on the ease of end-users producing applications themselves. This is generally done through modern-day Mashup editors (which I will talk about below), and not the olden way of SFTP/FTP-ing a file then doing some sort of transformation and loading of data through scripts and other mechanisms.

So yes, Mashups have been around for years. However, the concept of the end-user being able to easily ‘drag-drop’ and put together a hacked up application within minuites hasn’t - and this is what its all about.

Mashup Sources
1) API’s: REST vs SOA? or SOA + REST?
As we mentioned earlier, mashups is basically a mix of various data sources. Lets start off firstly with API’s. Because API’s expose system functionality to other systems and users, they play a critical part in the whole mashup space.

Service Oriented Architecture (SOA)
Lets start off discussing the Service Oriented Architecture (SOA). When I refer to ‘traditional SOA’ I mean (web services through such things as SOAP, and the older XML-RPC protocols). API’s generally require the user to make Web Service calls from their application passing through relevant parameters, and getting results based on what was passed through.

Almost every Web 2.0 startup wanting to expose its functionality to external users or other developers would have some form of API available. Examples include the Facebook API, Google Maps API (and the many other Google API’s) as well as the dozens of other API’s available for hundreds of sites.

In general, API’s which work on what I called ‘Traditional SOA’ (IE SOAP/XML-RPC) provide a very powerful way to interact with other services programmatically. However, this does come with a down side - its generally quite technical and requires developers who have a good understanding of protocols and programming languages. How does this fit into Mashups? Well, whilst it can be quite technically complex to interact with other sites for the average business user. The introduction of Mashup editors try to do all this hard work for you and give you a drag-drop feel to make things a lot easier.

Therefore, Although traditional SOA does play an important part in the Mashup equation, it must work well with Mashup editors and other architectural styles which are simpler…. (In comes the RESTful Architecture style…)

RESTful Architecture
In comes Representational State Transfer (REST). REST in essence, is an an architectural style for implementing web services. This is done over the HTTP Protocol (without SOAP).

With a ‘RESTful Web Service, each service is easily identified by a unique URL (yes, the actual website address). Essentially, when the server receives the request, it knows what to do based on the URL path. Whats an example?

http://www.myonlineshop.com/product/12345 (the Restful way of doing things)

In essence the URL now is a noun not a traditional verb:

http://www.myonlineshop.com/getProduct?productID=12345 (this is the traditional way we did things)

All that would change now is the HTTP action parameter. This would basically equate to the database transaction or (CRUD Action - Create, Read, Update or Delete) that is wanted to be performed:

HTTP Method	CRUD Action	Description
POST	CREATE	Create new resource
GET	RETRIEVE	Retrieve the resource
PUT	UPDATE	Update resource
DELETE	DELETE	Delete resource

RESTful web services have open been mentioned as alternatives to ‘Traditional SOA’ (SOAP / XML-RPC), however, I believe they need to work hand-in-hand to provide a mix of sources for Mashups (and Mashup editors) .

With web services that are generally SOAP-based, the request and response are hidden. SOAP requests must be interpreted as they are received at the server to determine the operation to perform and the arguments required to perform that operation. They are generally passed through as a parameter, which is essentially a function/method call. SOAP does not currently provide a mechanism for caching results, where as REST can (through the standard HTTP caching).

Therefore, the REST service architecture shows itself as a much more simpler, more standardized in terms of CRUD-style applications and is very similar to the HTTP protocol. Something maybe an average End-user could understand?

Same result, different views
What I am trying to conclude at is that you will need both for effective mashups. Essentially, the Traditional SOA way of doing things and the RESTful way of doing things would both yield similar results. However you might find that the Traditional SOA would allow you to do more powerfull things (and as a result is more complex) and the RESTful oriented architecture would allow you to easily do simple things (and this being much easier to implement)

REST becomes an architecture style applicable to systems that would want operate with a Resource view.
SOA, on the flip-side, has a different view of the web. It uses the web as a application infrastructure between service providers and consumers otherwise known as the Service view.

SOA and REST are architecture styles applicable to different application domains. It is not useful to argue which one is better without knowing the target application. REST works well with distributed resources and SOA does better with distributed services. Resource interactions are different from, but in general simpler than, service interactions.

To get the best result - you need both. Some situations require a RESTful architecture, some require a ‘Traditional SOA’ architecture, and some might even have both!

2) So we’ve got REST + SOA, how does Web 2.0 fit into this?
When I reffer to Web 2.0 in this article, I am generally referring to the social networking space as well as the features and services provided by these sites. Two main things I want to draw out of the 2.0 space:

A) Social Context is the next big thing.
For mashups to really take off, we need to be able to capture the context of information. A lot of people in the enterprise would often say that the Enterprise is suffering from information overload. Information becomes relevant, and more useful when its placed in the right context. I strongly believe that if a Mashup can leverage of some form of context, it would then be able to provide the relevant information to the user.

There is a lot of hype around Facebook lately. If you ask people why they would usually say due to the amount of users its got - a hell of a lot!. However the power of Facebook really comes into play once they can tap into the social trending. How much more effective could advertising be if the advertiser knew who the ‘trend setters’ were, and targeted them directly? With Facebook, you can quickly see if a user adds an application, how the effect would filter down on his/her friends.

Now Facebooks insn’t necessarily going to be the best example to draw information from for the Enterprise. However, what If you applied the same theory to something like LinkedIn. Lets use the example if you were a HR recruitment person, using Linked in to find people for a Job. Imagine the power you could have if you could create a mashup to find out who in the employment business could change companies, and draw two or three other people to come with them. From that social context you could quickly see which people in a company would be much more valuable in terms of their people ‘pull’ factor.

B) RSS Feeds
One other thing we can draw out of the Web 2.0 space is RSS feeds. RSS gives us the capability to extract content from a source, in a neat little way and allow us to also stay updated on a regular basis. Mashups will work well when mixed with both Web services (the two styles I mentioned above) as well as RSS feeds to obtain content that might not be as-dynamically updates as the type of content you would normally get form an API service.

The Mashup-world today
So where are we at today?
Mashup Tools & Editors
There are plenty of Mashup tools and editors that really allow users to start playing around with this stuff. It’s all still very primitive at present, but will grow into something significant over the coming years. Below is a list of Mashup tools and editors I have played with on the net:

• Microsoft Popfly: Microsoft Popfly is Microsoft’s Mashup Editor.
  I’ve played around with it and I’m quite impressed. It pre-gives you a whole bunch of web services already available. And all you have to do is ‘drag-drop’ content from one source to another. Its very useful to an end-user and requires little technical understanding.
  I thought I’d give it a go. Within minutes I was able to pull my friends avatars from Facebook, and display them in a collage via a few clicks. It’s pretty cool. Popfly is built on Microsoft Silverlight (it’s try-hard Flash equivalent). Microsoft’s Steve Ballmer describes it as: “(Popfly is) a (mashup) tool for end users, not necessarily codeheads.”
• Yahoo Pipes!: Yahoo Pipes is Yahoo’s flash-based tool to
  ‘aggregate, manipulate, and mashup content from around the web’. Yahoo Pipes was one of the first mashup editing tools to come out. It appears to be targeted to the slightly more technical people. However it has a ‘drag-drop interface’. Its quite easy to use, I’ve used it myself to pull content from two various sources and create a mashup - was pretty impressive. Checkout a simple video to get started:
  
• Google Mashup Editor: The Google Mashup Editor (GME), is defiantly the most advanced out of all the ones I have seen. It’s got a whole stash of documentation, and defiantly the ‘least user friendly’ - that generally means its the most powerful, and it is. Its basically got a tag based markup language, that lets you also embed HTML into your results.
  Its very ‘componentized’ too - Java developers would love this. For example, lets say I want to create a mashup to read content from a site:
  1) Firstly I would define my data source(s) via a ‘ 2) Then you would define your result set similar to a tag-based result set for a set of JSP's.
  3) Then you could mix and match data from other sites/sources/services.

There are many other tools out there, but those are the main ones I have come across.

Is this the end of Portals?
When the whole concept of Portals first come out, the whole idea was that you could draw content from various sources using little Portlets, and personalize it to what you want.

Is this the end of Portals? No, I don’t believe it is. In fact, look at the success of iGoogle (aka Google Start Page) which is essentially a Portal platform that lets you add and configure your own widgets/gadgets (aka Portlets) to do what you want.

I see portals providing a platform to leverage off these services. The example above of iGoogle is one, another would be Facebook. If you think of Facebook as a platform, and all the widgets/gadgets as what makes the overall content, you have a mashup. Through a portal-like interface you have brought in content from many sources: Web Services (SOAP, XML-RPC), REST, RSS Feeds and even Screen Scraping.

So in summary, portals are staying, if anything they will be come richer with more composite content from many sources.

The end result
Mashups in the Enterprise
I think the consumer space has already embraced Mashups, and we have seen this through the large amount of mashups available today on the web (just Google it!). However when it comes to Mashups in the enterprise, it’s still got a bit to go.

I often refer to Masups as the modern-day ‘Macro’. Let me explain: Often in the enterprise you would find a lot of business decisions being made from a whole bunch of Excel spreadsheets, Access databases and macros (sad, but true). Most of these macro’s would have been developed my business users themselves, rather than the full-on tech IT Programmer. Why? Because it was simple enough to get by, and gave them just the right amount of information they need. Not only that, but it was the cheaper solution than engaging IT - and why not if they can do it themselves? This is still the case today.

As business start to embrace mashups more, I believe mashups will play this similar role of a modern-day macro. Additionally, it will allow them it to obtain much more detailed information from their various sources (rather than a bunch of spreadsheets), in a much richer format (through combining such things as videos, images, spreadsheets, and other sources).

Will this give end-users critical data which they can make key decisions off? Probably not, I think it will just play a small factor in decision making. At the end of the day I believe mashups in the Enterprise, will just be another tool which business users can utilize that will help them make decisions by analyzing and comparing data from various sources.

The need for the mix: (REST + Traditional SOA) * Web 2.0
In summary, you need the mix before Mashups really take off. I believe both REST and ‘Traditional SOA’ will work together alongside all the other various ways of getting content on the web to achieve this.

Traditional SOA Web Services + RESTful oriented architecture Web Services + RSS Feeds + Social Context + Screen Scraping = Good Mashups!!

The results
Show easy its going to be? Well I showed you an example above -Flickr Vision. Look how easy it is to create something like this through a Mashup Editor. Microsoft Popfly gets photos from Flickr and hooks them to Microsoft Virtual Earth (the equivalent of Google/Yahoo maps but Microsoft):

This is done in 30 seconds! That my friends is my Mashup rant.