|
>
 Friday, October 14, 2005
Saturday, September 24, 2005
 |
|
 |
|
|
|
|
|
Keving Boyle, one of my local Microsoft Architect Evangelists makes an interesting observation here...
http://blogs.msdn.com/socalarchitect/archive/2005/09/23/473399.aspx?CommentPosted=true#commentmessage
and I'm not surprised because I still hear from a lot of companies that need to get started with Web Services 101. SOA just sounds like this big huge ominous endeavor if you listen to all the buzz out there...yet it should be very simple in my opinion.
OOP to classes is like components to applications is like services to systems
The question is of when an “application“ becomes a system, and that is a question of composition, complexity and distribution.
Notice you did not see the term “web services“ above. Web services are NOT a requirement of SOA, there are an interoperability facilitator.
Enterprise systems should be designed so that major chunks of functionality can be moved, distributed, refactored, replaced with alternate application or vendor sources...without tumbling down the entire system. Today's system is no longer a single monolithic endeavor by a single vendor. We are now in the business of building composite systems that comprise many applications or feature sets that are respectively built by appropriate domain experts. So, systems must be sure that major sources of functionality are not tightly coupled. Major features become “services“. Each “service“ can receive inputs, or return outputs...and everything that happens in the middle should be completely independent of the rest of the application (black box). That means I should be able to move the service to another machine, another vendor and still have things work just fine so long as the location can be found. So, a service is designed to use its own tables, configure its own file IO directories, and manage all other resources needed to perform its function. That does not mean there is a different database for every service in an application. It just means that the service is programmed not to depend on another services table structure. Use the same database, use a different database, it should not matter to the application as a whole because the service maintains its own configuration.
Consider this progression.
An application that logs incoming Web service requests, records a transaction, and shoots off a request to generate a PDF from the XML.
The functionality that logs messages doesn't have to be on the same tier, and the application may leverage another application to do the work...therefore that is a service (logically speaking):
The transaction logging activity is a core part of the application, but could later be distributed therefore that can be considered a logical service as well. In particular the PDF generating functionality could receive XML inputs, and be considered a separate service as well:
But, let's not think small. This entire system could be considered a service to another application that requires PDF generating and transaction reporting activities. In this example, the system is a certificate issuance system (from a system I designed for the insurance industry years ago) - so that would be the purpose of this interoperable service endpoint:
SOA is an approach to system design that has been implemented in systems of many differing technologies in the past, that makes a business more agile. New technologies are making SOA easier to implement, Web services make SOA interoperable, but it is really about designing enterprise systems so that there is an appropriate level of configurability and reuse at the outer "service" or "functionality" layer.
Indigo (WCF) will just make the implementation of services a natural part of system development.
What do you think? Is SOA too confusing?
|
|
|
 |
|
 |
