David Chappell

Opinari

Get the Feed! Subscribe

Introducing Windows Server AppFabric  
# Monday, May 24, 2010
 
I know some application developers who really enjoy creating general infrastructure for their apps. My guess is that these people would be happier working for a software vendor--they shouldn't be application developers. Developers who get paid to write applications should write application code, not infrastructure. Software that provides general-purpose support for application logic--operating systems, database systems, and much more--should be provided by vendors.

Windows Server AppFabric is an important example of this. By providing caching and hosting services for Windows applications, it can reduce the amount of general-purpose infrastructure that app developers must write. I've written a Microsoft-sponsored introduction to this technology, available here, that provides a big-picture view of what it is and why you'd use it.

Don't confuse Windows Server AppFabric with Windows Azure AppFabric. Both have "AppFabric" in their names, and both provide infrastructure for applications, but they currently have no technologies in common. Microsoft tells us that this will change in the not-too-distant future, with the Windows Server AppFabric technologies appearing in Windows Azure AppFabric. You shouldn't let this throw you, though:  the caching and hosting services of Windows Server AppFabric can be useful for Windows apps today.


6 comments :: Post a Comment

 


Comments:

Excellent white paper, in just 20 page you have explained the practical use of AppFabric, AppFabric Hosting service, BizTalk Server, WCF and WF.

However following questions arises after reading this paper, can you throw some light or provide pointers/links:

1)In AppFabric Cache Cluster,
a)what type of replication is supported synchronous or asychronous?
b)Does it use disk i/o for
replication?
c)Does it support SQL 92 or do we have to use APIs
d)When the data is not found in cache does it automatically fatch it from database or needs to handled in code?
2)WF service is maintaining the state using its own database (persistent storage), and also supports monitoring of the service (again involves the use of persistent storage) - what is the overhead of state management and monitoring, are there any benchmark available for the same? Is there a option to use Cashing service instend of persistant data files?
 

I'm glad the paper was useful for you, Nilesh. Some answers:
- 1a: Updates to the secondary copy of a cached data item are asynchronous.
- 1b: Both the primary and secondary copies are held in memory, not on disk.
- 1c: The cache isn't a database, so you don't access it via SQL. Rather, you use either the provided APIs or another method, such as the built-in support for storing ASP.NET session object state.
- 1d: If the data isn't in the cache, your code needs to find it. The Caching service won't fetch it automatically.

- 2: I'm not aware of any current benchmarks for the performance of WF persistence, and using the Caching service for this isn't directly supported (although you might be able to achieve this with a custom persistence provider).
 

"Developers who get paid to write applications should write application code, not infrastructure.":)

Believe me, nobody (well, almost:)) writes an infrastructural code purely for fun. Usually it's just an easier and more controllable way than using infrastructural monsters provided by "vendors".
 

This is a really good point, Dmitry.

It does seem like the vendors are getting better about providing more modularized and less monstrous infrastructure options, though. Perhaps the wide available of simpler open source solutions (Spring comes to mind) has had some impact.
 

Are there any push replication implementations available for separate AppFabric clusters (most likely separated by a WAN)?

The ORACLE Coherence cache has a push replication feature but I can't find anything for AppFabric.
 

Not to my knowledge. I'd love to know what your scenario is, though. Why do you want this?
 

Post a Comment


<< Home