Asp Forum - 6 steps to .NET remoting - microsoft.public.dotnet.framework.remoting

Bob Rundle

7/17/2004 6:00:00 PM

Well its been two weeks and I now have my .NET remoting prototype working
completely. Along the way I was able to codify the 6 steps necessary for
getting a .NET remoting project to completion.

1. Enthusiasm
2. Hard work
3. Abject failure.
4. Utter and complete despair.
5. Stroke of unbelievable luck
6. Success.

I've been in the business a long time and what is remarkable is that you can
accomplish in 5 lines of code what used to take 5000. The difference is
that it used to take weeks to write those 5000 lines and now it takes weeks
(including nights and weekends) to figure out which 5 lines of code to
write.

Bob Rundle

5 Answers

jt

7/17/2004 9:23:00 PM

> Well its been two weeks and I now have my .NET remoting prototype
working
> completely. Along the way I was able to codify the 6 steps necessary
for
> getting a .NET remoting project to completion.
>
> 1. Enthusiasm
> 2. Hard work
> 3. Abject failure.
> 4. Utter and complete despair.
> 5. Stroke of unbelievable luck
> 6. Success.
>
> I've been in the business a long time and what is remarkable is that
you can
> accomplish in 5 lines of code what used to take 5000. The difference
is
> that it used to take weeks to write those 5000 lines and now it takes
weeks
> (including nights and weekends) to figure out which 5 lines of code to
> write.
>
> Bob Rundle

and why don't you tell us these 5 lines so we can save weeks?

Bob

Sunny

7/19/2004 2:47:00 PM

"Advanced remoting" by Info Rammer :)

After a week of fights (reading msdn, googling, newsgrouping, etc.) it
took me one day to read the book, and 2 more to try some examples to
figure out how it works. If I have started with the book - maybe the 4-5
days would be enough (not full days of course, I have to work as well :)
).

And when I started there was not so many articles and posts. Now, if you
know the basics and some advanced techniques (all this in the book
mentioned), and good google skills, there will be no problem to get
started very fast.

And I do not believe that Bob can create a full functioning remoting
infrastructure in only 5000 lines, and in only 2 weeks (tested and
deployed). You may take a look at mono sources to see how many lines are
in the remoting classes.

If you not create an infrastructure in 2 weeks, next time you are going
to spend 2 more weeks to tweak and enhance it. While (even if you spend
2 weeks in learning remoting -= believe me, it takes more :) ), next
time you will just put the right 5 lines.

2 c.

Sunny

In article <2ltjlgFgeqqnU1@uni-berlin.de>, me@privacy.net says...
> > Well its been two weeks and I now have my .NET remoting prototype
> working
> > completely. Along the way I was able to codify the 6 steps necessary
> for
> > getting a .NET remoting project to completion.
> >
> > 1. Enthusiasm
> > 2. Hard work
> > 3. Abject failure.
> > 4. Utter and complete despair.
> > 5. Stroke of unbelievable luck
> > 6. Success.
> >
> > I've been in the business a long time and what is remarkable is that
> you can
> > accomplish in 5 lines of code what used to take 5000. The difference
> is
> > that it used to take weeks to write those 5000 lines and now it takes
> weeks
> > (including nights and weekends) to figure out which 5 lines of code to
> > write.
> >
> > Bob Rundle
>
> and why don't you tell us these 5 lines so we can save weeks?
>
> Bob
>
>

Bob Rundle

7/19/2004 3:12:00 PM

Sunny

Perhaps you are right that I should have read Ingo Rammer before starting
the .NET Remoting prototype. However I have heard Ingo Rammer speak and he
is very hard to listen to. I wasn't looking forward to wading through his
book. Also the reviews on Amazon are not stellar.

The biggest trap I fell into was that I already attended a training class in
..NET Remoting (one of those guerilla type things -- we spent an hour on
remoting) and so I thought I had all the info I needed. .NET is so easy
anyway...the code practically writes itself.

Well of course silly classroom examples are one thing and a piece of real
code is entirely different. I kept running into things that were not
recommended: for example I want to both serialize and remote my objects:
this seems to me a very natural thing, but the docs say "no one does this."
And so I am on my own...

Regards,
Bob Rundle

