Another gem from Dave;

This is the main thesis of this article, that the application layer modeling is affected by the underlying protocol.

Absolutely. I think the leaks that Dave so accurately describes there, is, largely, his fault (but a Very Good Thing! 8-). He has tried to respect the architecture of the Web in his work on Web services, and as a result, created the problems he now describes, along with everybody else who ever pushed to defend a principle or constraint of Web architecture, including myself. I was very frankly surprised that it took this long for a Web services proponent to point it out, but I’ve been doing it for a while (and long before that post – it’s just the most succinct description I could recall of the layering problems with Web services, albeit slightly different ones than Dave’s describing).

He goes on…

Another possibility is to throw out anything “extra” from the underlying protocol, that is effectively dumbing HTTP down to UDP.

Yes, that’s the only way that what most Web services proponents know “protocol independence” to mean, could be realized, and the leaky abstractions Dave speaks of, avoided.

The next sentence reads;

Web services using SOAP and WSDL 1.1 has already done that by ignoring the HTTP Operation.

Right. And as I mention in the above mentioned post, there’s more than just the operation which is ignored, including the Request-URI when using wsa:To, and the response code when assuming any response with a SOAP fault element is a fault.

Unfortunately, at that point, Dave apparently reiterates his undying faith in this beast of an architecture, and attempts to resolve this fundamental problem within it. Ouch!

There is another way; embrace the Web.

Oh, and all this reminds me that Steve Vinoski and I just had a great chat where we came to agree on what was and wasn’t desirable to do in the name of “protocol independence”.

Can you think of a cuter way to present a reported breakthrough in storage density improvement?

Hmm, that first character reminds me of somebody… Who could it be? Ah, right; Bill.

Inaccurate (“ruthless disregard for unpleasant facts” seems to be the purvey of SOA proponents), but very funny nonetheless 8-)
(link) [del.icio.us/distobj]
Congrats Roy!
(link) [del.icio.us/distobj]
Not quite a RESTafarian, but a quality post from Anne nonetheless.
(link) [del.icio.us/distobj]

This is too cool.

Here’s Casa Baker. There’s old City Hall in the lower left, Rideau Falls near it, the French Embassy just past the falls, then the big man himself. Just to the right of us on the map, is the Governor General.

Notice too, that you can get driving directions overlayed on the satellite images. Very neat.

“One of the complaints that has been raised by some with regards to the WS-I Basic Profile is that it doesn’t go far enough in reducing choice”. ROTFL! Seriously, that’s funny, ironic stuff. 8-)
(link) [del.icio.us/distobj]

I’m on the PC for the Distributed Objects and Applications conference again this year. I haven’t yet been able to attend (I don’t really “do” conferences anyhow – I prefer to spend my “soft time” doing standards instead 8-), but IIRC, the papers from the last one were pretty interesting. But then, I’m the guy with the “distobj” email address, so that shouldn’t come as any surprise. 8-)

Here’s the CFP;

                         C A L L   F O R   P A P E R S
                         =============================

             International Symposium on
             Distributed Objects and Applications (DOA)
         Agia Napa, Cyprus, Oct 31 - Nov 4, 2005


                      http://www.cs.rmit.edu.au/fedconf/

               Proceedings will be published by Springer Verlag


Some of the world's most important and critical software systems are
based on distribution technologies. For example, distributed objects
run critical systems in industries such as telecommunication,
manufacturing, finance, insurance, and government. When a phone call
is made or a financial transaction performed, chances are that
distributed objects are acting in the background.

Whether you are a researcher or practitioner who is building
innovative distributed systems, evaluating emerging technologies, and
managing large-scale applications, you should consider contributing a
practice report or a research paper to this event to present, discuss
and obtain feedback for your ideas from other practitioners and
researchers active in this area.

Although existing distribution technologies, such as CORBA, DCOM and
Java-based technologies have been widely successful, they are still
evolving and serving as the basis for emerging technologies and
standards, such as CORBA Components, J2EE, .NET, and Web
Services. Regardless of the specifics of each approach, they all aim
to provide openness, reliability, scalability, distribution
transparency, security, ease of development, and support for
heterogeneity between applications and platforms. Also, of utmost
importance today is the ability to integrate distributed object
systems with other technologies such as the web, multimedia systems,
databases, message-oriented middleware, the Global Information Grid,
and peer-to-peer systems. However, significant research and
development continues to be required in all of these areas in order to
continue to advance the state of the art and broaden the scope of the
applicability of distribution technologies.

Two Dimensions: Research & Practice

Research in distributed objects, components, services, and
applications establishes new principles that open the way to solutions
that can meet the requirements of tomorrow's applications. Conversely,
practical experience in real-world projects drives this same research
by exposing new ideas and posing new types of problems to be
solved. With DOA 2005 we explicitly intend to provide a forum to help
this mutual interaction occur, and to trigger and foster
it. Submissions are therefore welcomed along both these dimensions:
research (fundamentals, concepts, principles, evaluations, patterns,
and algorithms) and practice (applications, experience, case studies,
and lessons). Contributions attempting to cross over the gap between
these two dimensions are particularly encouraged.

As we are fully aware of the differences in environment for research
and development that exist in academia and industry, submissions from
each will be treated accordingly and judged by a peer review not only
for scientific rigor (in the case of "academic research" papers), but
also for originality and generality of applications and case studies
(in the case of "case studies" papers).

