Clemens blogged the Microsoft EMEA Architect’s Journal a couple weeks ago. In addition to his article on dasBlog, issue 1 contains articles on SOA, architecture design, business process, meta-data driven design and rule-based application development. You can download the entire issue as a PDF. Major props to Arvindra Sehmi, editor of the Architect’s Journal. When I first took this job, Enrico Sabbadin suggested that MSDN Magazine should have a regular architecture focused article. I think we will all agree that Arvindra’s journal dedicated to the topic is an even better idea.

Going forward, my group will be working Arvindra’s group to help publish the journal. It’s interesting to note that none of the six articles in issue 1 are written by Microsoft architects. While I hope to see some articles written by Microsoft architects, the plan of action is to primarily feature architects from our partners, our customers and from the community. Anyone interested?

After reading Sam’s slides on Atom, Scoble posted three times about how syndication could evolve. Of course, Scoble has his Longhorn-colored glasses on. Dare pointed out that “The major problems with syndication today have little to do with the syndication format and more to do with it’s associated technologies.” I agree with Dare. IMO, the only thing that the ATOM syndication format has over RSS is a namespace declaration. I care about that because one of the “associated technologies” I care about is SOAP and the lack of an RSS namespace makes it hard to embed an RSS item inside a SOAP message.

I think Scoble should be asking how syndication will evolve in the face of Service Oriented Architecture in general, not Longhorn specifically. Granted, Indigo is going to make Longhorn a great platform for SOA. (If you check out the Longhorn Interoperability and Migration Guide, Chapter 2 is mostly dedicated to describing SOA.) But I think the real change to syndication is going to come from WS-ReliableMessaging. In order to truly evolve syndication, I think we need to break free of the synchronous polling model we have today. Polling only works in scenarios with a central syndication source (like a weblog). However, as the sources of syndicated content get to be more distributed (phones, P2P networks, etc) that polling model breaks down. I need to be able to send messages when things change without regard to network availability. With WS-RM, I can send messages and the infrastructure (i.e. Indigo) can take care of the ugly details of making sure the messages get delivered to their final destination.

There’s a new Pattern and Practice out: Application Interoperability: Microsoft .NET and J2EE. This is complementary to the .NET and J2EE Interoperability Toolkit by my teammate Simon Guest.

FYI, I have links to many of the Patterns and Practices under “Architecture” on my Linkroll. This new one is under “Guidance”. There are also sections for Application Blocks, Lifecycle Management and Patterns.

I’m supposed to be on vacation, but it doesn’t look like this news has hit the blogosphere. Ward Cunningham, inventor of the Wiki and general pattern wonk, has joined Microsoft. He’s got a wiki page up for tips. I got to meet him on Tuesday and promised not to blog his arrival until he posted it on his site. Welcome Ward! I’ll be doing some very cool things with him, but more on that later. In the meantime, check out Testing Software Patterns on the MSDN Architecture Center.

Speaking of wikis, the source code FlexWiki, another .NET based wiki, is available online. I need to dig thru FlexWiki to see if having DevHawk Wiki around anymore makes any sense.

SQL Service Broker is probably the least known new feature of SQL Server “Yukon”, but I can’t wait for it. It makes messages a first class object in the database. If you’ve ever had multiple processes banging on your database or you’ve ever used a flag on a row to indicate if it’s been processed or not, you want SQL Service Broker too.

While there is huge disagreement as to exactly what “Service-Oriented Architecture” is, I think there is some general consensus around the fact that it is an asynchronous message driven model rather than a synchronous RPC model. This means that the thread you receive a message on will never be the same thread that you process the message on. In fact, typically you will write the message to a persistent data store (hello, Yukon native XML support) in order to be handled by a thread in a different process and probably on a different machine. Today, kicking off the thread to handle the message is a pain in the ass. You probably want lots of threads across lots of machines to handle the incoming messages (assuming you’re getting lots of incoming messages). In order to synchronize message processing across machines, you need a mechanism to make sure each incoming message is handled once and only once. Today, the closest solution is message queue technology like MSMQ (or MQSeries). However, since that’s a different data store from where the data lives (i.e. the database), now you need two phase distributed transactions to get that done. However, since messaging is going to be such a huge piece of architecture going forward, it makes sense to have the concept of messages baked right into the database.

With Service Broker, when the message is received, it is placed into a service broker queue. (It’ll probably get stored for archival and retry avoidance reasons, but that’s a different blog entry.) Now I can have processes that, within the scope of a local transaction, receive the incoming message, make whatever data changes that message implies and send off any new messages. This is both more productive (manually handling local transactions for async processing is this kind of a scenario much easier than using serviced components) as well as more performant.