The backchannel is the central element of EventWeb. The name can stand for "background channel" or "channel back to the server", both concepts apply.
The backchannel maintains a connection between the client web page and the server. The connection is bi-directional and either the client or the server can initiate a message transfer. It is implemented as separate classes for clients and servers: RandPortCliChan for the client, and RandPortSrvrChan for the server.
Some web architectures consider persistent connections a bad thing. But, if you want live data, you either have to maintain a connection or do polling. Polling over a network can be very expensive, and still involves some latency in the data. It also makes it harder for the server to maintain a client session, because there's no easy way for it to know when the client ends. (Ie: moves on to a different URL or closes the browser.)
We have chosen to accept the drawbacks of a connected client as preferable to polling.
A normal http connection. We use the term frontchannel to distinguish it from backchannel.
Backchannel connections are initiated by the client. This is done by a standard http request (with an EventWeb specific http header added). This initial connection is also referred to as a frontchannel connection.
A list of tags with associated values. The body of an http post is a tag-value list. EventWeb messages are sent as tag-value lists. Their format is identical to the body of an http post.
EventWeb uses tag-value lists extensively, both as it's message format and internally. We chose tag-value lists over xml because they are easier to process. It should be noted that there is no reason why the value in a tag-value pair cannot be an xml fragment, or even a whole xml document.
Pretty much the same as everyone else's concept of server. We tend to use the term server to refer to the stand-alone server, as opposed to a servlet based server.
Our stand-alone server has a number of standard components. "Server" can refer to the whole server including the components, or the portion that holds the other components. Which is which should be clear from the context.
EventWeb servers host one or more service managers. Each service manager listens for http requests at a specific port. It hosts one or more services, and directs requests to the appropriate one based on the path in the request.
EvwSrvr is configurable and the service managers and services it hosts are defined in a configuration file. The default configuration has only one service manager, but more can be added if you want services on more than one port. (SimpleBcTestSrvr is hard wired for a single service on a single port and doesn't have a service manager.)
Basically the same as everyone else's concept of service, but there are specifics that apply to EventWeb services.
In EventWeb V0.6.4 we eliminated service as a specific object type. Service objects are now called service connectors, which is more descriptive of their actual function. The term service is used as a generic reference to function being performed.
A service is typically composed of a service connector and one or more service providers and/or event providers.
A service connector is used to interface a service provider to an EventWeb channel.
The initial client connections (frontchannel) are established by the service manager and passed to the service connector when it is invoked. It then serves that specific client. Typically, a backchannel connection is set up, but that isn't absolutely necessary, and depends on the details of that particular service. Eg: ByteFileHttpSrvc serves files over the frontchannel.
EventWeb service connectors can be hosted by a stand-alone server, or by a servlet. When hosted by a servlet, the servlet passes it the client connection. Services can be fairly self-contained, Eg: SimpleBcTestSrvc, But there are a number of standard components that a service connector often hosts.
A service provider is hosted by a service. It's responsible for handling a single client, where the communication channel is open and running. The service passes it a tag-value list with the client request, and a reference to the channel to send the reply on.
Starting with EvntWeb 0.6.3, Service Providers are independent of the method used to communicate with the client.
An event provider notifies services of events that occur, such as a change in a data value. The Quote of the Hour service uses an event provider to notify it when the quote changes. (Technically, it is the RqstRouterEvwSrvc that receives the notifications. The request router service hosts the quote of the hour service provider and the quote of the hour event provider, along with other service providers.)
Event providers have add listener and remove listener methods that allow services to host them.
An data provider simply provides data. The distinction is that it does not talk to the client. All communication with a data provider is by method call. It can be used by a Service, Service Provider, or Event Provider.
Pretty much the same as everyone else's definition of client. In EventWeb a client generally connects to a service through a network connection. But that isn't required. A client that is hosted in the same server can access a service provider by direct function call. (The publish provider serves clients through network messages and also by function call.)
Also, our notion of client is generally defined by a network connection. If a user connects to a service, disconnects, and then reconnects, it's two separate clients. (It would be nice to have something that preserves identity across connections, but we don't have that yet.)
A service provider factory consists of a main SrvcProvFtry class and a SrvcProvImp inner class. The main class does all the load time initialization, and has a newClient() method that returns a SrvcProvImp object when a new client connects. The SrvcProvImp handles all client interaction.
The SrvcProfFtry main class also holds fields and methods that are shared by all the clients of this SrvcProfFtry instance.
The SrvcProvImp has the dispatchRqst method, and all fields and methods that are unique to an individual client. The factory generally returns a new SrvcProvImp instance for each client connection, but that isn't strictly required. If the factory always returns the same object, the SrvcProvImp will have to be threadsafe.
The service provider factory approach has a couple of advantages: