Road Ahead - ArcGIS Runtime

Euan Cameron, Mary Harvey, and Ralf Gottschalk give an overview of the ArcGIS Runtime SDK, a new developer product for creating lightweight focused GIS applications.

Jul 14th, 2011

Start From:
Player Color:

Right-click on these links to download and save this video.


00:01This is the ArcGIS Runtime Road Ahead session. It's set to be a 20-minute session.

00:07I'm not sure if anybody's coming into the room after us, so I'm more than happy and so is Ralph and Mary to…

00:13…to stay here longer if you have questions. We can have questions in the room.

00:18If somebody comes in and wants to present in 20 minutes' time, we can all pile outside and we can answer your questions.

00:23If nobody is in the room, then, and if people want to hang around…

00:27…I’m more than happy to show some more slides and get into things in a bit more detail.

00:31So we'll whiz through this 20-minute slide deck, and then if there's…

00:36…if we can, maybe we can dig in a little bit deeper to the architecture.

00:41So when we think about the ArcGIS system…

00:43…the way that developers typically approach it is the platform that they're developing on.

00:48So developers work on servers, they work on desktops…

00:52…they're starting to work more on mobile clients, and they're also starting to work on online.

00:59The runtime, as a concept, cuts across desktop and mobile.

01:04Desktop, because of the platforms that we're running on up here, but mobile in concept…

01:09…because often you're trying to build applications that are disconnected and they're being used for field use.

01:15And increasingly we're seeing that spread out against…over multiple mobile platforms.

01:21So at Esri, when we talk about runtimes and the ArcGIS Runtime…

01:27…we're really starting to think about it as a series of runtimes that run on specific platforms.

01:35So you'll start to hear more of the term runtime and ArcGIS Runtime being applied to iOS, Android…

01:41…Windows Phone, Windows Mobile, Windows, and Linux.

01:45And what we're going to talk about specifically this afternoon is the Windows and Linux platform, and we'll dig in deep there.

01:53But I just wanted to give you the context of the runtime in general.

02:00So introducing something new, the ArcGIS Runtime for developers.

02:04It's a completely new GIS runtime for Windows and Linux platform.

02:10Although it's brand new, it's still integrated well into the ArcGIS ecosystem…

02:16…so data that you author and maps that you author on the desktop can be used inside of the runtime.

02:21The runtime can connect to services coming from ArcGIS [for] Server or the cloud if you have a connection.

02:26So although it's brand new, it's not something completely different. We've designed it to be part of the system.

02:32It has a very small footprint and a fast display, and it's easy to deploy, and we'll have a look at all of these later.

02:39I'm going through the slides quickly 'cause we don't have much time.

02:42And more specifically, the new architecture supports native code execution for both 32 bit and 64 bit, so there's two runtimes.

02:52And you pick which one you want to deploy…

02:54…depending on the platforms that you're going to be deploying your solutions onto.

03:00And the architecture also utilizes all of the hardware at its disposal…

03:06…so on desktop computers, typical, it's often you have four cores on a CPU.

03:12Sometimes they're hyperthreaded, so if the system sees eight CPUs…

03:16…we'll make use of all of the CPUs and multitask a lot of the operations.

03:21So it scales very nicely, as you add more computing power, and because it's on 64 bit, as you add more memory…

03:29…you'll get better performance as well, 'cause we'll fully utilize all of the memory on the machine.

03:34The architecture promotes an asynchronous programming pattern. You can't avoid this.

03:40If you're a programmer with the ArcGIS Runtime, you will be an asynchronous programmer.

03:45So you ask the runtime to do certain amounts of work, it's doing it, and when it's done…

03:51…it's going to call you back, and all the time your UI threads and your UI application stays responsive for a user event.

03:58So you get a much better user experience that you're able to build into your applications.

04:03We've worked hard to simplify the deployment. One of the goals that we set out was no install required.

04:11Don't need to register DLLs anymore. You just need to copy files from a folder and everything is there…

04:17…self-contained, the application starts up, and the runtime is there for it to work.

04:21And that was to make it easier to deploy solutions.

04:24So it works if you have administrative privileges on the machine; it works if you don't have administrative privileges.

04:30It also fully supports side-by-side deployments.

04:33So each [ArcGIS] Runtime deployment on your machine runs completely independent from any other runtime.

04:40It runs completely independent from any other ArcGIS technology…

04:44…so you don't get rev locked into a situation where your users are on a particular version…

04:49…and you have to keep on migrating your products along with the version that they're on their platforms.

04:55It's all side by side. And we have three SDKs and it's not…these SDKs haven't been built from one central one.

