Calendar

March 2024
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031

September 6, 2005

Bay Area visit

Filed under: Uncategorized — Mark Baker @ 4:34 pm

I’ll be down in the Bay Area for a few days, arriving next
Wednesday, September 14th.

On the 14th, I’ll be attending (though arriving late) the
SDForum “Web Based Architectures: Where do we go from here?” in Palo Alto. The next day, I might (still working it out) be giving a talk at CommerceNet on (working title), “RESTful advice for AJAX developers”. The following week, I’m at
Oracle OpenWorld at Moscone, for a client. I return the morning of the 23rd.

Please feel free to drop me a line if you’d like to get together to talk integration.

• • •

August 9, 2005

W3C CDF WG posts first draft of compound document framework specification

Filed under: integration,webarch — Mark Baker @ 12:31 pm

After several months of work, the W3C Compound Document Formats WG has published the first draft of the specification of the base framework and profiles.

This is important work with broader applicability than might seem initially apparent, as although the objective of the WG is to focus on visual formats such as HTML, SVG, and others, the framework should be reusable for non-visual languages in many cases.

As a member of the WG (representing my client Justsystem), the part of the spec that consumed most of my time was the base framework, and in particular specifying how to bind it onto the existing Web in order to maximize its generality as well as the probability of success. This is a lot harder task than it seems, as demonstrated by the fact that this version of the draft asks more questions than it answers about this issue. But that’s ok, it’s still early in the process, and I’m confident that there’s a fruitful way forward. Please though, if you have some experience in the XML-meets-MIME/media-types space, we’d love to hear what you have to say.

• • •

July 18, 2005

Towards truly document oriented Web services

Filed under: webarch,webservices — Mark Baker @ 11:26 am

In the beginning

For much of the first year or two in the life of Web services – and indeed all of their
history up to that point
they were about remote procedure calls (RPC); exposing remote APIs across the Internet in order to facilitate machine-to-machine communication and ultimately, business-to-business integration over the Internet.

It didn’t take very long however, for Web services proponents to realize that they needed to distance themselves from RPC and its well-deserved reputation as a poor large scale integration architectural style, due to the failure of systems such as CORBA, DCOM, and
RMI to see any widespread use on the Internet. So, sometime in 2000/2001, collective wisdom in the space shifted towards a preference for “document oriented” services. Vendors quickly jumped on board with upgraded toolkits, and that was that; documents were the New Big Thing.

Unfortunately, the basic architectural assumptions underlying Web services at the time, didn’t change nearly enough to distance Web services from the problems of RPC.

What is “Document oriented”?

Respected Web services guru Anne Thomas Manes
succinctly (and unknowingly, it appears)
describes the differences between RPC and document orientation;

Document style:

<env:Body> 
    <m:purchaseOrder xmlns:m="someURI"> 
      ... 
    </m:purchaseOrder> 
  </env:Body>

RPC style:

<env:Body> 
    <m:placeOrder xmlns:m="someURI"> 
      <m:purchaseOrder> 
        ... 
      </m:purchaseOrder> 
    </m:placeOrder> 
  </env:Body>

The bigger difference is how you encode the message. […]

While the encodings used were certainly different, each with its own not-insignificant pros and cons, what Anne failed to point out is that the RPC example included an operation name (“placeOrder”) while the document oriented example did not. This constitutes an extremely significant architectural difference, as it tells us that Anne’s document example uses a state transfer style, while the RPC example does not.

State Transfer

State transfer styles, which include
MOM,
EDI,
pipe and filter
and others, are characterized primarily by one architectural constraint; all the components expose the same application interface. Actually, in most cases, including those three, the application interface is constrained to providing a single operation that one might call “processData” (it’s actually called “putData” in that pipe-and-filter description). Each server component exposes this operation, enabling any client to submit data to it for processing. In addition, because there’s only one operation, its use is implicit and therefore needn’t be included in the message.

