Software Design Specification.doc

SOFTWARE DESIGN SPECIFICATION SOFTWARE DESIGN SPECIFICATION (SDS)(SDS)

PUBLISH-SUBSCRIBE NOTIFICATION FOR WEB SERVICES (PSN-WS)

Prepared byLEAH ROSENBURG

4/10/2023

Table of Contents

1 INTRODUCTION.......................................................................................................................................................... 4

2 SYSTEM OVERVIEW................................................................................................................................................... 4

3 DESIGN CONSIDERATIONS.......................................................................................................................................... 4

3.1 ASSUMPTIONS AND DEPENDENCIES........................................................................................................................ 4

3.2 GENERAL CONSTRAINTS........................................................................................................................................ 4

3.2.1. Requirements.................................................................................................................................................. 4

3.2.2. Network Communications............................................................................................................................... 5

3.2.3. Hardware Constraints..................................................................................................................................... 5

3.2.4. Software Constraints....................................................................................................................................... 5

3.3 GOALS AND GUIDELINES........................................................................................................................................ 5

3.4 DEVELOPMENT METHODS...................................................................................................................................... 5

4 ARCHITECTURAL STRATEGIES.................................................................................................................................... 5

4.1 ARCHITECTURAL STYLE......................................................................................................................................... 5

4.2 WEB SERVICES..................................................................................................................................................... 5

4.3 USER INTERFACE.................................................................................................................................................. 6

4.4 DATA DISTRIBUTION.............................................................................................................................................. 6

4.5 SECURITY............................................................................................................................................................. 6

4.6 DATA STORAGE..................................................................................................................................................... 6

4.7 FUTURE ENHANCEMENTS....................................................................................................................................... 6

5 SYSTEM ARCHITECTURE............................................................................................................................................ 7

5.1 SERVER................................................................................................................................................................ 7

5.1.1. Subscription Manager..................................................................................................................................... 7

5.1.2. Handler........................................................................................................................................................... 7

5.1.3. Dispatcher....................................................................................................................................................... 8

5.1.4. Administration Facade.................................................................................................................................... 8

5.2 CLIENT.................................................................................................................................................................. 8

5.2.1. Data Consumer............................................................................................................................................... 8

5.2.2. JiBX Binding.................................................................................................................................................... 8

5.2.3. Unmarshaller................................................................................................................................................... 8

5.3 ADMINISTRATION................................................................................................................................................... 8

5.3.1. Monitor............................................................................................................................................................ 8

5.3.2. Control............................................................................................................................................................ 9

6 POLICIES AND TACTICS.............................................................................................................................................. 9

6.1 JAVA VIRTUAL MACHINE........................................................................................................................................ 9

6.2 CODING CONVENTIONS.......................................................................................................................................... 9

6.3 DESIGN PATTERNS................................................................................................................................................ 9

6.3.1. Publish/Subscribe........................................................................................................................................... 9

6.3.2. Observer......................................................................................................................................................... 9

6.4 REQUIREMENTS TRACEABILITY............................................................................................................................... 9

6.5 CONFIGURATION MANAGEMENT............................................................................................................................ 10

6.6 TEST PLAN.......................................................................................................................................................... 10

7 DETAILED SYSTEM DESIGN...................................................................................................................................... 10

7.1 State Diagrams.................................................................................................................................................. 10

7.2 Use Case Diagrams.......................................................................................................................................... 10

Rosenburg – PSN-WS SDD / 25

7.3 Data Flow Diagrams.......................................................................................................................................... 11

7.4 Class Diagrams................................................................................................................................................. 13

7.4.1. Server........................................................................................................................................................... 13

7.4.2. Client............................................................................................................................................................. 14

7.5 User Interface Screens...................................................................................................................................... 15

7.5.1. Interface Layout............................................................................................................................................ 15

7.5.2. Monitor Status............................................................................................................................................... 16

7.5.3. Monitor Subscription Statistics...................................................................................................................... 17

7.5.4. Control Configure.......................................................................................................................................... 18

7.5.5. Control Subscribe/Unsubscribe..................................................................................................................... 19

7.5.6. Control GetStatus.......................................................................................................................................... 20

7.6 Message Definitions.......................................................................................................................................... 21

7.6.1. Control Messages......................................................................................................................................... 22

7.6.2. Notification/Data Messages.......................................................................................................................... 23