05:04This was kind of the ArcObjects style where we had a COM API and we wrapped it with .NET, and Java, and C++.

05:11We have three from the ground up, SDKs designed and built to be WPF, Java, and QT.

05:18They each share a common conceptual model, so you can, you see similarities…

05:24…but where WPF does things a certain way, we'll fully exploit the platform of WPF and .NET.

05:30Where the Java programmer expects to see something specific to Java, we'll exploit that.

05:35So although yes, they all have a control and a map and layers, a lot of the language constructs within that are specific to the platform.

05:47Yes, we do have SDKs, but it's not just about writing code.

05:49The idea is that you really leverage other parts of the ArcGIS system to provision data and functionality…

05:57…in the way of geoprocessing models into the runtime.

06:01So you author maps on the desktop and you package them and you give the map and the data to the runtime and it uses it.

06:08And we've been promoting that style with [ArcGIS] Engine for a while now, and it becomes a necessity with the runtime.

06:14You can actually ask a server for content, and at 10.1, the server will be able to deliver packages to the runtime.

06:21So you don't always have to provision things up front and deploy your data with the runtime.

06:27You can sometimes just deploy your application and then the application can go and ask the server, Can you give me a tile package?

06:33Can you give me a map package or a geoprocessing package?

06:36And it will pull all the necessary content down onto the local machine…

06:40…where you can then go disconnect it and run in the field disconnected.

06:46Okay, let's move on to some of the functionality. Mapping and cartography.

06:52We support all of the ArcGIS cartography that you'd expect in the desktop or the server.

06:58So Maplex labeling's built into the runtime, and representations, they're there…

07:03…all the symbology, and the layer types that are supported at 10.1 with the server, are also supported by the runtime.

07:12So if you can make your maps in ArcGIS [for] Desktop, you can package them and then use them in the runtime.

07:20There is a limitation that we have.

07:22We don't support custom layers, custom renderers, and custom symbols that you can use on the desktop.

07:28So if you're making use of custom layers, renderers, or symbols within ArcMap…

07:32…you can't package that content and use it in the runtime.

07:36You'll have to move away from your custom objects…

07:39…and make use of representations or make use of some of the standard symbols.

07:44The APIs of the runtime do support some notion of custom symbols.

07:48So you can build custom, fancy symbols on the clients…

07:52…but you can't get your custom symbols from [ArcGIS for] Desktop all the way across to the runtime.

07:58And mapping and cartography's delivered in what we refer to as map packages.

08:02They were introduced at 10.0, and tile packages.

08:07That's a new type of package that we're implementing at 10.1.

08:11Map packages are for dynamic data, data that's changing, and so we ship the raw data…

08:18…and we render it every time the map gets redrawn within the runtime.

08:23That's your classic way of working with data and maps.

08:26Tile packages are exactly what they sound.

08:28They're prerendered tiles that we cook once, deploy to the runtime, and then the runtime just draws the tiles…

08:34…and you get a fantastic performance improvement if you take that approach.

08:39But if your data's changing underneath, that's not suitable.

08:44So we really expect people to start to split their data up into basemaps…

08:48…which they can deliver with tile packages, and then the operational data…

08:52…the data that's changing, maybe only one or two layers, these as map packages.

08:57So that takes us to our first demonstration with Mary.

09:01Okay, so I'm in ArcMap and I'm going to show you how we're going to create a map package…

09:08…and then we're going to flip over and I'm going to show you how a tile package performs in the map control that we've got.

09:13So here we go. There's some data of San Francisco that we're looking at and it's just an MXD floated off into ArcMap.

09:20So this is 10.1, but at 10.0 you can create a map package.

09:26So for those people who know how to do it, they'll know that they'll need to go to the File menu and have a look at Share As.

09:33So Share As has a map package and mine has a tile package…

09:36…because this is a 10.1 version. So just to reiterate, the tile packaging is 10.1.

09:42So if you go into a map package, you can see the little screen that comes up…

09:47…and there's a menu option in here which is Make ArcGIS Runtime Compatible.

09:52So at 10.1 you can make your map packages compatible for runtime. So that's how you'd do that.

09:59So I'm just going to flick out and I want to run an application that's going to show you the tile package in the screen.

10:06I'm just pausing here a little bit 'cause I just wanted to wait and click it, 'cause you can see how fast it loads up then.

10:11So it's a tile package. Euan showed you this data at the plenary…

10:16…so that was the speed at which it takes to load up the map control display on-screen and to see the tile package data. So it's quite fast.

10:23So this is a map control, just in a little window that I've got, and you could place that in your own business application.

10:30You know, that's really what we're talking about, building your own business application…

