Application Platform Strategies Blog

The difference between SOA and 3-tier

Blogger: Anne Thomas Manes

Jeff Schneider recently started a thread on the Yahoo! service-orientated-architecture discussion list asking for a comparison between SOA and 3-tier. Here's my response:

3-tier or n-tier application architecture is just that -- an *application* architecture. It's focus is on building monolithic applications that can be distributed across multiple processors to increase performance and scalability. The tiers represent different aspects of the application: presentation, business logic, and data access. But the fundamental architecture doesn't talk about services, and it has never stressed reusability -- except at the DBMS layer.

SOA and n-tier are somewhat orthogonal -- you can build the various application tiers from services. Folks that built n-tier systems with CORBA or similar service-oriented technology were more likely to use services than most others. But consider the predominant n-tier development environment in use today -- Java EE:

• presentation implemented with JSP/servlets
• business logic implemented with POJOs or EJBs
• data access logic implemented with JPA/Hibernate

I don't see much that looks like SOA in this model.

SOA operates at a significantly different level from n-tier. SOA is focused on reducing the amount of redundancy in the corporate application portfolio. I've said it before: SOA is an enterprise architectural style rather than an application architectural style. SOA doesn't focus on individual application architecture. It focuses on encapsulating discrete functionality into services.

SOA and n-tier architectures have one thing in common -- they focus on separation of concerns. But SOA takes SoC to a new level. I think of it as refactoring application systems. (similar to refactoring code,
but on an enterprise  application architectural level).

As industry experience with SOA matures, I expect we'll start to develop new application architectures that more effectively exploit a development model based on services. SCA is a start, although still
way too immature for prime time. I expect to see some synergy develop among RIA, widgets and gadgets, mashups, composite application development, and services.

I also expect that the concept of "application" is likely to go away. Why is it that we as systems users have to be constrained by the limits of this artificial boundary called an application? Why do I have to shift my focus among multiple applications? Why do I have to copy data from one application to another? Why do I have to launch this stupid browser or that stupid application to get my work done? Why isn't everything just accessible to me from my desktop (via widgets and gadgets) or from within my preferred operating context (e.g., email)? Why can't I just link to whatever I need? (think REST)

Think outside the box!

Chris Haddad talked a little about the need to abandon traditional n-tier concepts and the MVC design patterns in his blog post, MVC Matrix and the Red Pill.We'll be talking a lot more about this next generation application platform this year. Stay tuned.

What are Widgets and Gadgets?

Blogger: Richard Monson-Haefel

In case you haven’t noticed, there have been a lot of new software start-ups and initiatives by major software vendors around the concept of widgets and gadgets. A widget is a small GUI application (both visually and computationally) that provides information on, or an interface to, a very restricted set of functionality or data.

In many ways a widget is analogous to a gage on the dashboard of your car. Just as automobile gages provides information about a single aspect of your automobile (tachometer, speedometer, oil level, gas level), software widgets provide information on a single aspect your personal, public, or enterprise data.

Here is the definition I use for software widgets and gadgets:

A small footprint application that provides relevant on-demand, personalized, encapsulated information from a predetermined data source.

Widgets and gadgets (which I’ll call collectively widgets) got their start in the computing industry back in 1984 when Apple Computer released Apple Desktop Accessories as shown in figure 1.

Microsoft followed suite with their own calculator and clock widgets, but really Apple Desktop Accessories were the first set of software widgets available for mass consumers. These widgets were essentially applications you used to perform minor functions (i.e. calculator).

In 1996 PointCast introduced another pre-cursor to today’s widgets – a set of small applications that provide information from a specific data set in what was called “push technology” (see Figure 2). PointCast went away but the idea that widgets could provide information or an interface to applications whose data is accessed remotely was important.

Also in 1996 and about the time that Microsoft released its first real widget product, Active Desktop, Bill Gates said the following (which may have been somewhat self-serving at the time but is also prophetic).

“the future of computing will revolve around" these small, Internet-connected applications that would live on the desktop, "blurring the distinction" between individual PCs and network and Internet servers.”
Dow Jones International News, Quoting Bill Gates, 1996

Widgets as we know them today and as defined in the definition provided at the start of this article were fully manifested for the first time by a product called Konfabulator (figure 3) for Mac OS X in 2002. Konfabultor was acquired by Yahoo! and became the foundation for Yahoo! Widgets.

Today there are several widget products to choose from all of which promise a dashboard like experience for mass consumers. You can divide widget products into three categories: Desktop Widgets, Web Widgets, and Mobile Widgets.

List 1: Widget Products
Desktop Widgets Engines
• Apple Desktop Widgets
• Yahoo! Widget Engine
• Microsoft Gadgets
• Google Desktop
• KlipFolio Klips
• Opera Widgets
• SpringWidgets

Web Widgets
• Google AdSense
• Flickr
• YouTube
• SnapShots
• LineBuzz
• ClustrMaps
• Microsoft Gadgets

Mobile Widgets
• Openwave Mobile Widgets
• Opera Platform
• S60 Web Run-Time

There are at least seven widget products (see List 1) for the desktop and more are being introduced every quarter. The objective for most of these widget products is to provide services to mass consumers but there is also a growing interest in widgets for enterprise consumers. This would make sense for both tacit workers and developers. For example, developers can use widgets to monitor CVS check-ins or transform binary to Hex. Tacit workers such as sales people might have a widget to monitor updates to client records (Salesforce.com widgets?) or merchandisers might use widgets monitor sales at brick and mortar stores.

Each widget product has its own “widget engine” which is essentially a runtime application that provides a framework for developing, storing, displaying, and updating widgets. Google Gadgets, Yahoo! Widgets, and Microsoft Gadgets are all widget engines. Desktop widget engines are in fact “fat clients” that you install on your desktop – making each widget a “little fat client”. Mobile widget engines are resident applications on the mobile phone. Web widgets also have an engine, but it’s remote. For most web widgets whether its Google Adsense or SnapShots – there is a server application that makes the data you are interested in available.

Ideally you should be able to develop a widget for one engine, say Google Gadgets, and have it work with all the other engines (Yahoo! Widgets, Apple Desktop Widgets, SpringWidgets, etc.), but that’s not the case and it probably will not be for a long time. The impetus beyond creating widget engines (beyond advertising revenue) in the first place is the potential for creating a widget market place where the widget engine vendor acts as the middle man between those creating widgets and those purchasing widgets. Making widgets portable across desktops removes the ability for widget engines to differentiate. Without differentiation there is no reason to choose one widget engine over another.

In the future it seems likely, IMO, that the open source community will develop a widget engine that will initially fail to capture people’s imagination but will eventually become THE platform for mass consumer widgets. The enterprise may also adopt the same open source engine, but that will take more time. For a while, vendors that provide enterprise, communication, collaboration, and content (e.g. Microsoft and Adobe) will dominate the enterprise landscape for widgets.

The fast growing widget industry is really a good thing for consumers. Widgets are lightweight and powerful providing you exactly the information you need and nothing more. Personally, I enjoy using widgets and find them most useful on my iPhone where built in widgets such as YouTube!, Weather, Stocks and Maps have become invaluable.

(Btw - I’m pretty sure that Apple has a plan for a widget engine for the iPhone that will enable third parities to create and sell widgets through iTunes – an idea that was proposed in a conversation among Burton Group analysts. Keep your eyes pealed for that – Ajax is not that last word on widgets for the iPhone.)