I've seen serviced components abused and misused due to inherent limitations in how COM operates and now I’m looking to architect a web based, OO, n-tier system and wish to avoid the same mistakes.
In my system there are two architectural problems:
- Much of the data is common across users, complex and potentially quite large, which leads to a large number of objects when using standard OOD (not so good for COM as I understand).
- Some (but not all) update requests need to be processed in serial, all others concurrently.
I’m considering a windows service application that can hold all the user independent data in a classic object hierarchy.
The serviced components can then call this to resolve business rules and handle processing the request.
However I have not been able to find any information on concurrent access to a service application, let alone on if it is possible to control this in a configuration or runtime manner.
If it is possible to gain concurrent access to a service then message queuing should resolve serializing necessary requests.
So my question is :
Is this feasible
Or is there a better solution that manages large state data when much is independent of the user process
And are there any good articles on OOD and serviced components or any advice on this
Serviced component architecture issues (State management/ OOD).
shals
Scalabiltity of service depends on what technolgy you are using. Old COM components run in a Single threaded apartment - STA. In COM+ applications, the maximum pool size for the STA thread pool is 10 Multiplied by the number of processors you have.
But for a .NET serviced components, they run in a Multi Threaded Apartments - MTA which have no limitation on the pool size.
You can Synchronize the access to an object by using the Synchronization attribute at the class level. see this link for more detail:
http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnpag/html/ScaleNetChapt08.asp
If you are expecting a big number of users, even supporting multiple access may not sovle the problem completely, where the COM+ will spend a lot of time swtiching between threads. In this situation I recommend you to consider clustering your application.
Andy65
It is feasible - however you will have to take care of the scalability of this cache service as well as reading the data from the main SQL server etc.
if you are going to have inter-process communication anyway - you might as well deploy a copy of SQL server on the middle-tier and use database replication to get the non-changing data unto this server. SQL Server already has memory cache inside it additionally since this DB will only have read requests it should be pretty fast
Arnon
Bertil Syamken
Thanks both,
The system is .NET 2.0, and I'm using custom marshalling to allow both local and distributed/clustered implementation.
Excellent link, I'm going to do some reading there and in the other chapters around that.
I need to brush up on my process and thread mangagement as well.
However its not so much the serviced component side I'm concerned with here, more the service application (Windows Service) and OOD when used with COM services.
But that maybe covered in the documentation.
I was agreeing this is a perfectly viable solution.
But in the attempt to be elegant in the solution I'm looking for a way to avoid this.
In that it is a more coherient system if one service can handle both processes, keeps code and functionality together in defined objects.
Of course many systems have failed in an attempt to be elegant. :)
MariaSh
It is OK to cache immutable data - so I don't see a problem with having the SQL server as a read-only cach in the middle-tier as problematic (and as I said use replication to update this cache)
Why do you think this is not scalable
Arnon
Mick Badran - MVP
The potential Scalability of this service is my main concern. If the service application can support concurrent access then the idea should be scalable.
I have/am concidering using a SQL server database in the middle-ware as you mentioned, which would certainly handle reads in a concurrent, scalable manner.
This does not address the business rules and write processes though, and if just used for the read process then this leads to a disjointed system.
The objects are part of an order management system, that many users can append to (with business rules) but not modify. So having a pre-populated structure of the days orders that will be worked on, within a runtime environment that supports concurrent access, this should reduce much of the processing requirements of each call.
I avoid inter-process comms when ever posible, but it is a very limited version I am looking at, that is just to 'lock the door' on a process that is adding to the same order as one that is currently in process, once executing no more comms are required. In fact this may be better achieved with a database than message queueing.
In someways I'm looking to find a way to 'Have my cake and eat it to'.
By having the advantage of complex object sturcture that is overly large in runtime but as such supports widly varied functionallity with easy development.
But not have the COM (and scalability) killing overhead of creating and destroying these, when any given call requires a highly variable number of objects to resolve.
Noddy74
I think you could use the asp.net cache object in the business layer, i read that somewhere. I think this isn't very elegant, but perhaps a little more elegant than having a database in the business layer.
I am just a beginner, i would appreciate any comment about that idea.