Robert Hurlbut's Blog

Benjamin Mitchell has a great post summarizing Clemens Vasters' talk today on managing state across layers.

I found this item most interesting:

Services shouldn't share databases
One of the gems I picked up from the talk was that we shouldn't necessarily tightly couple everything at the database layer by putting it all in one place. Sometimes this is done for speed, but the benefit may disappear if you put it in a cluster.

Benjamin quoted Martin Fowler's post today about this strategy:

Martin Fowler posted about this today:

The recent rise of Service Oriented Architecture seems to mean very different things to different people, but one plausible thread is a rise of autonomous applications with their own ApplicationDatabase that communicate through service interfaces - effectively replacing shared database integration with rpc or messaging based integration. I'm very sympathetic to this view, particularly favoring integration through messaging - which is why I encouraged the development of EIP. In this view of the world the integration database is no longer the default assumption.

Since I work on the development of middleware applications daily, all using central databases, and all of them more-or-less tightly coupled, I found this very intriguing.  You could say it was my “Aha” moment!  I have been reading the SO literature for a little while, and I have been thinking of it as WebServices, even though I “know” its not just WebServices.  But this made a lot of sense to me, along with the rest of Benjamin's post (and Clemens' helpful background reading for this talk).

I don't know yet where this will be used, at least with my own clients, but I can see the possibilities for the changes that will come in the future.

One of the announcements today was the release of the SQL Server 2000 Best Practices Analyzer:

Microsoft SQL Server Best Practices Analyzer is a database management tool that lets you verify the implementation of common Best Practices. These best practices typically relate to the usage and administration aspects of SQL Server databases and ensure that your SQL Servers are managed and operated well.

Download it here.

Notice the requirements:

 Microsoft Internet Explorer 6.0 or later
 Microsoft .Net Framework 1.1

Nice to see .Net as a requirement for SQL tools ...

Aaron posts his notes from Richard Turner's talk on Service Orientation (SO -- notice the “A” has been dropped off now) Prescriptive Guidance.

Some key points I noticed (comments in red are mine):

Why is SO important?

• Services are meant to last. Microsoft is betting the farm on services being everywhere. Indigo is the is one of the most fundamental rewrites in a long time.
• A common tongue is needed for services to interact: boundary, schema, contract, and policy.
• An SO environment extends only as far as we agree on the expression onf the boundary.
• SO systems that want boroadest possible interop will build on the WS-I protocol family.

Which technology should I use and where?

At the service boundary:

• Build services using ASMX (default). Use ASMX at boundaries. (No surprises here)
  • Components should stay within your service boundaries.
  • Closely aligned to SO tenets.
  • Closest alignment with Indigo.
  • Great interop support.
• Use WSE for advanced Web services (WS-* protocols)

Inside the service boundary:

• Consider using ASMX within the service boundary too! (Interesting!)
• Use ES if you need its rich services, want to re-use/extend existing ES/COM+ components, path to "Indigo" from ES.
• (Notice:  Remoting not mentioned ...)

Asynchronous communications:

• Use System.Messaging if you need asynchronous messaging, reliable messaging and queing, "first and forget" messaging. MSMQ is not going away. It's going to be the underlying engine in Indigo.
• The System.Messaging API and namespace does not move forward to Indigo. Indigo navtively supports queing semantics.

Remoting:

• Use remoting where it's absolutely appropriate. Only use it within the service. Great for getting close to the wire. Inproc cross appdomain communications, handling custom wire protocols.
• Remoting is not the fastest for cross machine access, DCOM is the absolute fastest. (This is definitely true.  Yet, ES can be difficult (today), so there may need to be trade-offs until Indigo)
• Avoid exposing remoted components at service boundaries.
• Remoting is an object technology, not aligned with SO principles.
• Limited interop (e.g., only does SOAP rpc/encoded style).
• Limited future migration to Indigo.
• Remoting is not going away. It is moving forward, but there will be better solutions in Indigo.

Caveats:

• ASMX - avoid using low-level extensibility such as the HTTP context model.
• ES - avoid passing objrefs inside of ES (Yes!)
• Native COM+ and MSMQ - use System.EnterpriseServices and
• System.Messaging, do not use native COM+ and MSMQ APIs
• Remoting - avoid low-level extensibility such as sinks and channels

From the RSS feed:

Welcome to Pluralsight - founded by some of the top technical talents in .NET today, Pluralsight focuses on providing in-depth, clear, and thoroughly researched technical content. We are available to develop custom technical content in the form of presentations, training material, or whitepapers. For more information see our content, training, and community pages.

As mentioned before, Pluralsight are Keith Brown, Fritz Onion, and Aaron Skonnard.  Best wishes to all for a very successful endeavor!

By way of Michael Howard:

Finally, it has been posted - Frank Swiderski's Threat modeling tool is now available for free download on MSDN. From the blurb:

The Threat Modeling Tool allows users to create threat model documents for applications. It organizes relevant data points, such as entry points, assets, trust levels, data flow diagrams, threats, threat trees, and vulnerabilities into an easy-to-use tree-based view. The tool saves the document as XML, and will export to HTML and MHT using the included XSLTs, or a custom transform supplied by the user.

http://www.microsoft.com/downloads/details.aspx?FamilyID=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en

This is fantastic news!  I am looking forward to using this while still waiting for Frank's and Window Synder's new Threat Modeling book to ship.  Check out Frank's talk on Threat Modeling at Win-Dev later this year.