"Sunny" <sunny@newsgroups.nospam> wrote in message
news:%23xz998ZbEHA.712@TK2MSFTNGP11.phx.gbl...
> "Advanced remoting" by Info Rammer :)
>
> After a week of fights (reading msdn, googling, newsgrouping, etc.) it
> took me one day to read the book, and 2 more to try some examples to
> figure out how it works. If I have started with the book - maybe the 4-5
> days would be enough (not full days of course, I have to work as well :)
> ).
>
> And when I started there was not so many articles and posts. Now, if you
> know the basics and some advanced techniques (all this in the book
> mentioned), and good google skills, there will be no problem to get
> started very fast.
>
> And I do not believe that Bob can create a full functioning remoting
> infrastructure in only 5000 lines, and in only 2 weeks (tested and
> deployed). You may take a look at mono sources to see how many lines are
> in the remoting classes.
>
> If you not create an infrastructure in 2 weeks, next time you are going
> to spend 2 more weeks to tweak and enhance it. While (even if you spend
> 2 weeks in learning remoting -= believe me, it takes more :) ), next
> time you will just put the right 5 lines.
>
> 2 c.
>
> Sunny
>
>
> In article <2ltjlgFgeqqnU1@uni-berlin.de>, me@privacy.net says...
> > > Well its been two weeks and I now have my .NET remoting prototype
> > working
> > > completely. Along the way I was able to codify the 6 steps necessary
> > for
> > > getting a .NET remoting project to completion.
> > >
> > > 1. Enthusiasm
> > > 2. Hard work
> > > 3. Abject failure.
> > > 4. Utter and complete despair.
> > > 5. Stroke of unbelievable luck
> > > 6. Success.
> > >
> > > I've been in the business a long time and what is remarkable is that
> > you can
> > > accomplish in 5 lines of code what used to take 5000. The difference
> > is
> > > that it used to take weeks to write those 5000 lines and now it takes
> > weeks
> > > (including nights and weekends) to figure out which 5 lines of code to
> > > write.
> > >
> > > Bob Rundle
> >
> > and why don't you tell us these 5 lines so we can save weeks?
> >
> > Bob
> >
> >

Sunny

7/19/2004 4:14:00 PM

Hi Bob,

In article <ug2vDLabEHA.3508@TK2MSFTNGP09.phx.gbl>, rundle@rundle.com
says...
> Perhaps you are right that I should have read Ingo Rammer before starting
> the .NET Remoting prototype. However I have heard Ingo Rammer speak and he
> is very hard to listen to. I wasn't looking forward to wading through his
> book. Also the reviews on Amazon are not stellar.

I found the book easy to read, and it builds a strong base for further
understanding. You don't have to consider the book alone, there are some
articles on Ingo Rammer's site as well. The worst review at Amazon (when
I bought the book) was that "advanced" is not so advanced. Which is good
as far as it creates the base :). And not true, as it indeed shows some
advanced techniques.

And ... as I said, I also bought the book when I already have spend some
time in fights :)

>
> The biggest trap I fell into was that I already attended a training class in
> .NET Remoting (one of those guerilla type things -- we spent an hour on
> remoting) and so I thought I had all the info I needed. .NET is so easy
> anyway...the code practically writes itself.

Kids, don't do this at home :). The bad part is that the idea of
remoting is very good, but maybe MS have hurried to ship the framework,
so they left out many many things.

>
> Well of course silly classroom examples are one thing and a piece of real
> code is entirely different. I kept running into things that were not
> recommended: for example I want to both serialize and remote my objects:
> this seems to me a very natural thing, but the docs say "no one does this."

Yes, I know what you mean :) It happens all the time. One way or
another, if I remember properly from another post of yours, you need to
marshal and serialize the objects in order that you can save them. If
this is the case, I'd rather put all the data you need to serialize and
save in another class, and reference it from my MBR. Your MBR should be
only like an interface (or wrapper) for the remoting - i.e. accept
connections from the clients and serve the requests. The internals
should be only for the server.

But there is a lot of unexplored space in remoting, I agree. And until
enough applications are written, and experience exchanged, there will be
a lot of pain :). For sure the official docs are not complete.

Cheers
Sunny

Bob Rundle

7/20/2004 12:09:00 PM

> this is the case, I'd rather put all the data you need to serialize and
> save in another class, and reference it from my MBR. Your MBR should be
> only like an interface (or wrapper) for the remoting - i.e. accept
> connections from the clients and serve the requests. The internals
> should be only for the server.

Yes, this is definitely the recommended approach and I have agonized over
the design choices that I have made, since I am obviously swimming upstream.
However I started with a UML design that addressed the business issues in a
comprehensive way. Now, I find out that I am struggling with implementation
issues. I could have started out with a UML design that addressed
implementation issues in a comprehensive way and I think the business issues
would have suffered.

In the final analysis products are built for users and not programmers. As
long as the implementation issues are tractable, then I will stay on my
present course.

Regards,
Bob Rundle

microsoft.public.dotnet.framework.remoting

6 steps to .NET remoting

Bob Rundle

jt

Sunny

Bob Rundle

Sunny

Bob Rundle

x Login to ForumsZone