Thanks for linking to my St. Lawrence County site! All due props to OpenGeo, but I believe the timing of the Community Edition release was more of a coincidence than anything else and Simon’s comment was a bit tongue-in-cheek…

I followed all the following steps listed in the tutorial:

1. Built SimpleSOE_interfaces.dll and SimpleSOE.dll
2. Registered SimpleSOE_interfaces with the tlb option and SimpleSOE.
3. Added SimpleSOE.dll to GAC
4. Ran RegisterSOE to register SimpleSOE
5. Placed the wsdl file in the XmlSchema folder

I created a map service and checked the SimpleSOE option in the capabilities tab. But the service couldn’t be started. There wasn’t much an error message, except the server object instance creation failed on all SOC machines. The verbose log didn’t show anything more than that. Full control was granted to all assembly files. I couldn’t think any way to find out what might be the problem.

Anything is helpful. Thanks!

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