10:34…putting the map control in it, so, with the tile data…

10:37…then you could then lay your operational data on top of the map package data.

10:42So this tile package has been designed really well, so it's a consideration when you are building a tile package.

10:49So that as we zoom in and out, the different scale thresholds have been set…

10:53…so that the right level of data appears at the right scale threshold that you're looking at.

11:00So, yes, we've got good panning and zooming in here and you can see how it works.

11:06So that's really the…that's how the tile package works.

11:11Alright. Moving right along, editing and support.

11:16The runtime supports editing data in a file geodatabase on your local machine.

11:23It supports editing [Arc]SDE data, maybe on your local machine…

11:28…if you're running maybe SQL Server Express or SQL Server or one of the other databases.

11:35It also supports editing data in an enterprise geodatabase…

11:40…so on a back end, as long as you've got a connection to the database, it supports editing.

11:46It supports simple features. So that's not networks; it's not topologies.

11:53We don't currently support editing features in networks or topologies…

11:56…but simple features, and both attributes and shape are supported.

12:01So we have a demo of editing…

12:05…from Ralph. It's plugged in. [Unintelligible].

12:21Okay, so here I've got ArcMap open and I've created a bunch of feature templates in ArcMap…

12:28…and I can actually share those feature templates right in my map package.

12:31I'm not going to go through that 'cause we're really low on time here.

12:34But I've built a runtime application that uses Java…

12:38…and I've actually imported all the symbols from my feature templates right out of my map package onto these J buttons.

12:45And then what I can do is, I can go in and click these J buttons and start editing my features, creating a new trail here…

12:54…maybe adding a viewpoint over here and a campsite right there, picnic area here.

13:02Now if I go back to ArcMap, this map document does actually point to the same database that I'm editing with the runtime…

13:09…and if I hit Refresh, we could see the edits are right there.

13:13Okay. That was a very fast editing demo, but you get the idea.

13:20We really have to whiz along here. We've got so much stuff to cover.

13:23Alright. Geocoding. We support geocoding, we support composite locators and simple locators.

13:31We do reverse geocoding as well as forward geocoding.

13:36Single-line input, so you don't need to specify and break up all the different fields.

13:40You can just give it the single line and the locator itself will figure out the content of that and do the address match.

13:47So geocoding's all supported and, again, how do you get your geocoder's information into the runtime?

13:52You create a locator package. That's something new at 10.1, and it makes it very easy to deploy locators to the runtime.

14:00It also makes it easy to deploy locators to the server.

14:05Going, moving on straight to geoprocessing. This is a really powerful feature of the runtime.

14:12So we support geoprocessing and that can be standard built-in tools, it could be scripts…

14:19…you can author models using the ModelBuilder part of geoprocessing…

14:22…which has Python scripts and tools, and then execute these inside of your runtime solution.

14:31And the very next question we get asked once we say we support geoprocessing, Well, what tools do you support?

14:37So, the easiest way to say this, and there's a little bit more information later on in the slide…in the slides.

14:43We have three levels of the [ArcGIS] Runtime, basic, standard, and advanced. Basic, there is no GP support.

14:48Basic's all about just drawing a map and there's no editing support in basic…

14:52…but basic comes with a free deployment, so you're not going to get everything for free.

14:59At standard, we…that's where most developers will start to come in and build really rich applications.

15:07You get typically the ArcView level of GP tools…

15:10…plus a few extra ones that we think are valuable for developers building solutions.

15:15So you get point-to-point routing support through geoprocessing at standard.

15:21You get viewshed support at standard, even though these typically don't come as part of ArcView.

15:26And then advanced gives you a lot more of the tools of the toolset.

15:32There's a…if you join the beta program and you download the beta, you get a tool list, which will tell you which tools are supported.

15:40How do you get geoprocessing into the runtime? You create a geoprocessing package.

15:44And when you create that package and you check on that box and say, Make compatible with runtime, it runs a series of analyzers…

15:50…and if you're using a tool that's in a model or in a script and it's not supported, you'll be told it's not compatible.

15:58If you are using a tool that's in perhaps the advanced toolset, you'll be told you need to deploy this with the advanced license.

16:05So you do get told by the analyzers.

16:09So that moves me straight on to another demo from Ralph, and he's going to combine geoprocessing and geocoding.

16:15So here I've got a WPF application. I'm just going to spin it up right now.

16:19This is actually using a tile package like what Mary showed earlier.

16:24So we could see I've got really good, smooth panning and zooming.

16:29It's also consuming a locator package, so as I click on these points and then click in various spots in my map…

16:36…we can see it does a reverse geocode from that point, and I can go ahead and click over here, get another address…

