ESRI Dev Summit Day 1

IBM Breakfast

I’ve sat through more powerpoint presentations than I care to remember stating (with no references) that 80% of all business information has some sort of geographic aspect. Then they follow up with some geocentric diagram with GIS is in the middle and surrounded by smaller applications orbiting around it, in synch with Copernicus rolling over in his grave. That didn’t happen this morning.

Instead, reps from IBM presented a new view based on a graphic similar to this, except with the Enterprise Service Bus as the integration platform.  Diagrams similar to this came up several times, almost as if this is becoming a mandala.

This new way of thinking revolves around a workflow, as enabled by the Enterprise Service Bus. Realization: it’s the workflow, stupid! [Reminds me of the old joke “Census Poller: ‘How many people work here?’ Respondent: ‘About half'”] Geography still matters – but only to the extent that it helps organize workflows, not as an end unto itself.

Julio Olimpio quite forcefully made the point that ESRI is committed to IBM, citing numerous multimillion $ projects they’ve collaborated on. Also mentioned 2 days of IBM’s profits == 1 year of ESRI’s profit. Profits matter. Given IBM’s embrace of opensource, I wonder how they view their relationship with ESRI compared to opensource GIS.

WebSphere looks cool. I’ve been dabbling with the freely downloadable Windows WF extensions. I hope to soon test some workflows with GIS-based activities. I don’t see any place to freely download something from WebSphere (if anyone does, please let me know). This redpaper seems to go into details of what they presented. I wish they would have gone into more detail about what differentiates them from Windows WF. Maybe they realized they’d be perceived as biased so they don’t bother. I look forward to tomorrow’s presentation by Mark Driver of Gartner group, I hope he’ll go into this. I wonder if he’ll talk about open source, as he has in the past.

Plenary Session

Attendance: 1600 (some said 2000) twice what it was in 2006.

Estimated Percent Male: 95%

Estimated Median Age: 40

The mandala for the Framework had 3 circles: Desktop, Server, and ArcOnline – unlike the mandala here, that has 5.

Others have blogged about what was said, so I figure I’ll blog a bit about what was not being said:


Very little mention. It’s still there and its not going away. The web ADF is growing faster than the COM libraries. Service Packs will now contain new functionality. Was implied a lot of the new functionality will be in the web ADF. Interestingly, lots of code was shown, but no OMD’s or any UML that I can recall.


In the past there was a lot of whining about price. Didn’t hear any of that today. Maybe people realize ease of deployment justify license costs.

Custom Features

I guess Class Extensions are now the recommended approach. Larry Young did a good job presenting Class Extension demo. What ESRI really needs is a new class extension called ClassExtensionContainer. This would follow the composite pattern. Let’s say I wanted to implement the classextension Larry showed us, only to find my featureclass already used the timestamper class extension. Well, if we had something like the ClassExtensionContainer, we could add both as subclass extensions. We would also need a new optional interface with something to establish what order the classextensions are notified for events. Maybe something analogous to IComPropertyPage.Priority.

Moving ArcObjects Code to ArcGIS Server from ArcGIS Desktop

Hosted by Jian Huang and Allan Laframboise. This was excellent. By the afternoon I was so saturated with new material from earlier sessions, it was comforting to see familiar desktop concepts along with a migration path into ArcGIS Server. A lot of good performance statistics for alternative approaches were presented. I look forward to seeing these posted as samples. Would have been nice to hear about debugging Server Object Extensions (SOE’s). I haven’t found a way to step through execution of an SOE using the debugger. I’m wondering if it might be a good practice to develop a class that implements both IServerObjectExtension as well as IExtension so that I can debug it using Arcmap as a test harness.


8 comments so far

  1. Ron Bruder on


    After attending this session, I returned back to my room and immediately researched SOEs. I am looking for some confirmation on one item. On a few of the pages, samples actually, there’s indication that a pooled MapServer SHOULD be used. I’m looking for an indication of whether a pooled MapServer *MUST* be used. Can you confirm whether that is the case? This bit from one of the examples seems to indicate that it is indeed a requirement:

    “The server object extension in this scenario extends the MapServer with specialized functionality exposed as a stateless method on a custom interface. As a result, you should configure the server object extension with a pooled MapServer.”

    If so, I believe, that rules out all applications that offer editing (which require a non-pooled Server connections) from using COEs.

    I guess the COM Utility class approach is the the next best option for editing apps.

    Enjoy the conference! If I catch you along the way, I’ll be sure to say “Hello”.


  2. […] write up’s Steve! Kirk Kuykendall has also made a post about this day. You can find this here: The day ended off with a the Developer Summit dinner. Last year we had it as part of St Patricks […]

  3. Greg Manship on

    I would like to respond to the initial statement regarding an Enterprise Service Bus and Microsoft’s Windows Workflow Foundation and clear up a perception that was created. First off, this is not an applies to apples comparison of the two technologies. No customer would look to compare the technologies, as Microsoft’s WWF is not designed to be an ESB. An ESB is designed to address middleware challenges as new applications are developed, there come new interfaces to build and maintain, which in turn create a barrier to future modifications to your IT infrastructure and existing assets that should be available for reuse in a Service Oriented Architecture. As new standards emerge, integration developers must spend increasing amounts of time to develop support for and test against those standards internally. The result is a sea of connectivity as developers connect IT applications manually from point to point to solve today’s problem without an eye to future requirements. The ESB eliminates the costly approach of building point to point integration scenarios, and the maintenance of these connectivity points between applications.

    IBM’s Enterprise Server Bus (ESB) is designed to address many middleware needs such as providing universal connectivity for your integration needs. It enables the developer to abstract their data away from protocol and transport specifics, separate information distribution from the actual business logic that governs that distribution. This capability, in turn, makes the data centrally available within the ESB, and offers the potential to develop new, value-add services that can use your critical data. Through this abstraction, you can gain the flexibility to introduce new services gradually without having to change existing application code to realize the benefits of those new services. Last, through the rich protocol- and message-format conversion services of advanced ESB technology, you can easily add new information feeds to your systems as the need arises.

    Clearly this is not what a workflow application/solution is designed to meet. As Microsoft’s Windows Workflow Foundation is not designed to address the capabilities of an ESB, and this is something Microsoft would agree upon. Microsoft has positioned WWF as a general foundation for workflows; Windows Workflow Foundation targets a number of goals such as providing a common workflow technology for Windows, offering a workflow framework for diverse applications, and unifying system and human workflow. This is entirely different than what an ESB is designed to accomplish.

    To state that all applications should have their application logic embedded in workflow, would defeat the purposes of a Service Oriented Architecture an ESB. This was not what was discussed by us at IBM at the conference. Workflow may initiate a business process that then enables an ESB to execute many processes and return results back to the application, these processes may run across a diverse set of platforms. The ESB should enable any application that has workflow requirements, may it be human task oriented, business state machine or long running transactions to have these processes executed closest to where the data resides. I am more than happy to expand this conversation with anyone who has any questions on the subject whether it is via a conference call, email or this posting. I may be reached at

    Thank you,

    Greg Manship

  4. kirkktx on

    Thanks for the feedback Greg.

    Sorry for trying to compare WF Foundation with ESB. Would it be more realistic to compare a Windows WF-Sharepoint solution to WebSphere-ESB ?

    Suppose I am providing advice to a large organization that has two (somewhat competing) groups. One uses WebSphere, and the other Microsoft Sharepoint.

    If a group is using WebSphere, does this mean they already have some sort of ESB in place ?

    Suppose one of my tasks is to identify alternatives for how ArcGIS applications can be integrated into an enterprise workflow. Let’s say, for example, the process involves permit approval where GIS is but one component.

    Could one alternative be to leverage the ESB using WebSphere to add GIS as outlined in the Redpaper?

    The other alternative would be to leverage Sharepoint using the Microsoft WF perhaps with the BPEL extension (?)

    Is this an accurate comparison?

    Thanks again,


  5. Greg Manship on

    Hi Kirk, a more realistic comparison of platform technologies would be Microsoft’s BizTalk Server versus the IBM WebSphere ESB platform. BizTalk is designed for business process management; where as we at IBM would compare that technology match to our WebSphere Process Server (WPS) to BizTalk. Now BizTalk supports the import and export of BPEL, but that BPEL cannot run natively within BizTalk, it must be converted to C# to be executed, and WPS would be comparable in that BPEL code can be executed at run time without having to rewrite the code in java, this may include long running transactions, human workflow etc. Now some of that BPEL may be executed and be presented in a presentation layer of a portal, such as Microsoft’s Share Point, or IBM’s WebSphere Portal or any other portal for that matter. So if we had to do a product comparison, it would be WPS to BizTalk, and WebSphere Portal to SharePoint. Our advanced ESB (which makes this comparison more confusing) sometimes is compared to BizTalk but a more realistic competitive comparison is to products such as Tibco or BEA, as Microsoft has not marketed BizTalk as an ESB although from a marketing standpoint they are changing that strategy.

    The challenge that you face, is that when an organization says they are using WebSphere that could be one of 300 different WebSphere products, so we make that difficult from a middleware marketing perspective as to what is WebSphere. A customer may be using WebSphere Application Server (WAS) (equivalent from a marketing perspective to JBoss, IIS etc) which could have nothing to do with an ESB, BPM etc. They may be just using WAS to manage JSP pages; this is in the same logical architecture of a Windows 2003 Server and just pure ASP.NET applications.

    Leveraging an ESB with ArcGIS could be a very useful way to extend the application into integrating additional data points. One easy example to think of that a business partner mentioned to me last week was that they are consistently having customers tell them they don’t need an ESB in that it is easier to just build a point to point integration. Although the initial upfront costs may be less, i.e. software acquisition licenses costs; the maintenance of those integration points becomes costly over time. If all you ever had to do was build one integration point to ArcGIS, in all honesty, an ESB may be overkill, but the value of the ESB is as there are more and more touch points to integrate to ArcGIS, it will reduce the complexity, management of data etc. Think if you had 7 applications to integrate together, there could be a total of 42 different integration points if all 7 applications needed to touch each other, quickly that can grow into a brittle, inflexible architecture patterns to manage and maintain, never mind the impact to what happens when you need to upgrade one of those 7 applications.

    Let’s say we take your example of workflow with ArcGIS. The workflow may get initiated via SPS 2007, and there could be bits of human workflow. At some point in the workflow, the process may need to step over to ArcGIS which could be running on a non-Windows platform, this process could be a BPEL extension (which is a web service), natively for SharePoint to connect out and integrate to backend non-Windows systems could become a challenge. Then that process may run in ArcGIS which has the process go off and collect many different data points from other systems, i.e. Oracle, SAP etc, this would be where an ESB could enhance the value of ArcGIS across the enterprise. Maybe in the flow of the data, a Web Service needed to be binded to JMS, something that Microsoft does not support, but again an area where the ESB would help ArcGIS extends it value throughout the enterprise without having to code that integration. The end result would be that either ArcGIS or the ESB would send the results back to Sharepoint whether it is via a web service or some other data format that SharePoint can handle to expose the data in a webpart.

    Let me know if you have any questions, understanding the entire WebSphere product stack is a challenge due to so many products and understanding what is best for which scenario.



  6. Grace on

    Kirk, per your earlier question, IBM has many WebSphere downloadable products for trial. Please visit:

  7. Jian Huang on

    I didn’t test if pooled server object is the requirement.
    But if you applied non-pooled server object to SOE, it just defeats against the purpose of SOE. SOE is holding some expensive resources in memory and allowing them to be shared by any user who accesses the web app. If using non-pooled server object, ArcGIS Server will create new server object instance for each user and initialize it at runtime. So it’s no difference to create a utility com object or more expensive.

  8. minlynch on

    To anyone above that can offer a help on my SOE question:

    1) I developed a SOE that runs on ArcGIS Server backend, call “MyDoSomethingSOE”. The back-end SOE project has following dlls:

    MyDoSomethingSOE.dll (class that implements the interfaces)
    MyDoSomethingSOEInterfaces.dll (interfaces class)
    MyDoSomethingSOEPros (ArcCatalog property page)

    the server-end dlls registered on ArcGIS Server fine and runs with SOC fine.

    Now when on Web ADF end, when I obtain my “MyDoSomethingSOE” IServerObjectExtension and try to cast it to a interface type in my MyDoSomethingSOEInterfaces, I always get “null”. Where should I look to see what I can’t cast it to my interface type?

    2) I try to using “Attach Process”in my Visual Studio 2005 to my remote ArcGIS Server for debuging, don’t know which “ArcGIS SOC” process I should attach and even I attach them all, don’t seem able to debug it although the Remote Debug Monitor says it is connected. Any idea how to debug this way?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: