Start using rtd to document the lib.

Currently the LocalSynchronousInitializer can only register initialized handlers but it should care about an already existing comman_map in the ServiceBus configuration.

Commands-, Events- and MessagesFactories should also be derived from PluginManagers by passing the FQCNs to them. So you can register different factories for different types of commands, events, messages.

We need an EventReceiver that receives events from a queue and publish them to local listeners.

When an exception is thrown during message dispatch the CommandDispatchException or EventDispatchException should use the current event name of the Dispatch to give a hint in which phase the exception was thrown, but the phase is always finalize cause finalize is always triggered whether the dispatch was successful or not.

All message dispatcher implementations, except the InMemoryMessageDispatcher, should be managed in separate repos.

The new message routing strategy (see #25) allows to simplify message dispatching and configuration.

Following changes can ease the usage:

• #32
• #33
• #34

• QueryDispatch
• QueryRouter
• QueryBus returning a promise
• Align invoke strategies
• Add a MessageDispatcher\RemoteQueryDispatcher interface

• Provide interface ServiceBusSerializable with method toServiceBusMessage
• Provide interface ServiceBusUnserializable with static method fromServiceBusMessage

ServiceLocator should be of type QueueManager

Align all message dispatchers

• http
• bernard
• resque

Other than a CommandReceiver, an EventReceiver should publish an Event to many EventHandlers.

Change event_map structure to allow an array of EventHandlers for a specific Event.
Let EventReceiver check if one handler or a collection of handlers is configrued.
Let EventReceiver publish event to all configured handlers.

This message dispachter should work with the react API and should push messages on a asynchronous queue.

The public interface should provide non abstract getter for all specific managers and should override the abstract get to be protected.

Define an interface with two methods: fromCommand and fromEvent.
Implement a MessageFactory.
Let CommandBus use the MessageFactory by default and make it possible, that MessageFactory can be exchanged. like the CommandFactory in a CommandReceiver

Make sure that the Prooph\Common\Event\Zf2\Zf2ActionEventDispatcher can handle the dispatch event so that we don't introduce a BC break in proophessor!

The InMemoryMessageDispatcher handles messages synchronous. This is useful for local messaging and UnitTests.

See failing tests:

method Prooph\ServiceBus\Router\CommandRouter::onRouteCommand not found.

see: https://travis-ci.org/prooph/proophessor/jobs/64147997

Additional: Shouldn't the query-router have a onRouteQuery method?

CommandInterface/EventInterface no longer exist, change method signature to mixed

We need a bus that publishes events on a queue.

The config root comes in play when ServiceBus is integrated in ZF2 but this should be manged by the integration module.

By default the ServiceBus should be configured with a CommandBus, CommandReceiver, EventBus, EventReceiver, local Queue and InMemoryMessageDispatcher in place.

Enable direct attach of CommandHandlers and EventListeners to ease the setup for a new client. It should be possible to explore the system iterative.

The RESTfulMessageDispatcher can be used to publish commands and events as resources and to receive them from a client. The RESTfulMessageDispatcher should be provided as ZF2 Module, cause we need REST controllers and a Database. To much dependencies to include it in the core service bus.

With this change it becomes possible to track routing of messages even when the dispatch process is skipped, cause in the end the same methods on the ServiceBus are used to deliver a message to it's handler.

Docs need to be aligned due to upgrade to prooph/common v3.x and remove of ZF2\Events.

• How to update own plugins.
• How to continue using a logger.

When the ServiceBus invokes a command or event on a handler, exceptions should be catched and an error event should be triggered containing a raiseException flag which defaults to true but can be changed by a listener if error is handled in another way, f.e. delivery of the message is retried.

A bus and it's receiver part should just act as from/to message translator and topic provider for the message dispatcher.

Design a consistent status API that can be added via initializer and listen to the various message dispatcher, receiver and routing events to track status of published messages.
Look at the resque example for inspiration.

Depends On

• #30 tracking of errors should be possible, too

Provide a generic messagebox endpoint to receive commands from the client. Each command type should have an own messagebox, so that you can document the different commands like you would document resources.

A messagebox should answer with a HTTP Status code and with a hypermedia link to an endpoint where client can check the status of the command: pending, succeeded, failed, ....

Provide helper to add hal links to resources pointing to available commands for the resource.

Also provide an event-stream endpoint, so that a client can query for published events.

The LocalQueueSetup should register itself to the ServiceBusInitializationEvent.
During the Event it should activate the InMemoryMessageDispatcher and add the CommandRceiverManager to the localQueue mapping of the InMemoryMessageDispatcher.

Each component should provide an own EventManager and trigger pre and post events in all public methods.
The ServiceBusManager should addionally trigger an ServiceBusInitializationEvent.

The LocalSynchronousInitiliazer is no good default. Most times you will use the ServiceBus for simple synchronous command/event dispatching. The complete message translation via bus, message dispatcher and receiver is just overhead for this use case.

A simpler solution is required. The idea is that the ServiceBus#route method looks for direct_command_map and direct_event_map configuration. These maps are simple dictionaries where the key is the message name and the value is the handler alias of the services configuration of the ServiceBus. So the ServiceBus can directly detect the appropriate handler an invoke it with the help of an InvokeStrategy.

The LocalSynchronousInitiliazer is no longer required and can be removed.

Depends On

• #26

Sub-Tasks

• #27
• #28
• #29
• #31
• #35

Use PhpResqueue as MessageDispatcher

Currently you have to define ServiceLocator configuration for the ServiceBus under the root config key. This is confusing and should be changed. The ServiceLocator config can be organized under the key "service_bus_manager".

Design specific events for all actions and let listener change the arguments, f.e. switch queue in a MessageDispatcher, etc.

We need a CommandBusManager and initialization logic to inject the correct MessageDispatcher into CommandBus.

The default command/event bus factories do not check if they can create the requested bus. It would be better, if they check the configuration in the canCreateService method and not in the createServiceWithName method. So the ServiceBusManager can fall back to direct routing if requested bus is not available but ServiceBusManager has a mapping for the message.

With this change in mind you can know send a message on a non existing topic bus and if you later decide to route this topic to a asynchronous message dispatcher, you can do so by simply add a configuration for the topic bus.

Tests for ServiceBusConfiguration are missing

The header of a message should provide information of the original type of the message (command or event).

Change InMemoryMessageDispatcher to check the type and use the correct *Receiver

Each ServiceManager type should have it's own config key, so that you can configure factories, invokables, etc. like you can with the ZF2 ServiceManagers.

At the moment the aliases defined in Definition are used in the ServiceBusManager to point to the default implementations. The aliases are defined like they are used within a ZF2 ServiceManager (without underscores, etc.). The spelling do not answer to configuration keys, so the notation should be adapted and usage in ServiceBusManager, too.

Queues are not really necessary. The original intention was to use them for topic based routing but it is enough to use the command bus name for this kind of purpose.