16:44…and then it uses a geoprocessing package to do point-to-point routing.

16:49So if I click on here, the geoprocessing package starts to execute.

16:52I can, since this is all asynchronous, I can still pan and zoom, and then when I finally get my result, asynchronously I see it.

17:02And not only that, this point-to-point routing supports solving routes with barriers.

17:07So if I add a barrier in here and re-solve my route, we'll see a new route.

17:15Okay, another very quick demonstration from Ralph.

17:19Online integration.

17:21So with online, we definitely see there's a shift, a paradigm shift in development…

17:26…where developers today are desktop developers and you've probably worked very hard to create your [ArcGIS] Engine customizations…

17:35…and custom commands and tools so that they work both for [ArcGIS for] Desktop and for [ArcGIS] Engine…

17:39…and moving forward, we can definitely see desktop developers will start to become a mixture of purely desktop…

17:46…or online or maybe a combination of both.

17:49So you have an online solution, they want to go disconnected…

17:52…they'll go then sort of offline, disconnected, and then they'll become online.

17:57And this API that we're working on makes it very easy for you to migrate your code…

18:02…and your applications to a mixture of online/offline moving forward.

18:06So I've got a little animation here. We have the application with your custom components.

18:10They talk to our API. Our API then talks to the ArcGIS Runtime.

18:14Well, exactly the same API can talk to ArcGIS Online or ArcGIS [for] Server.

18:20The only thing that's different is, is my server…is my layer being served up remotely? Or is my layer being served up locally?

18:28The architecture's actually very similar and we're going to exploit that with the API.

18:35Don't think we have an online integration demo. Okay.

18:38So, deployment. Moving right along toward the end of the presentation. No install style of deployment.

18:46The other thing is you only deploy what you need. So if you're not making use of all of the runtime, don't deploy it all.

18:52Only deploy the DLLs that are required to support the functionality that you need.

18:56Again, trying to keep the size of the deployment small.

19:00Each application on a machine has its own copy of the [ArcGIS] Runtime…

19:03…so it's important to realize they all run independent and you can have different versions of the runtime on the machine.

19:09Every application will get its own personal copy.

19:14So that leads me to Mary's demonstration.

19:16So I've got the USB stick here and we're going to…Mary's going to deploy and go through what's on it.

19:23Okay, so I've got a USB stick here and I'm just going to put that in quick and…there we go.

19:31It's in my machine. It will start reading the stick any second. There we go.

19:35I'm going to open up the Windows view.

19:38You can see there's a couple of folders and some other file in there, so I'll just go into this folder here and I'm going to run the .exe.

19:47So what have we got in this folder? That's a little bit quick. [Inaudible].

19:53There's some folder packages with the data in Runtime 400…

19:58…so that is the runtime we're deploying and some DLLs alongside the .exe.

20:02So that is the deployment. The deployment on this stick that we're running right now, is basically that.

20:09You would Xcopy that and deploy that folder. So what have we got here?

20:15I'm going to just move this up a bit and show you what's happened in Task Manager.

20:22So in Task Manager, you can see there's some ArcGIS Runtime .exe processes running and they…running from the E drive.

20:29You can see that. So it is using the runtime that is on this E drive.

20:34Okay, let's just shift and zoom in a bit. So this application is going to allow me to locate a culvert.

20:46I think it's this one here. Okay.

20:50And the geoprocessing task is going to run now to explore the viewshed…

20:55…and it's going to return the viewshed as a result, which we'll see, and…

21:00Yes, this GP package, it's using standard tools to calculate viewshed upstream from the river network…

21:06…and it's also running Python scripts and it's using NumPy as part of its calculation to come up with the Talbot's culvert size.

21:16Standard forestry calculation [Inaudible] defined.

21:18Okay. So we've got a result and I can show you the outline of that viewshed.

21:26Okay, really…

21:27So, if you just stay there, we'll just go back to that folder again…

21:30…just to remind ourselves. That is the deployment. It's those elements in that folder that you can see there.

21:37[Inaudible audience comment]

21:40It's going to depend on the data that's in that...

21:41The size of the folder, as Mary said, depends on the datas of some of…the data to support the models in there…

21:48…as well as the map package that you saw for doing the renderings. So that has an impact.

21:52That could be anywhere from less than a megabyte to, depending on the size of the data, it could be hundreds of megabytes.

21:59The actual size of the runtime to support that is about, uncompressed, ready to use, it's about a hundred and fifty megabytes…

22:08…because that's got all of geoprocessing and support in there…

22:12…but, maybe a little bit less than a hundred and fifty, maybe a hundred and forty megabytes.

