thinking-out-loud

Dissecting Infosets

Mark Nottingham digs in on Infosets, and offers some interesting insight. Count him Thought Leader in my book.

He provides some thoughts about the infoset that echo some undercurrent feelings I have about it, but of course, he has actually turned into quite a nice essay. The first and the last sentence of this excerpt do it for me.

To sum: Xml ain't all that great for data modeling, but the readability sure is nice.

And I quote:

I’m forming a belief that the complexity of the Infoset as a data model forces an unwelcome choice upon its users:

1) You can describe your format in terms of the Infoset, and therefore get easy human-readability and writability, while getting a lot of baggage as part of the bargain. I believe that a lot of the problems evident in the use of XML Schema and XML itself have their root in this complexity.

2) Or, you can layer a model on top of the Infoset that explains how format-specific components are serialised into XML. This is great for particular formats, but a fair amount of work. For example, WSDL 2.0 defines a component model that gets serialised into XML; the markup is still very human-readable, and the model is clear. However, it takes a fair amount of work to do this, and it’s very tricky to get the full benefits of Infoset-layer mechanisms like Schema in your component model.

3) The other option is to layer a generic model on top of the Infoset. This is the approach that RDF/XML takes; it insulates the data model from the XML serialisation, and as a consequence loses much of the intuitive readability of XML. Ask anybody about RDF, and they’ll tell you that they love the model, but hate the syntax.

The root of this, I think, is that XML was first and foremost a markup language, not a data modelling language; we’ve seen a number of attempts to layer something more appropriate on top of it (e.g., SOAP encoding, RDF/RDFS, XML Schema, etc.) but the human-readability draws people back to the Infoset level every time.
I’m forming a belief that the complexity of the Infoset as a data model forces an unwelcome choice upon its users:

1) You can describe your format in terms of the Infoset, and therefore get easy human-readability and writability, while getting a lot of baggage as part of the bargain. I believe that a lot of the problems evident in the use of XML Schema and XML itself have their root in this complexity.

2) Or, you can layer a model on top of the Infoset that explains how format-specific components are serialised into XML. This is great for particular formats, but a fair amount of work. For example, WSDL 2.0 defines a component model that gets serialised into XML; the markup is still very human-readable, and the model is clear. However, it takes a fair amount of work to do this, and it’s very tricky to get the full benefits of Infoset-layer mechanisms like Schema in your component model.

3) The other option is to layer a generic model on top of the Infoset. This is the approach that RDF/XML takes; it insulates the data model from the XML serialisation, and as a consequence loses much of the intuitive readability of XML. Ask anybody about RDF, and they’ll tell you that they love the model, but hate the syntax.

The root of this, I think, is that XML was first and foremost a markup language, not a data modelling language; we’ve seen a number of attempts to layer something more appropriate on top of it (e.g., SOAP encoding, RDF/RDFS, XML Schema, etc.) but the human-readability draws people back to the Infoset level every time.

Pub/Sub, REST style

This is the second time I have run across pubsub.com, and it seems interesting and relevant to some of my recent posts, so here you go. They have a RESTful service api for pub/sub rss news feeds. Very cool. I want to take the time to dig in to their API, but I am tired.

So tired.

WSE, WS-Addressing, SoapMail

I recently posted about WSE, transports, and MOM. I am making some good progress on implementing messaging transports and a router implementation using the WSE 2.0 Tech Preview.

I got snagged a bit on getting the WS-Addressing right, and searched for some refs. I remember reading that Aaron Skonnard had a recent, relevant article over at the Web Services Developer Center, so I hopped on over and had a peek. It definitely helped, and it also referenced another article by some of the WSE team on implementing an email-based soap transport and email->http soap router.

Hmmm.

Particularly relevant. Why didn't I see this before?

A little disappointing, too. I was thinking that I might implement an smtp based transport for an article. I'll still probably do it, because I wanted to implement the server side smtp for grins. The smtp and pop approach is definitely more firewall friendly, and you can use your existing, scalable mail infrastructure. You do have a scalable mail infrastructure, don't you?? I mean, everyone does, right??

It is chock full of lots of fun sample code, and I definitely recommend checking it out. Of course, if you are in the know, you probably read it back in October, so forgive me for being out of the loop.

Indigo and the Four Tenets

Several Microsoft Bloggers have been spreading their meme of the Four Tenets of Service Orientation. As Alan Kay once said, "The best way to predict the future is to invent it." MS is pushing the four tenets like your first, free rock. Like em or not (confession: I do, especially lately), MS are going to be a huge player in the SOA space by virtue of the fact that their platform will be dripping of the stuff in the next few years. If you are an enterprise architect or an integration architect, you are going to be using it, dealing with it, loving it, loathing it.

Some of the foundational discussion for the four tenets (as far as I know) are in Don Box's PDC 2003 presentation and this earlier referenced article on developing services in Indigo.

