I am actually not a fan of individuals posting aggregated feeds, but I found a set of posts tonight that all hit around my areas of interest. This will not be a common occurrence for me, as I am posting these mainly as a selfish set of pointers.
- For those that have been putting off looking at Indigo for awhile, there is a sample chapter of an upcoming book, “Inside Indigo“ on MSDN.
- Klaus posts on including a service layer in the more traditional layer stack (Presentation, Service, Business, Data). This was an interview question for a position as an architect, and we debated the merits of this approach versus the implicit tradeoffs.
- Owen Allen states that the RTM of BizTalk 2004 will be available to MSDN subscribers on March 2nd.
- Paul Wilson has been doing a lot of spelunking with the Garbage Collector in .NET. Rather than link to all of the posts, just look at Paul's February posts.
- Dare comments on Cazz' question of XSD as a type system. Is there an impedance mismatch when considering the serialization aspects of XmlSerializer alone, or should we further consider the schema as the type basis for a message contract? For the former, XSD and CLR typing are simplistic, but the latter seems to spark many of the issues that Dare lists.
- Dr. Rys is posting on moving FOR XML Explicit to the new PATH mode. Bryant Likes, the SQLXML guru, follows up here and here.
- I know this has been posted a lot, but for posterity I wanted to keep a pointer: Benjamin M has a diagram of the progression of connected systems
- On xml-dev, Michael Kay and Kurt Cagle take opposite approaches on the relative approachability of XSLT and XQuery. Oleg questions Kay's statement.
- Clemens tries to clarify the terms “Component” and “Service” for the general developer's lexicon. Good luck, since SOA right now seems commonly defined as “Web Services.“
And one of my new favorite reads, Matt Powell, has a great post on when to (not) consider SOA:
Zapthink wrote up an article on when SOA is not a good idea. This is their list of when SOA is not a good idea:
- ...when you have a homogeneous IT environment
- ...when true real-time performance is critical
- ...when things don't change
- ...when tight coupling is a pro, not a con
Of course the real message here is that
- Okay...the one company that has a homogeneous IT environment, you don't need SOA.
- Okay...some specific robotic control systems don't need SOA
- Okay...hmmm...I guess those folks who are still using Multiplan and Wordstar don't need SOA
- Okay...when you specifically don't want any of your systems to integrate with any other systems then you don't need SOA.
So all six of the people who the above rules apply to - they don't need SOA.
The rest of us should probably look pretty closely at SOA.