22:16If all you're doing is mapping and editing of data…

22:19…and you're not using geoprocessing, your runtime will be under a hundred megabytes.

22:24Okay, I'm sorry to say we've actually failed; we're two minutes over time, but we will keep on going.

22:30Is anybody waiting to present up here and going to kick us off?

22:34Okay, good answer.

22:35Right, let's move along. So this is where the runtime sits when it comes to our existing desktop developer technology.

22:44So you've got right at the bottom end ArcReader…

22:47…moving on up through [ArcGIS] Explorer, these are both free deployments and with increasing functionality…

22:54…and then with ArcGIS Mobile, the tablet edition, it brings in more capability.

22:59And then we have the runtime. And then with more capability is the ArcGIS Engine…

23:05…and then there's [ArcGIS for] Desktop, which has all of the capability for desktop developers.

23:10And we really see [ArcGIS] Runtime hitting that sweet spot.

23:13It doesn't have everything [ArcGIS] Engine has and it won't have everything [ArcGIS] Engine has…

23:18…but it's going to come at a lot less cost and it has a lot of the benefits because it's got this new architecture…

23:24…that it doesn't suffer from some of the negative things with [ArcGIS] Engine, being [ArcGIS] Engine's only 32 bits.

23:32It comes with 450, 500 megabytes of DLLs.

23:37You can't customize the [ArcGIS] Runtime. It's got to be registered, and it doesn't support side by side.

23:41These are the negative things that the [ArcGIS] Runtime doesn't have. So that's really where it fits in your developer options.

23:51How can you get your hands on the ArcGIS Runtime? Join the beta program. You can sign up right now.

23:56The beta program, that URL, the, is available for sign-up. You can log in there.

24:03All you need is your customer number and you can register for the ArcGIS beta.

24:07And then when it becomes available toward the end of this month, you'll be able to download it.

24:13That's how you can get your hands on it right away.

24:15When it's released, final, as a developer, you access it through your EDN subscription…

24:21…and you'll get all the bits required to start building solutions, no matter which API you're using, as part of EDN.

24:27And then once you build your solution, then you need to purchase deployment licenses to deploy it.

24:33And the deployment model that we're following is much closer to the MapObjects style of deployment…

24:39…than the ArcGIS Engine or [ArcGIS for] Desktop style of deployment.

24:45So before we get to questions, I've got to remind you, please fill out your surveys, and then we've got some questions.

24:52So I've got a question for you. How many people have to leave right now?

24:56How many people would like me to dig into the architecture a little bit more? Alright. Okay. Right answer, once again.

25:05Okay, let me…it was kind of ridiculous, I thought we only had 20 minutes, I'm afraid, but…


25:12Let me bring up…

25:13You're not just bringing in an application that's got online not local data together? Is that what you want or just…[Inaudible]


25:18Let me bring up…okay, so we had a…yes, there's a question up front here.

25:29[Inaudible audience question]

25:34So the question at the front here, it's a very good one...

25:36…the tile package, can I create the tile package from a tiled service, or does it have to always be created in [ArcGIS for] Desktop?

25:44The server at 10.1 will support delivering to you, if you ask it, tile packages.

25:50But only if the server administrator allows you to do that.

25:54So ArcGIS Online is not going to allow you to grab its tiles, for instance.

25:59But if you've got your own config…server in the cloud or you've got your own enterprise server…

26:04…you can allow as part of your user's workload, your users can say, Give me that basemap.

26:10And you've already cooked it once in the tile; it's very quick for us to extract that and deliver that as a tile package.

26:17Okay, so this was an architecture…we won't have all the demos here because my cohort, Chris, isn't actually at the conference today…

26:27…but this is a set of slides that we put together for a workshop that we did before the User Conference…

26:32…for a number of attendees, and it gives you an idea on the architecture of the [ArcGIS] Runtime.

26:39And I think once you hear this, things will start to click into place.

26:43And I'll try and get through it as quickly as I can, if I can just work PowerPoint.

26:51Okay, so it is a new…it's a new architecture.

26:57We've learned a lot from previous architectures and previous technology that we've worked on…

27:05…and stories that were and technology that was and an architecture that was good, very good 10 years ago…

27:11…isn't perhaps the way that we want to be moving, moving forward.

27:16And we've really tried to take a very forward-looking approach…

27:23…when we've come up with the design and implementation for the ArcGIS Runtime.

27:29So the first thing to say is, it's a services-based architecture. So what do I mean by that?

27:35Well, we have the GIS runtime. That's the guts.

27:38It's the thing that provides all the functionality, and you access it via services, mapping, feature services, geocoding…

