Orbit Code

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>What is Orbit? on Orbit</title>
    <link>/orbit/</link>
    <description>Recent content in What is Orbit? on Orbit</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    
	<atom:link href="/orbit/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Governance</title>
      <link>/orbit/contributing/governance/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/contributing/governance/</guid>
      <description>Project Control The Orbit project is currently controlled and maintained by Electronic Arts (EA).
As an Open Source project we welcome contributions from everyone. The final decision for changes being accepted into Orbit is taken by the Project Maintainer (currently Joe Hegarty).</description>
    </item>
    
    <item>
      <title>Prerequisites</title>
      <link>/orbit/getting-started/prerequisites/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/getting-started/prerequisites/</guid>
      <description>Required Software The minimum requirements for an Orbit client application.
 Java 11 SE SDK or above. Gradle Kotlin  Orbit Server To run an Orbit Server inside a Docker environment
 Docker Desktop Docker Compose  Recommended Software  IntelliJ IDEA is our preferred IDE.  </description>
    </item>
    
    <item>
      <title>Server Configuration</title>
      <link>/orbit/server/configuration/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/server/configuration/</guid>
      <description>Orbit Server offers extensive configuration and an extension model to support many situations outside the defaults. The OrbitServerConfig class supplied to the OrbitServer constructor has overrides for lease timing, process management, addressable and node storage, and metrics.
The OrbitServerConfig class is well documented and will be the authoritative source for the latest options. Some settings, like the pipelineBufferCount is a simple Int type. Others, like the addressableLeaseDuration are more complex objects.</description>
    </item>
    
    <item>
      <title>Hello World</title>
      <link>/orbit/getting-started/hello-world/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/getting-started/hello-world/</guid>
      <description>In this guide we’ll cover how to get a very simple Orbit application running in the form of “Hello World”. It shows using a single-module in a single-process environment, often useful for development purposes. This will demonstrate how to set up an Actor and communicate with an Orbit Server.
This tutorial assumes that you have set up a development environment as described in the Getting Started Prerequisites document and have some familiarity with Gradle based Kotlin projects.</description>
    </item>
    
    <item>
      <title>Hosting Orbit Server</title>
      <link>/orbit/server/hosting/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/server/hosting/</guid>
      <description>Almost any scenario can be handled by using the prepackaged Orbit Server. For scenarios where the developer needs extensive control over the server, Orbit functionality can be hosted within a custom application.