8 REQUIREMENTS TRACEABILITY................................................................................................................................. 24

GLOSSARY....................................................................................................................................................................... 25

REFERENCES................................................................................................................................................................... 25


1 INTRODUCTION

The purpose of this software design specification (SDS) is to describe the implementation details of the Publish-Subscribe Notification for Web Services (PSN-WS) project software system and subsystems. The PSN-WS software design is derived from the functional and nonfunctional software requirements detailed in the PSN-WS software requirements specification (SRS), as well as design constraints and any other external factors provided in the SRS.

2 SYSTEM OVERVIEW

The PSN-WS project is modeled after real-life missile defense work at Lockheed Martin. The Customer has directed the Program to support a Service Oriented Architecture (SOA) to allow sharing of data across information systems. The Program has identified many functional areas that web services could be used effectively to fulfill this requirement. One of these areas has been proposed and will be delivered this release to establish a reusable pattern for implementing web services within the existing system architecture.

The consumer web service will be asynchronous and conform to the industry WS-Eventing2 specification. The web service is intended to provide mission display data from an external system to my Program to facilitate collaboration between operators with a common situational awareness. The scope of the PSN-WS project includes developing the web service interface, distributing the data to internal consumers, and providing administration capabilities.

3 DESIGN CONSIDERATIONS

The design considerations section describes many of the issues that need to be addressed or resolved before attempting to devise a complete design solution.

3.1 ASSUMPTIONS AND DEPENDENCIES

As a Java-based application, PSN-WS assumes that the server and client machines running the software program will have a JVM installed version 1.5.0 or later. This provides platform-independence.

PSN-WS will provide a graphical user interface for administration capabilities implemented using Java Server Pages (JSPs) deployed to the application server.

PSN-WS will use BEA WebLogic 9.1 as the application server to deploy the PSN-WS web services and other J2EE components.

PSN-WS must conform to the Program-External System Interface Content Description (ICD). The ICD requires the use of the WS-Security3 and WS-Eventing2 specifications and provides schemas for the transfer of data via SOAP messaging.

PSN-WS depends on the availability of the external system web service. Since this provider web service is being developed on a different schedule on a different program, any modifications or issues with the interface will be difficult to resolve


3.2 GENERAL CONSTRAINTS

3.2.1. Requirements

Refer to the PSN-WS Software Requirements Specification (SRS) for the complete set of functional and non-functional requirements.

3.2.2. Network Communications

PSN-WS is a distributed project that uses SOAP over HTTP to transfer data between the Program and the External System. Networking design is out of scope for the PSN-WS and will be handled by the network group of the Program.

3.2.3. Hardware Constraints

None.

3.2.4. Software Constraints

The PSN-WS project must have a server component running BEA WebLogic 9.1 as the application server. The PSN-WS project depends on the availability of the external system web service. Since this provider web service is being developed on a different schedule on a different program, any modifications or issues with the interface will be difficult to resolve

3.3 GOALS AND GUIDELINES

Other than network errors, no internal software failures are acceptable.

Support a Service Oriented Architecture (SOA) using industry accepted standards and specifications.

Where possible, use known design patterns and employ software best practices.

Reuse open source community code where possible to support the open source community as well as minimize reinventing the wheel.

3.4 DEVELOPMENT METHODS

The incremental software development process will be used for the PSN-WS architecture development. An incremental software development process is necessary to incrementally deliver functionality by a deadline. Since the Program is being developed using the incremental software development process, the PSN-WS will also follow this paradigm.

4 ARCHITECTURAL STRATEGIES

4.1 ARCHITECTURAL STYLE

The architectural style used for the PSN-WS system is the Service Oriented Architecture (SOA). SOA provides a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains such as this PSN-WS project. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.1 SOA is not tied to a specific technology and may be implemented using a wide range of interoperability standards. The PSN-WS project will use web services to implement this architecture.


4.2 WEB SERVICES

PSN-WS will use asynchronous web services to implement the SOA architecture. The web service XML-based control and data messages will be exchanged via Simple Object Access Protocol (SOAP) over HTTP. This web service will be asynchronous and conform to the WS-Eventing and WS-Security specifications. The WS-Eventing specification provides a protocol that allows web services to subscribe to or accept subscriptions for event notification messages. The specification defines an interface for one web service, an event sink, to register interest via a subscription with another Web service, an event source, in receiving messages, or notifications, about events.

