nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Extending Java application running as a Windows service with ArcGIS Runtime

NicoleSulzberger

Hello,

I have an existing Java application running in its own JVM as a Windows Service - so there is no user interface.

At the moment the application is performing crud operations on an Oracle database, but in future should perform crud operations on ArcSDE too. Is it possible to extend this Java application with ArcGIS Runtime?

thanks for your help!

Nicole

Find more posts tagged with

Accepted answers

nita14

Nicole,

As far as I know, you do not use any of ArcGIS products to achieve your goal (supposing you have ArcGIS for Server license to enable SDE on your database and ArcGIS for Desktop for it's managing). Simply you can edit your data using jdbc drivers. I would just stick to the whatever java technology you have been already using. To my knowledge, the only caveat is versioned data and geometry storage type, both of which I mentioned previously.

I don't see much sense in using geoprecessing service since it is rather for analysis, not for editing. Runtime and Engine also are not a case- you do not have any UI. If you really think about enabling editing via ArcGIS for Server, you need to have a feature service which requires ArcGIS for Server Standard edition. Next, you should look at REST API to find out how to make CRUD calls via http.

I hope it clarifies a bit your case;-)

Kind regards,

Adam

All comments

nita14

Sorry for not being enough clear about ArcGIS server beased apps. I meant exactly what Eric said,

EricBader

Actually, ArcGIS Runtime was designed for building desktop clients that can consume services. That is quite different from server-based apps. I actually am of the opinion that it COULD be designed for both, but as the PM for the Java Runtime product, that is selfish of me to say. 🙂

The reality is, Nicole, your question is a valid one. Speaking for Runtime and Engine, and to confirm what Adam said, these are really not good options at this time for what you'd like to do. However, it may be worth looking at Esri's open source Geometry API? GitHub - Esri/geometry-api-java: The Esri Geometry API for Java enables developers to write custom applications for anal…

This can be used in any Java context you wish, client or server. It is unlicensed and unsupported, but there it is.

nita14

Well, I do not want to discredit what you have heard, but the statement sounds odd to me, since, ArcGIS Runtime has been designed to build (ArcGIS) server - based apps. The constraint is that it has to be deployed as 'per user' license. However, my licensing knowledge might not be up-to-date, so I suggest you double check it with your Esri rep.

Regards,

Adam

NicoleSulzberger

I have just checked with ESRI Switzerland about this issue, and they mentioned that according to the Esri Licence Agreement it is not allowed to build internet or server based applications with ArcGIS Runtime SDK. So it looks like we have to move our existing solution to ArcGIS Server.

nita14

Nicole,

I hope it clarifies a bit your case;-)

Kind regards,

Adam

NicoleSulzberger

Hi Adam

Thank you very much for your answer. I know how to do the crud operations on an ArcSDE database, my question was more about which Esri product would be most suitable to use. I am sorry, my question above was not very clear. We could move everything to an ArcGIS Server and build a Geoprocessing Service, but for now I would prefer to leave the system as it is. Does it make sense to use ArcGIS Runtime, or should we use ArcGIS Engine, or do we have to move to ArcGIS Server because of licensing issues?

nita14

Hi Nicole,

Indeed, when working with versioned vector data, use versioned views (What is a versioned view?—Help | ArcGIS for Desktop ). If the data is not - versioned (i.e. default database transactional model), there is nothing to change. Take into account geometry storage type, if crud operations manipulate shapes as well.

Regards,

Adam

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.