Does Windows Azure AppFabric Caching support High Availability? - c#

Back when AppFabric Caching was "Velocity", High Availability was "out of the box" option, and one of the few major features that made it stand out over other caching systems, namely memcached. However along the way "someone" decided it best to charge customers extra for HA by making it only available to Windows Server 2008 Enterprise Edition (or higher)... I am hopeful that Windows Azure AppFabric Caching does provide HA. I'm betting it must, if for no other reason because there is no "upgrade" option. Anyone know for certain?
As a secondary question, if anyone knows of the ETA for the production release of Windows Azure AppFabric Caching other than "2011", much appreciated. Roadmaps would be mighty handy... Instead most of us rely on Google to determine guesswork roadmaps :). Always been a big fan of MS products/services, but they could really use some additional "focus" in the area of Azure.
I understand AppFabric Caching is currently only in "alpha", and is only available via the Azure Labs portal.

Found the answer...
As we move towards commercial launch, we'll look to add many of the features that make Windows Server AppFabric Caching extremely popular, such as High Availability, the ability to emit notifications to clients when they need to refresh their local cache, and more.
http://blogs.msdn.com/b/windowsazureappfabric/archive/2010/10/28/introduction-to-windows-azure-appfabric-caching-ctp.aspx
So no go for the time being, but looks like it is planned. Good enough for me, since it is not yet released anyway. But any ETA on release date (or quarter) would be very helpful for configuring my roadmap...

commercial availability for the current Azure AppFabric labs features is looking to be Q2 of 2011. I'm basing this on the various PDC10 sessions. Only time will tell if we see HA included in that feature set or not.

Related

Cache server for .NET(Example Memcached)

I am looking for cache server for .NET. What can you suggest? As i know memcached has provider for .net. Is it good enough to use for .net in production?
AppFabric is another popular solution from Microsoft.
If you're willing to run your cache server in Linux, you could use Redis, and use the BookSleeve library from .NET, this is what StackOverflow uses
http://code.google.com/p/booksleeve/
Scale Out State Server is an excellent solution. It's not free, but for large-scale applications, it's one of the best options that we found.
NCache is another option, though I have no experience with it.
For enterprise scale (and budget) there's Oracle's Coherence. It works extremely well, though it's extremely pricey.
Here's another SO question with some information that may or may not be helpful:
Caching Solutions
Memached is plenty good for production, probably best using the enyim provider.
Couchbase provide a good web ui and easy memcached install on windows. Free if on a single server. It's great to be able to monitor your cache instance.
They have paid for solutions but and their own server.
AppFabric as mentioned is another obvious candidate but not a mature as memcached. AppFabric is an application server and can also provide distributed caching like membase
See the post Top caching libraries for .NET for several options, including both free and commercial. The choice will vary based on your actual need.
though there are numbers of third party caching solutions are available for .NET but if we narrow done the research based upon Google and word of mouth, it might be
1) Memcached
2) Appfabric
3) NCache
firs two are free/open source software so they have some limitations in it, while on the other hand NCache has a lot to offer as compared to others, but you have to buy it. but it has also a free version available called as NCache Express. below are two important links in this regard,
Video on NCache Vs AppFabric
Blog on NCache Vs AppFabric

Recommendations for .NET cloud service provider

Apologies for the vague question, I am looking for pointers rather than exact answers. I have an application I am developing in Silverlight which requires some back-end persistent data. I can certainly do this myself using IIS / SQL Server, but I am eager to learn something new!
Are there any suitable, free, cloud services I could use? A bit like Google App Engine, but preferably allowing me to use the .NET stack, e.g. via a WCF connection to my client.
As this is just for learning purposes I don't have many requirements regarding data volumes etc, however, it would be nice if I could run some scheduled services on my data in the cloud, e.g. some statistics calculations every hour.
Any pointers?
You can get Azure free for 30 days here. If you have a premium/ultimate MSDN subscription, you can get Azure free for 8 months.
if it's only a test and you do not expect high volume you could do with Windows Azure and SQL Azure, at least you learn how to deal with leading products and if afterwards you decide to develop something more commercial, you will reuse the know how. I do believe for testing reasons or low volume you should get it either for free or extremely cheap.
Try EyeOS. You can go for the trial version and test your applications.
Others are
icloud
Cloudo
Force

