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 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:11[Unintelligible]

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:17Yeah.

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.