Apr 222006

At first I was skeptical. Why in the world would I want to leave my cozy little world of Microsoft Outlook? I’ve got all of my information in there including appointments, notes, tasks (a la “Getting Things Done”), and email. It’s all in one place and it all synchronizes with my Treo 650.

But it is Google, which means to me that it’s at least worth a look. So I dug in. I exported my calendar from outlook to a .csv file and imported it into my new google calendar. This was very easy. I created a second calendar (my mother’s pocono house schedule) to see how it worked, and was pleased with the results. My new calendar was a different color, and its events were displayed in that color along with my personal calendar. Very cool. This is a bit better than Outlook. In outlook you can create multiple calendars, and you can view them side by side, but you can’t overlay multiple calendars in the same display (I don’t think).

In thinking about the utility of this new tool, I’ve come up with a few uses (for me anyway):

  • personal calendar
  • work calendar (shared)
  • family calendar (shared)
  • java user group calendar (public)
  • friends calendar (shared)
  • professional group calendar such as IEEE (public)

This is pretty cool. If my local java users group maintains a public calendar, I can search for it and add it to my display so I always know what events are happening on which dates. Additionally, with Google calendar people anywhere can see my free/busy information if they know where my calendar is.

So there is some value in this tool, but it’s still not worth it. I can’t use Google Calendar exclusively yet for the following reasons:

  • Can’t easily synchronize with my Treo
  • No task support
  • No memo support
Apr 202006

SOA is not necessarily ‘Web Services’.

A service oriented architecture could be implemented in many different ways. One implementation might be a client-server application, where services are independently deployed to the SOA platform and accessed by client programs. Think of 20 cash register operators at Wal-Mart (the client programs) and a server running a set of cashier related services in the back room somewhere. This might all be implemented in Java.

Another implementation of a service oriented architecture might involve traditional ‘Web Services’ implemented using SOAP (Simple Object Access Protocol) and WSDL (Web Service Description Language). Imagine Amazon.com providing software services to their business partners and UPS providing services to Amazon.com. In this scenario, Amazon.com might have implemented their system using Java, whereas UPS implemented their system in .NET. This is the value of ‘Web Services’ – SOAP and WSDL enable these heterogeneous systems to communicate with one another. The SOA part of this scenario lies in the fact that new services can be deployed and consumed independent of the existing services currently deployed. SOA enables this loose coupling which is quite valuable from a business standpoint, as I discussed before.

So service oriented architecture is not necessarily coupled to ‘Web Services’. It’s more of an architectural style.

Apr 192006

Why should anyone care about SOA?

Service Oriented Architecture (SOA) is the idea that business functions can be built in such a way that it becomes easy to produce or consume any service by loosely coupling services from consumers (and from each other). If you have an operational service that currently accepts standard purchase orders, it should theoretically be easy to build and deploy a new service that compliments the existing one. For example, perhaps your users want the ability to change the quantity of supplies ordered before the order ships. In theory it should be very easy to create and deploy such a service along side the existing purchase order service. Additionally, it should be easy for system integrators to integrate with the new service, and thus users of the service can use it much sooner.

You might be thinking, who cares? Well, here’s why it’s important. Enabling loose coupling of services makes software cheaper to produce and consume. Many companies have spent many millions of dollars on maintaining and/or modifying very tightly coupled systems. By enabling loose coupling and standardizing on certain technologies, companies can produce services more rapidly. Also, companies that consume those services can integrate with newly created services more rapidly, thus enabling their use much more rapidly than was previously possible. This has the downstream effect of providing value to users more quickly, which can generate economic activity.

So who cares about SOA? You should if you want to deliver value to your users as quickly as possible.

Apr 152006

There’s been a lot of activity lately regarding ESBs (Enterprise Service Bus). JSR-208 was finalized in August 2005, and since then a couple of implementations have been completed and become available. These include eXo ESB and LogicBlaze, both of which are open source implementations.

Then you have IBM, BEA, and Oracle lining up around the SCA and SDO specifications.

It makes me wonder – is JBI competing with SCA and SDO?

I’ll be looking into this. More to come soon.