27:46…geoprocessing, geometry; there's a number of services that are available to access that runtime.

27:52And then sitting on top of these services are APIs. So you as a developer don’t have to interact with the services directly.

27:59You interact with a rich API that we've developed in WPF, Java, or QT.

28:06The whole thing we refer to as the ArcGIS Runtime.

28:12So it's all about the services, and the services that we implement and we support adhere to the Geoservices and REST specification.

28:21Now this is a specification that Esri's published and it's actually going through OGC at the moment.

28:28And this is the specification that the ArcGIS [for] Server implements.

28:33So any client to the ArcGIS [for] Server, if they can honor the REST specification, they can connect to ArcGIS [for] Server.

28:39Clearly we have clients, but other companies are developing clients to ArcGIS [for] Server.

28:44Other companies are also implementing servers that deliver functionality…

28:49…through the Geoservices REST specification so our clients can talk to them.

28:54So it's all about the services. So we have another look at it here.

28:57We can replace sort of the individual ones with this ArcGIS REST services.

29:03This is the same architecture that's powering ArcGIS [for] Server, exactly the same architecture.

29:11So the API's on top, that's why I said in the previous slide…

29:15…it's very easy to take your functionality that you develop in the next months and years on the ArcGIS Runtime…

29:22…it's very easy for you to take that and redirect it to the cloud or to the server…

29:26…because they're just supporting the same REST specification.

29:29It's just a little bit of code that's different at the start-up…

29:32…whether you connect to services that you've already published and have running in the cloud…

29:36…or you have to have a little bit of code on the client that spins up with local services.

29:44So the benefits of this as an architecture, very, very clear separation from implementation and consumption.

29:53It's probably one of the biggest headaches that we all have with ArcObjects…

29:58…the fact that our implementation API was exactly the same API that we deliver to you…

30:04…as a developer to consume the functionality. There was no separation.

30:09So that meant, if we modified our implementation, we often broke you as clients…

30:15…because your code didn't stop working and you had to go in with subsequent releases…

30:21…tweak things, change things, recompile, and then re-release your applications.

30:25It also meant we couldn't change the implementation the way that we wanted, so over time our application sometime…

30:33…our architecture's grown wider than we really wanted it because we couldn't touch the code that we'd already implemented…

30:40…so we had to keep on adding new things, when in reality it would have been much better…

30:44…if we could have just ripped out the guts of a piece of our code and reimplemented it.

30:49And we can't do that with ArcObjects. So it's gotten very, very large and very complicated because of that.

30:56With this architecture, we can completely change the implementation.

31:00As long as we honor the REST specification, the clients don't change at all.

31:04And it's a much coarser-grained specification than the fine-grained ArcObjects.

31:08So we have a lot more flexibility on moving this platform forward into the future…

31:13…moving it onto different platforms, for instance.

31:16If you're an application developer and you're in Java or .NET…

31:21…you'll just build one application, and you don't care whether it's 32 bit or 64 bit.

31:26In .NET, if you're WPF, you'll just compile it to be CPU any, and when the application starts up…

31:32…it knows the architecture that it's running on and the virtual machine that it hits and it spins up correctly.

31:41You only have to worry about which runtime you deploy. Do you want to deploy the 32-bit runtime or the 64-bit runtime?

31:49You never have to recompile your code. You just need to pick from the runtime when you build your deployment.

31:54And we have a tool in the SDK to help you build the deployment.

31:58It asks you a number of questions about the functionality that you're using…

32:01…and it will create a package for you, which you can then use to deploy to your end user's machine.

32:09And then, this is the thing about moving forward into the future…

32:14…once you've got your clients, you can really bind on to any REST provider.

32:18It could be the local REST provider, in the case of the ArcGIS Runtime, or it could be the server.

32:26Okay, so this is the runtime. It's important to realize that you can treat it like a black box.

32:33You don't need to know how it works internally to be an efficient user of the runtime.

32:40You need to know how to program against the API, and the internals of the runtime you can kind of leave up to us.

32:49But what I want to do is, I want to share with you what's in the black box…

32:54…because I think it…if you do understand it, or have an appreciation…

32:58…it really helps understanding the API and the programming patterns around it.

33:04So, the entry into the runtime area is the REST services.

33:10So you have your application; bound into your executable is the ArcGIS API.

33:17Now that comes in a series of DLLs or JARs or C++ libraries, depending on which API you're using.

33:26Maybe in the case of WPF, I think there's a maximum of about six DLLs that you might want to bind into your application.

33:34And then you talk through the API to the REST services, and it talks in turn to an embedded web server.

33:44And the embedded web server then decides what it needs to do to handle the request that you've just asked for it.

