Leap Frogs: Mobile Infrastructure

This one is obvious.

Of course, hindsight is 20/20, but the facts have been out there for some time, for those who wanted to look.

In some countries (and some areas in the United States .. have you ever read the details on the Universal Service Charge / Universal Connectivity Fee?), getting a telephone land line can be a challenge. It can take YEARS (and political connections) to get.

There is a technology that makes this a totally irrelevant discussion, and it’s right in the palm of your hand: your mobile phone. Wireless infrastructure can be built out at a tiny fraction of the cost of dragging cable. This technology creates market opportunities .. for the cost of a “few” antennas and repeaters (instead of miles and miles of wire), entire markets can be opened.

Costs can be defrayed too: a Washington Times editorial (from 02/2010) argues to “Kill the Universal Service Fund” as it tends to provide too much money to too few (and potentially inappropriate) recipients. From the editorial:

Rural phone companies see the greatest benefit. In 2008, the USF gave the Oregon Telephone Corporation $16,834 federal subsidy for each of the company’s subscribers in Beaver Creek, Wash. Such largess is especially absurd now that satellite phones can provide service anywhere in the country where one has a clear view of the sky at a fraction of the cost.

The evidence is clear: consider India, where pay-as-you-go mobile phone providers emerge on a moments’ notice .. but with the creative use of SIM cards, you can acquire PAYG coverage wherever you find yourself. If you found that sentence confusing, drop me a line and I’ll point you to resources that will help.

Let’s extend to broadband. There are unlimited providers who offer pay-as-you-go service in a number of countries. Take care with your credit card, though: there are a number of shady folks keen to balance their checkbooks with your cash.

There are heroes too: this chap keeps an eye out for potential villains: suggest you consult him before you consider an provider outside your country.

Why did I compare “Cloud” to “SOA”?

Color me busted. Don’t I look good?

Right after publishing “Is the Cloud Getting ‘Clouded’” I got a ton (well; a lot for me) of email questioning my analogy of “overloaded terms” as comparing SOA to the Cloud.

Some on the mails were from CTO-types and techies of companies with whom I am working (thanks for reading! Click on my ads and buy a lot of something!!).

To avoid giving my opinion multiple times in emails, I’ll state it here. To those of you who emailed me: expect this link when I respond. Please note: this is not by way of defense, but rather of discussion .. I stand ready to receive all flames and pragmatic corrections to my words. With more brains and opinions, we are smarter overall.

First: I am not comparing “SOA” to “Cloud”. Some infrastructure and integration bits aren’t too far off though, a number of parallel technologies and methodologies exist:

  • Remote (from your application perspective) processes and data.
  • Calls made via Web service to gain access to the remote processes and data.
  • Services that expose processes and data on the remote system.
  • Return values from the web service calls.

Your application makes the calls and then acts on the return values to continue the work you need to accomplish .. but that really wasn’t my point.

By way of background, I published “Services Orientation – The Architecture Formerly Known As SOA – Introduction” a few years ago. In this post, I made the statement that I felt the term “SOA” was misused as a noun. I feel SOA to be a paradigm or a methodology, rather than the modified noun usage, e.g., “Our enterprise sports a ‘services-oriented architecture’”.

Yeah: let the grammar police arrest me for nuance. I will smile and nod.

In the same way, the purposes of the “Clouded” post was to point out my feelings that “Cloud” is being misused, although not quite in the same way: Cloud has become the “catch-all” phrase for services in the sky, however, at the 100,000-foot level:

The same “Cloud” (services and storage in the sky via the Internet), but different implementations, requiring different development architectures. However, similar web service access methodologies between the three. Clear as mud? Write me and I’ll connect you to the right folks on our side.

P.S.: On SOA, why just an “Introduction”, you might ask. You might also ask “where’s the rest of the posts”? To be frank: I got busy. By the time I got back to that series, many of the questions I raised were being answered by myself and by others. It is totally my fault for not connecting the bits together. Write me, and I’ll send you links that help, or take a call with you to help sort it.

10 SOA Articles

From the mail bag, Fawcette Publications (aka FTPOnline) sent me 10 Articles about SOA today. I’m passing them along for your review (requires free registration with FTPOnline):

