There are two parts to a successful pattern with respect to Java Server Object Extenstion (SOE) development which emulates Java EE patterns of separating reusable business logic from specific service level logic. David has a terrific introductory post to SOE’s which you should read if you are new to SOE’s. He profides links to the online documentation as well to help get you started.
Reusable Business Logic pattern for SOE’s.
SOE’s extend Server Objects by producing a feature capability on a Server Object. At 9.3.1, Java supports SOE’s with Map Server Objects, so Java SOE’s produce a feature capability on Map Server Objects. There are multiple steps to synchronizing a SOE feature capability with Map Server Objects. First we must deploy/register the SOE so the ArcGIS platform can use it and then we need to enable it on a Server Object Type. For Java, we are currently limited to Map Server Objects. Once we enable SOE’s on a Map Server Object, it’s feature capabilities are available on all Map Server Objects. Given this design feature, the Reusable Business Logic pattern promotes encapsulating all business logic (feature capabilities) in SOE’s such that they can be used across all Map Server Objects they extend. Examples would be, export layer as shapefile or ESRI GRID, Layout View for printing or cartographic products, distance calculations to features, proximity analysis, etc.
Once our SOE has the encapsulated reusable business logic as a feature capability on all of the Map Server Objects, we can now extend the Web ADF to create service level features. This way we don’t put all of our application logic into SOE’s which are specific to a single Map Service. This could cause performance/scalability issues in an enterprise class architecture so by using this pattern we aim to decouple the service level logic from the business level logic.
As an example of using both parts of this SOE pattern, lets examine a hypothetical Insurance Application which requires spatial functionality to help determine a risk assessment to be used in the underwriting process. The application features and results are detailed below:
- Geocode an address
- Determine distance to facilities
- Determine proximity to natural hazards and zones
- Determine what rating territory address is located in
- A Spatial Risk Assessment value (number)
Using the pattern described above, we would abstract the features into the SOE and use the Web ADF for specific application service level logic. An example of breaking our features into SOE’s and Service extensions are offered below:
Reusable Business Logic:
- Parameters: Takes an address and an array of n layers.
- Returns: An array of distances from address to the layers submitted.
- Parameters: Takes an address, an array of n layers.
- Returns: A Proximity value and/or geometry representing proximity values spatially.
- Parameters: Takes an array of distances (double), an array of proximity values (double), and a rating territory (integer)
- Returns: A Spatial Risk Assessment value (double)
Spatial Risk Assessment Task (Extend the Web ADF Task Framework):
- Address, user can select a feature address from the map.
- Facility Layers, user can select from a list of layers or on the map.
- Hazard Layers, user can select from a list of layer or on the map.
- Hazard Zones, user can select from a list of layers on the map.
- A Spatial Risk Assessment value for the address submitted.
The user application workflow presents a Web Application that has a Spatial Risk Assessment Task which collects an address parameter from selections made by users either by entering an address into a form or selecting a location on a map. Once the task has the address it then goes through the following workflow:
- Gets distances from Distance SOE.
- Gets Proximity values from Proximity SOE
- Searches Rating Territory DB/layer to get a rating territory from address
Now the Web Application Task submits the return values of distances, proximity, and rating territory to Assessment SOE for a Spatial Risk Value associated with the address submitted or selected from the map and returns this to the user.
This example architecture separates out reusable spatial business logic from map service specific logic and data. You could encapsulate all of this logic in a single SOE, but this is not a preferred approach for enterprise applications as it would be bound to the service level of the application and not reusable in the enterprise.
The ArcGIS ArcObjects .NET Geoprocessing Class provides you with an easy way to execute GP tools in a pure .NET programming environment. In some cases however, you may want to pass in multiple input values e.g. feature classes, just like you can with the GP tool dialog in ArcCatalog.
So how can you accomplish this with .NET Geoprocessor class?
Well actually, there are three ways:
1. Use the parameterized constructor and separate the string parameters with a “;”.
Dim union As ESRI.ArcGIS.AnalysisTools.Union = New ESRI.ArcGIS.AnalysisTools.Union(“c:temptest.gdbstates;c:temptest.gdbcounties”, “c:tempUnion_Output.shp”
2. Use the object properties and separate parameters with a “;”.
Dim union As ESRI.ArcGIS.AnalysisTools.Union = New ESRI.ArcGIS.AnalysisTools.Union()union.in_features = “C:temptest.gdbstates;C:temptest.gdbcounties”
union.out_feature_class = “C:tempUnion_Output.shp”
3. Use a GpValueTableObject (probably the least widely known method, but very powerful!)
‘Feature Class Objects
Dim gpUtils As IGPUtilities2 = New GPUtilitiesClass()
Dim inFeature1 As IFeatureClass = gpUtils.OpenFeatureClassFromString(“C:temptest.gdbstates”)
Dim inFeature2 As IFeatureClass = gpUtils.OpenFeatureClassFromString(“C:temptest.gdbcounties”)‘Create and populate a Value Table Object
Dim vt As IGpValueTableObject = New GpValueTableObjectClass()
Dim obj1 As Object = inFeature1
Dim obj2 As Object = inFeature2
vt.AddRow(obj2)‘Run the Tool
Dim union As ESRI.ArcGIS.AnalysisTools.Union = New ESRI.ArcGIS.AnalysisTools.Union()
union.in_features = vt
union.out_feature_class = “C:tempUnion_Output.shp”
NOTE: If you want to union more than two feature classes then you will need an ArcInfo-level license. See these links for more info:
How to Access Licensing and Extensions for the Geoprocessor
Licensing for Geoprocessing Tools
Learn more about programming with GP in .NET.
With contributions from Ralf Gottschalk, ESRI Technical Support
Starting with 3.2 Eclipse began to use packages instead of version numbers for each major release:
3.2.x = Callisto
3.3.x = Europa
3.4.x = Ganymede
Generally speaking, our Eclipse plug-ins work with Callisto and above. The server plug-ins require Europa and above. But there are some exceptions. Eclipse’s update manager usually does a pretty good job so you will normally not be able to install plug-ins that aren’t supported by a particular instance of Eclipse. For example, trying to install ArcGIS server plug-in on a non-JavaEE version of Eclipse will result in an error.
It can be confusing to tell which version of Eclipse one has, follow these steps to confirm your version:
- Select ‘About’ in help
- Your Eclipse version will show up in the ‘About Eclipse Platform’ dialog.
- Further configuration details can be viewed by clicking the ‘Configuration Details’ button.
The most popular bundles appear to be Eclipse IDE for Java EE Developers and Eclipse IDE for Java Developers. Our server plug-in obviously requires the Eclipse IDE for Java EE Developers bundle. You can still start with the Eclipse Classic SDK bundle although our plug-ins will not work with the classic bundle of Eclipse. Specifically our core plug-ins depend on the org.apache.xerces plug-in which is not available in the SDK bundle, but is included in the Java EE and Java bundles. If you choose to use the Classic SDK bundle, you will be required to manage the dependency plug-ins manually starting with the xerces plug-in. Since 9.3, we introduced a new feature in the server plug-ins to support drag-and-drop style of web application design. This feature is only available in Europa and above. So the server plug-ins now cannot be installed in Callisto.
As of Eclipse 3.4/Ganymede M6, the Eclipse SDK contains a new provisioning system called Equinox/P2 which replaces the Update Manager as a mechanism for managing Eclipse, searching for updates, and installing new functionality through plug-ins. Experienced users will notice the new software update dialog which replaces the ‘Find and Install/Manage Configuration’ approach. The big change is the concept of ‘dropins’ folder which is a default ‘watched’ directory and scanned during start up. This allows for changes to be immediately applied to a running system. Plug-ins and features added to the dropins folder are properly installed into the system rather than being forced in by prior versions using the plug-ins folder concept. Plug-ins installed via dropins behave exactly like plug-ins installed via the user interface. Something to note is that updating plug-ins located under the dropins folder through the UI will result in updated plug-ins being saved under the main eclipse/plugins & eclipse/features folders and not under the dropins hierarchy as one might expect.
If you use multiple eclipse installations, you can configure a central shared dropins folder where you can put Eclipse plug-ins used by all your Eclipse installations which links back to your central location.
The Equinox p2 update UI supports drag and drop of an update site URL straight from your browser or from your OS file manager for local sites. If you choose to use the UI to install plug-ins they lose control of where Eclipse installs the plug-in as all plug-ins/features go to the default location, which can be a bit overwhelming.
Finally, you can also configure Eclipse 3.4 to use the legacy update manager which reverts Eclipse back to the ‘Find and Install/Manage Configuration’ approach from previous versions.
Eclipse Galileo arrives in 3 weeks on June 24, 2009.
Now that many of you have had the opportunity to use the Code Galleries we would like to get your feedback on some ideas we had for future enhancements.
To get the discussion started, we’ve posted a new poll here with the following choices:
- Contact the Author (email directly)
- Discussion Forums (for highly active entries)
- Collaboration Support (project hosting/collaboration)
- Versioning Support (upload ver 1.0, 1.1…)
- Sort by date added (easier to find newest)
- Improved Search (search across all galleries)
Please take a moment to vote for the #1 enhancement that is most important to you. If you have any other feedback related to Code Gallery enhancements, we encourage you to leave your comments below.
Are you heading out to SanFrancisco this week for JavaOne 2009 conference? Our developers and product Engineers are also packing their bags as we speak. We have our own booth at JavaOne! Our team had been busy all this week, working on great demos for the booth. Please visit us at our ESRI booth (booth #827) and check out the demos on ArcGIS Java technology and recent enhancements at 9.3.1. Better yet, you can also chat with our developers and product engineers at the booth.
Wish you sunshine and see you at JavaOne!
At the Developer Summit I talked with a customer who had a grid computing environment where they needed to handle high volume specialized routing requests. He knew how to do
If you are working with the ArcGIS 9.3.1 .NET SDK, then you may have noticed a small enhancement when coding against the core ArcObjects Primary Interop Assemblies (PIA) in Visual Studio 2005 and 2008.
In previous versions, when you typed in a property or method, you simply got this:
Now the intellisense reads the actual IDL help string from the core COM libraries and displays them for you.
Just a small enhancement, but worth noting.
You will hear me talk a lot about SOEs this year as the best practice for providing low-level GIS functionality on the web. What are these SOEs and why should you use them? An SOE (Server Object Extension) is a class and a set of methods that are developed to run within the SOC and then can be called by web applications. We just introduced them in Java in ArcGIS Server 9.3.1 and I think they may be the most important thing the Java team worked on at 9.3.1.
What are the advantages of writing an SOE?
- Modularizing your code. SOEs allow you to separate low-level ArcObjects business logic code from presentation code. ArcObjects developers can write SOEs without knowing JSF and JSF developers can create great web applications without knowing ArcObjects.
- Performance. There are several cases where you will see huge performance gains.
- Round-trips. A lot of developers have written code or tasks that take lots of round trips to the Server. In many cases the calls to the server don’t take a lot of processing time but the network overhead is killing their application performance.
- Fine-grained ArcObjects. If you need access to fine-grained ArcObjects you should put that code in an SOE. Fine-grained ArcObjects code almost always requires lots of round-trips. Use an SOE.
- Data Analysis. If you are transferring data to your application for analysis then you should really think about either a Geoprocessing model if possible or an SOE for complex analysis. For example, one developer I met wanted to get the median value of one of the attribute fields. He queried all records and then computed the median in his JSF code. When we moved his code to an SOE there was a 75% performance savings. The only time you should be transferring data from the SOC to the client is to present it to the user.
It’s SOE Easy!
We have put a lot of effort to make the development and deployment of SOEs easy. Take a look at the documentation on SOEs to find out about them.
Since the ESRI Resource Centers were released over a year ago, the Code Galleries, organized by product and technology, have been a very popular place to upload and download ArcGIS code samples, models, and scripts. Many staff from ESRI and the global ArcGIS developer community have participated in uploading hundreds of samples, and to date, there have been thousands of downloads as well. As described in a previous post, they are quite an improvement over the otherwise very successful “ArcScripts” area on the ESRI Support Center.
But now that there are two places for accessing samples on ESRI’s website, a few questions have come up over the past year from the developer community. Here is a short Q&A below to help answer these.
When should I use the Code Galleries?
Searching: Use any of the dozen or so Code Galleries (here is one example) when you want to search for the latest code and application samples from ESRI and the developer community. Each entry is fully described, searchable, and many have video or Try It Live links for seeing the sample in action before you download it.
Sharing: Use the Code Galleries when you have created helpful samples and would like to share them with the rest of the commmunity.
When should I use ArcScripts instead of the Code Galleries?
ArcScripts continues to exist for older products and versions. If you cannot find a resource center and code gallery for the sample you are trying to search for or upload to, then feel free to use ArcScripts for those. Some examples of ESRI’s older products and technologies that are not represented on the ESRI Resource Centers are MapObjects, ArcView 3.x/Avenue, and ArcIMS.
Should I upload my entry to both ArcScripts and the Code Galleries?
That is not necessary. If you want your sample to reach the widest audience, and you are using current products and technologies, then the Code Galleries will give you the best results. However, you will need to continue using ArcScripts if you are searching for older technologies such as MapObjects, ArcView 3.x/Avenue, ArcIMS, or any other older product not represented in the ESRI Resource Centers.
Will ArcScripts be phased out?
Yes, over time. But as long as users and developers are finding those older code samples and tools helpful, it will remain.
- EDN Team
We wanted to introduce you to a few important tools for your HTTP debugging toolbox: Fiddler and Firebug. If you are building Internet applications, these tools can help take a lot of the guess work out of questions such as “Why isn’t my app connecting to the ArcGIS Server REST endpoint?” Or “Why isn’t my map loading when I open the app in a browser window?”
- Built for .NET-based machines, but it works with both Internet Explorer and Firefox.
- Installed as a standalone application.
- Logs all HTTP and HTTPS traffic between your local machine and the internet.
- Works with FireFox and installs as a browser add-on.
Both Fiddler and Firebug let you examine many different aspects of the HTTP connection such as URL pathnames, error logging, as well as information contained in the request/response headers and response body.
To find more information on all the other useful features included with these tools, be sure to check out the Fiddler docs and the Firebug docs. But, if you just want to look “under the hood” and see what’s going on with your Internet applications, then these are the right tools for the job, and they may save you a lot of time when diagnosing problems.