Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Best Add-In architecture : what are your Best Practices and Guidelines ? RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hello,

    i am working on an Add-In and i think I will rewrite all my code ( my current Add-In is more a 'learn and code lab' than a real AAA grade Add-In ).

    I searched the msdn and the forum to gather all the available informations concerning the WHS best practices, but I still need some help and advices.

    My application will need the following components :

    * a Windows Service
    * a local Database
    * an WHS Add-In Administration panel
    * a WPF Client
    * an ASP.NET Web client integrated in the WHS web site.


    In my current code, the Windows Service run a local Database using a sdf file, a TCP server to allow communication with the WPF client ( installed on the user computers ).

    In your point of view, what is the best way to communicate between the service and the administration add-in ?

    What is the best path/way to host the local db file ?

    How can I identify the Users when they connect directly to my TCP server  ( can i use the local accounts to validate my socket connections in any way ? )

    Regards,
    Guillaume
    Monday, May 11, 2009 8:29 AM

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote
    WHS Developer Guidelines: http://www.microsoft.com/downloads/details.aspx?FamilyID=fd907752-0db0-4a6f-846d-974c19cd08fe&DisplayLang=en

    In answer to your specific questions:

    1. I'd use IPC to communicate between service and GUI; that way you don't have to worry about more TCP ports or communication outside the machine boundary.

    2. Databases on WHS are a bit of a minefield. What sort of data is going into the db?
    - you don't want the sdf to be inside the storage pool if it's going to be held open for long periods of time (DE will complain eventually), which means no storing the db file in an application folder or shared folder.
    - if you put the db on C:\, it will be deleted if the user performs a server recovery

    3. You can use standard WCF practices for authenticating users; WHS user accounts are normal Windows accounts that exist in the local SAM, and can be grabbed like any Windows account.
    - theoretically, the user's local PC username/password will be the same as the one on WHS (if they've been created in WHS of course), but you'll still want to do the authentication and authorization yourself agains the WHS SAM
    Tentacle Blog: http://www.tentaclesoftware.com/blog/
    WHS Disk Management: http://www.tentaclesoftware.com/WHSDiskManagement/
    Monday, May 11, 2009 10:50 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    1. ok :-)

    2. my application is a media recorder (using media streams as input, and files as output). Users will be able to schedule records, according to their rights ( for example : parental control, space disk allowed, ... ). That's why i need a database file to store the scheduled records and all the information concerning the users. Today i install my db file in the service install folder. The db connection is always open while the service runs.

    3. that sounds good :-) This application is intended to works with the users created in WHS.

    Monday, May 11, 2009 11:43 AM
  • Question
    Sign in to vote
    1
    Sign in to vote
    It's not clear to me why you would want to use a database in this application. The application/add-in itself will only ever contain user and scheduling metadata, as far as I understand. You wouldn't want to store the recordings themselves in the database; they'll be huge, and will be much easier to use if they're files in the file system. Rather than using a database, which will require a separate database engine of some sort, with associated headaches (backups, updates, etc.), you could just as easily keep all of this data in memory while running, and flush to disk on each change. Then you could store the data on disk however you like (serialized objects, text files, whatever; I'd probably go with serialized objects). On startup you just read everything into memory.
    I'm not on the WHS team, I just post a lot. :)
    Monday, May 11, 2009 5:42 PM
    Moderator
  • Question
    Sign in to vote
    1
    Sign in to vote
    1. ok :-)

    2. my application is a media recorder (using media streams as input, and files as output). Users will be able to schedule records, according to their rights ( for example : parental control, space disk allowed, ... ). That's why i need a database file to store the scheduled records and all the information concerning the users. Today i install my db file in the service install folder. The db connection is always open while the service runs.

    3. that sounds good :-) This application is intended to works with the users created in WHS.


    You're only talking about storing the date/time for recording jobs, right? As Ken says you don't want to be storing the actual media fields in the db.

    What information will you be storing about the users? If you're talking about parental rights, it'd probably be easier to create a few groups in the local SAM and add users to those as needed; that way you can use the build in IsInRole() methods to check permissions for a user.
    Tentacle Blog: http://www.tentaclesoftware.com/blog/
    WHS Disk Management: http://www.tentaclesoftware.com/WHSDiskManagement/
    Monday, May 11, 2009 7:05 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Of course, my stream records won't be store in the database.
    My first message was not enought accurate. I only want to store the metadata.
    I was planning to use SQL Server CE.

    Tuesday, May 12, 2009 7:23 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Yes, i only want to store some metadata ( startdate, time, channel, user, file path, ... )

    Concerning the users, i want to store the following informations : disk space allowed for the records, priority ( if too much records are scheduled and the bandwith can't allow those records, i must decide which record will be canceled ), application rights ( a kid can schedule some records ( lowest level)  and the parents will validate the kid's scheduled records for example (high level ), highest is administrator )

    I think using groups in the local sam is not really user friendly, because it requires to be a server administrator.

    Tuesday, May 12, 2009 7:30 AM
  • Question
    Sign in to vote
    1
    Sign in to vote
    I think using groups in the local sam is not really user friendly, because it requires to be a server administrator.

    If there's a bunch of other metadata then maybe it does make sense to create your own storage for roles, but you can create Windows groups programmatically in .NET; your application would create the groups, not the user:

    http://msdn.microsoft.com/en-us/library/ms180903.aspx
    Tentacle Blog: http://www.tentaclesoftware.com/blog/
    WHS Disk Management: http://www.tentaclesoftware.com/WHSDiskManagement/
    Tuesday, May 12, 2009 8:03 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    I understand that i can create groups programmatically, but this impact all the applications / add-ins that rely on the user groups. I don't want to be too much intrusive in the server administration.

    In order to sum up :

    1. use IPC to communicate between service and Add-In control panel.
    2. database : SQL CE or object with serialization.
    3. WCF to communicate between service and Client Applications ( or ASP.NET site ).
    4. Rely on the server groups or use my own storage.


    I must ask another question : will you consider that an Add-In can ask for the .NET 3.5 SP1 since it is spread throw Windows Update ?

    Tuesday, May 12, 2009 8:43 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I disagree that it will impact other applications or add-ins; you're creating your own groups that won't show up anywhere but Computer Management, and you could name them whatever you want. You wouldn't be changing or reusing existing groups.

    A lot of developers are now using .NET 3.5 SP1, yes. I think you're mostly safe assuming users will have that installed (there are always a few people who refuse those sorts of updates, of course).
    Tentacle Blog: http://www.tentaclesoftware.com/blog/
    WHS Disk Management: http://www.tentaclesoftware.com/WHSDiskManagement/
    Tuesday, May 12, 2009 8:58 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    That's right, but someone or an application can still alter my own groups ?
    Tuesday, May 12, 2009 9:15 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Of course, but someone could open or delete your database maliciously as well. Security through obfuscation (by hiding data in a different file format) isn't security :)

    All I was saying was that it might be easier to leverage the existing Windows/.NET authorization stack rather than write your own, based on your own database. As I said above, if you've got more metadata about user access than can be represented in a simple user/group architecture, by all means write your own.
    Tentacle Blog: http://www.tentaclesoftware.com/blog/
    WHS Disk Management: http://www.tentaclesoftware.com/WHSDiskManagement/
    Tuesday, May 12, 2009 9:20 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Also, if you're okay with security through obscurity (which is a valid approach in some circumstances) I still like serializing your data (user, schedule, etc.) objects to disk. It's a binary format, and it's pretty unlikely that the average user of your add-in will have the knowledge to reverse engineer it. Especially a kid; they might be more motivated than average, but it's unlikely they'll have the skills and patience required.

    In my opinion, even SQL Server Embedded is severe overkill for your application.
    I'm not on the WHS team, I just post a lot. :)
    Tuesday, May 12, 2009 4:29 PM
    Moderator