Editor's Note

Patents Present New SOA Vulnerability

The BlackBerry case highlights issues that affect all of us.

In a case of good old-fashioned brinksmanship, Research in Motion (RIM) narrowly averted having its popular BlackBerry messaging service shut down recently over patent infringements.

Patent infringement cases are nothing new; indeed, they are a hazard of operating a technology company of any significant size in the digital age. It's not inconceivable that a little-known patent from an unheard-of company could completely alter how a given company, or range of companies, does business tomorrow.

Microsoft, IBM, Intel, Unisys, and others have been embroiled in significant cases where patent infringements have been alleged, often with significant ramifications to those who use their products and services.

There is a temptation to think that cases like this affect only the "big fish," but issues like these affect all of us. Companies of nearly every size incorporate BlackBerry devices into their overall Exchange communications systems, and the disruption would have been significant had RIM been forced to discontinue its BlackBerry service.

It's possible that other companies could and would have stepped in to fill the niche supplied by BlackBerry, but these other companies might have been vulnerable to patent-infringement charges themselves.

The narrowly averted crisis highlights an area of vulnerability in service-oriented architectures. In many respects, the world that has been envisioned—where you build apps from an agglomeration of services, your own and others—is occurring. One of the concerns announced when the services model was being pushed initially was how to handle the fact that your app is only as reliable as your least-available service. If you build functionality on top of a critical service that isn't available when you need it, you can find yourself facing unacceptable downtime.

Service providers have been stepping up to the plate in this regard, providing redundancy for critical services. And businesses that rely on SOA-based apps have adapted to this by building in backup systems, where possible, to account for a service that might suddenly become unavailable. Apps today are commonly constructed to account for disruptions. For example, an app might be designed to proceed without a given service it relies on, queuing the work that needs to be done until the service is available again. You'd expect this to happen in a service-oriented environment, and businesses have been finding creative ways to address these kinds of issues.

But the BlackBerry incident points to a different kind of vulnerability, one that might be considerably more difficult for your business to anticipate and/or work around: What if a type of service you've built your application around becomes suddenly unavailable, not for a short while, but indefinitely, and for the foreseeable future?

Businesses of all types and sizes have incorporated the BlackBerry service. If BlackBerry had been taken offline, the communications systems built up around it would have had a gaping hole. You might argue that the nature of BlackBerry service means that companies might have adapted to the situation by doing without—the kind of service provided by BlackBerry is a relatively recent capability, and companies could return to the way they conducted their communications previously. That's small comfort to the companies that must suddenly find a way to work around this disruption, or that might wonder if a key part of their communications infrastructure will no be longer available to them.

More importantly, the next service that is affected by this kind of disruption might be something even more critical to how your applications or business processes work. Therefore, in addition to building your application around the idea of service redundancy and availability, you should also look at the possibility that a given service—even a service you've created internally—might be suddenly unavailable for reasons that you couldn't have envisioned at the time you constructed that application.

You might need to ask yourself: How would I design the application if this piece were suddenly unavailable? Or its companion piece? It might seem absurd to envision a given, critical aspect of your application suddenly becoming unavailable, but you ignore what just occurred with BlackBerry at your own risk. Considering how you might adapt to this situation at the time you create your app will save you an enormous headache later on.

About the Author

Patrick Meader is editor in chief of Visual Studio Magazine.

comments powered by Disqus

Featured

  • Build Your First AI Applications with Local AI

    "AI right now feels like a vast space which can be hard to jump into," says Craig Loewen, a senior product manager at Microsoft who is helping devs unsure about making that first daunting leap.

  • On Blazor Component Reusability - From Day 0

    "We want to try to design from Day One, even Day Zero, with reusability in mind," says Blazor expert Allen Conway in imparting his expertise to an audience of hundreds in an online tech event on Tuesday.

  • Decision Tree Regression from Scratch Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of decision tree regression using the C# language. Unlike most implementations, this one does not use recursion or pointers, which makes the code easy to understand and modify.

  • Visual Studio's AI Future: Copilot .NET Upgrades and More

    At this week's Microsoft Ignite conference, the Visual Studio team showed off a future AI-powered IDE that will leverage GitHub Copilot for legacy app .NET upgrades, along with several more cutting-edge features.

  • PowerShell Gets AI-ified in 'AI Shell' Preview

    Eschewing the term "Copilot," Microsoft introduced a new AI-powered tool for PowerShell called "AI Shell," available in preview.

Subscribe on YouTube