Editors Notes: - OASIS



OASIS Provisioning Services Technical Committee

SPML V1.0 Interoperability Event

Technical & Operations Plan - Working Draft 03 June 6st 2003

Document identifier:

pstc-interop1-draft02.doc

Location:



Send comments to:

provision@lists.oasis-

Editor:

Darran Rolls (Darran.Rolls@)

Contributors:

TC Members

Abstract:

This document details the interoperation scenario, setup and operations of the planned PSTC interoperation event at Burton catalyst 2003.

Status:

Working draft.

Copyright (C) OASIS Open 2002. All Rights Reserved.

Table of contents

Document identifier: 2

Location: 2

Send comments to: 2

Editor: 2

Contributors: 2

Abstract: 2

Status: 2

1. Introduction 4

1.1. Terminology 4

1.2. Glossary 4

2. Scenario Outline (non-normative) 4

2.1. Common RA (C-RA) 6

2.2. PSP Implementations 8

2.3. PST Implementations 9

3. Common RA (normative, with the exception of the schema fragments) 9

3.1. Basic Technology & Implementation 9

3.2. Availability & PV Access 9

3.3. Service Schema 10

3.4. Managed PV Requests & Responses 10

4. Interop Provisioning Schema (normative, with the exception of the schema fragments) 10

5. Message Flows (normative, with the exception of the schema fragments) 10

5.1. 10

5.2. 11

6. References 11

Introduction

This document describes the message exchanges to be tested during the Burton Catalyst interoperability event in San Francisco, July 2003 (here by referred to as “the interop”). This interoperability test is designed to show the interoperation of service subscription and provisioning based on the draft SPML V1.0 specification.

This interop event is based around a defined scenario intended to test the interoperability of different implementations performing a common set of SPML operations, to test the soundness of the specification and clarity the mutual understanding of its meaning and application in a given business scenario.

Note the scenario and context of this interop is not intended to represent a definitive implementation of the SPML V1.0 specification.

1 Terminology

Where indicated as “Normative Text” the key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].

2 Glossary

The following identifies terms specific to this document. Please see the PSTC glossary for a full definition of terms.

|Interop User (IU) |An Interop User (IU) is a Burton Catalyst conference participants that comes to the interop event to take |

| |part in the interactive scenario. |

|Participating Vendor (PV) |A Participating Vendor (PV) is a vendor participating in the delivery of the interop scenario. |

|Common RA (C-RA) |Each PV will be able to display a common client screen running on a centralized application server |

| |referred to in this document as the Common RA (C-RA). |

The Scenario (non-normative)

1 Outline

The interop scenario is based on interactive attendee participation. Interop Users (IU’s) will be directed through a defined scenario, in which they input “New Hire” user data into a PeopleSoft HRMS system. This action will cause a set of SPML protocol exchanges to create service subscriptions at each vendor station participating at the interop.

The business scenario is based around a fictional company SPML Contractors Inc. When a new employee starts at SPML Contractors, an SPML enabled system is used to manage account subscriptions with a defined set of SPML Contracts’ customers. New employees are added to the SPML Contractors PeopleSoft HRMS using the standard PeopleSoft web based interface. The creation of records within HRMS is used to trigger SPML service subscription requests to be sent to each PV at the interop. In this scenario PeopleSoft HRMS will be acting in the role of SPML Contractors Inc. and will be functioning as an SPML Requesting Authority (RA). Mycroft will be providing an integration “SPML multiplexer” module that takes the SPML request from PeopleSoft and creates individual SPML service requests for each of the PV’s. Each of the PV’s will be modeled as SPML Contractors Inc customers and will receive, process and respond to their own service requests in accordance with their own systems models and PSP/PST implementations. Figure 1 shows an overview of this scenario.

[pic]

Figure 1. Scenario Overview

The SPML Contractors Inc PeopleSoft HRMS installation will be running a centralized server, accessible and available to all of the PV’s. By employing the PeopleSoft HRMS web based user access model, new SPML Contractors Inc employees will be able to be added from any of the workstations at the interop event room. This will prevent a bottleneck from forming at the PeopleSoft workstation and allow an IU to approach the scenario from any PV, thus making more staff available to help IU’s with questions and generally spread the traffic more evenly across the event.

Within the SPML Contractors Inc. domain we are modeling a sub-system based on a collaborative effort between PeopleSoft and Mycroft. PeopleSoft HRMS will be used to capture new hire details and produce a single SPML operation. This generic will be consumed by a custom component developed by Mycroft. The Mycroft code will operate as a PSP to the PeopleSoft request and will turn round and function as a “Common RA” responsible for the “multiplexing” that single request out to generate individual operations for each PV. The implementation of the “Common RA (C-RA) will be transparent to the PV’s and no “upstream” view will be provided or required by any on the other PV’s functioning as either PSP’s or PST’s. The C-RA will manage the and flows with each PV and may provide other services such as a protocol flow status view discussed later in this document.

2 Basic Scenario Flow

Guided by the PV displaying the PeopleSoft HRMS screens, the IU enters the data required to create a new contractor. The PeopleSoft Integrator environment in conjunction with the Mycroft “multiplexer” will then generate a pre-defined SPML service subscription request for each PV. The service subscription requests sent to each PV’s should result in the creation of some form or account or data that can subsequently be shown to the IU. Once the IU has completed their subscription request they will be free to move around the interop room and (in many cases) go to other participating vendor stations and see their “account subscription” enacted locally in the context of the local PV.

Figure 2 shows the operational flow of the interop scenario. NOTE the actual PeopleSoft HRMS installation will be running on a central server and will be accessible by all PV’s via a browser interface. The yellow highlighted processes depict the operational flow as seen from a single PV. The blue highlighted processes depict the operational flow from the perspective of the Interop User.

3 Common RA (C-RA)

In the basic flow of the scenario, PeopleSoft HRMS and the Mycroft “multiplexer” act as the central point from which subscriptions are initiated and reported. This combined functionality is referred to in this document as the “Common RA” (C-RA). The C-RA provides a browser interface for Interop Users (IU’s) to initiate subscription requests within the defined interop scenario. The C-RA propagates this subscription as operations to all registered PV’s. Figure 3 shows this operating model graphically.

[pic]

Figure 2. Basic scenario flow

[pic]

Figure 3. Scenario operating model

The scenario as described allows for subscription requests to be started from any vendor station and be propagated to all PV PSP implementations. Assume a subscription is initiated from the C-RA displayed by Vendor B in figure 2, the request would be propagated to Vendors A-H (implicit in this is basically a “provision to self”).

The scenario as described allows for multiple C-RA service subscriptions to be executing in real-time. In order to provide some notion of name space control in what could potentially be a complex set of asynchronous SPML message flows, the C-RA will be based on PSTC Use Case #1 “RA-PSP: Create PSU (RA generated PSU-ID)” as descried in [PSTC-UC]. In this model, the C-RA will be responsible for generating a unique primary identifier for each “account” across each PV.

The interface/paste-up for these subscription requests will be based on the PeopleSoft HRMS web based input screens. This interface will be used to create a unique record within PeopleSoft HRMS. The PeopleSoft Integration server will then be used to generate a single SPML for the Mycroft Multiplexer. The Multiplexer will then forward this request to the following list of PV’s:

|Participating Vendors |

|BMC |

|Business Layers |

|Critical Path |

|Entrust |

|OpenNetwork Technologies |

|Sun Microsystems |

|Thor Technologies |

|Waveset Technologies |

4 PSP Implementations

Each PV is invited to provide a PSP implementation. The implementation of PSP functionality is expected to be in conformance with those elements of the PS-TC SPML V1.0 Committee draft specification relevant to this event. The PSP implementations will be expected to be able to receive process and respond to the SPML V1.0 protocol messages described in this document.

Each PV implementing a PSP will receive an SPML V1.0 compliant against a pre-defined SPML V1.0 Provisioning Schema. It is left to the PV and implementer of the PSP to do with that service request what ever they see fit. One PSP implementer may choose to simply create an entry in a text file; another may choose to create an account in a locally managed PST; another may choose to implement a complex set of subordinate SPML request within an implementation model of their choosing. Regardless, the emphasis should always be on an understandable (and if possible physically viewable) incantation of the subscription request. The objective of the interop is IU participation. It is therefore important to easily be able to show each participant what their C-RA subscription request resulted in the creation of a something locally at the PSP.

5 PST Implementations