4.3 USER INTERFACE

The PSN-WS application requires a system administration graphical user interface. One of the design constraints is the use of the Java programming language. Within the J2EE environment, server and platform independent Java Server Pages (JSPs) will be used to develop this PSN-WS GUI capability. The JSP(s) will be deployed on the application server component.

4.4 DATA DISTRIBUTION.

Once the data is received by the subscribing web service, the message must be distributed to consumers internal to the Program. The Program environment is distributed, and internal consumers may not necessarily reside on the local machine. Within the J2EE environment, the XML message payload will be dropped onto a local Java Messaging Service (JMS) topic where these consumers can receive notification. Additional processing is necessary to translate the XML payload into a Java object that is of use to the internal consumer. I will provide this translation by processing the XML using the open source JiBX4 technology.

4.5 SECURITY

Security information will be contained in the SOAP message header according to the WS-Security specification. Both sides of the interface, producer and subscriber, will supply a user token (e.g. username and encrypted password) embedded within the SOAP message header. Additional security will be implemented simply by using BEA’s WebLogic Server. The WebLogic Server product provides Secure Sockets Layer (SSL) support for encrypting data transmitted across WebLogic Server, clients, and other servers. In addition to the security portion of the message headers and the security provided by WebLogic Server, IP filtering will be used to manage the finite list of IP addresses that are allowed to connect to the server. However, this portion is out of scope for the PSN-WS project, and the network team of the Program is responsible for implementing this portion of security.

4.6 DATA STORAGE

The PSN-WS software requirements as written for this release do not warrant the use of a database for data storage management and persistence. The requirements describe a logging capability as the only type of persistence required. In this case, PSN-WS will log event notifications, faults, etc, to a centralized repository of ASCII log files using the Log4J open-source logging component.

4.7 FUTURE ENHANCEMENTS

This section describes future extensions and enhancements that have were considered during the system architecture development. The functionality described in this section was not included in the initial requirements specification and could not be considered for implementation in this increment. However, the PSN-WS architecture was developed to accommodate these enhancements for future development.


The enhancements are documented here to ensure the ideas were not lost and could be considered for future implementation efforts.

Producer Capability – The PSN-WS project requires that the Program only subscribe to the External System. In the future, this design framework will be used to provide event data as a Producer component to other external systems.

Additional Subscriber Capability - The PSN-WS project requires that the Program only subscribe to the External System. In the future, this design framework will be used to provide additional event data as a Subscriber component to external systems other than the External System.

5 SYSTEM ARCHITECTURE

The PSN-WS will be partitioned into subsystems and components of major functionality and responsibilities. This section describes how the system is decomposed, the rationale for the decomposition, and how the major subsystems interact to provide the desired functionality.

The PSN-WS system is composed of three major subsystems: Server, Client, and Administration. The PSN-WS system easily decomposes into these three subsystems. The system requires a user interface to administer the PSN-WS server component that provides incoming data to the Program.

The high-level system architecture for PSN-WS, including these subsystems and components are shown in Figure 5-1. For further decomposition, the components making up each of these subsystems are described in more detail in the following sections.

Figure 5-1High-Level System Architecture


Figure 5-2High-Level System Architecture - Components

5.1 SERVER

5.1.1. Subscription Manager

The Subscription Manager component manages the list of active message topics/subscriptions, as well as the list active subscribers for each topic.

5.1.2. Handler

The handler receives response SOAP messages from the provider service at the External System. The receiver will appropriately handle and process the different incoming messages based on the message type (e.g. data versus control message).

5.1.3. Dispatcher

The Dispatch component sends request SOAP messages to the provider service at the External System. For future enhancements, the dispatcher component would also handle the details related to sending the outbound messages from the Program to the active subscribers.

5.1.4. Administration Facade

The administration façade component is the interface from the administration console to the internal workings of the WS-Eventing functionality on the server. This component will return data and control the server properties.


5.2 CLIENT

Within the J2EE environment, the XML message payload received by the server component will be dropped onto a local Java Messaging Service (JMS) topic where the client consumers can receive notification. Additional processing is necessary to translate the XML payload into a Java object that is of use to the internal consumer. This client component section describes the design of the Program’s internal consumer.

5.2.1. Data Consumer

