In Service-Oriented Architecture: Concepts, Technology and Design, author Thomas Erl frames ontologies (section 10.2) in a top-down strategy for the delivery of a Service Oriented Architecture (SOA) .
As the first step, in a multistep process, what starts with ontologies ultimately results in a Contemporary SOA (Erl, section 3.2.20):
Contemporary SOA represents an open, extensible, federated, composable architecture that promotes service-orientation and is comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reuable services, implemented as Web services.
SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains.
SOA is an evolution of past platforms, preserving successful characteristics of traditional architectures, and bringing with it distinct principles that foster service-orientation in support of a service-oriented enterprise.
SOA is ideally standardized throughout an enterprise, but achieving this state requires a planned transition and the support of a still evolving technology set.
In the same chapter, Erl also provides an abridged Contemporary SOA definition:
SOA is a form of technology architecture that adheres to the principles of service-orientation. When realized through the Web services technology platform, SOA establishes the potential to support and promote these principles throughout the business process and automation domains of an enterprise.
In other words, buying into the top-down strategy can ultimately result in a Contemporary SOA and this is a big deal.
Erl also discusses the bottom-up strategy for delivering a SOA (section 10.2).
In striking contrast to the top-down strategy, and as Erl describes it, the bottom-up strategy does not incorporate ontologies. Despite the fact that “… the majority of organizations that are currently building Web services apply the bottom-up approach …” (Erl, pg. 368):
The bottom-up strategy is really not a strategy at all. Nor is it a valid approach to achieving a contemporary SOA. This is a realization that will hit many organizations as they begin to take service-orientation, as an architectural model, more seriously. Although the bottom-up design allows for the creation of Web services as required by applications, implementing an SOA at a later point can result in a great deal of retro-fitting and even the introduction of new standardized service layers positioned over the top of the non-standardized services produced by this approach.
After reading this chapter, one is left with the impression that Erl favors the agile strategy (Erl, section 10.4) as it attempts “… to find an acceptable balance between incorporating service-oriented design principles into business analysis environments without having to wait before introducing Web services technologies into technical environments.”
I would be willing to accept all of this on spec if it weren’t for the fact that it’s possible to create informal ontologies, in non-SOA contexts, during bottom-up processes.
And if this is possible in non-SOA contexts, then it’s reasonable that informal ontologies could be incorporated into the bottom-up strategy for SOA delivery.
I believe this is worth exploring because use of informal ontologies in a bottom-up strategy for SOA delivery may improve the potential for ultimately achieving a Contemporary SOA. (An outcome, you’ll recall from above, Erl stated wasn’t otherwise acheiveable.)
I also believe this is worth exploring as, as Erl states, most organizations are attempting to gravitate towards SOAs from the bottom up.
Because the agile strategy (ideally) combines the best of both the top-down and bottom-up approaches, I also believe it’s worth exploring the potential for informal ontologies in this case as well.
Although further research is required, the figure below extends Erl’s Figure 10.3 (pg. 367) with a first-blush suggestion of how informal ontologies might be incorporated into the bottom-up strategy for SOA delivery.
It’s important to note that Erl’s original figure illustrates a five-step process that culminates with “Deploy services”.
Based on work I’ve done elsewhere, in this first-blush depiction, I believe the steps required to make use of informal ontologies would need to include:
- “Extract service relationships” – In the work I’ve done elsewhere, this extraction has been achieved by Gleaning Resource Descriptions from Dialects of Languages (GRDDL). GRDDL extracts relationships and represents them in RDF from XML via XSLT.
- “Generate informal ontology” – These days, ontologies are often expressed in the Web Ontology Language (OWL). OWL is a semantically richer and more-expressive variation of XML than is XML. Much like the previous step, the generated informal ontology is expressed in OWL via processing that would likely make use of XSLT. This step might also involve the need to incorporate annotations.
- “Integrate informal ontologies” – Because each act of modeling through deploying application services will result in an informal ontology, there will eventually be a pressing need a integrate these informal ontologies. This ontology integration, which may also involve top-down or formal ontologies, will provide the best possibilities for ultimately realizing a Contemporary SOA.
Even at this early stage, the use of informal ontologies in the delivery of a SOA appears promising and worth investigating.
My Palm didn’t have one. Neither does my BlackBerry. And it doesn’t look like the highly anticipated iPhone will either.
What don’t these handhelds have?
A USB port.
In fact, I don’t know of any handheld that has a USB port. (Of course, I’d be delighted to be proven wrong.)
Why do I care?
Well, sometimes, I have an real (air) or perceived (too-much-effort-required) gap between my laptop and some way of getting Internet connectivity.
For example, I may be at my cottage where my only option for Internet access is a 28.8 kb/s modem connection. Or, I may be at an airport, with only a few minutes before my flight departs, and my only option for Internet connectivity is a daily pass to some wireless service.
In these and other situations, I wish my BlackBerry had a USB connection. If it did, I’d have a painless way of moving data between my laptop and BlackBerry. In my cottage scenario I want to use my laptop to review, create or edit documents and my BlackBerry to transport them via email.
To some extent, I could achieve the desired outcome for the cottage scenario using the Bluetooth capabilities of my laptop and BlackBerry.
In addition to transferring data, I could use a USB-enabled BlackBerry to:
- Back up to the USB drive my data from my BlackBerry
- Update the O/S and/or applications on my BlackBerry
And this is just scraping the surface of possibilities …
So again, I ask: Why doesn’t my handheld have a USB port?
I think I first ran across Chris Anderson’s The Long Tail last Summer while blogging on blogging as a writer’s tool.
I’ve finally gotten around to reading Anderson’s book.
Anderson ends his first chapter with the following paragraph:
When you can dramatically lower the costs of connecting supply and demand, it changes not just the numbers, but the entire nature of the market. This is not just a quantitative change, but a qualitative one, too. Bringing niches within reach reveals latent demand for non-commercial content. Then, as demand shifts towards the niches, the economics of providing them improve further, and so on, creating a positive feedback loop that will transform entire industries – and the culture – for decades to come.
I’m still internalizing this, so I’ll reflect more before adding my $0.02. At this point, I just thought it was a quote worth sharing.