On 18:43 23/05/03, Alex Rousskov said:
Here is my interpretation of the primary part of your problem:
I am afraid I was not clear enough. The system exists. It runs well and is
designed to have A respondng B an XML status report. This is all what A
knows doing. It checks the calling IP address and respons. This permits B
to discover that A has a problem from the daily status report. The only
improvement is that A will call when it has a problem (an empty XML message).
A emits messages using format/protocol pA
Yes. Empty XML.
A is configured to talk D as its "next hop" for pA
It calls B. But because it uses IP addresses, the address listed as B has
to be D address.
Or better - but how will that work. D fakes being B.
B is interested in A's state but understands
(or prefers) messages in format/protocol pB, not pA
Yes. The message is unique. A full A XML status report
D accepts messages in pA from A,
D adapts messages in pA to messages in pB, possibly using C,
D forwards adapted messages (in pB) to B
Yes but you by pass all what is interesting:
- multiple sending in one very long cession
- possible changes in who is C
- necessary calls from C to A to be able to complete the service
on the pA to B call.
C is in a different administrative domain than D
An OPES system can support the format/protocol adaptation above, IMO.
OCP already handles the case when one message from A is converted to
multiple messages to B (to address your concern #3).
- even if it is a "long cession" are there no timers anywhere
which may influence?
- no impact if there are reboots of D?
The other part of your problem is communication in the other direction
(B, D, and C talking to A). I believe such communication is not
prohibited by OPES rules, but otherwise is outside of OPES scope.
- problem in having them totally supported under OCP you would
Interest is that if I got the funding it might help developping OCP functions
and test them. Also, to put me back in the OCP stuff (I am out of scope
right now with the load with my ICANN oriented load). Low chances to get
a budget, so is it worth a try? Or are there enough resources already
commited in here?
On Fri, 23 May 2003, jfcm wrote:
> I come across the following customer request. I think it may help checking
> OCP can be used and can support this.
> There are four systems involved.
> 1. A: an automated system (oil station pump)
> 2. B; a remote management station
> 3. C: a considered ticketing service
> 4. D: a possible OPES
> B polls A once a day
> When A has an incident it calls B.
> But B is management not support
> So the idea is D as an OPES between A and B branching into C via OCP.
> 1. when A has a problem, the call is blocked by D and C is told.
> 2. C manages the incident (may take hours)
> 3. when the incident has been repaired, C can authorize D to forward the
> call as "treated".
> I would like to understand if all this is orthodox as far as OCP which will
> be used between D and C.
> 1. is there a problem about qualifying this as an OPES?
> 2. A only knows to say "I have a problem" and to report its status upon
> request from B (IP address) and respond.
> D's IP would replace B's IP in A table. So the dialog would actually
> be A-D.
> So, if B and C call, D should make the calls coming from D.
> there are three reasons to call A:
> - normal administrative calls by B
> - calls by D when receiving the alarm: to check the reason of the call
> (D may decide to discard if it is a repetitive call)
> - calls be C: as part of the ticketing status control and reporting to
> Calls by D and C are part of the OPES service. Is that dialog with the
> caller permitted?
> 3. there would be a need for a multiple "continuations" of A calls to be
> received by B.
> - A calls to say I have a problem : this is the data transmitted that
> is going to be modified.
> - B should receive that data as a continuity of different blocks, may
> be over hours
> - 1st block: there is an alarm info to follow
> - 2. this alarms has been taken over by the ticketing service
> - 3. the ticketing service may pass different reports
> - 4. report "the problem has been addressed as follows: ...."
> 4. what is also interesting is that A, B, D are in the same domain of
> security While C is an externalized service. So OCP relations would have to
> be secure. Also, C may change into C1, C2, etc as the complexity/type of
> incident management is handled.
> Thank you.
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.483 / Virus Database: 279 - Release Date: 19/05/03