The data consumer client component consumes messages from a JMS subscriber. The consume method provides the callback for the subscriber object to pass received JMS messages back to the client subscriber. In addition to consuming messages from JMS, the data consumer is responsible for translating the incoming JMS message into a Java type that is recognizable by the client consumer.

5.2.2. JiBX Binding

The JiBX binding definition is an XML document that defines the rules for converting Java objects to and from XML. The JiBX binding compiler takes binding definitions as input along with the actual class files. The binding compiler compiles the binding definitions into Java byte code that it adds to the class files. Once the class files have been enhanced with this compiled binding definition code, they're ready to work with the JiBX runtime. Since a schema defining the data messages has been provided by the architecture team, the initial binding definition and Java classes will be generated using the Xsd2Jibx tool from the JiBX website.

5.2.3. Unmarshaller

The JiBX runtime provides APIs for unmarshalling input XML documents to Java objects based on the compiled binding definition. For the client portion of PSN-WS, the internal client consumer will invoke the JiBX unmarshalling function on the incoming XML document coming off the JMS topic. The unmarshaller component will produce a Payload Java object containing the event information.

5.3 ADMINISTRATION

The administration subsystem provides administration and the user interface for the PSN-WS project. The administration subsystem is the subsystem in which all of the system functionality is evident to an administrator. The administration subsystem is composed of the following components: Monitor and Control. The Monitor and Control subcomponents will interface with the Server subsystem to monitor subscription status and control subscription configuration.

5.3.1. Monitor

The monitor component of the administration subsystem monitors the current statistics for the selected subscription of the managed server. The status information will include provider server name and IP address, subscription start time, number of events/faults received, etc.

5.3.2. Control

The control component of the administration subsystem controls the current configuration for the PSN-WS provider subscriptions of the managed server. The configuration information will include user name and password, subscription timeout threshold, IP addresses, etc. There will also be functions to get status from the provider web service, view logs, etc.


6 POLICIES AND TACTICS

6.1 JAVA VIRTUAL MACHINE

The PSN-WS project will be developed using the Java programming language. Java is a platform-independent language that can execute on any machine having a compatible version of the JVM. To stay current with a supported JVM, Java 5 will be used.

6.2 CODING CONVENTIONS

The PSN-WS source code implementation will follow Sun Microsystems Code Conventions for the Java Programming Language. These coding conventions are the Sun-recommended standard conventions covering filenames, file organization, indentation, comments, declarations, statements, white space, naming conventions, and programming practices.

6.3 DESIGN PATTERNS

The PSN-WS design will utilize well-known design patterns where possible. Specifically, the following common design patterns will be used. The publish/subscribe and observer patterns will be used between the Program and External System using web services, as well as for internal consumers of the Program.

6.3.1. Publish/Subscribe

The Publish/Subscribe pattern is a heavily used pattern in Enterprise Application Integration (EAI) software as well as in many distributed programming paradigms. The Publish/Subscribe pattern is interesting in the context of the definition of Web Services as application components. Using a topic-based mechanism common in very loosely coupled architectures, you create a stand-alone event service that is, in effect, an application component. The event service forwards published events to subscribers without awareness of the application components that use the event service.

6.3.2. Observer

Rather than leaving a client to determine when data changed on a server, it is often more efficient to have the server component tell interested clients when data changes. This is especially true when the server component has a low frequency of updates compared to the frequency that clients will want to check. The Observer pattern formalizes the relationship between one or more clients and a Web Service that contains interesting state. The Web Service delivers events to interested clients when an interesting change occurs. The Gang of Four documented the Observer pattern. This implementation is similar to the original documentation of the pattern, with necessary information about Web Services.

6.4 REQUIREMENTS TRACEABILITY

Requirements traceability is the ability to describe and follow the life of a requirement through the software lifecycle. This traceability can be used to improve software verification, change control management, and the quality of the product. Requirements traceability is necessary to verify that all software requirements have been met in the software design and have been implemented in the final product. To fulfill requirements traceability to software design, the requirements met by software systems or subsystems will be documented in the detailed design section, as well as the Requirements Traceability section.


http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

6.5 CONFIGURATION MANAGEMENT

This Software Design Document will be controlled by The Program’s Rational ClearCase environment, the PSN-WS software configuration management (SCM) system.

6.6 TEST PLAN

The test plan is essential to define early in the lifecycle to ensure the designers understand the system, the tests meet the requirements and trace to design, as well as prevent test cases that are written to the implementation. The test plan is described in detail in the PSN-WS Test Plan.

7 DETAILED SYSTEM DESIGN

7.1 State Diagrams

The interface between the Program subscriber and the External System is subscription based. The behavior of the interface is largely determined by the state of the subscription, as illustrated in Figure 7.1-1. This figure identifies the primary states that the Program subscriber can traverse for sent and received SOAP messages. Initially, the subscriber is in Unsubscribed state and will typically send a Subscribe to the External System. If the subscription is successfully established, the External System will send the Program subscriber a Subscription Response message, moving the Program subscriber to the Subscribed state. At this state, the Program subscriber can initiate Get Status and Unsubscribe messages to the External System and receive Get Status Response, Unsubscribe Response, and Subscription End messages.

Unsubscribed Subscribed

Receive SubsciprtionResponse

GetStatus, GetStatusResponse

ReceiveGetStatus failure,SubscriptionEnd

Receive UnsubscribeResponse Send Unsubscribe

Figure 7.1-3 State Diagram: WS-Eventing Subscription States

7.2 Use Case Diagrams

The use case diagram in Figure 7.2-1 shows the high-level use cases associated with the typical flow of the user actions. All use cases identified for the PSN-WS software project are included in this figure.


Figure 7.2-4 PSN-WS Use Case Diagram

7.3 Data Flow Diagrams

Data flow diagrams are used as a graphical representation of the flow of data through the system. The data flow diagrams in Figure 7.3-1 and Figure 7.3-2 visually display the event messages coming into the Program from the External System as well as the processing of the internal messages for internal Program consumers.


Figure 7.3-5 Data Flow Diagram: Incoming Data Message (Server)

Figure 7.3-6 Data Flow Diagram: Incoming Data Message (Client)

7.4 Class Diagrams

The class diagrams shown in the following figures show the detailed design for the major components of the PSN-WS system. The diagrams are broken down into the PSN-WS subcomponents server and client.


7.4.1. Server

Figure 7.4.1-7 Class Diagram: Server Subscription Manager Design

Figure 7.4.1-8 Class Diagram: Server Handler Design


Figure 7.4.1-9 Class Diagram: Server Dispatch Design

7.4.2. Client

Figure 7.4.2-10 Class Diagram: Client Data Consumer Design

Figure 7.4.2-11 Class Diagram: Client Payload Message Design


7.5 User Interface Screens

Since the administration user interface screens and images were not explicitly directed in the SRS, this section describes and defines the design as related to the user interface. The screen navigation and visual screens used in the user interface should be easily learned and easy to use. This specification simulates as much as possible the images that will be implemented for the administration portion of the PSN-WS project.

7.5.1. Interface Layout

The PSN-WS Administration Console web application is made up of the following key content zones shown in Figure 7.5.1-1.

Figure 7.5.1-12 Zone Layout

Logo/Header: This zone contains the Program logo graphic, site identifier, and site classification. This zone is displayed in the same location on every page throughout the entire web site.

Information Zone: This zone contains the general details describing the user, what is being edited, and provides links to general topics including but not limited to who is logged on, where they are connected to, a link to online help, a link to the home page, and a link to log out. This zone is displayed in the same location on every page throughout the entire web site.

Change Zone: This zone contains the feature which enables the user to lock the control configuration for editing to ensure only one user is editing the configuration at a time. Actions include “Lock & Edit” and “Release Configuration”. This zone is displayed in the same location on every page throughout the entire web site.

Service Selection Zone: This zone contains a list of resources which are available for the user to control and monitoring. Examples would include, but are not limited to application servers, database servers, diagnostics, and security. This zone is the same on every page throughout the entire web site.


System Status Zone: This zone contains a list of resource high-level statuses. The goal is to provide a snapshot of the cumulative system resource statuses in a single location. This zone is displayed in the same location on every page throughout the entire web site.

Content Zone: This zone displays the content details for the resource selected from the Service Selection Zone. It presents the data in tabular form breaking down the control and monitoring details on separate tabs where applicable.

7.5.2. Monitor Status

This tab is accessible after selecting the PROGRAM service from the Control & Monitor Services zone. It displays the current managed PROGRAM subscriptions for the managed Program Server. A single Program Server may display one or more subscription management servers. The status of each subscription management server is displayed in list format with the applicable alias, IP address, and status. If the subscription is not running the status is reflected and the information is provided to perform control features which will enable the Console Admin to diagnose the problem. Finally, a user may initialize the ‘Auto-Refresh’ action to cause the page to be refreshed based on the Subscription Configuration refresh rate.