Ensuring Business Agility With SOA
Sonic Software’s Gordon Van Huizen examines two new pillars of software architecture, the enterprise service bus (ESB) and event stream processing (ESP), and how you can leverage them to build the next generation of IT infrastructure.

Get Acquainted With SOA and Indigo
Learn about the core principles behind Windows Communication Foundation’s service orientation (SO), so you can better understand and create service-oriented applications with Indigo.

ESB vs. BizTalk Debate Heats Up in Barcelona
At his Enterprise Architect Summit Barcelona session, conference speaker Dave Chappell got into a heated debate with a couple Microsoft guys over core architectural fundamentals.

How SOA Can Benefit From Active EA Models
Learn how ontology-based EA models enable SOA implementations by providing an active registry of business capabilities.

Stories From the Field: Adoptions of SOA and Web Services
Chris Haddad reviews the decisions made by your peers when prioritizing architecture components, adopting specification standards, and selling SOA to business managers.

Developing a Web Services Security Strategy
Develop an effective Web service security strategy. Chris Haddad provides practical information about security risks, product solutions, and implementation.

Integrate SOA Portals With WSE
Use the ASP.NET 2.0 Web Parts framework and Web Services Enhancements (WSE) 3.0 to create a successful service-oriented architecture portal.

The Importance of Mediation in a Services Network
As an SOA matures and expands, incompatibilities inevitably emerge. They must be managed to achieve your goals.

5 Web Service Architecture Tenets
Use these guidelines to ensure you build successful Web service architectures.

12 Steps Toward SOA
Emerging patterns might help you understand how to implement SOA.

I’ve posted more articles in my Architecture topic.

Services Orientation – The Architecture Formerly Known As SOA – Introduction

This is the first in a series of articles about enabling an enterprise to the Services Orientation model.

We’ve all heard it: Services Oriented Architecture is it; it is “The One”. It is the architecture that will save our skins. It will slice, dice, chop, grate, drop and julienne (that very thin cut; typically for garnish, if you were wondering).

So, you might ask: "What is SOA"? I’d like to answer that, but first, I’d like to tell you what I think SOA is not.

From a technical perspective (and in my opinion), SOA is misnamed. If you think it through, there really isn’t any such thing as a services-oriented architecture per se. Applications are still applications, network protocols are still network protocols, data is, well, you get the drift.

Applications and their interactions represent a logical architecture and data flow. Other pieces of the puzzle represent physical architecture, providing the necessary infrastructure on which applications and data services can live. The design of the data flows and mapping of the logical to the physical is where the potential for services originates.

So, if SOA is the wrong name, what is the right name? While we’re at it, what is a service?

First things first: let’s discuss the name. SOA has become quite a maligned term of late. I place the true intent of “SOA” firmly in the methodology court. That is, defining a “services-oriented methodology” that describes how we would make a data request using a standardized pattern to form the request, and receiving the response data in a standardized pattern for consumption. As there can be many services in an enterprise, this methodology typically demands the use of a services bus, which is a logical transport layer between services and consumers.

The use of the services and bus methodologies creates the opportunity to expose the data from applications of all shapes and sizes (and ages: let’s not leave legacy applications out in the cold; they can play in this realm too), as services.

An application written to conform to a services interface and methodology can be described as being “exposed as a service”. Through this exposure, data contained within the application can be requested and exposed to the enterprise. These services can interact with each other, consuming each others’ output to produce rich enterprise-wide data results.

I’ve covered the methodology; but what is a service? Compare a data service to a service business. A service business accepts requests from customers for particular tasks the business provides; this might run the gamut from legal to janitorial, fast food to buying books online. In all these cases, each business offers discrete services to potential customers. Service businesses must advertise their offerings to make customers aware of the availability.

In this analogy, a data service is the company. Consumers are obvious at the first level (requesting data), but I’ll address primary, secondary and composite consumers in more detail later. The analogy will break down in a few places which include redundancy, consistency, differentiation and advertising.

Let’s isolate the fast food vendor for the moment. In the real world, you have many companies, all competing with each other for customer attention. Multiple fast food vendors offer the same types of services: the preparation of meat, cheese, dough and vegetables, but with differing levels of quality, presentation (burger or taco), availability (scheduled hours or 24-hour drive through), delivery (or pick-up), and so on. Marketing makes the effort to differentiate fast food vendors from each other in the real world, and customers decide how to satisfy their palate for that meal.