Each PV is invited to provide a PST implementation. The implementation of PST functionality is expected to be in conformance with those elements of the PS-TC SPML V1.0 Committee draft specification relevant to this event. Each PST will be expected to receive and process the SPML V1.0 protocol messages described in this document OR to establish suitable agreement with a PV’s PSP implementation such that their PST functionality is exposed through that relationship.

Each PV implementing a PST will receive an SPML V1.0 compliant against a pre-defined SPML V1.0 Provisioning Schema. It is entirely left to the PV and implementer of the PST to do with that service request what ever they see fit. Again, the objective of the interop is interop user participation. It is therefore important to be easily able to show that participant what their C-RA subscription request resulted in the creation of or actions there after.

Common RA (normative, with the exception of the schema fragments)

1 Basic Technology & Implementation

It is left as an exercise for the C-RA development team to decide on suitable implementation technology for the C-RA with the following basic requirements:

|3.1.1 |The C-RA MUST not display any vendor specific logo or branding in the interface. |

|3.1.2 |The C-RA subscription request interface MUST be compatible with the leading HTML browsers (version list to be|

| |confirmed) |

|3.1.3 |The C-RA MAY be developed using technology chosen by the C-RA development team. However, this technology MUST|

| |not be directly included in the scenario and SHOULD not be discernable by the interop participant via the |

| |C-RA interface. |

|3.2.4 |The C-RA MUST be available and ready to be used at the pre-interop testing meeting June 18-20th. |

2 Availability & PV Access

Due to the nature of the scenario and its implied dependence on the C-RA functionality, the C-RA implementation MUST be available to all vendors throughout the interop event. The C-RA development team MUST provide suitable availability and scalability to service at least the following request loading:

|3.2.1 |The C-RA implementation MUST support 15 concurrent PV connections |

|3.2.2 |The C-RA implementation MUST support 150 concurrent outstanding individual asynchronous across |

| |multiple PV’s |

3 Service Schema

Service subscription requests MUST be based on service schema defined in section 4 of this document. Certain attributes of this service schema MAY be generated by the C-RA.

4 User Input Screens

The PeopleSoft Portal environment WILL be used to add HRMS user records. The following screens are samples of the input paste-up. These screens MAY change prior to the live event. They are provided here as a place holder.

5 User name

[pic]

6 Address

[pic]

7 Personal Data

[pic]

[pic]

8 Employment Data

[pic]

9 Managed PV Requests & Responses

The C-RA MUST take each subscription request and generate an asynchronous SPML V1.0 compliant for each PSP and or PST in the interop. Each request generated MUST be in accordance with the provisioning schema defined in section 4 of this document. The C-RA MAY provide a graphical model for displaying the requests generated and or responses received. If such a model is provided it MUST not include or otherwise imply any performance statistics or preference over the request or response flows from any vendor.

Interop Provisioning Schema (normative, with the exception of the schema fragments)

The following SPML V1.0 Provisioning Schema will form the basis of the interop. All SPML based message flows MUST be based on this service schema.

| |

| |

|urn:oasis:names:tc:SPML |

| |

| |

|standard |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

Message Flows (normative, with the exception of the schema fragments)

1 Message Transport Binding

The interop will be using a basic SOAP/HTTP transport binding as defined in the SPML V1.0 bindings specification [BIND-1]. All SPML request and response messages MUST support a benign WSS X.509 Certificate authentication model as defined in [WSS-1]. Note we will be using “mustUnderstand=”0”” for this authentication. See section 5.2 below for an explanation.

2 Authentication & Message Integrity

An X.509 Certificate may be used to show one possible means of authentication between cooperating parties in the interop. The following SOAP header MUST be included in all message exchanges.

| |

| |

| |

|MIIEZzCCA9CgAwIBAgIQEmtJZc0... |

| |

| |

| |

3 Ports etc.

4

The C-RA MUST generate a unique identifier (PSTD-ID) for each request generated, this value MUST be represented in the provisioning schema attribute . This unique identifier SHOULD be semantically relevant to the scenario and MAY include a name-space model sequential to the C-RA or the specific PV.

All PV’s implementing PSP functionality MUST support an SPML V1.0 compliant operation. The following sample request includes sample attribute values. During the interop live data will be a reflection of the service subscription data entered at the C-RA.

| |

| |

| |

| |

|MIIEZzCCA9CgAwIBAgIQEmtJZc0... |

| |

| |

| |

| |

| ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download