I think you're going to need to provide some more details concerning what you're trying to do. WCF provides for sessionful services, and you can have a singleton service if you want. This all falls generally under the concept of "instance management". In general, these do not require "keep alive" routines, because they live beyond the particular method call. But they also require you to consider a whole host of other factors when designing/building your service. Unless we know some more about what you want to do, and what you want your service to provide, it's hard to provide some guidance.
(This is all irrespective of CSLA, BTW - this is all in the realm of WCF.)
If you want a place to start, you might try looking at the InstanceContextMode property of the ServiceBehaviorAttribute. This is where you tell WCF how it should hoist up your service class. Perhaps that will give you what you need. If not - well, head back here and give us some more detail. ![Smile [:)]](/emoticons/emotion-1.gif)
HTH
- Scott
I'm still a little confused about the requirement, mostly because I'm not sure whether this account is used for database access or if it's some kind of application account. The requirement sounds a little odd, unless this is some kind of variation of user-account-lockout. The way I read this, any ID used by the system is essentially temporary, which means you're issuing new ID's and passwords on a regular basis... are these ID's given out to your users, or is this some sort of back-end process?
In any event, a lot depends on what purpose your Windows service is serving. I'm going to assume for the moment that your Windows service is basically a middle tier, serving up CSLA BO's. Given that, and how I read your requirement, I don't necessarily think this is directly a CSLA or WCF concern.
It sounds like you need to build your service using a login/logout paradigm. Your service contract has explicit Login and Logout methods, and your client app provides credentials to the Login method. The typical way to handle this is to provide some sort of token (a session ID) to the client app as the return value for the Login method that the client then passes in as part of the service calls. That token is also passed to the Logout method, which clears out the session. Any calls in-between validate the token before doing anything.
You can create a sessionful service in WCF to mimic this, though I'm not entirely sure what that would gain you. FWIW, sessionful services in WCF essentially follow this protocol, and you can lean on the WCF infrastructure for timeout/abandoned-session issues. But typically those are created so that the service can retain important state between method calls. Since your basic need is to restrict account logins, and that login information exists in the database (and is potentially shared by multiple client-app instances), I don't think a sessionful WCF service is going to be terribly helpful to you.
Given this, I'd also use the database to store your session info as well. That way, you can rely on database transactions to keep things going, and link your session data to the account info to easily keep track of the number of logins. There are a number of issues surrounding creating your own sessions, from session timeouts to abandoned sessions. Given what you're doing, I don't think session timeouts necessarily apply - but you need to be real sure about that. Not timing out sessions opens a security vulnerability, and can affect the scalability of your app. Abandoned sessions are always an issue, and there are a number of ways to handle that.
In any event, your service code would contain all the logic to create/verify/delete the session information, and you can certainly use CSLA Command objects to interface with the database. Within your actual BO's, however, I wouldn't necessarily embed anything related to this. That's because this doesn't really sound like a business requirement - it sounds more like a system-infrastructure requirement. Since BO's are about containing business logic, I don't think it belongs there. You could certainly create a business object to handle the session stuff, but that would be internal to your service.
If I've misunderstood the requirement, then please fill me in on what I've missed and I'll tell you what of this you can ignore.
HTH
- Scott
OK... I am by no means a licensing expert, largely because I've never had to tackle the problem. Your situation raises some other questions to me, but ultimately they aren't germane to the main issue - they're more a curiosity.
In my opinion, the choices you are making are probably not going to be terribly secure for a licensing requirement, largely because of the point you make - someone could connect to the DB and change your key values. If you're worried about someone connecting to your database and changing the login count, what's to stop them from changing the max-account-login value as well? You can encrypt both values in the DB, which would certainly help, and may be enough to solve your problem. Any kind of plain-text licensing scheme isn't really a licensing scheme... or at least not an effective one. Should you choose to go that route, it's my belief that the encryption/decryption functionality is a service concern, not a BO concern.
FWIW, implementing a "lockout" procedure is also probably not a CSLA concern. Basically, I'm talking about locking an account after a specific number of failed login attempts. It's another piece of the security-infrastructure puzzle that, if you implement it, should also probably be contained within the service and not your BO's. Again, this information is best kept (and encrypted) in the database, to guard against the service-restart issue you mentioned.
(Note that when I talk about a "database", that doesn't necessarily have to be an actual database. That may be what you've chosen to do, but a text file could serve just as well. Your "encryption" could simply be a serialized byte stream - integers and other non-string types don't look like much when serialized to a binary stream, and you could use a .NET object to manage your licensing information and serialize it using the many built-in serialization techniques. Just a thought.)
At the end of the day, all this is basically an authorization/authentication scheme. While there are pieces of CSLA built to integrate with that, you don't use your CSLA BO's to actually *do* that. Your Windows service serves as a "front end" to your business objects, and that's where this code belongs as well.
Typically, licensing issues are also a client concern - after all, the client app is the most exposed piece of the situation. Also, enforcing a licensing scheme at the "server level" can be relatively non-trivial. In any event, the manner in which each piece is "licensed" aren't necsssarily the same, and perhaps you've already got a client licensing scheme. I understand your concern about someone bypassing your client application, accessing your Windows service directly, and mucking about. But if your app users have the skills to do that, then you should probably be looking at professional (i.e. ones you pay money for) server licensing schemes, or getting hold of some documentation around professional-level licensing schemes.
HTH
- Scott
Everything in WCF has a "session", though in WCF it's largely defined by the instance-management attributes. The recommended setting is per-call, which means the session only lives as long as the service-method call. There are other options. Oddly enough, I don't think the recommended setting is the default...
It's been a while since I looked, but I don't think you can attach session-related attributes to an endpoint - I think those are service-level-only. If so, you'll actually have to create a separate service interface and implementation. Both services can be hosted in your Windows service, but it will actually be two different WCF services, along with two endpoints (though, technically, they could share the same TCP/IP address).
HTH
- Scott
Copyright (c) Marimer LLC