Figure 7.5.2-13 Home > The Program > Monitoring > Status

7.5.3. Monitor Subscription Statistics

This tab is accessible after selecting a running PROGRAM subscription from the PROGRAM Monitor Status tab. It displays the current statistics for the selected subscription of the managed Program


Server. The status of the subscription is displayed and the user may choose to refresh the contents by selecting the ‘Refresh’ action from the common ‘Info Zone’.

Figure 7.5.3-14 Home > The Program > Monitoring > Status Statistics

7.5.4. Control Configure

This tab is accessible after selecting the PROGRAM service from the Control & Monitor Services zone and then the Control tab. It displays the current configuration for the PROGRAM subscriptions of the managed Program Server. A Console Admin may enter one or more IP:Port values to associate as managed subscriptions. A Console Admin is required to ‘Lock & Edit’ the console in order to save information to the persistence store.


Figure 7.5.4-15 Home > The Program > Control > Configure


7.5.5. Control Subscribe/Unsubscribe

This tab is accessible after selecting the PROGRAM service from the Control & Monitor Services zone and then the Control tab and ‘Subscribe/Unsubscribe’ option. It provides the Console Admin the ability to subscribe and then unsubscribe from a selected managed subscription. A Console Admin is required to ‘Lock & Edit’ the console in order to perform either of these actions. After locking the console, the screen’s ‘Subscribe’ action will be enabled. After entering the subscription information and selecting the ‘Subscribe’ action, the system will auto refresh this screen until a response is received from the server. During this working time the system will display a ‘Subscription Message Response’ value indicating that action is in a working state. Once a response is received, the ‘Subscription Message Response’ will be updated to reflect the response value and the ‘Unsubscribe’ action will be enabled. Only after performing an unsubscribe action will the subscribe action be enabled again.

Figure 7.5.5-16 Home > The Program > Control > Subscribe/Unsubscribe


7.5.6. Control GetStatus

This tab is accessible after selecting the PROGRAM service from the Control & Monitor Services zone and then the Control tab and ‘GetStatus’ option. It provides the Console Admin the ability to perform a status request for a selected managed subscription. After entering the subscription information and selecting the ‘Send’ action, the system will auto refresh this screen until a response is received from the server. After entering the subscription information and selecting the ‘Subscribe’ action, the system will auto refresh this screen until a response is received from the server. During this working time the system will display a ‘Subscription Message Response’ value indicating that action is in a working state. Once received, the message response will be activated and the ‘Send’ action will be again enabled.

Figure 7.5.6-17: Home > The Program > Control > GetStatus

7.6 Message Definitions

External users to the Program can subscribe to data service notification through web services. This will allow subscribers to receive data notifications, regardless of their hardware platform, operating system, or language implementation. The initial release of the PSN-WS will provide a partial implementation of the WS-Eventing web services specification. This specification provides for a publish/subscribe framework for web services, allowing one web service (called a "subscriber") to register interest (called a "subscription") with another web service (called an "event source") in receiving messages about events


(called "notifications" or "event messages"). The interface between the Program and the External System has two types of messages: control messages and data messages. Control messages manage the connection between the Program server and the External System server. Data messages contain the actual information of interest to the Program.

ITW/AANet SvrBMDS Net Svr

Control Flow

Data Flow

Figure 7.6-18 Control and Data Messages

In the WS-Eventing specification, the subscriber calls a web service interface provided by the server. The client provides fundamental subscription information, including: The client credentials A topic of interest that the client wishes to subscribe to A subscription callback URL, or “reply to” address where the server will send a subscription

response A “notify to” address, where the server will send data messages An “end to” address, where the server can send subscription termination notifications.

Net Server(Event Source)

ClientSubscriber

(Event Sink)

Subscription

Subscription includes:1) Client credentials2) Topic of interest3) Callback URL

Notification

Notification includes:1) Server credentials2) Message data


ClientSubscriber

(Event Sink)

Subscription

Subscription includes:1) Client credentials2) Topic of interest3) Callback URL

Notification

Notification includes:1) Server credentials2) Message data

Figure 7.6-19 Web Services Eventing Overview

7.6.1. Control Messages

