Fulmine
Tutorials
Project Documentation
General
AsyncLog
?
No. JMS, as an example, provides generic pub-sub ability but leaves aspects such as data structure serialisation, data instance subscription management, data permission to upper logic levels. Fulmine provides all the upper logic and its pub-sub ability is tightly coupled to the data model.
| [top] |
As a convention, having interfaces named Ixxx makes it explicit that the code is written against an interface. Whilst we all know it is good practice to code against interfaces, in reality this is not always the case. It can become ambiguous at times, particularly if you are not familiar with the coding framework, as to whether the code is using interfaces or abstract/concrete class references.
| [top] |
AsyncLog
?
The
AsyncLog
was added to ensure that all internal logging within the Fulmine
framework was done asynchronously, irrespective of the chosen
logging framework.
| [top] |
Containers have 3 attributes to define them; a string identity, type and domain. A container can be used to represent a data entity. In certain circumstances, the data entity may be broken down into logical data segments; the type would be used to describe the logical data segment whilst keeping the same identity. Thus an entity can be represented by many containers, each showing a different logical segment.
The domain is orthogonal to the type; the same entity with its logically segmented structure may be available from different sources. The domain would be used to express this and thus allows the entity to be addressed using its identity, type and domain.
Financial market data systems are an example where the type and domain would be used.
| [top] |
Fulmine binds the event processors to the type of a container to ensure that all containers of a particular type are processed by the same thread. This ensures that subscribers will not receive any out-of-order updates. Generally, the updates to containers will come from an external source and all containers of the same type will also be updated from this same source. Therefore it is critical to ensure that the update sequence from the external source is properly maintained.
| [top] |
Whilst Fulmine has a framework to use any protocol to send data changes, the out-of-the-box implementation only uses TCP/IP. This is actually a preferred approach for back-end server architectures where fan-out is generally low. TCP/IP provides a robust and reliable communication protocol and coupled with switched networks, the fan-out time is, on balance, equivalent to a multi-cast protocol with loss detection and retransmission capability. Fulmine uses the NIO java framework for efficient TCP/IP scaling.
| [top] |
Fulmine is described as a near-real-time distributed system. It is near-real-time because it has no real-world operational deadlines to meet; it responds to events as fast as the hardware and software performs, network and other I/O latencies will reduce the response time. In contrast, a true real-time system has to compute and distribute the response to an external event within a defined timeframe. The term 'real-time' is used ubiquitously for distributed data systems but is, strictly speaking, mis-used. Fulmine should only ever be considered a near-real-time distributed data system.
| [top] |
Technically, a record is a container as it extends the container hierarchy. However, the two terms are used interchangeably and generally refer to the same concept.
| [top] |
All subscribers receive copies in order to reduce contention on the original. By receiving a copy, the subscriber does not have to be concerned about concurrency issues when examining the update.
| [top] |
The add operation must be performed in an event frame.
| [top] |
Is the destroy method being called on a copy of the container; are you destroying the container from within the body of a subscription listener? If so, this is a clone, you need to get the original container from the context.
| [top] |
The following system events are raised (these are only picked up by system listeners)
Any
ISubscriptionListener
instances that are registered with a subscription against the
container will receive a container update with the new state of the
container (it will be STALE and will have no fields).
| [top] |
Register an
ISystemEventListener
instance with the
SystemEventSource
responsible for raising the
EventSourceObservedEvent
context.getSystemEventSource(EventSourceObservedEvent.class).addListener(myListener);
| [top] |
If the state of the container is LIVE, then it will be receiving
updates. The state is accessed via the
getState
method on the container.
| [top] |
There are a number of reasons why permissions may appear not to be working.
| [top] |
By default remote updating of containers is disabled. The native
context of the remote container needs to enable this by providing
an
IRemoteUpdateHandler
that will process the update request.
| [top] |