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: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: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 betacommunity.esri.com, 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, 127.0.0.1.
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.