Wednesday, September 21, 2005
Saturday, June 11, 2005
Saturday, March 26, 2005
|
|
|
|
|
|
|
|
|
In this talk I discussed architectural approaches to address incremental steps to scaling .NET applications.
Here are my references for this talk, thanks for coming out:
- HTTP Handler references:
- Here’s my scalability page that takes you to my MSDN article discussed in the session, and other resources on scalability:
- I also wrote some articles for The Server Side.NET regarding distributing components and security. Find those and more security resources here:
|
|
|
|
|
|
|
Monday, March 21, 2005
Wednesday, January 12, 2005
|
|
|
|
|
|
|
|
|
Tonight was my turn to present as part of Regional Directors presentation month in southern california. Tim Huckaby presented at the San DIego .NET Developer's Group last week, I presented to the VBUG in Orange County (with a good collection of C# UG members also present), and Paul Sheriff is next, presenting to the San Diego .NET User Group the last week of January.
Tonight I test drove my latest materials on .NET 2.0 ClickOnce and related subject matters for Smart Clients such as offline connectivity and data storage, versioning and deployment, security evaluation and elevation, and so forth. The slide deck is in PPT format here:
versiondeploysmartclient20.zip (979.02 KB)
Related links I showed at the end of my talk:
http://www.idesign.net - See some of the .NET 2.0 webcasts delivered by my colleagues
http://www.dotnetdashboard.net/sessions/versiondeploy.aspx - see my resources on .NET 1.1 versioning and deployment
Other Microsoft resources for smart clients:
http://www.windowsforms.net
http://msdn.microsoft.com/smartclient
|
|
|
|
|
|
|
Thursday, January 06, 2005
|
|
|
|
|
|
|
|
|
On Tuesday night this week I volunteered to do the 101 talk for the .NET Developer's group, before the famous and infamous Tim Huckaby did his killer, wicked Visual Studio Tools for Office (VSTO) presentation.
For my talk, I took a much deeper, advanced talk I do, which articulates 10 steps to versioning and deployment success, and I basically c-o-v-e-r-e-d t-h-e f-i-r-s-t b-u-l-l-e-t w-e-r-y w-e-r-y s-l-o-o-o-w-l-y to turn it into 1 hour of deep discussion on the subject of strong names, their value from a security and versioining perspective, some of the pains of using them, and some demonstrations to go along. The complete list of materials for this subject can be found on my versioning and deployment resource site:
http://www.dotnetdashboard.net/sessions/versiondeploy.aspx
The next time I do a 101 talk for this group, if Dave and Woody invite me back ;), I'll move to bullets 2 and three of the 10 step presentation...and so on, and so on, and so on...
What are the 10 steps I discuss in the advanced talk?
- 1.Use strongly named assemblies
- 2.Think before you GAC
- 3.Covet all private keys
- 4.Get to know Code Access Security
- 5.Evaluate runtime security requirements
- 6.Run with least privilege
- 7.Protect your intellectual property
- 8.Master assembly versioning
- 9.Design a deploy/upgrade strategy
- 10.Prepare for future of .NET
Enjoy :)
|
|
|
|
|
|
|
Wednesday, November 24, 2004
|
|
|
|
|
|
|
|
|
Glad to see everyone last night at this presentation, it was quite enjoyable, great questions from the audience as well which always makes my day! Here's the link to the site with access to my slide deck and other resources:
http://www.dotnetdashboard.net/resources/scalability.aspx
You can get the Enterprise Services sample from there, and a reference to my article which provide more detail. In addition, I demonstrated some asynchronous handler examples, but I found a great article from Fritz Onion on the subject, so here's the link to his article with access to his samples for the article, that will be even more detailed from that I demonstrated:
http://msdn.microsoft.com/msdnmag/issues/03/06/Threading/default.aspx
If you are new to handlers, check out my handlers page, with reference to some other articles I've written as well:
http://www.dotnetdashboard.net/sessions/handlers.aspx
Enjoy!
|
|
|
|
|
|
|
Saturday, November 13, 2004
|
|
|
|
|
|
|
|
|
Thanks to everyone who attended my talk at VS Connections this week in Vegas, despite the temptation to hit the Casino instead! You may have noticed my site was actually down all week, I had to move it to a new location, and I thank you for your patience.
Here's the link to my Versioning and Deployment Resource page which you may have already visited (that site wasn't down). I have updated the site with new content, however, so check it own again and let me know if you have any questions.
http://www.dasblonde.net/PermaLink.aspx?guid=17d12fa3-59c9-4c49-9cc6-9b62f959df19
Also, don't forget to check out the slides for my talk, there are many links in there to other resources.
Nostrovia!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I recently wrote up an article that discusses best practices for versioning and deployment of .NET components. In the article, and in my sessions on this subject I emphasize code access security, running with least privilege, versioning issues, publisher policies and more. Check it out here: http://www.15seconds.com/Issue/041103.htm
On a related resource page, you can find the tutorial I wrote for the code sample: http://www.dotnetdashboard.net/sessions/versiondeploy.aspx
This month, you can expect an article explaining .NET runtime security and sandboxing.
Cheers!
|
|
|
|
|
|
|
Saturday, October 16, 2004
|
|
|
|
|
|
|
|
|
Thought I'd christen my newly repaired blog (crossing fingers) with a new post about Service Pack 1 for the .NET Framework 1.1 - which has been available for over a month now (yes, I have been busy):
SP1 - http://www.microsoft.com/downloads/details.aspx?familyid=A8F5654F-088E-40B2-BBDB-A83353618B38&displaylang=en
Yesterday I finally had a chance to update my machines and take a closer look. Ironically, on the same day I had a fantastic conversation with Vivek Nirkhe from the VS 2005 Team System group ( http://lab.msdn.microsoft.com/vs2005/teamsystem/ ) on the issues of versioning; updating assembly version versus file version; and best practices for build process to handle distribution during development, the pass to QA and final release. He was kind enough to provide feedback on some of my concerns about SP1.
Much to my surprise, SP1 doesn't version the updated .NET Framework assemblies, which happen to contain a long list of fixes. My immediate thought was:
Why aren't they versioning their assemblies and shipping a publisher policy?
A publisher policy makes it possible for you to deploy updated assemblies to the GAC, and all installed applications will automatically bind to those updated assemblies. UNLESS, they override policy in their own app.config file. Therein lies the problem, according to the following blog post by Junfeng Zhang on the subject:
http://blogs.msdn.com/junfeng/archive/2004/10/11/240822.aspx
In summary he states:
- The service pack is security related, and we don't want customers to opt-out by publisher policy override
- The main reason for the concern in #1 is because through publisher policy override you must specify which assembly to override. Since SP1 includes multiple files, it is possible that applications will forget to include ALL of the assemblies in the override, and thus create a situation where some assemblies are 1.1, others SP1.
Ok, so this is a good call, because we all know this would happen and create a support nightmare. But, this exposes an inherent limitation to assembly versioning in .NET 1.1, which I have spoken about in some of my talks on the subject.
Assembly redirection, publisher policy overrides, and related assembly binding concepts can be configured in XML, through the local app.config or web.config for particular applications and subdirectories. But, you have to specify individual assemblies one-by-one even if you are configuring a single policy that should apply to multiple assemblies. If you miss one, time to trouble-shoot. But, if all SP1 files all carry the same version number, and no other group of updates carry that number, then shouldn't it be possible to specify a publisher policy override in one fell swoop, by identifying the version number the override applies to?
My wish list on this subject:
- Make it possible to deploy a publisher policy-like DLL to my local app.config, that supplies a binding policy that could group a number of assemblies and policies in a single DLL. Easier than an open XML config file that can be edited, and less error prone because it can be tested and deployed to clients.
- With this, SP1 could have updated version, shipped a publisher policy, and provided a publisher policy override in assembly format for anyone to override just in their application. They might need to do this, if for example they need some time to update fixed to their application for the service pack. I know, it is supposed to be backward compatible, however sometimes clients depend even on bugs in previous versions, for their code to work...strange and lame, but true.
- With this, deployment of fixes to local applications not installed in the GAC could include policy DLLs instead of hand-rolled updates to the local app.config/web.config. What if the customer has edited those config files? That means our installations have to edit the config, not ship a new one. This is painful. Let me ship a DLL that specifies a policy.
We don't have these options today, readily available, so they made the right choice for SP1 and vendors will have to make sure their apps function against it. And, there are plans to improve the versioning and deployment of framework vs. application assemblies in the future. Find out more in this insightful article by Cathi Gero and Jeffrey Ritcher:
http://www.theserverside.net/articles/showarticle.tss?id=AssemblyVersioning
So, the dogfood is just ok, and that's why with SP1, MSFT opted out of eating it. For single-assembly updates, it tastes a little bit better.
|
|
|
|
|
|
|
Wednesday, September 22, 2004
|
|
|
|
|
|
|
|
|
This entry has references for both of my talks at SD Best Practices (www.sdexpo.com) in Boston this week. I apologize that the slide decks are not on the conference CD, however I was invited to cover another speaker, therefore my materials were not part of the materials submission deadline as they were different talks from those originally scheduled.
I have added some supporting resources to the link below, related to security as well. Enjoy!
http://www.dotnetdashboard.net/resources/scalability.aspx
THank you for attending both talks, and please email me with any questions we could not get to within the timeframe.
|
|
|
|
|
|
|
Thursday, September 16, 2004
|
|
|
|
|
|
|
|
|
Tonight I delivered a speech to the Orange County Architecture User Group in Irvine, CA. I definitely enjoyed all the great comments and questions from the group, thanks for attending the talk everyone!
Here is a link to my presentation slides in PDF format:
http://www.dasblonde.net/downloads/versiondeploybestpractices.zip
Some of the items mentioned during the talk:
And, here is a link to my versioning & deployment page:
http://www.dotnetdashboard.net/sessions/versiondeploy.aspx
On this page you'll find sample code with a detailed script that takes you through many of the demonstrations I showed tonight, in a single sample. Also in there are steps for versioning and handling publisher policy, but I have more links to add to this site when I post my slides. Stay tuned.
-------------------------------
NOW - I invite you to tell me your versioning and deployment pain points, I have many code samples, references and other resources and may not be organized on my site at this time...but if you ask for something that will give me incentive to post it. Tell me what you want to hear more about...
|
|
|
|
|
|
|
Saturday, July 24, 2004
|
|
|
|
|
|
|
|
|
Some great discussions are going on regarding the choice of Enterprise Services, .NET Remoting and Web Services for .NET applications. I'm adding on, so sit yourself down...this has really long blog written all over it...
|
|
|
|
|
|
|
Friday, July 02, 2004
Thursday, June 17, 2004
|
|
|
|
|
|
|
|
|
In many presentations of late I have mentioned to folks the preference of Enterprise Services over .NET Remoting. In part to reduce the risk associated with rolling your own security model across boundaries (among other things), and due to the fact that the Indigo team at Microsoft recommends Enterprise Services as the way to build your component architecture today, to better migrate to Indigo tomorrow.
Here are some references I found on the subject on Rich Turner's blog (he's a PM) and a video on the MSFT site. If I find more, I'll add to comments. If you have your own proof, or have questions/concerns on this subject, YOU add to comments :)
Cheers.
|
|
|
|
|
|
|
Wednesday, June 16, 2004
|