Choosing CMS vs Portal vs MVC+Components?

I need some help figuring out whether it'd be a good idea to use a CMS or portal solution for my latest project, which is (currently) an ASP.NET MVC application that must serve multiple customers (being a company or some other entity with a list of users) from a single installation (that is, a SaaS solution).
In addition to the core functionality, which includes document management/publishing, I also need to provide basic social features (such as blog, forum, gallery, polls, etc.). However, it is imperative that content is only visible for the customer to which it belongs, and my evaluation of a bunch of CMS and portal solutions has shed little light on whether they support this. They're pretty focused on single-user installations, and documentation on how to integrate with an existing MVC solution is pretty thin.
Essentially I'm looking for some guidance to help me discard dead-end options (the product does not meet requirements, imposes too many restrictions, is not mature, etc.) and find unexplored options before getting too far ahead with the project.
My requirements for the architecture include:
Multi-site support (using a single domain for hosting)
Watertight separation of content between customers
Full integration across components/features
SSO (single-sign-on)
Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
Ease of development and deployment
Custom logic will be written using C# and ASP.NET MVC and any products should support this
I want to stay in control
Solution should offer features but otherwise stay out of the way (for example, not force stupid idioms on me, like insisting on GUIDs for primary keys)
Active development community
No single-man efforts
Recent source control activity
Reasonable levels of documentation and maturity
Does not have to be open source
I have spent a fair amount of time evaluating products and components, which I'll briefly share here:
Umbraco
Does not support ASP.NET MVC (yet, as someone is bound to otherwise comment)
Great community support, active development
Seems to be lots of work to get started
Kooboo
No source activity (no updates for almost two months)
GPL licensed? (need something that allows for closed source applications)
N2CMS
Partial ASP.NET MVC support
Every customer must have a separate domain
Limited source activity (not dead but not vibrant either)
Orchard
Microsoft-sponsored (which means it's likely to be over-architected, code-bloated and slow, although it does have some well known and respected contributors/leads)
Built using ASP.NET MVC
Looks promising feature-wise (but is unlikely to be stable at this stage)
AtomSite
Feels reasonably mature and has decent documentation, albeit with holes
Built using ASP.NET MVC
Limited source activity, single developer
MojoPortal
Looks good for a portal, but probably requires custom logic to be built as modules around the product (I was hoping to avoid that kind of lock-in if possible)
DotNetNuke (DNN), CommunityServer and Microsoft Office SharePoint Server (MOSS)
Definitely not my cup of tea ;)
BlogEngine.NET
Mature and feature-complete
No ASP.NET MVC support
Integration possible but not without lots of Web.config voodoo
Not sure if it supports customer separation
Given the list above I'm leaning towards AtomSite, N2CMS, Orchard or BlogEngine.NET. If I go with the latter I'll be using jitbit AspNetForum, which is a great match for my needs.
I'd probably prefer to use a custom ASP.NET MVC solution and individual components as this is likely to give me the greatest amount of control, but on the other hand, it'll make site theming and integration harder. What combinations have you tried, what worked well and what didn't? Anything important I'm leaving out of my evaluation? Any other relevant advice?
I'd appreciate it if the answers were not simply endorsements of your favorite product or way of doing things, but something that would help me choose or eliminate solution candidates given the requirements outlined above.
With the level of requirements you've specified, I'm personally going to have to lean towards the custom approach. You can hire someone to do the design (view) portion of the site for you, or you can buy a theme off the internet from site designers and customize it to your liking. (Sometimes just having somewhere to start is enough for intermediate level customization).
Multi-site support (using a single domain for hosting)
You're probably going to want to have control of your hosting environment, either a VPS (Virtual Private Server) or a dedicated box. This is still possible on shared hosting but not reccomended.
Watertight separation of content between customers
You'd probably have to spawn a unique app-pool for each customer with thier own services user for 100% seperation.
Full integration across components/features / SSO (single-sign-on) /Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
This is going to be the tricky part. This Example may have some useful insight for you in the development process, but you're going to want a unified login service and have all sites use it or link to it.
Ease of development and deployment
This is where it gets tricky. Development ease comes from your background I think. MVC is definately the right choice in this respect then, knowing a lot about the right ways of going about building a site in MVC will aid in this process. Keep up to date by reading community blogs and listening to podcasts like Hanselminutes or DotNetRocks will help keep you in touch with the newest and greatest tools/technologies for making your site get off the ground quickly and effectively.
Deployment is the tricky spot. MSDeploy still isn't quite there. But if you can you probably will want to come up with a Dev -> Staging -> Release publish structure so you can test your code in a staging (mimiced production) environment.
Custom logic will be written using C# and MVC and any products should support this
I want to stay in control
If you develop the site in ASP.NET-MVC, you'll be able to build common libraries that you can use not just in your site, but also in your custom tooling. This will greatly reduce your code duplication and helps make sure operational unity is achieved. (Everything works the same way).
Solution should offer features but otherwise stay out of the way (e.g. not force stupid idioms on me, like insisting on GUIDs for primary keys)
While you'll have control in this situation, I'd strongly reccomend GUID Primary Keys. This allows Merge Replication, which can help you easily restore backups or use failover DB servers when things go awry.
Active development community
.NET has a great community out there, (including this one) and you should get lots of support if you ask for it politely.
No single-man efforts
Not sure what you mean here, You'd be the Single-Man unless you hire help, but even 2 people can do great things given a little time. Even one-man can do great things, but the framework you're running on here is backed by a commercially funded huge team.
Recent source control activity
Doesn't really apply to .NET, but a lot of the libraries that you may use (NHibernate, MVC Contrib, AutoFac, Etc...) will have lots of activity and constantly being improved.
Reasonable levels of documentation and maturity
.NET and most of the production level libraries developed for .NET (Mentioned above) actually have a pretty good degree of documentation. There's multiple paid & non-paid sources of information for .NET alone, and most libraries (are well supported by the community and known on StackOverflow)
Does not have to be open source
Look for support libraries that are LGPL (i.e. you can use it in commercial software, but if you modify the library you have to release the new library code if you release the binary.) You're pretty safe here, your site dosen't have to be open source if you use these libraries to support your development.
Well, that's my 2cents. The project you've described is no small job, you're looking at a considerable amount of work even if you go with a pre-built solution (mainly hacking it to work the way you want). I imagine your biggest hangups would be SSO & Security for the pre-done solutions. Not to say it's impossible, just tricky and the end result may not be exactly what you're looking for.
Also, look into OpenID, it may be the best solution for linking all your sites together and most pre-built systems can easily be ported to use it.
Take another look at MojoPortal. The CMS is awesome and the main developer , Joe Audette, is very responsive. I'm have several installations of the CMS running single and multiple sites.
I would lean towards a CMS based solution. Having a tested and production ready software not only reduces the development time but also helps in continuous upgrade and reduced bug count.
If you go down this route, you may want to also consider Sitefinity. Not only does it support all the features required by you, but also is built on .NET and supports MVC development. The product is built by Telerik, the makers of UX tools.
Disclaimer: I am employed by Telerik.
I've recently come across phpFox which is a social networking/forums/community site CMS. This may be of use to you and is fairly inexpensive.
The solution for the site of our company has become EBIZ CMS: full-featured site that includes social networking, online store, features a presentation, a forum, create HTML pages and much more, including the maintenance of professional technical support, so we do not even need help for installing by a programmer, and it is only US$ 9/month!