33:53So if you say, draw me a map…

33:55…the embedded web server needs…the web server itself isn't going to draw the map…

33:59…it's going to get a worker component, and the worker's going to draw the map for you.

34:04And this is a very similar architecture to ArcGIS [for] Server …

34:07…but this is all running on the same machine, and we can have any number of workers spun up.

34:15Now how they communicate through…from the API they talk HTTP REST and they go through to this web server…

34:24…and the web server takes the request, determines how it's going to handle that, and passes them on to these worker components.

34:32And it does that through shared memory, so it's very, it's very efficient.

34:36And when people look at the architecture the first time, they often come back with the question…

34:41…Well, that can't be as efficient as having everything running in the same process.

34:46But what we found…because these services are generally quite grained…

34:50…you don't do lots and lots of chitty-chatty calls like you do in ArcObjects…

34:54…you're making fairly coarse-grained calls like, draw me a map, or perform a geoprocessing function…

35:00…or take this geometry and buffer it and give me back the answer.

35:04You're actually…the call overhead and…introduced, which is only a few milliseconds…

35:09…doesn't add up to a whole lot when it comes to your application.

35:13The other benefit of the architecture is it's asynchronous.

35:16So even though there's a call overhead of a few milliseconds…

35:19…as soon as the call has come into the embedded web server, it returns straight back out again to your application…

35:28…and everything else is happening asynchronously.

35:30So you still…your user experience is still very fluid and very smooth so the user never gets a pause.

35:35The user interface never locks up waiting for the application to do something…

35:39…'cause all it's doing is sending a very quick call in, and getting back, and then listening for the response on the call back.

35:50So the embedded web server runs as a process, and it's a very tight process.

35:57It's just a few megabytes in size and it sits there listening for requests.

36:02It's not a generic web server. It's not an embedded Tomcat.

36:06It's implemented in C++ and its sole purpose is to listen to requests coming in from the API…

36:12…and every application that starts up gets its own web server.

36:17It's not a web server that's one per machine.

36:20You're not running a server on your machine…

36:22…you're just really running a…uniquely tied to your application there's another executable tied to it…

36:28…and the lifetime of it's controlled by the host application.

36:32That embedded web server takes the response and, if required, spins up other processes to do work.

36:39So you'll see here, there's multiple processes. That's why it scales very well if you have multiple CPUs.

36:46And we experimented early on, should we have all this running within one process…

36:52…or should we have it running in separate processes?

36:54And we found that the operating system actually multitasks processes better than threads within one process.

37:05So we get better performance splitting it out into separate processes. We also get more robustness.

37:13If one of these workers has an issue and crashes…

37:18…all the information to spin up the worker in the first place is in that embedded web server.

37:22There's a monitor there. If we see a process crash, it just gets spun up again, within reason…

37:27…because we're not going to spin it up continually if it always has problems.

37:31So it's actually…it's a very robust mechanism.

37:34So your application, no matter what happens down below, your application just continues to function normally.

37:43One of the other benefits is, with [ArcGIS] Engine applications we've often had a request in the past…

37:49…I have an application and I spin up a map control to do a little bit of work, and then I'm done with the map control.

37:56I want to get rid of ArcObjects out of my process space.

37:59But you can't, 'cause we've got lots of singleton objects that spin up and there's a lot of allocate code and memory allocated…

38:06…and the only way you can rid of it is to release your application.

38:09Well, with this architecture, you can spin up the server, you can shut the server down…

38:13…you can spin up services, you can release services.

38:16Every time you do that, all of the resources dedicated to that are released to the OS.

38:25And then the final thing about this architecture is just to stress that these processes…

38:30…they're sharing a lot of memory amongst them.

38:33So all the DLLs that get loaded in, that's memory that's being shared…

38:37…is actually a fairly small private working set of memory that's dedicated to each process.

38:43There's an awful lot of it that gets shared and so it's not a huge memory consumption.

38:49If you look in Task Manager, you'll think, Wow, I'm just about to run out of memory.

38:54Because by default, Task Manager just shows you working set size.

39:00What you really want to ask is, How much private working set is allocated to each EXE?

39:05Because that's the real memory that that executable's using and not the memory that's being shared across all of the executables.

39:16Okay, no demo I'm afraid. Just me talking. The runtime server, it is a server, but not really as you know it.

39:26It does listen on a port for HTTP communication; it's not the public HTTP port, it's a specific one.

39:35It's not tunable, it's not Tomcat, it's not a self…standard server.

39:40It's a really small C++ server that we've developed. It serves only one application.

39:48Multiple applications start up, they'll all get their own individual instance of the server.

