News

Analyst Looks at Mashups vs. SOBAs

Mashups need to get serious and take a lesson from SOBAs if they're to succeed in the world of enterprises.

The Web 2.0 era has ushered in mashups, the practice of stitching together applications from a collection of existing -- and usually Web-based -- assets.

These days, one can hardly launch a browser without tripping over a passel of mashups like EarthAlbum, which slaps together content from photo-storage and mapping sites to create on-demand visual tours of the world.

Cool stuff, for sure. But it's an open question how the mashup concept can be applied to business-critical functions within enterprises, where the concerns go well beyond gee-whiz functionality to include questions of governance, security and availability.

Analyst Jason Bloomberg of ZapThink LLC, a consulting group focused on service-oriented architecture (SOA), is set to deliver a talk on mashup-style development and the enterprise at the upcoming SOA World Conference & Expo, scheduled for June 25-27 in New York.

Bloomberg draws a line between consumer-oriented mashups and service-oriented business applications (SOBAs), and argues that while mashup principles have their place within enterprises, serious challenges await any effort to implement them.

What's the difference between a SOBA and a mashup?
They're sort of coming from different worlds. A SOBA is essentially a composite application composed of business processes. It comes from the SOA world. A mashup is essentially a collaborative app within a rich Internet application (RIA) environment.

What challenges do corporate dev shops face in implementing mashups?
The first is loose coupling. If you're mashing up services and something happens, your mashup's going to break. It's one thing to say my pizza-Google map mashup broke, [because] no one cares. But if it's your call center app, that's a different story. You need that loose coupling to support services throughout their full lifecycle.

The other is governance. Mashups give users the capabilities that previously have been reserved for IT. But if you give them the capability without guidelines on what to do, they're just going to go off half-cocked.

You have to have that governance framework in place so people who are doing the mashups can only follow the rules. Without SOA, mashups are toys. Without governance, mashups are dangerous.

Ideally, who within an enterprise should be creating mashups? A developer? An IT administrator?
If you have a mashup tool, it's not that the tool is for one kind of person, but rather that depending on the policy it gives different capabilities to different people. A call center rep may not have any capabilities, but an IT person would have a much broader set. For the most part, even the best mashup tools are still for technical people. Over time it'll be as easy to use a mashup tool as Microsoft Excel. We're just not there yet.

About the Author

Chris Kanaracus is the news editor for Redmond Developer News.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube