4

I have developed and deployed few ASP.NET applications. Sometimes I want to stop the users from either inserting or updating a record when:

  1. Maintenance is going on.
  2. Stop operations due to payment delay.

In one of my recent application I have implemented this feature to first check the database operations for locked status. If any of the above condition fulfils, database operations like insert and update are not carried out.

I now need this feature in all the old applications and the future applications I build. I want to know whether WCF is suitable in this scenario as I want to share methods or an independent locking application among various other applications.

Is WCF appropriate for this type of scenario?

Improve this question
1
  • 1
    I would think the avalability of your service, however it is implemented would be you primary concern. WCF would be a workable choice, I've recently been considering servicestack.net but there ar many others en.wikipedia.org/wiki/List_of_web_service_frameworks. I think the reliability of your hosting should be your primary concern, do you want you applications to fail because your ISP is doing maintenance?
    – Jodrell
    Commented Jun 22, 2012 at 16:12

3 Answers 3

Reset to default
8
+50

I should begin by saying that WCF is the goto solution. What you mentioned above fits very well in the SOA (Service Oriented Architecture) definition, and WCF deals very well with SOA.

Implementing a single locking service application, which can then be then integrated in all your components would be ideal because:

  1. When you update your locking and payment checking methods, you do it one place only. So it gives you maintainability.
  2. You implement the code only once, which gives you reusability.
  3. In the central app you can always add new services, with new logic which can be coupled or decoupled of your existing model, from existing services. So you have scalability.
  4. It also gives you coolness, for all the reasons I mentioned above.

If anything else, then please ask.

Improve this answer
2
  • 1
    I agree and if the ASP.Net applications and WCF services are on one machine use the namedpipe binding otherwise use net.tcp binding. This is especially good for case 2 which is a business requirement and rules can change in futire. For case 1 arguably you can do a DB level check as that is more of a technical issue.
    – softveda
    Commented Jun 17, 2012 at 22:38
  • 1
    This is the answer, and it is yes. WCF is the appropriate way to share information across multiple applications these days.
    – deltree
    Commented Jun 22, 2012 at 19:54
0

You could insert a file on your webserver and protect it by placing it in a safe folder and make it only editable by admin user. In that file you could specify a string to indicate the system status. Accessing this file can be performed in any way you like. The reason for choosing a file is to be able to access it even if the database is down. This is a a very simple solution that serves the objective you described.

Eidt: Also, instead of a separate file, you could use a configuration item to server the same purpose.

Improve this answer
4
  • 1
    And how do you know that all the ASP.Net applications are deployed on one machine. This is a poor solution that doesn't take into account distributed and load-balanced deployment. Also it is poor from security perspective as well. The 'safe folder' should have write permission by all the ASP.Net apps that may have different application pool identity. Not very good.
    – softveda
    Commented Jun 17, 2012 at 22:35
  • @Pratik , I am aware that this solution has limitation. The OP did not mention that he/she is using multiple servers. The folder does not have to have write permissions at all. An application needs to read the file not write to it. The solution is very safe if correctly implemented.
    – NoChance
    Commented Jun 18, 2012 at 4:08
  • Even if it is a single server, why not keep a separate SQL Server database instead of a file.
    – RPK
    Commented Jun 19, 2012 at 18:02
  • @RPK, Using a file in this case is more generic because, you may want to shut down the site when you are doing database maintenance operation that you want to do off-line or if your database is built from batch feeds that are run on off-hours basis. If that is not the case, by all means, use a database table.
    – NoChance
    Commented Jun 19, 2012 at 19:37
-3

If you wanted a locking solution, a web service is not necessarily the way to go - the overhead involved is very great. So just to check "can I do some writes now" will require a lot of calls, and a webservice call is very slow (relatively speaking).

A more optimised solution would be to keep with your database calls, but to move the sql to a stored procedure that can also check the locked status as part of the query. Alternatively, keep the lock check as local as possible, checking whether a file exists is quick (as the OS tends to cache such files if they're accessed often) and easy, especially if you're reading your applications' code from files or writing to logs anyway.

Improve this answer
2
  • 2
    I would say this is a hack, not a real solution. A real solution has to work on a long term, not just now, when it's needed.
    – Marcel N.
    Commented Jun 17, 2012 at 21:23
  • what, stored procedures are a hack?! Sure the file isn't perfect, but it a common practice in scripted language web serving. Putting a trivial web service call in every page request is simply not a scalable solution.
    – gbjbaanb
    Commented Jun 18, 2012 at 9:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.