.NET
.NET
It seems that the .NET Framework will be included in the Windows XP SP2. It would be really nice. Look at this article on "The Register" (last paragraph) : http://www.theregister.co.uk/2004/05/13/xp_sp2_rollout_impends/
The final version of the excellent guide "Improving .NET Application Performance and Scalability" has juse been released on MSDN ! IT'S A MUST READ ! GET IT NOW !
As I mentionned it in many of my previous posts, I'm currently working on a personal project. Since it's going to manage a lot of informations, tables of my database have a pretty big number of columns (like 30 columns)... I know what you're going to tell me : Normalize your database ! Of course I did and it's normalized, but these 30 fields really are native properties and core data of my entities.
Since the application will have a lot of users and a real need of scalability, I was wondering if 30 columns in a table is a problem or not... Does it have any consequences at the performance level ? If so, I guess I would have to normalize a bit more, but another problem appears here : over-normalization which is also a performance degradation cause... Do you guys have any advices about that ?
During the development phase of your BizTalk orchestrations, it's pretty long and boring to continuously deploy / undeploy your assemblies in the GAC and BizTalk Engine. So, here is a pretty usefull command script to automatically deploy or undeploy your assembly :
DEPLOY.CMD :
@SETLOCAL
@CALL "%VS71COMNTOOLS%vsvars32.bat"
@SET AssemblyKeyFile=MyProject.snk
@SET SolutionName=MyProject.sln
@SET AssemblyName=MyProject.Orchestration
@SET BizTalkPath="C:\Program Files\Microsoft BizTalk Server 2004\"
@ECHO.
@ECHO If key file is not found, will generate a new key file...
@IF NOT EXIST %AssemblyKeyFile% sn -k %AssemblyKeyFile%
@ECHO.
@ECHO Building solution...
@DevEnv %SolutionName% /Build Development /Out Build.log
@ECHO.
@ECHO GAC and deploy the Assemblies...
@BTSDeploy DEPLOY Assembly=%AssemblyName%\bin\Development\MyProject.Schemas.dll Install=True Log=Deploy
@BTSDeploy DEPLOY Assembly=%AssemblyName%\bin\Development\MyProject.Orchestration.dll Install=True Log=Deploy
@ENDLOCAL
@PAUSE
UNDEPLOY.CMD :
@SETLOCAL
@CALL "%VS71COMNTOOLS%vsvars32.bat"
@SET AssemblyName=MyProject.Orchestration
@SET BizTalkPath="C:\Program Files\Microsoft BizTalk Server 2004\"
@ECHO.
@ECHO Undeploying assemblies from BizTalk...
@BTSDeploy Remove Assembly=%AssemblyName%\bin\Development\MyProject.Orchestration.dll Uninstall=True Log=Undeploy
@BTSDeploy Remove Assembly=%AssemblyName%\bin\Development\MyProject.Schemas.dll Uninstall=True Log=Undeploy
@ENDLOCAL
@PAUSE
I'm currently working on a classical ASP.NET application which uses the Data Access Application Block (v2) to communicate and to perform data operations with SQL Server. With it's big set of provided methods, the DAAB is pretty usefull for handling database operations. But the problem of the DAAB is that it made me forget all the underlying stuff (SqlConnection, SqlCommand, etc.).
Indeed, while using the DAAB, I didn't create even one SqlConnection or SqlCommand, because I mainly call the methods which takes the ConnectionString as parameter, like :
SqlHelper.ExecuteReader(connectionString, CommandType.StoredProcedure, spName, spParams);
For instance, I have a page, where I have to load the Customer details, and its related Orders, I do :
SqlHelper.ExecuteReader(connectionString, CommandType.StoredProcedure, spName1, spParams1);
SqlHelper.ExecuteReader(connectionString, CommandType.StoredProcedure, spName2, spParams2);
Then I told my self : hey... wait a minute... I'm calling many times SqlHelper.ExecuteReader in the same function... Ok, but, it is creating and opening/closing a SqlConnection for each call ! Shouldn't I establish the SqlConnection myself before the two calls of SqlHelper.ExecuteReader(), and pass the SqlConnection as a parameter, so that only one SqlConnection is opened and then closed ? Shouldn't that be more performant ?
I guess that in my sample (two consecutives calls to the database, in order to get some data), I should handle the SqlConnection myself and pass it as a parameter to SqlHelper.ExecuteReader().
But, let's take another sample. Let's say, I extract from my database, a list of RSS Feeds to download and save into my database.
public void UpdateRssFeeds()
{
// 1. Get the list of RSS Feeds to download
SqlDataReader reader = SqlHelper.ExecuteReader(connectionString, CommandType.StoredProcedure, "GetRssFeeds", null);
// 2. For each RSS Feed, download it and save its content into the database
while (reader.Read()) {
// 2.1. Download RSS Feed
...
// 2.2. Update RSS Feed content into the database
SqlHelper.ExecuteNonQuery(connectionString, CommandType.StoredProcedure, "UpdateRssFeedContent", spParams);
}
reader.Close();
}
What about SqlConnections ? Should I establish only one, but long SqlConnection in order to perform all this long process ? Or should I get the list of RSS Feeds, disconnect, then download each RSS Feed and connect/disconnect a SqlConnection for each one ?
Eric Sink just published another excellent column : Be careful where you build (via Chris Sells). This time, Eric talks about the importance of the language and components you choose, and what are their business consequences.
If you can read French,
Fabrice Marguerie just published an
excellent article about SOA.
Last week, I outlined that Sam Gentile published an excellent post about distributed applications. Robert Hurlbut then added some valuable infos by commenting Sam's post.
Today, Robert has published another post. This post is a little more security-focused but does provide some very interesting informations. Another must read !!!
A nice article (by Adnan Masood) on 15 seconds explains how you can protect your application from registration spam programs using CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart), you know those images containg letters and numbers you are told to identify and write in registration forms, like this :
While doing some research about the benefits of using a "metamodel" for service oriented architecture, I found a very interesting web site :
JOURNAL (Microsoft EMEA Architects Journal). A
first "Issue 1" was recently published (January) and talks about many different architecture subjects. "Oh ! What a gem !"
If in your applications, you download RSS Feeds in order to process them, you may have noticed that character encoding can be a real pain in the a**.
Mark Pilgrim just published a nice article describing the good way to
determine the character encoding of a feed.
The famous Scott Mitchell just published a nice article explaining how it's possible to add a Calendar to the top left of your .Text blog. Since many blog engines, such as MT, Blogger, etc., already let you do this, .Text had to be able to do it too. Thanks to Scott, it's now done !
So, you've just built a big enterprise project, and with your beautiful 3-Tier architecture, you think you designed it correctly and that by using DataReaders instead of DataSets you'll be able to scale up ? BUUUUUUZZZZZZZZZZZZZ ! You're wrong !!
Sam Gentile just published a very good, what do I say, an *excellent* article about .NET developers writing "compact" (one-block) applications, instead of trying to build distributed applications, much more able to scale up. He also criticizes the fact that .NET developers don't think "enterprise" contrarly to Java Developers : "Screw it they say (.NET developers talking about architecture articles), just show me that drop in Server control again."
For a personal project which is a pretty big-sized web project, I decided to immediately design the application to work in distributed mode, so that I am able to scale up easily without having to invest into expensive data center and clustering solutions. Distributed architecture will allow me to add much cheaper boxes when needed. I'm still a student and this will be my first distributed application, but I do think that this is the good choice when your application manages and handles huge data volumes, has a lot of users, etc. As Sam said at the end of his article : "Distributed computing is your friend."
UPDATE : Fixed some mistyping faults :)
If you can read french, the article about the Implementation of a business process with Microsoft BizTalk Server 2004 I wrote for my new internship at Business Design Consulting has just been published.
"L'article démontre comment il est possible de décrire un processus métier avec BizTalk Server 2004, quelles sont les possibilités d'intégration avec d'autres système d'information, et comment l'invoquer à l'aide d'un formulaire InfoPath."
If you're using BizTalk Server 2004, Scott Woodgate (BizTalk Tech Project Manager) just published an excellent tip to activate BizTalk explorer extension:
Just run a simple : regsvr32 BtsAsmExt.dll (which you can find into "program files\microsoft biztalk server 2004\developer tools"), and restart the explorer and hop ! A new folder called "BizTalk Server Assemblies" just appeared. Nice and usefull !
InfoPath, the new (well, not so new now...) product of Office System, is great ! It lets you create beautiful and fully functional forms with just a few clicks. I'm using InfoPath to invoke web services published by BizTalk Server 2004, and I think we can say that InfoPath is to BizTalk Server what Outlook is to Exchange. InfoPath + BizTalk Server lets you easily collect information from users, it lets you use, reuse and share collected information within the different business processes and applications of your information system, without forcing the users to re-enter data (thus, avoiding data error input).
BUT ! I'm still wondering why InfoPath forms requires the user to have InfoPath installed on his machine to be able to fill out the forms. The only reason I see is that Microsoft can sell more licences. I don't see any other reason, because technically, I really do think all forms generated with InfoPath can be created in Web mode (understand HTML). I actually recreated a lot of JavaScript functions to perform the same kind of UI actions (textbox highlighting, etc.).
Another point : where is the navigational ability of InfoPath ? I couldn't find any possibility to implement a navigation workflow between forms. Indeed, i'd like to be able to navigate between InfoPath forms. That would allow us to create applications with an InfoPath frontal without beeing obliged to have a system behind these InfoPath forms to manage the navigation between them. Is this feature coming in the next version of InfoPath ?
That was my 2 cents on InfoPath.
I finally found some time to take a deeper look at SOA. I started to read a really nice post by Udi Dahan, I bookmarked a few weeks ago (thanks to Roy Osherove), which explains the basic principles of SOA. I really recommend it if you're interested in SOA but you're still new to it.
All I can say is that SOA just makes sense to me. Nowadays, we are in a society of service, and it's also true in the e-world. I do agree with the fact that we have to split every business process (services) into independant but communicant objects, just like in the real life. I guess SOA is a good technique to expose and provide existing functionalities of information systems, allowing an easier integration and communication between applications.
I think my .NET school project, a web photo gallery, will be the perfect opportunity for me to implement an SOA solution.
Does anyone have any information about Yukon performance compare to the actual version SQL Server 2000 ? Will there be any performance boost ?
A new build of ShadowFax is out : Build 1.23.2004 (via Christian Weyer)
For information, ShadowFax is an SOA (Service Oriented Architecture) reference application. So, if you're interested about things concerning SOA, you should definitively check this out.