DOA 2005 is a joint event with two other conferences organized within
the global theme "Integration, Interoperability, and Internet
Computing 2005." This federated event co-locates three related and
complementary conferences in the areas of Intelligent Networked
Information Systems, covering key issues in data and web semantics
(ODBASE'05), distributed objects, infrastructure and enabling
technology and Internet computing (DOA'05), and workflow, cooperation,
and interoperability (CoopIS'05), as required for the deployment of
Internet- and intranet-based systems in organizations and for
e-business. More details about this federated event can be found at
http://www.cs.rmit.edu.au/fedconf.

TOPICS OF INTEREST

The topics of this symposium include, but are not limited to:

    * Adaptive distributed object and component systems
    * Aspect-oriented approaches for augmenting distribution technologies
    * Application case studies of distribution technologies (e.g., CORBA,
Java-based, .Net, and Web Services)
    * Applications and evaluations of the Model Driven Architecture approach
    * Component-based software development
    * Design patterns for distributed systems
    * Distributed business objects and components
    * Distribution technologies for embedded systems
    * Interoperability between object systems and complementary technologies
    * Management of distributed systems
    * Mobility in distributed systems
    * Real-time solutions for distributed objects
    * Relationship to peer-to-peer technologies
    * Scalability for distributed objects and object middleware
    * Security for distributed object systems
    * Service oriented architectures
    * Solutions for (massive) caching and replication
    * Specification and enforcement of Quality of Service
    * Technologies for reliability and fault-tolerance
    * Web-based distributed objects
    * Web Services


IMPORTANT DATES

  Abstract Submission Deadline   May 24, 2005
Paper Submission Deadline May 31, 2005
Acceptance Notification August 10, 2005
Final Version Due August 25, 2005
Conference October 31 - November 4, 2005

SUBMISSION GUIDELINES

All submitted papers will be carefully evaluated based on originality,
significance, technical soundness, and clarity of expression. All
papers will be refereed by at least three members of the program
committee, and at least two will be experts from industry in the case
of practice reports. All submissions must be in English. Submissions
must not exceed 18 pages in the final camera-ready paper
style. Submissions must be laid out according to the final
camera-ready formatting instructions and must be submitted in PDF
format.

The final proceedings will be published by Springer Verlag as LNCS
(Lecture Notes in Computer Science). Author instructions can be found
at:

http://www.springer.de/comp/lncs/authors.html

Failure to comply with the above formatting instructions for submitted
papers will lead to the outright rejection of the paper without
review.

Failure to commit to presentation at the conference automatically
excludes a paper from the proceedings.

ORGANISATION COMMITTEE

General Co-Chairs (fedconf@cs.rmit.edu.au)

    * Robert Meersman, VU Brussels, Belgium
    * Zahir Tari, RMIT University, Australia

Program Committee Co-Chairs (doa2005@cs.rmit.edu.au)

    * Ozalp Babaoglu, University of Bologna, Italy
    * H.-Arno Jacobsen, University of Toronto, Canada
    * Joseph Loyall, BBN Technologies, USA

Local Organising Chair (skevos@cs.ucy.ac.cy)

    * Skevos Evripidou, University of Cyprus

Publicity Chair (bright@cs.pdx.edu)

    * Laura Bright, Portland State University, Oregon, USA

Program Committee Members (incomplete list)

    * Cristiana Amza (University of Toronto, Canada)
    * Matthias Anlauff (Kestrel Institute, USA)
    * Mark Baker (Independent consultant, Canada)
    * Guruduth Banavar (IBM, USA)
    * Alberto Bartoli (University of Trieste, Italy)
    * Judith Bishop (University of Pretoria)
    * Gordon Blair (Lancaster University, UK)
    * Harold Carr (SUN, USA)
    * Shing-Chi Cheung (Hong Kong University of Science and Technology,
Hong Kong)
    * Geoff Coulson (Lancaster University, UK)
    * Francisco "Paco" Curbera (IBM, USA)
    * Wolfgang Emmerich (University College London, UK)
    * Patrick Eugster (EPFL, Switzerland)
    * Pascal Felber (University of Neuchatel, Switzerland)
    * Kurt Geihs (Universitaet Kassel, Germany)
    * Jeff Gray (University of Alabama at Birmingham)
    * Mohand-Said Hacid (Université Claude Bernard Lyon 1, France)
    * Franz Hauck (University of Ulm, Germany)
    * Peter Honeyman (University of Michigan, USA)
    * Rebecca Isaacs (Microsoft Research, USA)
    * Mehdi Jazayeri (Technical University of Vienna, Austria)
    * Bettina Kemme (McGill University, Canada)
    * Fabio Kon (University of São Paulo, Brazil)
    * Peter Loehr (University of Berlin, Germany)
    * Frank Manola (Independent consultant)
    * Francois Pacull (Xerox, France)
    * Simon Patarin (University of Bologna, Italy)
    * Rajendra Raj (Rochester Institute of Technology, USA)
    * Andry Rakotonirainy (The University of Queensland, Australia)
    * Luis Rodrigues (University of Lisboa, Portugal)
    * Rick Schantz (BBN, USA)
    * Douglas Schmidt (Vanderbilt University, USA)
    * Richard Soley (OMG, USA)
    * Michael Stal (Siemens, Germany)
    * Stefan Tai (IBM, USA)
    * Hong Va Leong (Hong Kong Polytechnic University, Hong Kong)
    * Maarten van Steen (Vrije Universiteit, The Netherlands)
    * Steve Vinoski (Iona, USA)
    * Doug Wells (The Open Group, USA)

Imagine it’s 1997, before REST or SOA were crafted.

What architectural constraint goes in the middle box?

“Every time you wanted to configure a new service intermediation, you’d have to custom describe the API.” What Phil seems to be missing is that RESTful intermediaries all have the same interface.
(link) [del.icio.us/distobj]