InfoQ

News

The Microsoft OBA Framework

Posted by James Vastbinder on Jun 11, 2007 01:03 AM

Community
.NET
Topics
Office Business Applications ,
Enterprise Architecture
Tags
Frameworks ,
OpenXML ,
Microsoft Office ,
Microsoft Office SharePoint Server 2007

Lately Microsoft has been touting a new way to build composite applications that will connect back end Line of Business applications to the front office via Microsoft Office using the acronym, "OBA". OBA stands for Office Business Applications which Microsoft intends as a new framework for developers and ISVs to build applications utilizing Microsoft Office as the entry point.

The intended sweet spot for OBA is within the Lines of Business within the greater Enterprise cloud and will capitalize on the large number of Microsoft Office licenses that have been sold world-wide.

The OBA framework supports Office versions 2003 forward and is accessed via the following integration points:

      - Microsoft Office SharePoint Server (provides a convenient end-to-end Web framework)

      - Open XML (at the document level)

      - Microsoft Office Extensible UI capabilities 

      - Via SharePoint on the server side

      - Via Word, Excel, InfoPath with VSTO

      - MOSS 2007 Business Data Catalog (BDC)

      - Microsoft Enterprise Search

      - Windows Workflow (which shipped in Windows Vista, Office 2007 and the .NET Framework 3.0)

      - Microsoft Dynamics

While this may seem an OZ like scenario to the Microsoft fold, others feel OBA is too little too late. Ephraim Schwartz of InfoWorld wrote:

"Microsoft is trying to say that Office is relevant and that it can become a development platform that can integrate and operate with other vertical applications to create something new. Microsoft hopes that one plus one will equal three."

Ephraim goes on to explain why:

"I think Microsoft is reading the market wrong. OBAs remind me of the old school EAI, enterprise application integration technology while the entire world is moving to an SOA architecture. Mashups can do the same thing and over time I think even the most staid of enterprises will not wait for Microsoft to launch its next OBA RAP solution."

This debate is beginning to heat up with the recent Eweek slideshow titled: "Why Microsoft Ultimately Will Triumph Over Google (and Vice Versa)".

What are your thoughts? Who wins in the clash between Rich Client and Thin Client when building composite applications?

3 comments

Reply

in some ways it just makes sense by Floyd Marinescu Posted Jun 11, 2007 9:23 AM
Re: in some ways it just makes sense by Brandon Satrom Posted Jun 11, 2007 2:05 PM
But in other ways it looks dangerous by Rodrigo Salinas Posted Jun 24, 2007 10:35 PM
  1. Back to top

    in some ways it just makes sense

    Jun 11, 2007 9:23 AM by Floyd Marinescu

    I think using Office as an application client just makes good sense in many areas. Often the business users are already using Office (especially Excel), so letting them stick to their apps of comfort and integrating them into a backend of any technology using the tools MS provided just make sense.

  2. Back to top

    Re: in some ways it just makes sense

    Jun 11, 2007 2:05 PM by Brandon Satrom

    I agree that is does seem to make good sense. Ephraim seems to forget that just "doing SOA" doesn't provide UI's to end-users. He does mention mashups, but I think I agree with Microsoft in their assertion that users would love to use Office apps to perform their work... they already do for that matter. I think Microsoft has a good vision in positioning OBA's as a new "Productivity Tier" of applications which enable the fluid nature of knowledge work.

  3. Back to top

    But in other ways it looks dangerous

    Jun 24, 2007 10:35 PM by Rodrigo Salinas

    Specially now when we are seeing alternative technologies to Microsoft Office System. I have the hope that Google (or any other company) will impose a real alternative to Excel and Word. Just by doing that, by offering an alternative, we have to ask ourselves if we want to invest our time and efforts making a proprietary system to grow, instead of support architectures more independents and interoperables. I would really prefer open standards that allow me to interchange the front-end tools I (or my clients) use.

Exclusive Content

Book Except and Interview : Aptana RadRails, An IDE for Rails Development

Aptana RadRails: An IDE for Rails Development by Javier Ramírez discusses the latest Aptana RadRails IDE, a development environment for creating Ruby on Rails applications.

Fast Bytecodes for Funny Languages

Cliff Click discusses how to optimize generated bytecode for running on the JVM. Click analyzes and reports on several JVM languages and shows several places where they could increase performance.

Scott Ambler On Agile’s Present and Future

Scott Ambler, Practice Lead for Agile Development at IBM, speaks on the current status of the Agile community and practices having a look at the perspective of the Agile’s future.

Manager's Introduction to Test-Driven Development

Dave Nicolette and Karl Scotland try to introduce non-technical managers to one of the most popular Agile development techniques: Test-Driven Development (TDD).

Structured Event Streaming with Smooks

Smooks is best known for its transformation capabilities, but in this article Tom Fennelly describes how you can also use it for structured event streaming.

How to Work With Business Leaders to Manage Architectural Change

Successful architectures evolve over time to meet changing business requirements. Luke Hohmann presents how to collaborate with key members of your business to manage architectural changes.

Colors and the UI

In this article, Dr. Tobias Komischke explains how colors used in a GUI can influence our interaction with a computer and offers advice on using the appropriate colors for the interface.

Building your next service with the Atom Publishing Protocol

In his presentation, recorded at QCon San Francisco, MuleSource architect Dan Diephouse explores ways to use the Atom Publishing Protocol (AtomPub) when building services in a RESTful way.