I find all the posts flying around about SOA vs. Web 2.0 kind of amusing.  Dion Hinchcliffe, Nick Carr (some very good comments on this post)

People must be bored. I am too, it's a rainy Sunday afternoon; what the hey. Last one, I swear.

Well this is a bummer.  I actually had a little proof of concept app I wanted to stick in this post, but apparently Type Pad isn't quite social enough to accept Javascript :) 

Anyway, SOA is just a way of building applications so that they are capable of sharing data.  REST and SOAP are both protocols for using the services it contains.  Web Services are just an implementation of (or wrapper for) those services.

Web 2.0 is allowing other people or systems to participate in the SOA you built. Web 2.0 is the idea of opening systems and allowing others to use them. Google opened its system, all kinds of Google Maps mashups resulted. Flickr opened their system, and mashups resulted. Amazon opened its system, and mashups resulted. "Mashup", is exactly what it implies--it mashes together two different systems and creates a brand new application using the two (or three, or four).

Web 2.0 for the consumer is allowing people to use more than one Web application at a time. People digging a link is feeding Digg's "service" with data. They're just running a fancy report on that data--an interactive report that also uses Digg's services to feed more data into the system. Then digg let's people use that data as part of their mashup.

Web 2.0 for the enterprise is allowing people to use more than one Web app AND/OR internal system at the same time. Web 2.0 for the enterprise will happen when IT departments begin wrapping Web services around existing systems, and start making mashups using THOSE. I can just see the sales pipeline overlaid on Google maps from here.

What will be REALLY cool is when standards start emerging and the data from those services wrapped around the internal systems can be shared with partner companies. Exposing sensitive data, either using. This is going to rock the business intelligence market, I'll betcha. Not only that, but when I had to facilitate data sharing between the company where I was IT Director at the time and our partner companies, I would have absolutely KILLed faor a simple way to share data with them. Instead it always resulted in a 2 week-long project.  As Barry Briggs points out, the issue of security needs to be carefully hashed out, and I would imagine some kind of data system partioning done at the enterprise level, but this is still a very exciting time.

Anyway, I digress. SOA is just an enabler.  I think I'm done now.

The New York Times writes that Microsoft "evidently surprised analysts by predicting significantly higher expenses in the next fiscal year".  This, apparently, is what happens when non-technical writers write about technical companies :)

If they'd have done some research they'd have seen that Microsoft is gearing up to provide free online storage and that the bigwigs there have been predicting this surge in spending for a while.  I personally can't wait, I'm impressed with their Windows Live efforts so far and more direct competition with Google can only bring better things.

They're building out an infrastructure to compete with Google, it'll be interesting to see how that goes.  Two different companies with two very different approaches to scalable systems:  Google built on cheap, disposable servers, Microsoft built on their enterprise servers and presumably Dell hardware.  For as good as Google's application performance is in general they've definititely seen their fair share of problems, so this will be a good litmus test of how Microsoft's stuff stacks up.

This is fantastic (found via Ajaxian).  I'm glad to see the DHTML community working with the Flash community.  Only bigger and better things will come of this.

I was originally leaning towards using the Prototype library for my next project, but this is causing me to re-think that decision.  I'm going to have to go back and re-evaluate Prototype and OpenLaszlo now because I think that tandem is going to be a killer and very well may become the standard Web 2.0 application building block of choice.

The only reservation I have about all this is the speed of Flash sites, as you've probably noticed if you use Goowy.  However, I need to go back and re-run some tests on it before I make a final decision, with proper architecture I can forsee the performance being just fine.

UPDATE:  I've been thinking and posting more about this topic here (further defining SOA and Web 2.0 and how they inter-relate) and here (what I believe is the solution--which doesn't exist, yet--for fixing this "misunderstanding).

There's been a lot of discussion lately about "SOA vs. Web 2.0".  See these posts by John Hagel and Jeff Nolan.  This is just wrong, wrong, wrong.

In my eyes they are the EXACT SAME THING.  This debate about REST vs. SOA, is completely off base.  You're debating about what method the user interface should use to access services.  A service is a service, it doesn't matter if it's called using SOAP or REST or a freakin' TCP/IP socket.

The real point is, the software needs to be written as a service.  If it's built properly (and this is very important, as certain Web 2.0 companies <cough>37signals</cough> have basically derided proper, loosely coupled, software architecture as limiting) you can throw another interface facade on top of the logic code an expose your service whichever way you want.  Hell, if I decide I want to expose my service via smoke signals tomorrow, all I have to do is write a smoke signal interface for the business logic layer of my application.  Not that there's anybody to consume it, but hey, when the smoke signal guys get all up in arms about it I can be the first vendor to embrace their standard :)

