[Css-csts] FW: add 'Blocked' and 'Unblocked' operations?

[Tim Ray]

Hello all,

 

Please allow me to clarify a few things about my previous email (forwarded
below):

 

1) THE BIG PICTURE:  I'm trying to find a more elegant way to handle
Production outages within the Data Processing procedure.  

2) One possible solution is to add Blocked and Unblocked operations.  I'm
not entirely sold on this particular solution, but it seems worth
considering.  (if you read this whole email, you will see that my own
consideration of this solution led to another potential solution)

3) Although these new operations would be available to all procedures, I
only see them being used by the Data Processing procedure, and.

4) the Blocked operation would only be initiated from the Started state.

 

The rest of this email attempts to elaborate on the above ideas. 

 

Our layered approach:

Services

Procedures

Operations (what I might call the "Foundation Layer")

 

Although we haven't decided on "option B" (that Martin presented last Friday
morning), let's see how Blocked/Unblocked might fit into that option:

 

The state of the "Foundation Layer" is either Unbound or Bound.

Once the Foundation Layer is Bound, the appropriate procedures are started.

Some procedures will probably be stateless.  Other procedures will have
states, and will have their own state table logic (separate from the
Foundation Layer's). 

The Data Processing procedure could be specified as having 3 states - Bound,
Started, and Blocked.  "Blocked" would mean that the Provider cannot
currently accept a Confirmed-Data-Transfer-Invocation from the User.  (Keep
in mind - this "Blocked" state is within the Data Processing Procedure;
therefore, its definition applies only to the Data Processing procedure).

 

Now, suppose that production is interrupted at the Provider side.  The Data
Processing procedure would enter the Blocked state.  It would use the
Blocked operation to synchronize with the User (i.e. to ensure that both
sides transition to the Blocked state).  (The Blocked-Invocation message
might include a field called 'Reason For Blockage", which could be set to
indicate Production-Interrupted).    

 

Now, suppose that production becomes operational again.  The Data Processing
procedure would not be blocked anymore, and would enter the Started state.
It would use the Unblocked operation to synchronize with the User (i.e. to
ensure that both sides transition to the Started state).

 

One potential problem - if the Provider can signal "Production Interrupted"
followed (later) by "Production Halted", how can we handle this elegantly?
i.e. if a production outage can be either short-term or long-term then a
single Blocked state may not be sufficient.  Perhaps instead of adding 1 new
state to the Data Processing procedure, we should add 2 new states -
Interrupted and Halted - the resulting states might be:  

            Running -- a successful Start operation causes this state to be
entered

            Interrupted -- a short-term outage causes this state to be
entered and an INTERRUPTED operation to be initiated by the Provider

            Halted -- a long-term outage causes this state to be entered and
a HALTED operation to be initiated by the Provider

NOTE:  When Production becomes operational again, the Provider would issue a
RUNNING operation and both sides would return to the RUNNING state.  The
RUNNING operation could occur from either the Interrupted or Halted state.

 

Best regards,

Tim Ray

NASA/Goddard

  _____  

From: Tim Ray [mailto:tim.ray at nasa.gov] 
Sent: Tuesday, September 20, 2005 2:06 PM
To: css-csts at mailman.ccsds.org
Subject: add 'Blocked' and 'Unblocked' operations?

 

Hello all,

 

Does it make sense to consider adding two confirmed operations (Blocked and
Unblocked) to our generic SLE spec?

 

The Blocked operation would be used to indicate that incoming data transfers
are blocked.  The return would always indicate a positive result.

 

The Unblocked operation would be used to indicate that incoming data
transfers are no longer blocked.  The return would always indicate a
positive result.  

 

Note that both the Blocked and Unblocked operations would originate at the
Provider side.

 

Perhaps these operations (or something similar) would allow us to specify
the reporting of (and recovery from) Production outages more elegantly? 

 

Best regards,

Tim Ray

NASA/Goddard

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20050921/4b6b3ad9/attachment.html