Request and Reply

A bean encapsulates the PES Client logic so that can handle the connection with the PES Manager, and exposes all the methods related to the use cases described below.

The bean is called by the Workflow Manager and each instance of the workflow carrying a VOD Item instantiates an instance of the PES Client Bean that connects to the PES Manager.

The stages of the Request and Reply model implemented by the PES Manager are described below:

MAS request at initialisation of the Request Session
PES response at initialisation of the Response Session
Exception model
Opening Connection
Session Document start
Result - Command Response model
Notification

The PESSession stays open until the tcp connection is closed; the PESClientSession to a PES can consist of the tags:

'getVersion',
'newAsset',
'newReEncryptAsset',
'prepareAsset',
'prepareReEncryptAsset',
'scrambleAsset',
'reEncryptAsset',
'changeAsset',
'listAssets',
'deleteAssets',
'getStorage',
'getToDolist'

All tags (commands) always return synchronously a Result tag. The PESServerSession from a PES can consist of the following tags:

Result - this tag is always sent synchronously as a reply to the incoming tags
Notify - this tag is always sent asynchronously

Request

The MAS/NAGRA CMS sends the PES Manager commands as XML objects defined by the PESSession.dtd. The structure of the XML documents sent by the MAS would be similar to:

CODE

<?xml version="1.0"?>
<!DOCTYPE PESSession SYSTEM "PESSession.dtd">
<PESSession Version="2.0">
<PESClientSession>

The MAS can send multiple commands element in the same client session. Closing tags for </PESClientSession></PESSession> are not sent until the MAS wants to terminate or abort the session.

Response

The PES Manager reply is a PESSession document which includes a PESServerSession element.

CODE

<?xml version="1.0"?>
<!DOCTYPE PESSession SYSTEM "PESSession.dtd">
<PESSession Version="2.0">
<PESServerSession>

The PES sends multiple Response elements as result of a Command element sent by the MAS. Closing tags for </PESServerSession></PESSession> are not sent by the PES until it is time to terminate or abort the session. The PES Server may send Notify elements to signal asynchronous events to the MAS.

Exceptions

The PES continuously checks the received XML against the DTD, and in case of a DTD violation, notifies the MAS that something is wrong. There are mainly two situations to consider that lead to a different behaviour:

Exceptions out of the command context
The DTD violation occurs outside a command element. The PES sends a notification with a Code of "-1" and a description of the violation. It closes the PES server session, sends closing PESServerSession and PESSession tags, and then closes the connection.
Exceptions in the command context
The PES Manager sends a Result element with a Code of "-1" and a description of the violation, but does not close the PES Server session.

Opening Connection

The control connection is opened by connecting to the TCP/IP mwport on the PES manager machine. After opening the TCP connection, the PES server sends:

CODE

<?xml version=”1.0”?>
<!DOCTYPE PESSession SYSTEM "PESSession.dtd">
<PESSession Version=”2.0”>
<PESServerSession>

Session Document Start

After opening the PES Manager connection, the session is started by sending the normal xml prologue and the starting tags for PESSession and PESClientSession.

CODE

<?xml version="1.0"?>
<!DOCTYPE PESSession SYSTEM "PESSession.dtd">
<PESSession Version="2.0">
<PESClientSession>

Exceptions

On any DTD Violations, the PES may send a notification and close the server session. However, if the MAS sends the following, which conforms to the DTD, but is wrongly sent by the client instead of the server.

CODE

<?xml version="1.0"?>
<!DOCTYPE PESSession SYSTEM "PESSession.dtd">
<PESSession Version="2.0">
<PESServerSession>

The PES will reply in the following way:

CODE

<Notify Code="-1">
<Description>Accept only PESClientSession</Description>
</Notify>

In this case the document and the connection are not closed; although closing the PESServerSession and opening a new PESClientSession within the same document is a DTD violation. If this occurs, the PESServerSession and the connection must be closed, and then the connection re-opened and the process restarted.

Result

When the MAS sends one of the command elements within the PES client session, the PES always responds with a result element synchronously in the PES server session.

Input in PES Client session

Any command element (newAsset*, prepareAsset*, scrambleAsset*,newReEncryptAsset*, prepareReEncryptAsset*, reEncryptAsset*,changeAsset*, listAssets*, deleteAssets*,deleteAsset*, getStorage*, getToDolist*)

CODE

<prepareAsset Name="Bond007"/>

Output in PES Server session

The PES sends back synchronously:

CODE

<Result Command="prepareAsset" Code="-1">
<Description>
Element prepareAsset does not carry attribute Type
</Description>
</Result>

Notification

The PES may insert Notification elements into the PES server session at any time; typically these are used to inform the MAS of scrambling progress. These progress notifications are sent to all PES server sessions. There are also session specific notifications, like the DTD violations in the PESSession or PESClientSession elements.

Output in PES Server session

Example: Some other connection starts scrambling "bond007”, PES sends:

CODE

<Notify Code="0">
<ToDolistitem AssetName="bond007" Status="SCRAMBLING" Progress="0%"/>
</Notify>