Don (can I call you Don? Great. Jef. Please call me Jef.) waxes historical and analogical on DCE RPC/MSRPC and the separation between contract and localization of that contract to an implementation.

Rich Turner (666) has a series of posts on service orientation, and he dives a little deeper into the four tenets. For autonomy, he states:

Why are these services Autonomous?

Either Service’s location can change at (almost) any time due to the fact that they’re dynamically addressable

The services communicate through dynamically negotiated communications channels that support the necessary formats and capabilities (security, reliability, etc)

Neither Service requires knowledge of each others’ internal workings in order to exchange data – they only need the published schemas & contracts

Neither party make demands on each other as to how the work is carried out

For Explicit Boundaries, Expensive Traversal, he argues:

A communications channel is dynamically negotated between Services based upon Policy which of course requires some work, the speed of which process is gated by the slowest party in the negotiations. And let's not forget the physical aspects of data marshalling, buffer copying, passing through the network stack, serializing onto the wire, navigating ethernet to the other end of the wire and then bubbling back up through all the network, OS and platform stacks.

A couple of non-but-definitely-pro MS guys, Benjamin Mitchell and Clemens Vasters (I am glad to see the alien abductions are back), provide more insight as well. Benjamin here. Clemens here.

Clemens has coined PEACE as a mnemonic device for the four tenets:

Policy-Based Behavior Negotiation
Explicitness of Boundaries
Autonomy
Contract
Exchange

Reminds me of "COM is Love." Only not as much zen.

VS.NET 2005

Microsoft recently released another alpha preview of Visual Studio 2005. I ran across this the other day on somebody's blog, but I didn't take the time to mindlessly propagate it then, so consider it propagated. If you have an MSDN subscription, you can download it now, but fair warning, the image is 2.7G. Yes. Gig. The image is a DVD image, but ISO buster can help if you don't have a suitable burner.

I could have known about it as soon as it happened if only I had have subscribed to their rss feed.

I am very excited to see the latest bits for Indigo. I went to an MS South-Central Architect's Council meeting last night, and we were entertained with the wit and witticism of David Chappell. He did a presentation titled "SOA: What's Next?" The presentation bits didn't really say anything new, i.e.

• Services aren't new, but they're better.
• SOA is the way of the future.
• SOA is a foundation for BPM.
• Biztalk is a great platform for SOA and BP.
• Indigo is the way of the future

He personally made up for the fact that the presentation was a little vanilla. We had a fairly lively discussion around the notion that Indigo was going to "VB" distributed computing by making so easy that people were almost guaranteed to screw it up, ala getting and setting properties on distributed objects.

An interesting note: The vast majority of the companies that Mr. Chappell talks to are not using SOA outside their firewall. A small handful of people in the room, however, said that they were. He commented that that was the largest positive response he has had to the question of inter-enterprise soa.

After the talk, we had dinner and an informal, roundtable discussion that was as much if not more engaging than the presentation, discussing a wide range of problems from SOA to BPM to pushing dirt with tractors. Thanks Raj. It was a good time.

Integration Patterns

If found this Microsoft document on Integration Patterns interesting in the context my recent work related to constructing an Integration Competency Center for the implementation of an Enterprise SOA.

Business Drivers for Enterprise SOA

Geniant’s white paper on Service Oriented Architecture started me thinking about the business drivers to E-SOA. They mention flexibility and efficiency, but I think there’s another “value add” happening, too.

Flexibility – by abstracting away from the implementation of business processes, the organization has more freedom to choose an implementation without impacting the client application.

Efficiency – by developing skills around standards and well-known techniques, the organization gets better reuse of knowledge at the application, application infrastructure, and technical infrastructure levels. Also, by using mechanisms supported by the IT industry at large, teams can incorporate work done by other organizations, resulting in more gain for less effort.

Other added value – the organization can introduce new capabilities into the SOA and reap the benefits everywhere. This is like efficiency, but it’s bigger. It means the ability to leverage new and existing assets enterprise wide. Of course, there’s significant effort to wrapping a capability in a generic service interface, but the possibilities of benefiting from it in more than one place can change the economics involved, and potentially make worthwhile a generalization effort that wasn’t previously.

Are there other facets of business value involved?

IT, meet Business

Software dorks are all about patterns. I received my copy of Design Patterns: Elements of Resuable Object-Oriented Software in January 1996 when I started working at ObjectSpace [the best job I have ever had, amazing people, had a problem called "business direction of the month", hit the pooper, R.I.P.]. An early history from Kent Beck's perspective provides some insight into the early patterns movement (I Am Behind Yet Another Thought Leader Entry).

For me, especially at that time, the Design Patterns book is worth the entire price just for section 1.6 in the introduction. Back then, I committed the 24 (23? Yeah... 23) patterns to memory, and could recite them chapter and verse. I occasionally still check to see if I can even name them all from memory.

