No More DCOM Part 1
Yes, thats right!, no more DCOM.
Some of the guys here are working on a new architecture for ArcGIS Server.
We have been talking on the proposed architecture they are looking at implementing and instead of going down the track our project team has followered, with the remote DCOM, they are thinking of eliminating DCOM communication totally.
This would involve secure webservices handling ArcGIS Server specific requests on the ArcGIS Server.
This can make communication even faster and with that you have all the advantages of SOAP.
I would like feedback from anyone that has been thinking about this method.
More on this to come 
One Response To No More DCOM Part 1
About Me
Jithen (J) Singh
Senior Technical Evangelist
GIS Technical Solutions Team
Eagle Technology Group Ltd (Esri, New Zealand Distributor)
Wellington, New Zealand
Content Usage
This Work Is Licensed Under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
J,
This sounds really interesting. Not sure if this is similar to what I’ve done(?) – putting a web service on the SOM/SOC machine, and having the client (in my case, a web page) send requests to the web service, which then handles all the ArcObject stuff. This was done b/c my client does not want any DCOM through the firewall, and they wanted the SOM/SOC on the internal network. Thus, web services as a proxy layer. In the end it worked out really well because I could write all kinds of unit tests against the various tiers, and be really sure it all worked before tying in the UI layer.
While getting lunch, I was thinking about this a little – are you taking DCOM out of it entirely, or just out from between the client (windows, or web app) and the ArcGIS Server? I’d be interested to see a high level diagram about how/where you put the web services, and how/where DCOM is eliminated.
Cheers,
Dave