Earth and Space Science Informatics at the 2007 Fall Meeting of the American Geophysical Union

In a previous post, I referred to Earth Science Informatics as a discipline-in-the-making.

To support this claim, I cited a number of data points. And of these data points, the 2006 Fall Meeting of the American Geophysical Union (AGU) stands out as a key enabler.

With 22 sessions posted, the 2007 Fall Meeting of the AGU is well primed to further enable the development of this discipline.

Because I’m a passionate advocate of this intersection between the Earth Sciences and Informatics, I’m involved in convening three of the 22 Earth and Space Science Informatics sessions:

I encourage you to take a moment to review the calls for participation for these three, as well as the other 19, sessions in Earth and Space Science Informatics at the 2007 Fall Meeting of the AGU.

Data Points on Tim Bray’s Keynote at CANHEIT 2007

As advertized, Tim Bray gave a keynote presentation at CANHEIT 2007 earlier today (May 29, 2007). And even though I would not describe Bray as an overly dynamic speaker, he certainly did suceed in being entertaining, educating, engaging and thought provoking.

Hopefully, Bray’s presentation will be made available online.

Until it is, you may find the following data points of interest:

  • Bray spoke very highly of RAILS – RAILS in general, and Ruby on RAILS in particular. As a better way of doing things, he suggested that RAILS might even change the way you think about programming. To whet everyone’s appetite, Bray itemized two of RAILS’ principles:
    • Don’t repeat yourself
    • Emphasize convention over configuration

To substantiate his zeal for RAILS, he shared an example of a project that took four months to develop in J2EE; the same project was developed in five days with RAILS! The momentum behind RAILS is also quantified by book sales and attendance levels (in excess of 1,000) at a recent event.

  • Bray also spoke very highly of REST – Even as a Sun employee, Bray was compelled to state that REST may eclipse Java/J2EE in the not-too-distant future. Of course, like many, he suggested that the RESTful approach has already eclipsed Web services. He even shared an image of the WS-DeathStar (Source: Unknown).

  • Bray is contributing to the Atom Project – “Atom is a simple way to read and write information on the web, allowing you to easily keep track of more sites in less time, and to seamlessly share your words and ideas by publishing to the web.” Looks interesting!
  • Bray made use of Apple’s Keynote presentation software – After seeing how Bray and Al Gore made use of Keynote, I broker down and licensed a copy of the software. In both cases, I was struck by the elegant simplicity of their presentations. After all, the purpose of presentations is to communicate. More on Keynote some other time I expect …
  • Bray blogs at http://www.tbray.org/ongoing – Worth reading!

Leveraging Your SOAP Toolkit via the Eclipse Web Tools Platform

Just over three months ago, I wrote:

Because so much value is being driven through SOAP, you must choose your SOAP toolkit wisely. More specifically, toolkit choice will determine, for example, which [Second Generation Web Services] specifications are supported via implementations.

Ultimately, this lead me to suggest that:

Your choice of SOAP toolkit may be the most important decision you make in implementing a Service Oriented Architecture (SOA) based on Web Services.

I still subscribe to this perspective.

Because it’s increasingly unlikely that developers will author SOAP and WSDL documents directly, however, your choice of Integrated Development Environment (IDE) is also increasingly important.

I’m coming to appreciate the value of a solid IDE as I dig into Web services more and more. Of late, I’ve been particularly impressed with the Eclipse Web Tool Platform (WTP).

Stay tuned.

On the Use of Informal Ontologies in the Delivery of Service Oriented Architectures (SOAs)

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.

informal_ontology_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.

What’s in Your SOAP Toolkit?

Your choice of SOAP toolkit may be the most important decision you make in implementing a Service Oriented Architecture (SOA) based on Web Services.

This wasn’t always the case.

For example, First-Generation Web Services (WS-1G) typically depicted SOAP, WSDL and UDDI as more-or-less equal players.

ws_triangle.png

In reality, however, UDDI was and remains (e.g., Erl, Chapter 3) a bit of a non-starter.

WSDL remains key, and continues to evolve with version 2 well on its way to becoming a bona fide standard.

So, what about SOAP?

In learning more about Second-Generation Web Services (WS-2G), I continue to be struck by how much value is being driven through SOAP. In turn then, WS-2G are being driven through XML, as SOAP makes use of XML. It is for reasons like this that SOA-guru Thomas Erl states that SOAs are ultimately all about XML and not Web Services (Erl, Chapter 3, Section 3.5.4).

And this returns us to the point made at the outset.

Because so much value is being driven through SOAP, you must choose your SOAP toolkit wisely. More specifically, toolkit choice will determine, for exanple, which WS-2G specifications are supported via implementations. Even more specifically, as a third-generation SOAP toolkit, Apache Axis2 includes core (e.g., WS-Addressing) and extended (e.g., WS-Coordination, WS-ReliableMessaging, WS-Security, etc.) implementations of a number of WS-2G standards.

SOAP toolkits may also reflect vendor bias. For example, IBM has championed WS-Notification, whereas Microsoft’s emphasis has been on WS-Eventing. These vendor biases at the standards level are quite likely reflected at the SOAP toolkit level. For example, it is reasonable to expect that an IBM SOAP toolkit would include an implementation of WS-Notification, whereas a Microsoft SOAP toolkit would offer one of WS-Eventing instead.

Even though working with SOAP may initially appear a low-level detail at the outset of conceptualizing a SOA, it turns to be a very important consideration that is amplified as SOA adoption proceeds.