MBR IT/.NET 247 : SAO with Parameters but Not CAO. on microsoft.public.dotnet.framework.remoting

SAO with Parameters but Not CAO.

Messages

Related Types

This message was discovered on microsoft.public.dotnet.framework.remoting.

Lord2702

Tue. Sep. 07, 2004 10:15 PM PT

Is it possible to create an MBRO to host as SingleCall or SingleTon(Really,
I do not preferred), with parameters, so that, I can pass a string as
parameters to this MBRO, w/o. changing the MBRO. ? I don't mind shutting
down the remoting server. This could be possible to COM+ ServicedComponent,
with Construct method. I strictly don't want CAO with Factory model.

Thanks.

Reply to this message...

Ken Kolda

It sounds like you want to call a constructor from the client side so you
can pass parameters to it. This goes against the concept of an SAO since,
from a client's point of view, these objects should be assumed to exist
before the client requests them.

Also, if you want a single-call object with a parameterized constructor, how
is that different than having a singlecall object (with no parameters for
the constructor) which then has a method that takes the parameters you want
to pass to the singlecall object. Your singleton could then instantiate some
other object (using those parameters), invoke it and destroy it.

Can you be more specific on your requirements and why a CAO isn't wanted?

Ken

"Lord2702" <Click here to reveal e-mail address> wrote in message
news:u37I%Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

Lord2702

Wed. Sep. 08, 2004 11:40 AM PT

Hello, Ken,

Thank you for your reply.

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.

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.

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..

Thanks.

"Ken Kolda" <Click here to reveal e-mail address> wrote in message
news:%Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

Ken Kolda

[Original message clipped]

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.

[Original message clipped]

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.

[Original message clipped]

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

Reply to this message...

Lord2702

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" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

	System.EnterpriseServices.ServicedComponent
	System.Runtime.Remoting.Services.RemotingService

MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

	Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
	Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com