There are already mechanisms out there for rich Web clients to consume SOAP services, REST just happens to be the most popular mechanism to access services by a browser right now for whatever reason.  I personally like SOAP 100x better than REST, I think it's more enterprise-ready, and there are many, many specs out there for extending it and making it secure.  But really, WHO CARES what an app uses to access a service?

To clarify:  when a Web 2.0 app makes an HTTP request in the background to get data, it's calling a service of some type.  When you click submit and it updates data in the background, it's calling a service of some type.  Now, there are exceptions, such as when a Web app makes a direct call to a business logic layer, but the entire point of Web 2.0 and AJAX is that you're trying to avoid round-trips to the server, which is where most of that happens. 

The real problem is people who don't understand both camps trying to have a debate about why they're right and the other guy is wrong.  How can you debate something you don't understand?  You're both saying the same thing, just in a different language.

This bit of the Google Data APIs Protocol spec intrigues me:

• A web-based client, such as a third-party front end to a GData service, should use a Google-specific authentication system called Proxy Authentication for Web Applications. This system is not yet available for use.

Beyond the fact that they said it'd be ready in late April and it's already getting late by my watch, I'm curious aobut how they're accomplishing this.  This must be absolutely secure, because I have a feeling they're going to be providing access to some pretty sensitive data using this, such as GMail data.

With desktop apps, Google is giving the application a cookie that they can use to authenticate with.  Obviously this doesn't in browsers because cookies aren't secure.  So how are they planning to authenticate Web apps?

I'm sure Google wants and NEEDS this authentication mechanism to be absolutely secure, so they're probably not using any of the existing HTTP authentication mechanisms (Joe Gregario has a hilarious description of problems with the current mechanisms written up as a Monty Python sketch).  Basically, the problems are born out of issues with the implementation of HTTP authentication on either the server (with Apache) or client (with IE) side.  None of the methods work across the board.

Is Google using a reverse proxy to hide their internal system from the unsecured Web, and forcing users to authenticate with that proxy by sending a 407 error (Proxy Authentication Required)?  No matter which browser or server the application is running on it will be able to connect.  It will marry together the different authentication mechanisms so that any application will be able to authenticate using a Google login regardless of what methods it supports.  This is a pretty cool idea.  In other words, take your pick, we support 'em all.

If this is true, it would actually support both browsers and servers as endpoints for the GData service.  I'll be keeping an eye on this to see what they do, should be interesting.  It looks like it could be the only way to do true HTTP authentication right now with the quagmire that's resulted from the fragmented implementations of standards.

Update:

I've been catching some heat for this post, as I kind of figured I would.  A couple points of clarification before you read on:

1. Directly authenticating with your  email server would only be used for sites that you trust and want to integrate into your online "identity".  You wouldn't want to use it to buy a digital camera from a fly by night Internet store, but I would question the wisdom of giving them your credit card info in the first place.  However, I would let Amazon authenticate me like this, provided they agree NOT to store my password (which isn't needed and would be a huge liability for them anyway).
2. If somebody does use this method to authenticate with a questionable party, all he needs to do to re-secure his identity is change his email password.
3. Client side javascript hashing is already available

I've never seen this method presented before in any forum so I wanted to get this out there as an option, however worthless an option it may turn out to be.  Never leave any stone unturned, that's my motto ;)

************************************************************************

In a previous post, I wrote about WHY single sign-on for the Web is needed--badly.  In this post, I'm going to look at an idea I had about how to make it happen with the infrastructure that's already in place today.  Whether it flies or not remains to be seen, please shoot holes in it :)

Microsoft wants us all to install InfoCards on all of the devices we use (including public terminals and kiosks), and OpenID wants us to establish our identity by setting up trusts with different Web sites, and there are a handful of other similar ideas.

However, I think it might actually be simpler than all that. I could (quite possibly) be nuts, but I had an intriguing thought the other day:

1. To authenticate, you need some type of authority.
2. The only real authorities on the Internet at this point are the domain registrars
3. The only user accounts associated with domains are email accounts

This tells me that the only way to achieve universal user authentication on the Internet right now is to use email accounts. The only definitive identification we have on the Internet right now is our email address.  What that doesn't mean, however, is that every application should use the email address as the username (although I do like this better than another, different, user ID) and create a new password for the account.

