Saturday, August 27, 2005 - Posts

RSS Convergence

RSS Convergence (RSS,NNTP, Forums, blogs)

I am firmly convinced that these 4 will merge sooner or later ....
or at least do 3 out of 4 combinations .....

just check out http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx,
its a forum based on a newsgroup (NNTP) and uses 2 of the above,
if you expose the threads as RSS it uses 3 ....

now, one just needs to get the blogging software to post to a newsgroup
and create the relevant linkings correlating :
1) the post in the blog to the entry in the newsgroup ....
2) the child entries in a thread to comments of a blogging tool ....

Latest TPC-C is a scam

I recently had a look at the no.1 on the TPC, which is amost 3 times as fast as the other ones.
I don't doubt that IBM is up there with the best, but the amounts of RAM and disks
compared to the others was a bit cheating. Why?
Because it has almost twice as much RAM as the DB files(s).
The DBs for the TPC are around 1 TB:
while MS and Oracle competed with 1 TB for the top spot, IBM had 2 TB.
What does it mean having THAT more RAM?
That besides having the DB file(s) in RAM,
having ALL temporary(e.g. old AND new data pages) data in RAM,
plus all OS in RAM,
plus any other code to help out the DB.
By avoiding to touch the disks for that extra 1 TB the performance is obviously superior.
Just recount that RAM is at least 40 times faster than disk persistence.

Where MS doesn't take advantage of it's "platform" APIs

Months ago Joel Spoelsky wrote about the API wars and how MS is losing them. While I felt that Joel
was mostly wrong some software is effectively being left behind.
While .NET has brought great advances in the platform API accessibility notably most Windows desktops apps
are being left almost untouched by the much welcomed .NET (r)evolution. Some time ago I mouned about Outlook; that
is being addressed by a late inclusion in VSTO, even if IMHO the update in the OOM (outlook Object Model) does not go
far enough. What I'd like to see is the possibility to have e.g.
a programmable MAPI pipeline ie. being able to easily intercept incoming messages by adding rules for spam detection, classification and other
a provider pattern for archiving/publishing mails to a persistent store (SQL Server, NTFS, Sharepoint, ...)

Another app, part of Office, is Access. While it is not one of the most strategically important apps it has
this unique appealing combination of a DB and a GUI, which has helped many hobbists getting into proper RDBMS.
While I surely don't rate it as a "enterprise" DB, it offers anyhow a convenient persistence store for many
desktops apps. Therefore I don't understand why no effort was made to get .NET to run in it, perhaps by
abstracting the code running engine to keep the existing VBA running and adding the necessary .NET support.

Other two apps which need desperately some rework are the MSN Messenger and IE.
While the first one is still very COM based and allows some customization, the IE browser needs desperately
to expose better .NET API both for it's own sake, but also to fend off competition by Firefox which has already
tens if not hundreds of plugings. While it is true that OS client programming hasn't beeh fashionable in the last
several years, but also why not take advantage of 700 milion + computers running it. Even IE like Outlook needs to get a .NET friendly
programmable "pipeline", to e.g. allow a .NET plugin/proxy like pre-check an URL before rendering it in the browser
or just plain simple applications safely taking advantage ot the browser bar's real estate.

IMHO, fixing up the .NET programmability of these 4 client apps would be more than welcome to many developers
wanting to add some cool little apps to the desktop and generally broaden the appeal of Windows and Office to developers
and end users alike.

 

 

 


 

Reliability features in .NET 2.0

Finally!!

Reliability features in .NET 2.0 : a must for those who write "critical" code

http://msdn.microsoft.com/msdnmag/issues/05/10/Reliability/default.aspx

Overview of Microsoft's Integration Tecnologies

Microsoft's Integration Tecnologies


taken from : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS_2004WP/html/14bc36a8-69a9-48ed-8e4c-1c85202544c0.asp

 

 

Appendix: Summarizing Microsoft Integration Technologies

Integrating Applications Directly

Technology Primary Integration Scenarios

ASP.NET Web Services (ASMX)

Connecting Windows applications with Windows and non-Windows applications via SOAP

.NET Remoting

Connecting Windows applications with other Windows applications via distributed objects

Enterprise Services

Connecting Windows applications with other Windows applications that use distributed transactions, object lifetime management, etc.

Indigo

Connecting Windows applications with Windows and non-Windows applications using web services, distributed transactions, lifetime management, etc. (subsumes ASMX,.NET Remoting and Enterprise Services)

Integrating Applications Through Queues

Technology Primary Integration Scenarios

Microsoft Message Queuing

Connecting Windows applications with other Windows applications using queued messaging

SQL Service Broker

Connecting SQL Server 2005 applications with other SQL Server 2005 applications using queued messaging

Indigo

Connecting Windows applications with other Windows applications using queued messaging (via MSMQ and/or SSB)

Integrating with Applications and Data on IBM Systems

Technology Primary Integration Scenarios

Host Integration Server 2004

Connecting Windows applications with IBM zSeries and iSeries applications and data

Connecting MSMQ with IBM WebSphere MQ

Integrating Applications Through a Broker

Technology Primary Integration Scenarios

BizTalk Server 2006

Connecting Windows applications and non-Windows applications using diverse protocols

Translating between different message formats

Controlling business processes with graphically-defined orchestrations

Connecting with business partners using industry standards, such as RosettaNet and HL7

Providing business process services, such as Business Activity Monitoring and a Business Rules Engine

Integrating Data

Technology Primary Integration Scenarios

SQL Server Integration Services

Combining and transforming data from diverse sources into SQL Server 2005 data

SQL Server Replication

Synchronizing SQL Server data with copies of that data in other instances of SQL Server, Oracle, or DB2