Going deeper:

  • Raw materials (meat, cheese, dough and vegetables) are delivered and stored until they’re used.
  • Consumers request specific presentations (burger or taco, depending on the vendor; some may offer both).
  • Consumers pay for their request.
  • Employees prepare the raw materials in accordance with published recipes and guidelines.
  • Employees serve consumers the end product.
  • Consumers consume, and go on their merry way.

So, now we have happy consumers, paying for their food and eating their fill. While most data services won’t require payment, they will require authentication and/or authorization. Payment is essentially a method of authorization: you pay for it, it’s yours.

Authentication is the means to obtain and confirm the identity of the requestor; in the fast food case, it is public and anonymous. Anyone who wants to eat at the vendor and is willing to pay for the food and service can do so. Exceptions include those for whom “No Shirt, No Shoes No Service” or “We reserve the right to refuse service”, apply.

Like a vendor, a data service provides product (result sets or data streams) from raw materials (inputs) and a preparation effort (system processes). The data service authenticates the requestor (some services will be public, others will not) and authorizes the requestor to receive the appropriate level of data.

Follows some of the differences between the fast food vendor and data service:

  • Result set / data stream quality and presentation is always consistent and bound by contract to the consumers.
  • The availability is constant; essentially whenever the system is activated. In a 24/7 system, the service needs to be available all the time.
  • The delivery methodology is always the same: a response to a request from an outside consumer.
  • The service must advertise, but not because of competition. In a good design, a particular data service represents the sole source for the service it provides to the enterprise. But note: the data service advertisement is more like the counter menu at the fast food vendor than a billboard that drives traffic into the store.

Data service advertising bears further discussion. Looking at the counter menu, you see items and prices. The implication is “pay us the printed price for the item”, and we all understand it. If you were to do a menu item nutritional review, you could dig very deeply into what you’re getting for your money, including the number of ounces of meat, cheese, dough and vegetables. If the lookup to the nutritional information represents a return set of data, you could surmise that the inputs are:

  • Item name
  • Cash price

The outputs are:

  • 3 ounces ground beef
  • 1 ounce cheese
  • 2 ounce bun (or tortilla)
  • ½ ounce lettuce
  • 1 ounce tomato
  • 1 serving Thousand Island dressing
  • And so on.

There is no obvious need to extend the counter menu to this level of detail; in fact, we’d all find it annoying. We all agree that the burger (or taco) is a food item, and that it contains the detailed list; even though we don’t need it at our level of consumption.

However, a request to a data service (using a weather metaphor) might include:

  • City code (Seattle)
  • State code (WA)
  • Temperature (could be wind speed and direction, precipitation, etc.)

The result might include (I used comma-separated for the second return example; in a web services world, the two returns would be formatted in XML):

  • String=“The temperature in Seattle, Washington is 60 degrees F, at 12:34pm, June 15, 2004.”
  • Fields=”Seattle,Washington,60,F,12:34:00,20040615”

You’ll note the service returns two data: a formatted string and a series of fields. This gives the consumer some options as to which return to accept and use in their application. The point of this example is to illustrate the negotiation that must go on to adopt a services orientation and methodology; the service must advertise it’s need for three data inputs (city, state and weather data point, in this case, the temperature) and it will return two outputs: a formatted string and a series of fields.

In a web services world, such advertisement can be accomplished in a Web Services Definition Language (WSDL) document, typically available by doing a request of the service root on a web server.

A Note on Web Services
I’ve not delved into web services in this article thus far, and I’ll not start now. There are misnomers about the role web services plays in a services orientation, but the short story is this: web services enable services-oriented methodologies. They are not service-oriented components by themselves. I will address these issues in another article.

This article explains what SOA isn’t, addressing services orientation as a methodology and design practice than architecture. The fast food metaphor is presented as a model that all can understand as to the interactions that go on behind the scenes in the real world and how similarities exist when discussing data services. The weather service example shows a simple input / output / consume scenario that I’ll expand on later.

%d bloggers like this: