Lord2702
9/8/2004 10:52:00 PM
My idea is to have an MBRO or whatever object, but it should be
configurable. Now COM+ serviced Component allows you to pass a string, which
I can parse it easily, these parameters configures the whole object, so
passing parameters to every function call is useless.
I have not tried more with SingleCall and SingleTon, and their performance,
but this is true, that I want a stateless object, for many users/ clients.
Now, if object has many methods that clients are going to call, this should
execute for sometime. This works exactly in JIT activation with Object
pooling. Your clients have many objects in pool but not activated, soon they
call on method it activates and deactivate on finish of methods, this way
pooled object is free to other clients. Which gives optimum performance. But
now, if I host this COM+ object on SingleCall server, then both does the
same thing. Then why should I not use MBRO with SingleCall, that saves my
burden to develop and fight with COM+ layer. Because COM+ component has to
register and must be install on GAC. Where as MBRO can be on your
application directory, I mean Interface assembly. Also, COM+ can get all the
exception thrown from server, debugging COM+ needs to use the surrogate
method dllhost. Now just to get rid of all these problem, I thought, It
would be good to use SingleCall MBRO. Only one thing, COM+ gives a security,
that means only those clients will access your component, to whom you
permits. In console based remoting server we do not have any security, but
then I will install it on IIS. But, after having all these thoughts, my
design HALTS, at the configurable MBRO.
"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:O4ccKEelEHA.3016@tk2msftngp13.phx.gbl...
> > I want to handle multiple clients, plus with speed, and to use server
> > resources as minimum as possible. This is only possible with SAO with
> > SingleCall, since it is stateless, and also gives maximum speed, and I
do
> > not want to maintain state between my clients. Whereas, SingleTon, has
its
> > own state, and about CAO it is going to client side. I don't want all
> these
> > multiple clients maintain their state and lifetime activation of the
> object.
> >
>
> This is not entirely true. A SingleCall SAO does not offer better speed
than
> a Singleton -- in fact, it should generally be quite the opposite. The
> advantage of SingleCall is that it promotes a stateless design which, in
> turns lends itself to greater scalability. There's a difference between
> scalability and performance. Scalability is the ability to take on
> increasingly larger number of clients while minimizing the impact to
> performance, which is the time it takes complete the operations your
service
> provides. Usually you take a slight performance hit to add scalability to
a
> system (e.g. keeping state in a database instead of in memory).
>
> The same goes for server resources. A singleton doesn't necessarily
require
> greater server resources -- that depends on what state, if any, it holds.
> All things being equal, a singleton would actually take fewer resources
than
> SingleCall objects, since there would probably be many single-calls in
> memory concurrently but only one singleton. So, pick whatever architecture
> you want, but be sure that you do it for the right reasons.
>
> > SingleCall activates only when client calls the method on object, this
> > behavior exactly like Just-In-Time of COM+ object.
> >
> > Now, my requirement for asking the parameterized constructor, is because
I
> > want my MBRO should be configurable. I want to pass the parameters like
> > this: strParam = S"ParamOne|ParamTwo|ParamThree" this way I can parse
the
> > string and make my object configurable, so, whenever client want to
> > configure, it should be possible. I can also publish my MBRO with
> > RemotingService::Marshal. But, again its activation is SingleTon.
>
> There is no way for a client to control the construction of an SAO in
> .NET -- that's what "SAO" means, it's server-activated. The server
controls
> the construction of the object. Is there a reason you can't simply pass
the
> parameters to the function(s) you wish to invoke? After all, if the object
> has a constructor that takes parameters, then most likely the object's not
> stateless, which defeats your purpose of having SingleCall objects.
>
>
> >
> > Ok, I don't want to call a constructor from client side, but, really, I
> want
> > my MBRO to be configurable. In my previous post, I mentioned about the
> COM+
> > object, which allows you to configure the object with the method,
> Construct.
> > But, again hosting COM+ object on any remoting server, has its own
> problems,
> > really heavy. You always have COM layer, and remoting layer, between
your
> > clients..
> >
>
> I'm not an expert on COM+ by any means, but when you specify a constructor
> for a COM+ object, doesn't it have to be a constant expression that you
> actually enter as a property into the COM+ console? It can't be passed by
a
> client application at runtime, can it?
>
> Ken
>
>