Allow me to reiterate my main point; Anne’s document oriented example above includes an implicit (“processData”) operation.

REST

REST – REpresentational State Transfer – is, as the name suggests, also a state transfer style. One of the interesting ways that REST differs from the others, is that rather than constrain the interface to the single “processData” operation, it allows any operation which is meaningful to all components (referred to as the “uniform interface”). An interesting side-effect of allowing more than one operation, is that it requires messages be explicit about the operation in use, since there obviously needs to be a way to disambiguate messages with the same document, but different operations.

HTTP is the application protocol most closely associated with REST, largely because it was developed to respect many of REST’s constraints. As it related to the uniform interface and explicit operations, HTTP provides a “POST” operation which is an alias for the aforementioned “processData” operation. So, back to Anne’s example again, this HTTP message is semantically identical to her document oriented example;

POST some-uri HTTP/1.1
Host: some-host.example.org
Content-Type: application/x-purchase-order+xml

<env:Body> 
    <m:purchaseOrder xmlns:m="someURI"> 
      ... 
    </m:purchaseOrder> 
  </env:Body>

Moreover, note that if the HTTP operation were different – say, if it were “PUT” instead of “POST” – then the message would no longer have semantics identical to Anne’s original document oriented example. Yes, this means that the semantics of the message are a function of the application protocol being used, unlike conventional wisdom with Web services which suggests that message semantics should be “protocol independent”.

Conclusion

Hopefully this little note helps put in context the architectural relationship between the Web and document oriented Web services. The relationship is closer than it appears in some important ways, yet more distant in others, likely as a result of the fact that Web services began with RPC, rather than with a truly document oriented architectural style. Perhaps spelling this out explicitly, as I hope I’ve done here, will help more Web services proponents realize the importance of the Web to their objectives of integrating systems across the Internet.

• • •

July 14, 2005

Indigo supports REST

Filed under: Uncategorized — Mark Baker @ 9:27 pm

Dare Obasanjo reports
that Indigo will include support for RESTful service development! A very welcome move indeed.

It will be interesting to see how the APIs deal with specs such as SOAP and WS-Addressing which can be used RESTfully and non-RESTfully. It seems to me that the worst thing that could happen for developers, would be to have two completely independent API packages with little or no significant overlap; a message is a message, after all.

• • •

July 12, 2005

JBI for document oriented integration?

Filed under: architecture,integration,webarch,webservices — Mark Baker @ 3:07 pm

When it was first announced last month, I had a quick look at JBI to see if they were making some of the same problems I perceived in the architecture of Web services. I caught a glimpse of figure 3 in section 4.1 where it describes a WSDL-based RPC messaging model, and immediately concluded it was misdirected.

The next week at JavaOne, I ran into Mark Hapner, and we had a talk about SOA, document orientation, REST, and JBI. It was a long, in-depth, thought-provoking talk that left me realizing, amoung other things, that this guy really gets document orientation. I’m not sure he fully appreciates the relationship of it to REST, but he completely understands what it means to do distributed computing with documents. As we were wrapping up, he surprised me by saying that JBI was developed, at least in part, with document oriented and RESTful uses in mind, and that he’d be interested in my thoughts on it. So, hear I am, having a deeper look into JBI.

Ok, so having read pretty much the whole thing (minus the APIs and management stuff), I’m not seeing the document orientation friendliness in JBI at all. The container architecture seems reasonable and could support it, but as it also supports the WSDL messaging model – in my opinion, an anathema to integration – perhaps it suffers from the far too common problem of trying to be all things to all people.

I guess I’m with Don Box on this;

I’ve always believed that the Java folks found the sweet spot with the Servlet+JDBC combination back in the 1990’s

• • •

July 5, 2005

Planet Web 2.0

Filed under: Uncategorized — Mark Baker @ 1:57 pm

Coactus is honoured that its weblog has been chosen to be integrated into the Planet Web 2.0 feed. Thanks to Ian Davis for his good taste in content. 8-)

• • •

