Learn About Creating and Implementing Oracle Cloud Infrastructure Queue By Using Its APIs and the Java SDK
You can use Oracle Cloud Infrastructure (OCI) Queue’s API and SDKs to create, report and then utilize this service as both a message source and as a consumer. While this playbook focuses on the Java APIs, the same principles and capabilities are available in all language SDKs.
OCI Queue is a fully managed, serverless message delivery service that automatically scales to meet your workload demand. It helps you decouple your applications and build an asynchronous event-driven architecture.
Learn About OCI Queue APIs
Architecture
The architecture described in this playbook makes it easy to run the logic from your own computer or to easily operate it from one or two VMs that can be controlled via an SSH tunnel. These architectures are shown in the following diagrams. Note that OCI Queue is not shown as the queue is created as needed.
If you are creating and implementing the queue with the OCI Queue tool outside of a VM, use this architecture:
Description of the illustration queue-api-playbook-arch-02.png
queue-api-playbook-arch-02-oracle.zip
If you are creating and implementing the queue with the OCI Queue tool within a VM, use this architecture:
Description of the illustration queue-api-playbook-arch-01.png
queue-api-playbook-arch-01-oracle.zip
For the purposes of the following playbook we are going to assume the use of our own desktop host for both the client and consumer.
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
- Compartment
Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Compute instances
Oracle Cloud Infrastructure Compute lets you provision and manage compute hosts. You can launch compute instances with shapes that meet your resource requirements (CPU, memory, network bandwidth, and storage). After creating a compute instance, you can access it securely, restart it, attach and detach volumes, and terminate it when you don't need it.
Considerations for Queue Policies
Policies for controlling and configuring OCI Queues and policies for creating and consuming messages are separate. This provides fine grain control on operations available through the APIs. This means you need to consider your application’s requirements and security needs.