Describe taking a reference to orbit-server, starting an instance. Role of orbit-application.
Gradle:
implementation(&amp;#34;cloud.orbit:orbit-server:2.0.0-alpha.108&amp;#34;) To instantiate an OrbitServer:
import kotlinx.coroutines.runBlocking import orbit.server.OrbitServerConfig import orbit.server.OrbitServer fun main() { runBlocking { val server = OrbitServer(OrbitServerConfig( ... configuration )) server.start().join() } } OrbitServerConfig The OrbitServerConfig class can be used to make changes to server configurations, including things like lease times, persistence technology, resource limitations, and metrics.</description>
    </item>
    
    <item>
      <title>Standards &amp; Policies</title>
      <link>/orbit/contributing/standards-and-policies/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/contributing/standards-and-policies/</guid>
      <description>Coding Standards Orbit adheres to the standard Kotlin Style Guide / Coding Conventions which can be found here.</description>
    </item>
    
    <item>
      <title>Legal</title>
      <link>/orbit/contributing/legal/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/contributing/legal/</guid>
      <description>Software License Orbit is licensed under the BSD 3-clause license. See it here.
Contributor License Agreement Like many other open source projects we require contributors to agree to our Contributor License Agreement (CLA) which can be found here.</description>
    </item>
    
    <item>
      <title>Modules</title>
      <link>/orbit/getting-started/modules/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/getting-started/modules/</guid>
      <description>The Orbit project is split into several modules for client and server.
Client orbit-client A JVM library for applications interfacing with an Orbit cluster. It handles maintaining a connection to the mesh, leasing addressables, and routing messages. It will be the main entrypoint for most developers.
To include in your Gradle project, import the client library.
implementation(&amp;#34;cloud.orbit:orbit-client:2.0.0-alpha.108&amp;#34;) Server Orbit can be run as a packaged service without having to delve into the server modules.</description>
    </item>
    
    <item>
      <title>Addressables</title>
      <link>/orbit/getting-started/addressables/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/getting-started/addressables/</guid>
      <description>In Orbit, an addressable is an object that interacts with the world through asynchronous messages. Simply, it has an address and can receive messages, even remotely.
Orbit will activate an addressable when it receives a message, and deactivate it when after a configurable period of inactivity. This patterns allows developers to speed up interactions and reduce load on databases and external services.
Orbit guarantees that only one addressable with a given identity can be active at any time in the cluster.</description>
    </item>
    
    <item>
      <title>Actors</title>
      <link>/orbit/getting-started/actors/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/getting-started/actors/</guid>
      <description>Actors are the most common form of addressable and are suitable for most situations. The distinction is semantic and Actor interfaces are provided to facilitate the actor pattern.
Actors are never created or destroyed; they always exist conceptually. Not all actors in Orbit will be in-memory in the cluster at a given time. Actors which are in-memory are considered “activated” and those which are not are “deactivated”. The process of an actor being created in-memory is known as “Activation” and the process of an actor being removed from memory is known as “Deactivation”.</description>
    </item>
    
    <item>
      <title>Client Configuration</title>
      <link>/orbit/client/configuration/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/client/configuration/</guid>
      <description>Orbit Client offers a broad set of configuration options to be supplied in its constructor. Some settings are required to discover addressables and connect to an Orbit Server cluster, while others can fine-tune how the client operates.
The OrbitClientConfig class contains the configuration values the OrbitClient needs to operate and is supplied in the constructor:
import orbit.client.OrbitClient import orbit.client.OrbitClientConfig fun main() { runBlocking { val orbitClient = OrbitClient( OrbitClientConfig( namespace = &amp;#34;carnival&amp;#34;, grpcEndpoint = &amp;#34;dns:///localhost:50056/&amp;#34;, .</description>
    </item>
    
    <item>
      <title>Dependency Injection</title>
      <link>/orbit/client/dependency-injection/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/client/dependency-injection/</guid>
      <description>By default, Orbit will instantiate and activate Addressables using the default, empty constructor. Many times an Addressable will require some service or store for activation or its functional use.
Orbit supports a &amp;ldquo;bring your own DI container&amp;rdquo; model
The typical approach is to use constructor dependency injection, where dependencies are be supplied as constructor arguments.
class PlayerImpl(private val playerStore: PlayerStore) : AbstractActor(), Player { ... PlayerImpl code } To wire a DI container into Orbit, the addressableConstructor member of OrbitConfig can be replaced with a custom implementation of the AddressableConstructor interface.</description>
    </item>
    
    <item>
      <title>Migration from Orbit 1.x</title>
      <link>/orbit/getting-started/migration-from-1.x/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/getting-started/migration-from-1.x/</guid>
      <description>Orbit 2 Philosophy Orbit 2 accomplishes the same basic goals as Orbit 1.x, but via a whole different approach. Orbit 1.x takes the form of a component included in an application utilizing distributed storage to coordinate messaging between service instances. Orbit 2 has taken all the responsibilities of tracking Actors and routing messaging into a standalone, scalable, and multi-tenant mesh service. Applications connect to the mesh over GRPC through a thin client library that manages the connection, leasing, and message delivery.</description>
    </item>
    
    <item>
      <title>Shutdown</title>
      <link>/orbit/client/shutdown/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/orbit/client/shutdown/</guid>
      <description>Orbit is designed to handle a graceful or hard shutdown.
In a hard shutdown scenario, Orbit servers will notice a client node disconnecting the GRPC connection and suspend the leases on all addressables placed on that node. Any subsequent messages will be routed to new nodes where the addressables become activated. There may be some message loss during this brief transition period.
Orbit also affords an opportunity for a graceful shutdown through a shutdown procedure that can be invoked by the client application.</description>
    </item>
    
  </channel>
</rss>