Rhode Island Government Web Services

Filed under: integration — Mark Baker @ 10:13 am

Jeff Barr reports on the Rhode Island Government Web Services effort.

It’s another example of “Accidentally RESTful”, so I hope they take care to evolve this application in the future. But there’s no missing the RESTful, integration-centric objectives of the project. In his blog post announcing it, S. James Willis writes;

Web 2.0 applications lean towards making small pieces of data available to users in such a way that the data can easily be married to other small pieces of data from disparate sources.

• • •

June 24, 2005

Web page as contract

Filed under: integration — Mark Baker @ 12:22 pm

It’s these kinds of integration tensions that remind me why I love the Web so much.

So, apparently, Google went and updated its GMail site, which caused a bunch of Greasemonkey scripts to fail. Conspiracy theories ensued.

Dare Obasanjo takes an extreme position on the issue;

Repeat after me, a web page is not an API or a platform.

It might be extreme, but I think it’s also a reasonable position, as I expect practically all Web developers would laugh out loud at hearing that somehow the form of the HTML they write is supposed to be, in some manner, “consistent” between versions. But I feel it important to note that HTML pages do, in practice, have some important “platform” qualities.

Consider CSS style sheets, and how they bind to HTML pages through the use of selectors and the cascade, both of which use information in the HTML; change the HTML in an “inappropriate” way – changing something that the CSS was depending upon – and whammo, broken Web site.

I hear you saying, “That’s different!”. Yes, it is, to a large extent. The HTML and CSS are authored by the same person (or at least are under the control of a single entity), so the interface between them does not constitute a public platform, just a private one, providing value in the form of a separation of concerns – and the resulting improvement in reusability – to site authors.

But then again, not all style sheets are created equal! Consider user style sheets, created by the end user for their own benefit, and applied by the browser on their behalf without any involvement of the server. For example, a visually impaired user could use them to increase the size of all fonts. As can be seen by some examples though, they’re typically very generic, and so commonly use type selectors, since they are generic to the HTML language, not specific to any site. And that’s certainly a best practice that I think is worth calling out;

For maximum reuse, depend only on the language, not on the form of any particular instance of that language

So, as I see it, this is all part of the ongoing battle between the Gods of Literature; the writer, and the reader. That relationship is incredibly dynamic, at least on a Web-historic time scale, with each side constantly pushing for more control. While I doubt there’s any balance to be found there, in either the short or long term, I would say that it’s interesting to observe that recent initiatives such as Greasemonkey, Google Autolink, and even microformats (by virtue of the information they add to a page making it more reusable for readers) are finally giving the reader their due after years of largely appeasing the writer.

Update; here’s yet another example of this same tension.

• • •

June 8, 2005

Names and testability

Filed under: webarch — Mark Baker @ 9:32 pm

In an article titled SOA by any other name, Phil Wainewright discusses the confusion with the term “SOA”;

The only reason for using these phrases is if they help establish shared meaning that allows people to effectively exchange information and constructively expand their knowledge.

No matter what position you take in the SOA vs. REST debate, I think you really have to respect that “RESTfulness” is testable, and in fact that the probability of any given architecture or architectural style being tested in the affirmative, is very small, something the Third Law of Thermodynamics tells us is desirable. If practically every distributed infrastructure ever developed is an SOA, then the term is of no value, either when trying to communicate with somebody else, or when designing a distributed system.

• • •

SOA for SMBs?

Filed under: integration — Mark Baker @ 2:10 pm

Joe McKendrick reports on a Webservices.org survey which shows that small to medium sized businesses aren’t doing SOA. No surprise there, really, since the cost of all this new Web services software, and the complexity of the architecture, is so high.

Perhaps somebody should ask those businesses if they’re exchanging any data with anybody (customers, partners, service providers like banks, etc..), over the Web? I’d expect the numbers would be quite high, probably higher than for SOA in big business.

• • •
« Previous PageNext Page »
Powered by: WordPress • Template by: Priss