Control messages that the Program Server supports are compliant to the WS-Eventing specification. An overview of control messages are summarized in the table below.



ClientSubscriber

(Event Sink)Notification (Data) Messages

Control Messages

Control Messages:• Subscribe • SubscribeResponse• GetStatus• GetStatusResponse

• Unsubscribe• UnsubscribeResponse• SubscriptionEnd


ClientSubscriber


Control Messages



Figure 7.6.1-20 Program Server Message Types

Message Description

Subscribe Issued by a subscriber to initiate a subscription to Program Server data.

SubscribeResponse

Issued by the Program Server in response to a Subscribe. Informs the subscriber that their subscription is in place and conveys the conversational ID number

GetStatus Issued by the external subscriber to the Program Server in order to check subscription status

GetStatusResponse

Issued by the Program Server as a successful reply to a GetStatus request.

Unsubscribe Issued by the subscriber to the Program Server in order to cancel an existing subscription.

UnsubscribeResponse

Issued by the Program Server to acknowledge the removal of a subscription.

SubscriptionEnd * Issued by the Program Server before shutting down service to a subscription. Does not require a response message.

Renew Allows the subscriber to renew or update the expiration date/time of a current subscription. Note: this control message is part of the WS:Eventing Specification, but not implemented for the initial version of the Program Server.

Table 7.6.1-21 Control Message Types

7.6.2. Notification/Data Messages

Control messages that the Program Server supports are compliant to the WS-Eventing specification. An overview of control messages are summarized in the table below.



ClientSubscriber


Control Messages




ClientSubscriber


Control Messages



Figure 7.6.2-22 Program Server Message Types

Message Description

Payload An XML Document specific to the topic that the client has subscribed to.

Table 7.6.2-23 Notification/Data Message Types

8 REQUIREMENTS TRACEABILITY

The traceability from software requirements to software design is shown in Table I. For the sake of space and simplicity, only the high-level functional and non-functional requirements are listed in this table. However, the column describing the design component(s) for which the requirement maps is the complete list for all applicable high-level requirement and sub-requirement mappings. Since this project is being implemented as a college project, effort emphasis must be placed on the design and implementation so the design traceability will not be robust for this project. However, requirements traceability is critical to project success so the traceability activity must be completed.

RQMT# DESCRIPTION TRACED TO DESIGN COMPONENT

F1 PSN-WS shall provide connectivity from Program site to the External System in accordance with the ICD.

Server

F2 PSN-WS shall support a publisher–subscriber communications architecture with External System in accordance with ICD.

Server

F3 PSN-WS shall receive external event data from External System.

Server

F4 PSN-WS shall make available event data received from External System available to Program users at all locations.

Client

F5 PSN-WS shall log the date and time of message receipt and the message contents of all

Server, Log4J


messages received from External System.

F7 PSN-WS shall provide the capability to display the status of the External System interface to the system administrator upon request.

Administration

F8 PSN-WS shall provide the capability for the system administrator to configure the subscription address of the External System server.

Administration

F9 PSN-WS shall provide security for the Program PSN-WS interfaces such that only authorized users can access the Program data.

Server

NF1 PSN-WS shall provide maintainability by using the Program coding standards for all source code.

Server, Client, Administration

NF2 PSN-WS shall provide maintainability by implementing source code functionality documentation per function/method.

Server, Client, Administration

Table I Requirements to Design Traceability

Glossary

ACRONYMS DEFINITIONS

ICD Interface Content Description

PSN-WS Publish-Subscribe Notification for Web Services

SOA Service Oriented Architecture

SRS Software Requirements Specification

WS Web Service

REFERENCES

1 OASIS - Organization for the Advancement of Structured Information Standards

http://en.wikipedia.org/wiki/Service-oriented_architecture

2 WS-Eventing Specificationhttp://ftpna2.bea.com/pub/downloads/WS-Eventing.pdf

3 WS-Security Specificationhttp://ftpna2.bea.com/pub/downloads/WS-Eventing.pdf

4 JiBX - Binding XML to Java Codehttp://jibx.sourceforge.net/


http://jibx.sourceforge.net/

http://ftpna2.bea.com/pub/downloads/WS-Eventing.pdf

http://ftpna2.bea.com/pub/downloads/WS-Eventing.pdf

http://en.wikipedia.org/wiki/Service-oriented_architecture

Software Design Specification.doc

Documents

Transcript of Software Design Specification.doc