Your SlideShare is downloading. ×
Software Design Specification.doc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Software Design Specification.doc

773
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
773
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. SOFTWARE DESIGN SPECIFICATION (SDS) PUBLISH-SUBSCRIBE NOTIFICATION FOR WEB SERVICES (PSN-WS) Prepared by LEAH ROSENBURG 5/6/2010
  • 2. TABLE OF CONTENTS Software Design Specification .........................................................................................................................................1 (SDS)................................................................................................................................................................................1 Publish-Subscribe Notification for Web SERVICES (PSN-WS).......................................................................................................................................1 Table of Contents.............................................................................................................................................................2 1Introduction.....................................................................................................................................................................4 2System Overview...........................................................................................................................................................4 3Design Considerations...................................................................................................................................................4 3.1Assumptions and Dependencies.................................................................................................................................4 3.2General Constraints.....................................................................................................................................................5 3.2.1.Requirements..........................................................................................................................................................5 3.2.2.Network Communications .......................................................................................................................................5 3.2.3.Hardware Constraints..............................................................................................................................................5 3.2.4.Software Constraints...............................................................................................................................................5 3.3Goals and Guidelines..................................................................................................................................................5 3.4Development Methods.................................................................................................................................................5 4Architectural Strategies..................................................................................................................................................5 4.1Architectural Style........................................................................................................................................................5 4.2Web Services..............................................................................................................................................................6 4.3User Interface..............................................................................................................................................................6 4.4Data Distribution. .......................................................................................................................................................6 4.5Security.......................................................................................................................................................................6 4.6Data Storage...............................................................................................................................................................6 4.7Future Enhancements.................................................................................................................................................6 5System Architecture.......................................................................................................................................................7 5.1Server..........................................................................................................................................................................8 5.1.1.Subscription Manager .............................................................................................................................................8 5.1.2.Handler ...................................................................................................................................................................8 5.1.3.Dispatcher ..............................................................................................................................................................8 5.1.4.Administration Facade ............................................................................................................................................8 5.2Client...........................................................................................................................................................................9 5.2.1.Data Consumer ......................................................................................................................................................9 5.2.2.JiBX Binding............................................................................................................................................................9 5.2.3.Unmarshaller...........................................................................................................................................................9 5.3Administration..............................................................................................................................................................9 5.3.1.Monitor ...................................................................................................................................................................9 5.3.2.Control ....................................................................................................................................................................9 6Policies and Tactics......................................................................................................................................................10 6.1Java Virtual Machine.................................................................................................................................................10 6.2Coding Conventions..................................................................................................................................................10 6.3Design Patterns.........................................................................................................................................................10 6.3.1.Publish/Subscribe .................................................................................................................................................10 6.3.2.Observer................................................................................................................................................................10 6.4Requirements Traceability.........................................................................................................................................10 6.5Configuration Management.......................................................................................................................................10 6.6Test Plan...................................................................................................................................................................11 Rosenburg – PSN-WS SDD Page 2 / 25
  • 3. 7Detailed System Design...............................................................................................................................................11 7.1State Diagrams..........................................................................................................................................................11 7.2Use Case Diagrams..................................................................................................................................................11 7.3Data Flow Diagrams .................................................................................................................................................12 7.4Class Diagrams.........................................................................................................................................................13 7.4.1.Server....................................................................................................................................................................14 7.4.2.Client.....................................................................................................................................................................15 7.5User Interface Screens..............................................................................................................................................16 7.5.1. Interface Layout...................................................................................................................................................16 7.5.2. Monitor Status.....................................................................................................................................................17 7.5.3. Monitor Subscription Statistics.............................................................................................................................17 7.5.4.Control Configure..................................................................................................................................................18 7.5.5. Control Subscribe/Unsubscribe...........................................................................................................................20 7.5.6. Control GetStatus................................................................................................................................................21 7.6Message Definitions..................................................................................................................................................21 7.6.1.Control Messages..................................................................................................................................................22 7.6.2.Notification/Data Messages...................................................................................................................................23 8Requirements Traceability............................................................................................................................................24 Glossary.........................................................................................................................................................................25 References.....................................................................................................................................................................25 Rosenburg – PSN-WS SDD Page 3 / 25
  • 4. 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 Rosenburg – PSN-WS SDD Page 4 / 25
  • 5. 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. Rosenburg – PSN-WS SDD Page 5 / 25
  • 6. 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. Rosenburg – PSN-WS SDD Page 6 / 25
  • 7. • 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 Rosenburg – PSN-WS SDD Page 7 / 25
  • 8. 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. Rosenburg – PSN-WS SDD Page 8 / 25
  • 9. 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. Rosenburg – PSN-WS SDD Page 9 / 25
  • 10. 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. 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. Rosenburg – PSN-WS SDD Page 10 / 25
  • 11. 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. Receive SubsciprtionResponse Unsubscribed Subscribed Receive UnsubscribeResponse Send Unsubscribe GetStatus, GetStatusResponse Receive GetStatus failure, SubscriptionEnd 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. Rosenburg – PSN-WS SDD Page 11 / 25
  • 12. 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. Rosenburg – PSN-WS SDD Page 12 / 25
  • 13. 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. Rosenburg – PSN-WS SDD Page 13 / 25
  • 14. 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 Rosenburg – PSN-WS SDD Page 14 / 25
  • 15. 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 Rosenburg – PSN-WS SDD Page 15 / 25
  • 16. 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. Logo / Header Zone Change Zone Information Zone Service Selection Zone Content Zone System Status Zone 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. Rosenburg – PSN-WS SDD Page 16 / 25
  • 17. 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 Rosenburg – PSN-WS SDD Page 17 / 25
  • 18. 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. Rosenburg – PSN-WS SDD Page 18 / 25
  • 19. Figure 7.5.4-15 Home > The Program > Control > Configure Rosenburg – PSN-WS SDD Page 19 / 25
  • 20. 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 Rosenburg – PSN-WS SDD Page 20 / 25
  • 21. 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 Rosenburg – PSN-WS SDD Page 21 / 25
  • 22. 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. Control Flow ITW/AA BMDS Net Svr Net Svr 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. Subscription includes: 1) Client credentials 2) Topic of interest 3) Callback URL Subscription Client Net Server Subscriber (Event Source) (Event Sink) Notification Notification includes: 1) Server credentials 2) 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. Rosenburg – PSN-WS SDD Page 22 / 25
  • 23. Control Messages: • Subscribe • Unsubscribe • SubscribeResponse • UnsubscribeResponse • GetStatus • SubscriptionEnd • GetStatusResponse Control Messages Client Net Server Subscriber (Event Source) (Event Sink) Notification (Data) 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. UnsubscribeRespons Issued by the Program Server to acknowledge the removal of a e 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. Rosenburg – PSN-WS SDD Page 23 / 25
  • 24. Control Messages: • Subscribe • Unsubscribe • SubscribeResponse • UnsubscribeResponse • GetStatus • SubscriptionEnd • GetStatusResponse Control Messages Client Net Server Subscriber (Event Source) (Event Sink) Notification (Data) 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 Server to the External System in accordance with the ICD. F2 PSN-WS shall support a publisher–subscriber Server communications architecture with External System in accordance with ICD. F3 PSN-WS shall receive external event data from Server External System. F4 PSN-WS shall make available event data received Client from External System available to Program users at all locations. F5 PSN-WS shall log the date and time of message Server, Log4J receipt and the message contents of all messages received from External System. Rosenburg – PSN-WS SDD Page 24 / 25
  • 25. F7 PSN-WS shall provide the capability to display the Administration status of the External System interface to the system administrator upon request. F8 PSN-WS shall provide the capability for the system Administration administrator to configure the subscription address of the External System server. F9 PSN-WS shall provide security for the Program PSN-WS Server interfaces such that only authorized users can access the Program data. NF1 PSN-WS shall provide maintainability by using the Server, Client, Administration Program coding standards for all source code. NF2 PSN-WS shall provide maintainability by implementing Server, Client, Administration source code functionality documentation per function/method. 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 Specification http://ftpna2.bea.com/pub/downloads/WS-Eventing.pdf 3 WS-Security Specification http://ftpna2.bea.com/pub/downloads/WS-Eventing.pdf 4 JiBX - Binding XML to Java Code http://jibx.sourceforge.net/ Rosenburg – PSN-WS SDD Page 25 / 25