What I'm getting at is this: I don't see any reason why users shouldn't be authenticated with their email servers. Why can't sign-on work like this?

1. The user goes to the site's URL (www.buystuff.com )
2. Before they can buy something, the user has to enter their email username and password (Jason@jasonkolb.com and test123)
3. www.buystuff.com looks up the email server for jasonkolb.com from the domain registrar (using the domain's MX record).  We now have a server that can authoritatively identify the user.
4. www.buystuff.com sends the email server the email address and password that it was given. If it's able to authenticate, the user can be positively identified as Jason@jasonkolb.com without the need for any further logins and passwords (and without even needing to STORE a password, of any kind!).

The problem I see with this is that you have to provide www.buystuff.com with your email password. This could be dangerous if somebody gave their email password to a site they shouldn't really be trusting.  However, this really isn't much different than what people are doing every day right now with their credit cards, so I don't think it's really that big of a leap.  The sign-on page should be signed with a trusted certificate from a certificate authority anyway, so it's essentially the same level of trust we have today.

The other alternative is to build hashed password support into the email server. I actually prefer this method, because it would allow the user to authenticate using email without having to tell the site what his password actually is.  If browsers could do the hashing that would be one step better since the user wouldn't have to send his real password to the site at all.  Today, the only browser-side caching that exists is using Digest Authentication, which is on the browser side, so the only missing piece to making this solution secure end-to-end is email servers that support digest authentication.  Alternatively, I think it's realistic to set up an authentication authority for each domain. In much the same way that an email server is found by looking up the MX record for a domain, we should be able to look up the authentication authority for a domain. The authentication authority for a domain should return the IP address of a server that supports digest authentication, so that applications could just forward the user's email address and hashed password to it and receive a response indicating whether the user is authenticated or not.  Or, possibly even a token that identifies the user.

One of the big advantages I see to this approach is that for say, publicly traded companies that need to be Sarbanes-Oxley compliant, their email server generally authenticates against an LDAP repository of some sort such as OpenLDAP or Active Directory. This means that their security policy is enforced for that email account, such as password complexity and expiration. All of the heavy lifting for compliance is done by the LDAP server, so there's never a risk of any of the user accounts on that server being out of compliance.

The only roadblock I see to this approach is people's reluctance to share their email account info with another party.  However, people don't seem very shy about giving their email account away right now anyway, just about every Web desktop such as Netvibes or Goowy requires you to enter your email account information to read your mail.  And the passwords are actually STORED on their servers, this approach doesn't require that.  Whatever happens, I hope it happens soon, because once we're able to track our activity against a single ID, the next leap in Web functionality is really going to take off.

FYI I'm planning to build a proof of concept on this very soon, unless somebody wants to volunteer :)

I just read an interesting post on Ajaxian about a new Powerpoint-like slideshow application called TeamSlide.  Mike Arrington also wrote about this new app.

As the online Office-killers pile up, I can't help but wonder what formats these companies are using.  If they're all using independently-developed formats, that's a bad thing.  If they keep them private, that's an even worse thing.

What they really need to do is put their formats out there in the public domain and allow people to beat on it and re-use it.  Not only will it allow people to re-use the work they've already done, but it'll allow to people to provide feedback about how to improve the product and the format.  And once a standardized format is reached, adoption is going to grow exponentially.  It'll allow people to choose which application they want to use to view a particular file, which levels the playing field for the little guy.  If somebody doesn't want to spend over a grand for an Office license with PowerPoint, they can choose to use TeamSlide to view the same file.

On a similar note, I know Microsoft is opening up the Office XML format for the next release, I wonder if PowerPoint is included in this.  If it is, it would be wise for TeamSlide and other applications like it to work with that format, even it is via an import or transform.

John Sviokla wrote a fascinating post recently about the reasons why people participate in social networks.  He argues that people participate in social networks for the social aspect of them, not for any monetary rewards.  In fact, it seems that when you attempt to provide monetary rewards for social behavior, people actually become less likely to participate as much as they did previously.  Ross Mayfield has an interesting discussion about this same topic.

This has some interesting implications on the adoption of Web 2.0 technology in the enterprise.  It essentially means that you have to leave the social rewards in place and not tie participation to performance reviews or any kind of "standard" incentives.  You need to make it easy for people to feel a certain sense of gratification about participating in the process--provide recognition, or thanks of some kind.

Now, I think if you went to the average manager who has to fight and claw their way to a bigger budget for raises, and told him that he could inspire his employees better, for free, he'd be doing backflips and asking you where the mind-control device was.  But, this is pretty simple stuff.  Respond to people, thank them, acknowledge them, and they'll contribute more and more.  It feeds into our base need to be social, to have other people acknowledge and respect us.  This is something that can only partially be addressed by paychecks.

What's really cool is that I think this opens up the possibility of Web 2.0 technology not only improving knowledge management and sharing processes, but it also has the ability to motivate people beyond their current levels of participation.  The main reason Web 2.0 technologies revolves are so cool is because they connect people and get them involved in communities where the whole is greater than the sum of the parts.

Simply doing things like including the top rated blog posts, or the person who posts/tags most often, on the company Intranet, may be enough to spur some great participation in these new technologies.  Include an RSS feed of the most relevant information coming from people, and most importantly, acknowledge them.  Perhaps the CEO could make a monthly mention of the person who contributes the most to the company's info-sphere for that month.  Not only would it encourage participation by everyone, but it would also motivate them.  It would let them know that if they just participate in this network, they will be noticed, and they'll be acknowledged.

One of the biggest pet peeves I had when I was an employed programmer was that when I would have a great idea and implement it, my boss would somehow get most of the credit.  The "team" aspect aside, there's a lot more motivation to flesh ideas out and develop them and see them thrive if I know that the success of the idea can be traced back to me.  It's selfish, yes, but it's also undeniable.

Web 2.0 technologies pull back the curtain and reveal who the real magicians are in the company.  Not only is it good for the magicians, there's really no way that it can't be good for the company.

I've been thinking a lot lately about different ways to authenticate
users on the Web without requiring them to maintain another username and
password set for each site.  Before the Internet can really become a
cohesive social network (and especially before we can start integrating it with the enterprise), some kind of authentication authority will need
to be developed--right now everything is way too fragmented.

All the new Web 2.0 apps are great, but most of them only done one thing.  Sell something.  Blog something.  Read something.  Tag something.  Write something.  They're all great, but how many logins can one person reasonably be expected to keep track of?

If you think about the real innovation happening with Web 2.0, most of
it revolves around the ability to connect people and let them
collaborate--easily. This works great when you're dealing with a closed system
where people need to log in and create an account.  You make them pick
a username and password, or use their email address as their username
and then choose a password. However, the account you're making
them create isn't the same account they use to post blog entries, buy
things, or comment about your pictures on Flickr. Because of this, all
the data that the user generates is fragmented and it's pretty near
impossible to aggregate it and look at the person as a person instead of just a collection of logins.  The closest we can get right now to viewing somebody as a "person" is to run a Google search on their name
and see what pops up.

Eventually, this will HAVE to change for the next evolutionary leap of the Internet--technology in general, even--to occur.  It's pretty evident that the "identity repository" can't be controlled by any one company or organization, or Microsoft probably would have been more successful with Passport.  It's going to have to be a decentralized way to find out who somebody is, that THEY have control over, not a corporation that they don't fully trust.  There are a couple of new technologies that seem to be going in this direction, most notably OpenID and Infocards.
OpenID basically tries to authenticate people using their blog account,
which is a good start. However, I don't think a Blog account is the
definitive identity that people want to use to authenticate themselves
around the Web.  Infocards use the WS-Trust Web service extension and
signed client certificates.  Maybe I'm just lazy, but I don't really
want to have to keep track of a certificate on every device that I need
to access the Web on.  I don't even know if my Blackberry knows how to
read a certificate (I would assume so, but the point is that it's not
common knowledge and installing a certificate is one more step that
people don't want to deal with).

In my next post I'll follow up on this with an idea I have that may be a nice simple yet elegant solution to this problem.

If I ever get any spare time I'd love to start an aerial advertising
company.  A company that leases rooftops of large
buildings and paints advertisements on top for satellite imaging and
airplane passengers. Like this Target ad, the first one I've ever seen:

http://maps.google.com/maps?ll=42.006505,-87.887138&z=0&t=k&hl=en

This is just about one of the last frontiers untouched by advertising
right now, it's pretty easy to see that when you fly over a major city.
I'm guessing it's only a matter of time until getting the window seat becomes a little more interesting on takeoff and landing.

I've always thought it would be a great idea to put advertising on the
side of railroad cars too. A lot of times they're parked over major
interstates or highways, and in more rural areas they have a pretty
captive audience while people wait for the train to pass.

I don't actually think I'd mind advertising in either of these places.
It doesn't seem invasive to me because the only time I'd see these ads
is when I'm sitting there with nothing better to do.