“more boilerplate than there was on the Bismarck.”

Oh yes we are all laughing now ha ha. You think this kind of talk is funny yes?

It is true I know of this TellyTubby. It is said that he works in one of those one-piece “day suits” for babies or divorced women from East Berlin who watch TV all day long.

He says “Remote objects [] are a big hammer.” but maybe a toy hammer and a rattle would be right for him, no?

Here Mr TellyTubby. I make it easy for you. Go to this page:

http://edndoc.esri.com/arcobjects/9.2/NET_Server_Doc/developer/scenarios/extend_svr_object.htm

There is a nice simple SOE example, even you might understand. Maybe you change some variable names and pretend it is your own original work yes?

I’m still hopeful that you will give us your thoughts on this issue, but Gunter’s interpretation of my question as the old “corba/dcom vs webservice” chestnut misses the point.

I’m really more interested in how many COM contortions developers are willing to go through in order to get themselves..

a) *stateful* remote objects

and (thus)

b) an enivonment where they can write the same kind of C#/Java that they could in a non-distributed (eg ArcMap desktop) environment.

My other pet theory is that developers who wouldn’t otherwise bother with COM, are building SOE’s because ESRI seems to be steering them that way. They are simply following the ESRI examples and generating more boilerplate than there was on the Bismarck.

There are good reasons for using DCom of course. In particular, you can buy good DCom books for one dollar on Amazon because they were all written in 1997.

Also, it is wicked fast. Yesterday I compared running a COM server on the same machine (cross process), vs running it on a different machine (on the same network). All the server did was return a meaningless packet of data of a requested size. To my amazement, as long as the packets were less than about 20K it was actually FASTER on the remote machine (which was of a lower spec than the client). I’m not even sure I believe these numbers! Perhaps this tells us that local COM servers are super slow.

When Gunter talks about re-use, and integrating with other “similarly remoted” apps, I concede that these are real benefits -I’m just not sure how many SOE’s are implemented for such valid reasons.

Remote objects (ie stateful ones) are a big hammer. I am not religiously opposed to them -but you do pay a price (complexity,scalability,fault tolerance,versioning) . I simply wonder if this style is being used “just because”

-best regards from the hot-tub

TT and Frieda

btw: Gunter’s emotional response would make more sense if he mentioned that he is super-pissed at me for stealing Freida. He took her to a “GIS at NATO” evening, and she went home with me. Now we are “combining in new ways our components every day”, while Gunter presumably plays with the Python.

You do well to ignore this silly question. This Telly Tubby is a (how do you say it) “scripting rabbit”.

“Who uses remote objects” he says, and I am laughing ha ha. At Siemens we use DCom and Corba all the time being much more stable and fast than toy “web services” like this TellyTubby asks for.

MY SOE is finished running when his XML is still parsing. We are combining in news ways our server components every day, while he is making from scratch yet another webservice, and another, and another until he makes just the stinking pile.

We are doing the integration with every enterprise system, similarly remoted, while he makes only his maps. And he cannot even spell extension.

I am thinking that this TellyTubby is spending too much time playing with his Python -yes?

Gunter

i never thought i would be writing to your magazine
i’m a marine, stationed in germany -working on ArcGIS server applications in a hot tub with my broadminded girlfriend

what we would like to know is: -what, in your view is the value in a server object extention (with all that baroque antique dcom complexity) over a simple GP tool called via soap? These can be written against the ArcObjects api too yes?

True, dcom gives you remote objects to play with -but to what end? How many production solutions really involve remote objects?

I struggle to see the value (but then i struggle to see my toes these days)

yours
TTand Freida