Guidance for Migrating MS Access Apps to .Net Apps

I will soon begin the painful*(kidding)* process of migrating multiple, separate, Access Applications to "Real" applications*(notice the quotes, no flame wars please)*. Most likely this will be Web Apps as the usual reason is multiple users and deployability but I will take it case by case.
Some of these are traditional Access apps using Access as the back end and others are using SQL Server(a central one) as the back end.
What I am looking for is a combination of your experience doing this and what resources you used to help.
Websites, apps, standards, best practices, gotcha's, don't forget's, etcetera.
I am a 1 person C# shop with SQL Server back end so whether Web or not I will be looking that direction.
Also, is it overkill or unattainable to try and develop a Framework for this kind of thing? Would there just be TOO MANY variables to even try and walk this path? Anyone ever try this?
Some further info based on below questions. We currently have ~250 users and they are spread between 5 Locations.
What I meant by deployability is perhaps a little vague. I simply meant that we are a Non-Profit Organization and as such we do not have the best bandwidth available so deploying full apps, even through ClickOnce can be tricky when combinded with the highly fickle nature of my users*(I want that box purple, no green, no get rid of it altogether type stuff...)*.
My idea is to try and develop a "framework", of sorts, that will help to streamline the process of moving an Access App to a .Net App.
Now I fully understand that this "framework" may be nothing more than a set of steps and guidelines; like, Use ORM*(LINQ2SQL or SubSonic)*to generate DAL, Copy UI to corresponding UserControls, rewrite Business Logic.
I am just looking for your experience/expertise to help me streamline my streamlining process... ;)
Those apps which use an Access database to store tables and which need web access should first be upsized to SQL Server. There is a tool from the SQL Server group. SQL Server Migration Assistant for Access (SSMA Access)
Then consider moving to the web only that portion of the app that requires remote access. And leaving the rest of the app in Access. That could save a considerable amount of time.
Alternatively consider going to Terminal Server. That along with a VPN means just some software licensing costs and next to no work on your part.
That said what do you mean by "multiple users" and "deployability"? Possibly we can give you some suggestions there. Access is multi user out of the box. However if you have mission critical data or can't rekey the data in the event of a corruption or have more than 25-50 users on the LAN then you should be moving the data to SQL Server.
Now that it's public Access 2010 can deploy applications to the web. All kinds of very interesting stuff can be done. For more information check the Microsoft Access product group blog or my blog with the appropriate Access 2010 tags
Speaking from experience I think you would need to upgrade on a case by case basis. Upgrading is essentially a re-write from scratch and you should take the opportunity here to re-design as necessary. The type of application structure and code style used for Access (likely to be procedural I'm guessing) is very different to a well designed OO .Net app.
You will be able to re-use the SQL Server databases of course and, depending on the apps maybe even the Access ones. If you're feeling brave you could even try the upsizing wizard although I wouldn't recommend it as we found the results less than ideal.
I would also advise you take a look at some kind of ORM tool (we use Subsonic) as this can massively reduce the amount of boiler plate code you need to write. Some ORM tools will also generate DDL for your database too.
We follow these standards (good idea to pick a standard early on and stick to it we found) and also found this really useful to get up and running.
Hope this was some help.

Web Services for Remote Portlets in C# / .NET -- Options?

I recently had my mind expanded by a new concept: Web Services for Remote Portlets, or WSRP. I learned of it during a presentation on a Java-based web portal we are considering purchasing at work; we are a .NET shop and WSRP would be the means by which we would extend this portal.
Although I cannot control the end decision as to whether or not we purchase the product, I can provide input as to how difficult it would be to build WSRP-compliant portlets. Unfortunately, my recent queries into the subject have turned up almost nill.
So I ask you, the SO community, the following: what libraries or frameworks are out there for building WSRP-compliant portlets in C#/.NET? What are some of the pros and cons of using WSRP in general?
Because there is no correct answer here, I will make this a community wiki post.
So far, I have only found the following:
WSRP Toolkit for Sharepoint by Microsoft (but requiring Sharepoint).
WSRP Portal and WSRP .NET Framework By NetUnity.
Given that WSRP is on top of SOAP, this seems like a perfect candidate for a WCF binding and channel, and yet I see nothing on the subject, anywhere.
WSRP is very contrarian. By now the world has seen that tight coupling between the data model and the presentation model is suboptimal. The success of RSS, REST, MVC, and web services in general shows this. Despite the WS in the name, WSRP stands against the core principles of Web services. The WSRP spec ignores the sound advice to keep data and presentation separate, and couples them tightly.
WSRP promises integration, at the UI level. This seems like the wrong problem to be solving.
It baffles me that this thing has lived as long as it has.
The problem it attempts to solve is often not the problem that should be solved.
If you read the WSRP spec carefully, you'll find it is a remote version of the Java Portlet Specification (if I'm spelling that right). That means that it's useful for integrating Java Portlets. Anything else will have to look like a Java Portlet, which is not very generic.
I think its popularity / adoption can be inferred by the fact that the last release from NetUnit was "This latest release adds support for Visual Studio 2005 and .NET 2.0."
I would have to agree with Cheeso. Integrating the UI with the Data only serves the portlet consumers and adds a big, unnecessary, risky layer to portlet producers. Our .NET shop has been recently forced to consider WSRP and I have found a lack of support and experience. The best MS-centric approach I have seen discussed is here. But I have not found any specific WCF implementation/support. Any leads greatly appreciated!
WSRP is essentially a portal-to-portlet web service standard. What is the primary data exchanged between portal and portlet? It's markup and largely because most portals use a web UI. This whole idea that it is not pure data versus UI is moot point. It's meant to be a web service for portlet discovery, meta data, markup, interactions, caching, portlet-to-portlet communication, etc. That's what a portal does even if not WSRP. WSRP however is an open, cross platform standard.
What is a portal that only integrates portlets from its own products and/or platform? Got Java-based PeopleSoft HR and would like to provide access to their portlets from SharePoint to your employees? Good luck. Why can't this be an achievable scenario for most enterprise software? And yes, I realize it is integration related to UI. That is one of the primary reason for why I'm using a portal. It's not like I'm expecting to get PeopleSoft integrated with SharePoint at the "pure" data level and somehow an Employee Benefits Web Part magically pops up in SharePoint ready for use. However, that is what I expect if the portlet-to-portlet integration is based on WSRP.
WSRP, although not perfect, is a superior solution in my opinion. Besides easy integration of portlet within a portal, it separates the portal from the application. No deploying of binaries to the portal server or even running on the same server. This makes sense. Never run applications on the same server as the portal server: neither will ever be upgraded. I've come to the conclusion that it's insane to put application binaries on the same server as the portal server. "Please deploy this application to the portal server and have it affect security, stability, performance, and everything in between and I would like create as many dependencies as possible and bring down the whole portal sever whenever I upgrade the application". It's a dependency nightmare. Better get a couple of portal vendor consultants to hold hands with when upgrading and to have someone to blame.
Do you need to load balance an entire portal platform when only a select number of portlets are hit the most? Portal vendors would like you to think so. A lot of the time, the portal is doing nothing more than waiting on portlets to finish processing. With WSRP, you have the flexibility to load balance portlets independently of the portal platform. It always breaks down to a few portlets that are hit the most. Why not load balance just those portlets? So instead of unnecessarily load balancing the portal on 80 CPU, you could load balance those few portlets on 10 CPUs. WSRP is also absolutely perfect for cloud computing.
WSRP is a portal-to-portlet standard. If you want to write a portlet that works in multiple portals and potentially across platforms, WSRP is it. If you are remotely contemplating integrating third party portlets, WSRP is it. It's the only standard. However, it also has some significant benefits over other proprietary local portal-to-portlet interfaces and should be considered for those benefits as well.

Categories

Resources