![tumblr_ks6ye726wN1qznuot[1]](http://mapbutcher.com/blog/wp-content/uploads/2009/12/tumblr_ks6ye726wN1qznuot1.jpg "tumblr_ks6ye726wN1qznuot[1]")
I’m working on a project where I’ve applied the following simple design principle:
“Don’t use ArcObjects unless you have to”
Most of the spatial functionality is delivered via a set of web services and is implemented directly between a custom WCF application server and Oracle (ESRI’s flavour of ST_Geometry). I took this decision for the following reasons:
1. I didn’t want to overly complicate what are essentially simple spatial processing steps
2. I wanted to reduce the number of layers within the application as much as possible
3. I wanted to make the services as fast as possible
However there are cases when I have no option and I have to use ArcObjects – I have implemented the functionality within a Server Object Extension (SOE) hosted within an ArcGIS Server Map Server context which I make remote calls to from the application server. Works Sweet.
For a long time our test manager has been busting my nuts about the crap error messages which are received back from the SOE when an exception occurs, this is basically because I’ve never implemented a useful exception class for my SOE – so this afternoon I did just that. Basically what I wanted was the ability for the application server to make calls onto the SOE and catch the custom exception. The communication between the application server and ArcGIS Server is via DCOM so I have a local instance of the SOE assembly referenced by the application server which means that I can do this:
catch (MyCustomSOEException SoeEx) { ...do something }
However the important thing is to ensure that your custom exception is serializable so that when it is thrown by the SOE it can be serialized/deserialized on the application server. Here’s how you do that:
1. Mark the class as serializable:
[Serializable] public class MyCustomSOEException : Exception { string foo; }
2. Override the base Exceptions Serializable constructor to implement deserialization
protected MyCustomSOEException (SerializationInfo info, StreamingContext context) : base(info, context) { this.foo= info.GetString("foo"); }
3. Override the GetObjectData method to implement serialization
public override void GetObjectData(SerializationInfo info, StreamingContext context) { info.AddValue("foo", this.foo); base.GetObjectData(info, context); }
The Exception class is now ready to be passed back and forth between the application server and the SOE. For example in the catch block on the application server side we can access any custom exception properties if the SOE throws:
catch (MyCustomSOEException SoeEx) { string exceptionProperty = SoeEx.foo; }
The same methodology can be applied to any objects you wish to return from a method call onto your SOE. As long as they’re safely serializable then you’re good to go – Making custom exceptions serializable is particularly important if your developing a server object extension for use by others.
dear sir
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
Mr Butcher
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
Herr MapButcher
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.
This TellyTubby says to us:
“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?