39:54So the services that it supports, the coarseness of…the coarse-grained services…

40:00…like the map service and the feature service and geoprocessing service, they're all supported just the same as the server.

40:06Where there are some differences is in the capabilities of the server.

40:09So for instance, a map server is primarily there to serve maps. It doesn't support asking for the map as a WMS.

40:18It doesn't support asking it as KML, because that's not important to our API.

40:23So the capabilities are not the same as the ArcGIS [for] Server. But at a high level, the mapping functionality's the same.

40:31The security, we'll get into that a little bit more.

40:38Because it's not a web server that's open for anybody to just point at your machine. It only runs within your machine.

40:43It won't accept communication from outside and it listens on a private port, so again, it's not an external port.

40:51You don't have issues with firewalls coming up.

40:56Okay, so we have different types of services.

41:00Obviously there's services which don't have any data associated with them.

41:04They're just there waiting to do work. An example of that's a geometry service, probably the simplest service that we have.

41:10You just give it a geometry and an operation - buffer or split or union - and it will return the results to you.

41:18We've got some services that are tied to data and that data could be tiles…

41:26…or it could be features in a geodatabase with a map associated with it, or it could just be the locator of the geocode.

41:35So we've got mapping and a subset of mapping is features.

41:39We have tiled maps and geocoding, and then the other type of service…

41:42…and this is the most complex, are tools and data and that's the geoprocessing.

41:48And this is the most complicated service that we have, where you have…

41:53When you create a data package, a geoprocessing package, and deliver it, it has everything required to run that tool.

42:00So all of the model data's there. Actually the inputs and the outputs of the initial run of that tool are included as well.

42:09And then what you do when you execute, you give it new inputs and it generates new outputs.

42:15But everything required to run that geoprocessing model successfully is included in that package.

42:21Many people here today publish geoprocessing services on the server. Not many.

42:29How many people would like to, but it's just really difficult? Yeah, a few more.

42:34You'll find at 10.1, publishing GP models to the server becomes an awful lot easier…

42:40…because of this packaging technology that we've done.

42:43And we've done this work in conjunction with the geoprocessing team and the server team…

42:46…because it was too difficult to get your GP services up and running…

42:50…'cause there're so many things that might not quite work when the data gets moved across in the model.

42:54Well, we're all benefiting from the packaging work.

42:58Okay, there's no demo. Okay, so the client-server communication. It happens over HTTP REST.

43:10There is a, as I said, a very small call overhead, and really when you look at the call overhead…

43:16…compared with the call execution time, it's almost negligible.

43:20And security, it's not an external port. Let's have a look at it in general.

43:24So the URL structure that we use, you can see there HTTP…

43:29…and then the first address there is the loopback adaptor of your PC,

43:38So that's available only internal to your machine.

43:42The next, after the call [Inaudible], is the internal port number…

43:46…and then we manufacture a unique server instance ID, which is a GUID.

43:53And that GUID, it only is valid for the lifetime of the server.

44:00As soon as your application gets taken down, if you start your application up again…

44:05…you'll get a different GUID, and the API is notified of that and binds onto that.

44:12And then after that, you've got the standard ArcGIS [for] Server REST URLs…

44:16…arcgis/rest/services to the Catalog, and then you've got the name of a service and map server or feature server, etc.

44:27Okay, there's no demo. So putting it all together, you have your application, it's using a map control…

44:34…it's using the ArcGIS API. You can communicate straight out through the cloud to get your map…

44:43…and it comes in, or you can give it a map package.

44:48So when you say to the ArcGIS API, Here's a map package, a local file on disk, I want to draw that…

44:56…what actually happens, the API hands that straight over to the embedded server. So it'll spin up the server for you.

45:03You don't need to do this manually, it knows it's got to spin up the server, and it gives the map package to the server.

45:11And the server, in turn, spins up another process in order to start rendering that map package and handling requests.

45:19And then the map gets passed back. And that map is not creating temporary files on disk.

45:25It's just passed back, the bytes, through the channel straight up to the API.

45:32And then if you have geocoding packages or geoprocessing packages, it's the same deal. Different .exe's get spun up.

45:43So the benefits of the architecture, it's scalable, it's very robust.

45:49We feel it's got a really good, efficient use of resources, and most importantly to me…

45:55…as the architect for the runtime, it's expandable and can evolve over time.

46:03That's, personally for my selfish reasons, that's why I like it, because I can evolve this over time without breaking clients.

Copyright 2016 Esri
Auto Scroll (on)Enable or disable the automatic scrolling of the transcript text when the video is playing. You can save this option if you login


No comments. Be the first to write one below.

Comment on this Video