I seldom can. My memory stinks. For instance, I just tried to iterate the Creational Patterns, and I remembered Factory Method, Abstract Factory, and Prototype, but neglected to remember Builder and Singleton, even though one of my favorite refactorings is "Remove Singleton." But I have google, so all is good.

It always surprises me which ones I have forgotten, and they are often ones that I use without thinking today (e.g. the beloved Template Method). And when I go back to the book (or the table of contents on amazon), and realize which ones I forgot, my mind harkons delightfully back to geeky times of applying the pattern in this or that project, or teaching this or that pattern in ObjectSpace's OO analysis and design course, and I would realize that I am a DORK. That would trigger an ADD-like episode in which I remember feeling a sense of solidarity at the end of Revenge of the Nerds, where Louis "comes out" about being a nerd and being damn proud of it.

Or something like that.

Forward to Present: Patterns are spreading like wildfire, and they aren't limited to Christopher Alexander and the architecture or Gamma, Beck and the software monkeys. For instance, I was recently doing some research on Porter's Value Chain, and I ran across Mercer Management's profit patterns recently. The PP are a collection of business strategy patterns that cover value chains, customer, product, knowledge, channel, organization, and "mega" categories of patterns. They also drill down and expand on brand patterns, variants of their "Product to Brand" pattern.

Now.

All of that to say, enterprise architecture was conceived as a means to align what IT does with what Business does and wants to do. Now, as with most grand schemes, many every enterprise architecture efforts failed-and-how. Each time they failed, the next generation explained away why they failed in terms of problems for which said new generation now how solutions. Of course, those had better success, but ultimately, did not achieve the lofty goals laid out by the calling of enterprise architecture, as a recent BPTrends article by David Ritter on enterprise architecture discusses:

To understand how Enterprise Architecture has matured, it is helpful to look at how Enterprise Architecture has been utilized in the past. Enterprise Architecture efforts were almost always driven by the IT organization. Not surprisingly, these Enterprise Architecture efforts focused their attention on developing an inventory of IT assets, and the tools employed to capture these Enterprise Architecture models were system modeling tools that focused heavily on collecting technical system artifacts. This thorough analysis of system and technology components did allow Enterprise Architecture teams to reduce the complexity within their IT organization. Enterprise Architecture projects frequently achieved operational efficiency benefits, such as standardizing technology platforms or eliminating incongruent systems. However, the ultimate goal of business and IT alignment was seldom achieved.

Well, folks, we are on the new, false horizon. That doesn't mean we shouldn't try to crest it.

SOA, MDA, DSL, BPM -- All of these are solutions looking for problems, and none of these is the silver bullet. But they are more and better tools in our toolkit, and they make it possible to get our heads around larger problems. Of course, as another brilliant Thought Leader once wrote, "By solving problem number 1, you promote problem number 2." The next wave will come, and we'll try to deal wth it, and our hindsight will elucidate the failures of the above-mentioned TLAs, and we will woefully regret the mistakes.

For the aspiring or otherwise enterprise architect, it behooves you to gain a base understanding of how your business people think about the problems your business addresses, so that you can align your IT efforts with their needs and you can speak their language. Read the profit patterns. Read business books. Get an MBA. Find out write drives your business. Meet them more than halfway.

WSE 2.0 Channels, Services, and MOM

Herveyw provides detailed insight into the WSE 2.0, in particular discussing changes to the underlying messaging channel model.

In the article, he discusses how transport semantics are not leaked up to the channel level. It begs the question of whether or not the parallel tranport/channel heirarchy in the Microsoft.Web.Services.Messaging namespace has been tamed. It seemed like the majority of the necessary concepts were there in the tech preview modulo a bit of massaging (i.e. SoapChannel, ITransport, IFormatter). When I first saw the class reference doc, I wondered why there were transport specific channel implementations given an ITransport abstraction. Performance maybe.

I have been interested in this thread, because I want to implement mq and msmq as transports for the services in the systems that I am working with. I want the consumers and providers to have to do as little as possible to leverage MOM to provide "guaranteed," idempotent delivery. In researching the options, I ran across the following articles that were of interest.

• The first article demonstrates extending the ASP.NET framework (System.Web and friends) to provide MQ and MSMQ transports.
• The second article demonstrates extending the WSE 2.0 technology preview to provide an MQ transport. It should be trivial to extend it to support MSMQ given the working MQ example.
• Additionally, Kevin Hammond has been working with the WSE team to implement MQ and MSMQ transports, and according to Herveyw that has had a signficant impact on the channel redesign.

For my project, I am prescribing that in the context of a service-oriented architecture, message-oriented middleware should be a transport that is bound to. Service providers and consumers should not know the difference (Within Reason-caveat lector).

There is a good wiki on Parallel Inheritance Heirarchies on the c2 site. Speaking of c2, I have a Thought Leaders entry I need to add.

SOA: What, Why, How

Geniant has published a white paper on SOA.

Full disclosure: I used to work for Geniant, and I am hopeful that they will be a very successful company some day.