As I mentioned on Monday, I’ll be starting a series of posts on Oracle Transportation Management (OTM) in the cloud.  In the first stage of these posts, I’ll be covering the set of feasible architectures given the infrastructure offerings at Amazon Web Services.  And, as you might expect, we’ll be starting with the simplest architecture possible – a single node running database, application, and web services without any supporting software like PC Miler or Kewill.  Before beginning, it’s probably worth providing a link to the OTM documentation library.  Each documentation release corresponds to a major release of OTM and includes material like administration, installation, integration, and architecture guides.  Any organization working with OTM should keep these documents in a readily accessible place.  For your convenience, wherever possible, I will use the same language as these guides.

  Back to the architecture.  In this post, our goal is to understand the simple, high-level diagram below.

  We’ll start with the big box at the bottom.  OTM is built on a standard three-tier design.  At the bottom of the stack, a transactional relational database stores and provides access to all business and transportation data.  OTM, as you might guess, uses Oracle Database; you should always check, but for most OTM license agreements, you should not need to obtain separate database licenses.  In many cases, organizations might also have databases for archiving or reporting transportation or financial data.

  In the middle of the stack, the application tier handles retrieving and processing data from a WebLogic container.  For OTM, this processing includes tasks as simple as converting packaging dimensions from yards to inches or as complex as dynamically consolidating and choosing the best mode.  As you would expect from enterprise software, work can be distributed across multiple OTM application servers to improve performance, provide segregation, or allow for high-availability.

  At the top of the stack, the web tier allows users to view and interact with business data.  OTM takes a common approach by strapping Apache on top of Tomcat; this combination allows Apache to focus on serving static content and Tomcat to safely focus on presentation-level servlets.  The web tier also can be configured in a load-balancing configuration.

  In this architecture, all three of these tiers run on one EC2 Linux instance.  This configuration requires the least overhead to maintain for reasons including:

  • Lowest cost to provision infrastructure.
  • Single machine to monitor, patch, restart, etc.
  • Risk of intra-datacenter connectivity issues are minimized.  Almost all services can be bound to localhost.
  • Communication between tiers is faster if cores and buses are not saturated.
  On the con side, this single-node configuration does have the following considerations:
  • Complete management of the stack, including operating system and database.
  • Single point of failure across all tiers.
  • More difficult to scale resources with demand.
  Finally, when it comes to users accessing the instance, there are two options.
  • Public Internet: The first and more common approach is to access OTM over the public internet, either through the transient IP or via an Elastic IP.  Elastic IPs are the simplest and most flexible solution, as they simplify external DNS management.
  • Amazon Direct Connection: The second approach is to utilize a direct, private line between an organization and Amazon through Amazon’s Direct Connection service.  Direct Connection is available for 1Gbps and 10Gbps lines and locations on the US East Coast, US West Coast, Singapore, Japan, and the UK.

  We’ve covered our first Oracle Transportation Management hosting architecture in the cloud – three tiers, one server, two ways to connect.  That wasn’t so bad, was it?  If you have any questions about hosting OTM in the cloud or would like to schedule a technical consultation, please feel free to comment below or contact us.