Chapter 4. Core Architecture

Table of Contents

1. Objectives
2. Transaction Flow
Local Transactions
Remote Transactions
3. Design Details

1. Objectives

  • Facilitate requests against a message board for any user application.

  • Any message board can implement either the local or remote API.

  • A remote network protocol based on REST will be implemented.

  • Design must anticipate alternate network protocol implementations.

  • Facilitate local same-process API calls for 100% PHP solutions.

  • Backwards compatibility must be supported in future version.

  • Primarily PHP based solution that allows none-PHP applications and message board to be integrated via a remote protocol.

  • Provide a safe authentication framework for network-based API calls.

  • The API must be stateless. It must not prevent the use of distributed solutions.

  • The API must minimize use of system resources.

2. Transaction Flow

Local Transactions

Local transactions take place through immediate function calls just like any software library.

Figure 4.1. Local Transaction Flow Use Case

Local Transaction Flow Use Case

  • User calls a method on a Naruto implementation which performs actions against a real message board API, or database, and returns the result synchronously to the user over the same channel.

Remote Transactions

Remote transactions take place over a network connection. The flow includes two different Naruto implementations and one service.

Figure 4.2. Remote Transaction Flow Use Case

Remote Transaction Flow Use Case

  • User calls a method on a Naruto implementation which uses a network based protocol like REST to communicate the request to a remote service.

  • The remote service then make the appropriate method call on a Naruto implementation which performs actions against a real message board API or database.

  • The remote service takes the result and returns the result synchronously to the user over the same channel.

3. Design Details

Figure 4.3. Core API

Core API

  • Naruto - This interface defines all the methods that might be supported by a message board.

  • NarutoService - This interface defines all the methods that might be supported by a server side request handler.

  • NarutoTopic - This class encapsulates the primary data associated with a message board topic.

  • NarutoDO - This class serves as a base class implementing the basic functions and encapsulating the data.

  • NarutoForum - This class encapsulates the primary data associated with a message board forum.

  • NarutoCategory - This class encapsulates the primary data associated with a message board category.

  • NarutoUser - This class encapsulates the primary data associated with a message board user.

  • NarutoException - This class encapsulates the base exception. Exceptions are used to identify any breaks in expected program flow.

  • NarutoCredentials - This class encapsulates the caller's authentication. The caller may or may not be the end user. It is more likely that a single administrative user will be the caller. All API methods that need it have the ability to make requests on behalf of another user.

  • NarutoOptions - This class is essentially a map of parameters and is used in all Naruto methods. It's purpose is to make it easier to add on minor custom options without impacting other implementations.