cs 701 masters project reportgsc/pub/master/lrosenbu/doc/rosenburg cs 701 fi… · cs 701 masters...

CS 701 MASTERS PROJECT REPORT

PUBLISH-SUBSCRIBE NOTIFICATION

FOR WEB SERVICES (PSNWS)

Prepared by

LEAH ROSENBURG 4/28/2008

Publish-Subscribe Notification for Web Services (PSNWS)

CS 701 Masters Project Rosenburg of 86

TABLE OF CONTENTS

1. INTRODUCTION .................................................................................................................. 6

1.1. Project Overview ............................................................................................................ 6

1.2. Project Scope .................................................................................................................. 6

1.3. Project Deliverables ........................................................................................................ 6

2. REQUIREMENTS.................................................................................................................. 6

2.1. Functional Requirements ................................................................................................ 7

2.2. Non-Functional Requirements ........................................................................................ 7

3. SYSTEM ARCHITECTURE ................................................................................................. 7

3.1. Architecture..................................................................................................................... 7

3.2. Software Design.............................................................................................................. 8

3.3. Design Tradeoffs............................................................................................................. 8

4. CONFIGURATION MANAGEMENT................................................................................ 11

5. INSTALLATION AND DEPLOYMENT............................................................................ 11

5.1. Installation Procedures.................................................................................................. 11

5.2. Deploying Libraries ...................................................................................................... 12

5.3. Deploying Applications ................................................................................................ 12

5.4. Running PSN-WS ......................................................................................................... 12

6. TEST RESULTS................................................................................................................... 13

6.1. Test Case 1: Operability of Consumer Web Service Configuration............................. 14

6.2. Test Case 2: Event Logging on Consumer Server ....................................................... 15

6.3. Test Case 3: Configuration of Internal Client Messaging ........................................... 16

6.4. Test Case 4: Security for Control Messages and Event Notification........................... 16

6.5. Test Case 5: Ability to subscribe to producer web service.......................................... 17

6.6. Test Case 6: Processing Incoming Control Messages and Event Notification............ 18

6.7. Test Case 7: Distribution of External Events to Internal Consumers .......................... 18

7. METRICS ............................................................................................................................. 20

7.1. Software Lines of Code (SLOC)................................................................................... 20

7.2. Resource Expenditure ................................................................................................... 21

8. RESEARCH TOPICS........................................................................................................... 21

8.1. Web Services Standards................................................................................................ 21

8.2. JAX-RPC vs. JAX-WS ................................................................................................. 23

8.3. References..................................................................................................................... 25

8.4. Influence on PSN-WS................................................................................................... 29

9. LESSONS LEARNED.......................................................................................................... 30

9.1. Backup Solution............................................................................................................ 30

9.2. Version Management .................................................................................................... 31

9.3. Documentation.............................................................................................................. 31

9.4. Learning Curve ............................................................................................................. 32

10. PRODUCT TURNOVER ................................................................................................. 32

10.1. Maintenance.............................................................................................................. 32

10.2. Future Enhancements................................................................................................ 32

11. CONCLUSION................................................................................................................. 33

12. APPENDICES .................................................................................................................. 34

12.1. Masters Project Proposal........................................................................................... 35



12.2. Proposal Presentation................................................................................................ 40

12.3. Software Requirements Specification (SRS) ............................................................ 45

12.4. Software Design Specification (SDS)....................................................................... 51

12.5. Software Test Plan (STP).......................................................................................... 76

12.6. Final Presentation...................................................................................................... 81

12.7. Source Code .............................................................................................................. 82

12.8. JavaDocs ................................................................................................................... 83

13. ACRONYMS.................................................................................................................... 84

14. REFERENCES ................................................................................................................. 86



TABLE OF FIGURES

Figure 3-1: High-Level System Architecture ................................................................................. 8

Figure 3-2: Performance of Data Binding Frameworks ............................................................... 10

Figure 4-1: Configuration Management Listing of FOSS and COTS Product Versions Used .... 11

Figure 6-1: Traceability Matrix for Requirements to Test Cases ................................................. 13

Figure 6-2: System Details for Test Environment ........................................................................ 13

Figure 6-3: Valid Configuration of Publisher Subscription Address............................................ 14

Figure 6-4: Invalid Configuration of Publisher Subscription Address ......................................... 14

Figure 6-5: Configuration of Internal Client Messaging .............................................................. 16

Figure 6-6: Ability to Subscribe to the Producer Web Service .................................................... 18

Figure 6-7: Message Injector Tool for Distribution of External Events to Internal Consumers .. 19

Figure 6-8: JMS Monitoring for Distribution of External Events to Internal Consumers............ 20

Figure 7-1: Software Lines of Code (SLOC) Metrics Summary.................................................. 20

Figure 7-2: Resource Expenditure Metrics Summary .................................................................. 21

Figure 8-1: Tabular comparison of JAX-RPC v. JAX-WS .......................................................... 24

Figure 8-2: Tabular comparison of WS-Notification v. WS-Eventing......................................... 26

Figure 8-3: Performance Comparison for Remote Invocation using Various Java Techniques... 29



REVISION HISTORY

Date Name Description

3/28/08 Leah Rosenburg Initial version.

4/20/08 Leah Rosenburg Added Appendices for deliverables. Version for 4/21/08 submission.

4/27/08 Leah Rosenburg Minor Updates. Version for 4/28/08 submission.

4/28/08 Leah Rosenburg Added blurb on JBoss WS-Eventing implementation.



1. INTRODUCTION

1.1. Project Overview

The PSN-WS project is modeled after real-life missile defense work for a major defense

contractor. 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 in 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-Eventing6

specification. The web service is intended to provide mission display data from an external

system to the 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.

1.2. Project Scope

The following listing describes the PSN-WS project scope as stated in Section V of the

Project Proposal.

• Design web services interface conforming to WS-Eventing

• Develop subscriber web service

• Distribute XML data to internal consumers

• Translate XML data to Java object

• Provide administration capabilities

• Create test harness

1.3. Project Deliverables

The following listing describes the PSN-WS project deliverables as stated in Section V of the

Project Proposal. Each of these deliverables has been delivered to the graduate committee

during project lifecycle and is included as an Appendix to this final report.

• Project Proposal

• Software Requirements Specification (SRS)

• Software Design Document (SDD)

• Software Test Plan (STP)

• Source Code

• Final Report and Presentation

2. REQUIREMENTS

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 from requirements to



software design, the requirements met by software systems or subsystems are documented in the

PSN-WS Software Requirements Specification (SRS) and traced to the Software Design

Specification (SDS). The SRS requirements are also traced to Test Cases in Section 6 that details

the test results for the PSN-WS.

2.1. Functional Requirements

This section provides a listing of the complete set of functional requirements that were

derived from Stakeholder Needs and Features as described in the PSN-WS Software

Requirements Specification (SRS). These functional requirements are verified through the

test procedures detailed in Section 6.

• PSN-WS shall provide connectivity from Program site to the External System in

accordance with the ICD.

• PSN-WS shall support a publisher–subscriber communications architecture with

External System in accordance with ICD.

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

• PSN-WS shall make available event data received from External System available to

Program users at all locations.

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

all messages received from External System.

• PSN-WS shall log any faults encountered during execution.

• PSN-WS shall provide the capability to display the status of the External System

interface to the system administrator upon request.

• PSN-WS shall provide the capability for the system administrator to configure the

subscription address of the External System server.

• PSN-WS shall provide security for the Program PSN-WS interfaces such that only

authorized users can access the Program data.

2.2. Non-Functional Requirements

This section provides a listing of the complete set of non-functional requirements that were

derived from Stakeholder Needs and Features as described in the PSN-WS Software

Requirements Specification (SRS). Non-functional requirements are primarily verified

through inspection and source code metrics.

• PSN-WS shall provide maintainability by using the Program coding standards for all

source code.

• PSN-WS shall provide maintainability by implementing source code functionality

documentation per function/method.

3. SYSTEM ARCHITECTURE

3.1. Architecture

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. SOA is not tied to



a specific technology and may be implemented using a wide range of interoperability

standards. The PSN-WS project uses web services to implement this architecture.

PSN-WS uses asynchronous web services to implement the SOA architecture. The web

service’s XML-based control and data messages will be exchanged via Simple Object Access

Protocol (SOAP) over HTTP. This web service is asynchronous and conforms to the WS-

Eventing specification. 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. Additional research about WS-Eventing is found in the Section

8.1. Figure 3-1 shows the high-level system architecture, including web services interfaces

and the WS-Eventing interaction between the Program and the External System.

Figure 3-1: High-Level System Architecture

3.2. Software Design

The PSN-WS software design is derived from the software requirements, design constraints,

and other external factors detailed in the PSN-WS SRS. The complete, detailed software

design can be found in the Software Design Specification (SDS). Specifically, the Security

Design can be found in Section 4.5, Quality Design in Section 6, and Detailed Software

Design in Section 7.

3.3. Design Tradeoffs

3.3.1. Why Web Services?

Net centricity is a customer priority for the Program. Providing this web services-based

data sharing interface between the Program and the External System will satisfy our

customer’s need for net centricity, as well as provide a strategic move for our programs to

leverage this technical strength in the future.

In addition to the driving customer requirement, web services are a logical solution for

this integration effort. Web services provide loosely-coupled, protocol-independent,

standards-based distributed computing. Any program can publish an interface that any

other authorized, interested program can access to provide data sharing and horizontal

integration across military services and/or government agencies. The web service

interface minimizes the amount of interdependencies between the programs and loosely

couples these programs through standards-based communication, such as XML and

Simple Object Access Protocol (SOAP). In contrast to web services, other models like



Common Object Request Broker Architecture (CORBA) are tightly-coupled due to the

usage of vendor specific communication standards.

3.3.2. Why WS-* Specifications?

Web service specifications (WS-*) are designed to be composed with each other to

provide a rich set of tools in the web services environment. Specifically, the PSN-WS

project uses the WS-Eventing, WS-Security, and WS-Addressing specifications. These

WS-* standards were used to create the Interface Content Description (ICD) for the

publishing External Program service. Per the ICD, the PSN-WS project must comply

with the ICD.

The rationale for using WS-* specifications is simple. Since web services have already

been declared as the interface solution, the WS-Eventing specification was selected

because it is an open-standard from World Wide Web (W3) Consortium, an

internationally recognized source of web standards and guidelines. WS-Eventing

describes a protocol that allows web services to subscribe to or accept subscriptions for

event notification messages, allowing an asynchronous notification of events. The nature

of the External Program’s events is random, real-life events. A synchronous, eventing

framework will not work in this problem space. WS-Eventing was selected over the WS-

BaseNotification specification, since it has been updated to reduce potential for overlap

and incompatibilities between these two very similar specifications. The WS-Eventing

specification specifically relies on the WS-Security specification to provide secure and

reliable message delivery. Only a portion of the WS-Security specification has been

implemented for the initial release per the ICD.

3.3.3. Why J2EE?

The PSN-WS project is a small subset of the applications and services that will be

developed for the Program. Currently, the Program is using J2EE to develop these

applications. Aside from the Program direction to use J2EE, it makes sense to use in this

environment. J2EE provides a standards-based platform to develop and deploy scalable,

web-enabled, server-centric enterprise applications. In contrast to other frameworks such

as Microsoft .NET, J2EE is platform-independent allowing us to deploy on non-Windows

machines, and since our program’s developers are familiar with Java, J2EE and BEA

WebLogic Server, J2EE is a simple solution allow for more productive and efficient

development.

3.3.4. Why JiBX?

A portion of the PSN-WS project scope deals with translating XML documents into Java

objects. This translation is necessary so the client component receiving the data can work

directly with the data content rather than the XML document. After some research, the

JiBX data binding framework was selected. JiBX is designed for performance. Since

much of the XML document translation occurs on the client, XML parsing cannot

consume the client resources.

The graphs in Figure 3-2 were taken from Dennis Sosnoski’s IBM article1 and show the

measured performance of some of the popular data binding frameworks available. Note

that JiBX leads these frameworks in the 2 performance areas of interest, client memory

usage for storing a large document representation in memory, and unmarshalling time for

parsing a large document. The performance measurements were also captured for small



documents and the figures are comparable to the large document results. The client will

be receiving documents in the order of the larger document sizes, so these are the most

relevant. Note the unmarshalling and memory usage performance for the JiBX data

binding framework as compared to the other frameworks.

Figure 3-2: Performance of Data Binding Frameworks

3.3.5. Design Changes

3.3.5.1.Interface Content Description (ICD)

The PSN-WS requirements state that the system “shall support a publisher–subscriber

communications architecture with External System in accordance with ICD.” At times

during development, I discovered that the design of the ICD was not implementable.

Specifically, the ICD is inconsistent with the WS-Addressing specification. The WS-

Addressing requires the <wsa:ReplyTo> tag have an embedded <wsa:Address> tag,

but the ICD states that a Subscribe message shall contain the URI address directly in

the <wsa:ReplyTo> tag. Another inconsistency between the ICD and XML standards

involved the formatting of the dateTime type. An example of the proper XML

dateTime type format is “2000-01-12T12:13:14Z”, but the ICD specified a

dateTime format of “CCYY-MM-DDThh:mm:ss”, which was missing the following “Z”.

I discovered some of the defects while both projects were still being funded and were

resolved, e.g. the dateTime format. However, some of these ICD defects were

discovered after the External System was delivered and could not be worked around,

e.g. the WS-Addressing issue. This was a known issue and addressed in Section 3.2.4

Software Constraints of the SDS in Appendix C. The developers of the External

System implemented per the ICD and therefore, the Program implementation must be

compliant in order to communicate with the External System.

3.3.5.2.User Interface

The original user interface design included JavaServer Pages (JSPs) for

administration and test capabilities. During the implementation phase, I completed the

View portion of the JSPs, but the learning curve to properly complete the Control

portion using Struts technology as-designed became overwhelming and taxing.

Before making any design changes, I reviewed my project requirements. The PSN-

WS requirement stated to “provide the capability to display the status of the External

System interface to the system administrator upon request” and “provide the

capability for the system administrator to configure the subscription address of the



External System server”. Since much of the original user interface design was very

out-of-scope from these driving requirements and JSPs were not a project

requirement, I opted to implement a simple, Swing-based user interface to fulfill the

project requirements of administering the subscription status and address.

4. CONFIGURATION MANAGEMENT

The configuration management plan for PSN-WS consists of periodically (no less than weekly)

archiving the development environment to CD-ROM to prevent data loss. Included in the archive

are weekly snapshots of the source code repository, weekly builds of the PSN-WS system, and

the supporting software development tools and libraries. Since the PSN-WS project involved as

much COTS integration as new development, there were a number of free and open-source

(FOSS) and commercial-off-the-shelf (COTS) products used. The different versions of these

software products were recorded, maintained, and archived to enable replication of the

development environment at a later time for maintenance or to implement future enhancements.

Figure 4-1 lists these software tools and versions used for the PSN-WS project.

Product Version Purpose

Apache Ant 1.6.5 Java-based build tool

BEA WebLogic Server 9.1 Application Server

EhCache 1.2.4 Java Distributed Cache

Java JDK 1.5.0_12 Java Development Kit

JiBX 1.1.5 XML Data Binding Tool

JUnit 4.1 Testing Framework

LOG4J 1.2.13 Logging Framework

SAAJ 1.3 Create and Send SOAP Messages

XDOCLET 1.2.3 Attribute-Oriented Programming

Figure 4-1: Configuration Management Listing of FOSS and COTS Product Versions Used

5. INSTALLATION AND DEPLOYMENT

5.1. Installation Procedures

• Install Java JDK 1.5.0_12

• Install BEA WebLogic Server 9.1

• Extract vobs_netserver.zip to C:\

• Create NetServer domain using WebLogic Scripting Tool (WLST)

o See C:\vobs_netserver\setup\NetServerWLS\readme.txt for instructions

o Note: this will set up entire configuration for WLS including security realm,

JMS topics, etc.

• Set NetServer environment variables before building source code using

setNSEnv.cmd

• Build NetServer project source code using C:\vobs_netserver\build.xml

• Verify the following files are located at

C:\bea\weblogic91\user_projects\domains\NetServerDomain\data

o c2bmCMConfig.xml



o HandlerManagerFactory.properties

o SOAP control and event messages for testing

� Subscribe.xml

� SubscribeResponse.xml

� UnSubscribe.xml

� UnSubscribeResponse.xml

� GetStatus.xml

� GetStatusResponse.xml

� SubscriptionEnd.xml

� MultiStage.xml

� MissileLaunchComplex.xml

� PredictedImpact.xml

� QuickAlert.xml

� Reset.xml

5.2. Deploying Libraries

• Log in to Admin server as weblogic in NetServer domain at

http://localhost:7950/console

• Using WLS console, deploy these libraries in the following order:

o c2bmUtilitiesPkg.jar

o c2bmLoggingPkg.jar

o c2bmPubsubPkg.jar

o NSConversions.jar

o c2pwch.jar

• Start servicing on all libraries.

5.3. Deploying Applications

• Log in to Admin server as weblogic in NetServer domain at

http://localhost:7950/console

• Using WLS console, deploy these applications in the following order:

o SubManWebService.war

o MissileWarningConsumerWebService.war

o DataServicesServer.ear

o DataServicesWeb.war

o DataServices-Client.jar

o c2bmConsoleServer.ear

o c2bmConsoleWeb.war

• Start servicing on all applications.

5.4. Running PSN-WS

• Run the PSN-WS administration tool by using the Apache Ant build file target: o C:\vobs_netserver\apps\WSEventing\WebServices>ant test.run.gui

• Configure the subscription address of the External System server

o When using the PSN-WS administration tool as a test harness, use the local server

subscription address localhost:7950



6. TEST RESULTS

As described in the Software Test Plan (STP), the testing process completed the validation and

verification of the following critical functional components. Each functional component is

captured in the test cases below.

• Operability of consumer web service configuration

• Event logging on consumer server

• Configuration of internal client messaging

• Security for control messages and event notification

• Ability to subscribe to producer web service

• Processing incoming control messages and event notification

• Distribution of external events to internal customers

The mapping from the SRS requirements to the test cases is shown in Figure 6-1.

Test Case ID Requirement Text

1 2 3 4 5 6 7

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

X X

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

X

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

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

X X

5 PSN-WS shall log the date and time of message receipt and the message contents of all messages received from External System.

X X

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

X

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

X

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

X

Figure 6-1: Traceability Matrix for Requirements to Test Cases

All test cases were executed on the same system. The system requirements and specifications for

this test environment are shown in Figure 6-2.

Environment Variable Value

Operating System Microsoft Windows XP SP2

CPU Intel Pentium M Processor, 1.73 GHz

Memory 2 GB

Figure 6-2: System Details for Test Environment



6.1. Test Case 1: Operability of Consumer Web Service Configuration

6.1.1. Description

This test verifies the operability of the consumer web service configuration by testing the

configuration parameters entered in the administration tool. The configuration parameters

of the consumer web service include the configuration of the subscription address of the

External System server.

To test the operability of the consumer web service configuration, I used the

administrative interface to enter a valid and invalid subscription address of the External

System server.

6.1.2. Results

By entering the valid test publisher subscription address of localhost:7950, the system

is able to connect to the server and send a Subscribe request.

Figure 6-3: Valid Configuration of Publisher Subscription Address

By entering the invalid test publisher subscription address of localhost:7777, the

system errors and does not connect to the server.

Figure 6-4: Invalid Configuration of Publisher Subscription Address



6.2. Test Case 2: Event Logging on Consumer Server

6.2.1. Description

This test verifies the event logging capabilities on the consumer server. The consumer

server uses Log4J to log event messages to the server logs, so these logs are viewed to

verify the event messages are being recorded when received from the producer server.

6.2.2. Results

The logging mechanism is currently set up to log to the server log located at

NetServerDomain\logs\WebServicesManagerServer\WebServicesManagerServer.log. To

verify SOAP messages are logged upon receipt, I ran the test tool and inspected the logs.

6.2.2.1.Subscribe Response Logging Output

<23 Apr 2008 20:49:15> <WebServicesManagerServer.c2bm.is.wse.GenericHandlerManager>

<DEBUG> request soap message:

<S12:Envelope xmlns:S12="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:wsa="http://www.wsa.org" xmlns:wse="http://www.program.gov/wse/SubscriptionManager"

xmlns:ibmd="http://www.program.gov/XMLSchema/ibmd" xmlns:wss="http://docs.oasis-

open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<S12:Header>

<wss:Security>

<wss:UsertokenName>NSUser<wss:Password type="AES">

aK45xoAlulGLo9LPMA7eMg</wss:Password>

</wss:UsertokenName>

</wss:Security>

<ibmd:VersionNumber>2.0</ibmd:VersionNumber>

<ibmd:DateGenerated TimeStandard="UTC">2006-09-27T21:20:34Z

</ibmd:DateGenerated>

<wsa:RelatesTo>abc123</wsa:RelatesTo>

<wse:Identifier>1234-5678-abcd</wse:Identifier>

<wsa:To>http://localhost:7950/wse/SubscriptionManager</wsa:To>

</S12:Header>

<S12:Body>

<wse:SubscribeResponse>

<wse:SubscriptionManager>

<wsa:Address>http://www.program.gov/mwmd/MissileWarningConsumer</wsa:Address>

</wse:SubscriptionManager>

</wse:SubscribeResponse>

</S12:Body>

</S12:Envelope>

6.2.2.2.Unsubscribe Response Logging Output

<23 Apr 2008 20:53:56> <WebServicesManagerServer.c2bm.is.wse.GenericHandlerManager>

<DEBUG> request soap message:

<S12:Envelope xmlns:S12="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:wsa="http://www.wsa.org" xmlns:wse="http://www.program.gov/wse/SubscriptionManager"

xmlns:ibmd="http://www.program.gov/XMLSchema/ibmd" xmlns:wss="http://docs.oasis-

open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<S12:Header>

<wss:Security>

<wss:UsertokenName>NSUser<wss:Password type="AES">

aK45xoAlulGLo9LPMA7eMg</wss:Password>

</wss:UsertokenName>

</wss:Security>

<ibmd:VersionNumber>2.0</ibmd:VersionNumber>

<ibmd:DateGenerated TimeStandard="UTC">2006-09-27T21:20:34Z

</ibmd:DateGenerated>

<wsa:RelatesTo>abc123</wsa:RelatesTo>

<wsa:ReplyTo>http://www.program.gov/wse/SubscriptionManager</wsa:ReplyTo>

<wsa:To>http://localhost:7950/wse/SubscriptionManager</wsa:To>

</S12:Header>

<S12:Body>

<wse:UnsubscribeResponse/>

</S12:Body>

</S12:Envelope>



6.3. Test Case 3: Configuration of Internal Client Messaging

6.3.1. Description

This test verifies the configuration of the internal client messaging. The internal client

event messaging is configured using BEA WebLogic’s JMS capabilities. The JMS

configuration is inspected for accuracy.

6.3.2. Results

Using the WebLogic Server console, navigate into the NetServerDomain � Services �

Messaging � JMS Modules � NetServerModule-1. The configuration of the NetServer

JMS Module is displayed. Ensure the MISSILE_WARNING_TOPIC is configured as

“topic.notification.missilewarning”.

Figure 6-5: Configuration of Internal Client Messaging

6.4. Test Case 4: Security for Control Messages and Event Notification

6.4.1. Description

This test verifies the authentication security for control messages and event notification

messages by checking the SOAP message security token for validity. By changing the

security token username and/or password in an incoming SOAP message, ensure the

consumer server doesn’t accept the message.

6.4.2. Results

A valid subscribe message was sent to the External System server to establish a

SUBSCRIBE_REQUESTED state. Using the PSN-WS administration and test tool, I

injected an invalid subscribe response message into the consumer web service using an

invalid user id token “invaliduser”. The system responded correctly by throwing the



following exception and rejecting the input and remaining in the

SUBSCRIBE_REQUESTED state, rather than moving to the SUBSCRIBED state. --------------------------------

Authenticating User: invaliduser

UnauthorizedUserException: c2bm.is.wse.exception.UnauthorizedUserException: User

"invaliduser" is not authorized

<Apr 19, 2008 11:52:20 AM MDT> <Error> <Console> <BEA-240003> <Console encountered the

following error UnauthorizedUserException thrown>

c2bm.is.wse.exception.UnauthorizedUserException: User "invaliduser" is not authorized

at c2bm.is.wse.security.NetServerAuthenticator.authenticate

(NetServerAuthenticator.java:12)

at

c2bm.is.wse.GenericHandlerManager.processRequest(GenericHandlerManager.java:71)

at c2bm.is.wse.GenericHandlerManager.handleRequest(GenericHandlerManager.java:46)

at c2bm.is.wse.RedirectHandler.handleRequest(RedirectHandler.java:41)

at

weblogic.wsee.handler.JaxrpcHandlerChain.handleRequest(JaxrpcHandlerChain.java:57)

at weblogic.wsee.ws.dispatch.server.JaxrpcChainHandler.handleRequest

(JaxrpcChainHandler.java:89)

at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:127)

at weblogic.wsee.ws.dispatch.server.ServerDispatcher.dispatch

(ServerDispatcher.java:84)

at weblogic.wsee.ws.WsSkel.invoke(WsSkel.java:60)

at weblogic.wsee.server.servlet.SoapProcessor.handlePost(SoapProcessor.java:66)

at weblogic.wsee.server.servlet.SoapProcessor.process(SoapProcessor.java:44)

at weblogic.wsee.server.servlet.BaseWSServlet$AuthorizedInvoke.run

(BaseWSServlet.java:124)

at weblogic.wsee.server.servlet.BaseWSServlet.service(BaseWSServlet.java:53)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run

(StubSecurityHelper.java:225)

at weblogic.servlet.internal.StubSecurityHelper.invokeServlet

(StubSecurityHelper.java:127)

at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:272)

at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:165)

at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run

(WebAppServletContext.java:3153)

at weblogic.security.acl.internal.AuthenticatedSubject.doAs

(AuthenticatedSubject.java:321)

at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)

at weblogic.servlet.internal.WebAppServletContext.securedExecute


at weblogic.servlet.internal.WebAppServletContext.execute


at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1310)

at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)

at weblogic.work.ExecuteThread.run(ExecuteThread.java:179)

6.5. Test Case 5: Ability to subscribe to producer web service

6.5.1. Description

This test verifies the ability to subscribe to the External System’s producer web service

and establish a “SUBSCRIBED” state as a subscriber to this service.

6.5.2. Results

A valid subscribe message was sent to the External System server to establish a

SUBSCRIBE_REQUESTED state. Using the PSN-WS administration and test tool, I

injected a valid subscribe response message into the consumer web service. The PSN-WS

Administration Tool shows the changed state to SUBSCRIBED and the logs are below. --------------------------------

Authenticating User: NSUser

Received: SubscribeResponse, c2bm.is.pubsub.mwmd.soapmsg.SubscribeResponse@368115

GenericHandlerManager: Done Processing Request



Figure 6-6: Ability to Subscribe to the Producer Web Service

6.6. Test Case 6: Processing Incoming Control Messages and Event Notification

6.6.1. Description

This test verifies the ability to successfully and accurately process incoming control

messages and event notifications.

6.6.2. Results

From the WebServices component, run the test suite that injects all valid messages into

the consumer service using test.run.suite from the build file.

6.7. Test Case 7: Distribution of External Events to Internal Consumers

6.7.1. Description

This test verifies the successful distribution of external events to internal consumers.

6.7.2. Results

Verify the JMS topic “MISSILE_WARNING_TOPIC” is configured using Test Case 3.

Using the MW Message Injector Test Tool, configure the internal NetServer IP address to

point to the server with this MISSILE_WARNING_TOPIC. Add the test data file(s) to

publish to the topic. Select the file(s) to send and click the Publish button. This test tool

acts as the publisher and subscriber, and will publish the file contents to the JMS topic

and also receive the message as a subscriber. Using the BEA WebLogic Server console,

view the JMS topic monitoring tab’s “Total Messages” to verify the correct number of

message(s) were published. View the MW Message Injector Test Tool output to verify

the message(s) sent were received by the internal subscriber.



Figure 6-7: Message Injector Tool for Distribution of External Events to Internal Consumers

--------------------------------

test.run.suite:

[java] log4j: Trying to find [test_log4j.xml] using context classloader

sun.misc.Launcher$AppClassLoader@e39a3e.

[java] log4j: Using URL

[file:/C:/vobs_netserver/components/pubsub/src/test/test_log4j.xml] for automatic log4j

configuration.

[java] log4j: Preferred configurator class: org.apache.log4j.xml.DOMConfigurator

[java] log4j: System property is :null

[java] log4j: Standard DocumentBuilderFactory search succeded.

[java] log4j: DocumentBuilderFactory is:

weblogic.xml.jaxp.RegistryDocumentBuilderFactory

[java] log4j: debug attribute= "null".

[java] log4j: Ignoring debug attribute.

[java] log4j: Threshold ="null".

[java] log4j: Level value for root is [DEBUG].

[java] log4j: root level set to DEBUG

[java] log4j: Class name: [org.apache.log4j.ConsoleAppender]

[java] log4j: Setting property [target] to [System.out].

[java] log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"

[java] log4j: Setting property [conversionPattern] to [%d %-5p [%t] [%c] %m%n].

[java] log4j: Adding appender named [CONSOLE] to category [root].

[java] Clearing existing file list and loading from configuration file

[java] 2008-04-19 17:13:41,986 DEBUG [main] [c2bm.is.util.NetServerUtils]

NetServerURL = localhost:7950

[java] 2008-04-19 17:13:42,868 DEBUG [main] [c2bm.is.pubsub.Subscriber]

Configuration values are:

[java] connectionFactory = topic.TopicConnectionFactory

[java] jndiFactory = weblogic.jndi.WLInitialContextFactory

[java] numberRetries = 3

[java] retryTimeDelay = 30000

[java] 2008-04-19 17:13:55,706 DEBUG [AWT-EventQueue-0]

[test.mwmd.MWEventTesterFrame]

Successfully connected to NetServer: t3://Configure

[java] 2008-04-19 17:13:55,716 DEBUG [AWT-EventQueue-0] [c2bm.is.pubsub.Subscriber]










Connecting publisher to JMS..

[java] 2008-04-19 17:13:59,542 DEBUG [AWT-EventQueue-0] [c2bm.is.pubsub.Publisher]








Publishing message to JMS topictopic.notification.missilewarning

[java] 2008-04-19 17:13:59,712 DEBUG [ExecuteThread: '3' for queue: 'default']

[test.mwmd.TestSubscriber] Consuming MWEvent...

[java] 2008-04-19 17:13:59,722 DEBUG [ExecuteThread: '3' for queue: 'default']

[test.mwmd.TestSubscriber] Received MissileLaunch

Message:c2bm.is.pubsub.mwmd.eventobjs.MissileLaunch@153113d

Figure 6-8: JMS Monitoring for Distribution of External Events to Internal Consumers

7. METRICS

7.1. Software Lines of Code (SLOC)

The SLOC for this project was calculated using the SLOCMetrics freeware product. These

metrics were derived by running the tool on only Java source code files. Therefore, file

extensions other than .java, such as Ant build files, deployment descriptors, and binding

definitions (.xml), Java Server Pages (.jsp), and configuration files (.config, .properties),

were not analyzed for these SLOC metrics. The SLOC summary is shown in Figure 7-1.

COMPONENT # FILES SLOC COMMENTS BLANK TOTAL %COMMENTS

logging 13 858 766 250 1896 42%

utilities 12 1142 682 254 2097 33%

pubsub 47 2291 2163 654 5132 42%

server 45 2096 1387 712 4223 34%

webservices 9 267 99 78 462 25%

console 75 2392 1829 608 4833 38%

TOTAL 201 9,046 6,926 2,556 18,643 37%

Figure 7-1: Software Lines of Code (SLOC) Metrics Summary



7.2. Resource Expenditure

To measure the labor effort for the PSN-WS project, the amount of resources expended in

hours per project activity was recorded. The resource expenditure summary is shown in

Figure 7-2.

ACTIVITY HOURS

Proposal 9

Requirements 15

Design 23

Development 126

Integration & Test 19

Research 41

Documentation 59

TOTAL 292

Figure 7-2: Resource Expenditure Metrics Summary

8. RESEARCH TOPICS

8.1. Web Services Standards

Web services are defined by a plethora of open standards and specifications that define

different components of the web services technology. These standards are developed by

industry participation (e.g. Microsoft, IBM, BEA, etc.) in international standards

organizations such as the World Wide Web (W3) Consortium, Organization for the

Advancement of Structured Information Standards (OASIS), and the Web Services

Interoperability Organization (WS-I).

The goal of developing standards for web services is to facilitate communication between

various distributed systems. The set of core architectural web services standards have been in

place for several years and are widely supported. As a member of the Department of Defense

(DoD) software development community trying to move into the Service-Oriented

Architecture paradigm, I chose to investigate these core architectural web services standards

due to their foundational nature in the web services technology. These core standards

include:

• Extensible Markup Language (XML)2 and XML Schema

3

• Web Services Description Language (WSDL)4

• Simple Object Access Protocol (SOAP)5

In addition to these core standards, a growing set of web services specifications have been

developed with varying degrees of maturity and support. Collectively, these specifications

are referred to as “WS-*”. Since these specifications are not maintained by any single

consortium organization and are being rapidly developed, the specifications often coincide,

overlap, or conflict with other specifications, causing interoperability issues. Many

developers are overwhelmed with the number of specifications available and are unable to

determine which specifications are appropriate for what circumstances. For their relevance in

the PSN-WS project, I will investigate the following WS-* specifications:



• Web Services Eventing (WS-Eventing)6

• Web Services Addressing (WS-Addressing)7

• Web Services Security (WS-Security)8

8.1.1. XML and XML Schema

XML is at the foundation of web services. Since XML is a language-independent

mechanism to describe data and messages, it has become the platform for distributed

application integration using web services. The PSN-WS project uses XML and XML

schemas to describe the web services WSDLs, to create, validate, and parse SOAP

messages, and to describe the internal data that is processed by the Program.

8.1.2. WSDL

The WSDL is an XML-based document that describes the web service interface and how

to access it. WSDL service descriptions are typically published to Universal Description

Discovery and Integration (UDDI) for web service discovery. However based on the ICD

requirement, the PSN-WS did not publish the web services descriptions to UDDI or

utilize UDDI to discover the External System WSDL.

The WSDL can have different binding styles which change the way the underlying SOAP

messages are formatted. The possible permutations are RPC/encoded, RPC/literal,

Document/Encoded, and Document/Literal. The PSN-WS project was required to use

Document/Literal web services based on the ICD requirement. Document/Literal was a

good choice because of the document style of messaging. The payload message can be

validated against an XML schema.

8.1.3. SOAP

SOAP is the communications protocol for web services. As discussed in the WSDL

section, the PSN-WS project used Document/Literal binding to SOAP messaging,

meaning that the XML data document is simply embedded in the SOAP message parts.

This binding is flexible since the contents of the message are in the XML document.

As an open-source specification, SOAP has been implemented by many vendors and

already in 2001, there were over 70 implementations available9. Specifically related to

the PSN-WS project, the BEA WebLogic Server and Java JDK support SOAP and

provides a SOAP implementation with their product. For PSN-WS, the SOAP messages

were manually generated and parsed due to the restrictions of the ICD. Due to this

tightly-coupled format of the SOAP messages, there were issues between the Program

and External System versions of SOAP implementations. To solve these

incompatibilities, both programs moved from the BEA-supplied implementation to using

the SOAP with Attachments API for Java (SAAJ) implementation for SOAP

manipulation.

8.1.4. WS-Eventing

This Web Services Eventing (WS-Eventing) specification proposes a way of

communicating events within and between web services. Similar to the functionality of

Java Messaging Service (JMS) and other publish-subscribe methods, the specification

provides asynchronous notifications to subscribed clients over web services. PSN-WS

uses the WS-Evening specification to subscribe to and receive asynchronous notifications

from the External System.



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.

The WS-Evening overlaps another specification WS-Notification. Both specifications

accomplish nearly the same functionality. The WS-Eventing was chosen and described in

the ICD. A comparison of the two specifications is made in An Analysis of Notification

Related Specifications for Web/Grid Applications13

, which is discussed in Section 8.3.3.

8.1.5. WS-Addressing

As web services specifications are often composed of one or more web services

specifications, the WS-Addressing specification is required by the WS-Eventing

specification to provide the protocol to define endpoint references and message

information headers. WS-Addressing stands alone to provide a standard for representing

message addressing information in web services messages and service descriptions. This

specification extends the capabilities of SOAP to incorporate delivery, reply-to, and fault

handler addressing information into the SOAP message. These details have typically been

handled by the transport layer, e.g. HTTP request/response, JMS message header, etc.

8.1.6. WS-Security

As web services specifications are often composed of one or more web services

specifications, the WS-Security specification is recommended by the WS-Eventing

specification to properly secure messages. However, due to the Program ICD, the only

security consideration taken from the WS-Security specification is the use of security

tokens for user authentication.

As discussed in Standards for XML and Web Services Security12

, the WS-Security

specification provides several additional security mechanisms above and beyond security

tokens for authentication including message transport, confidentiality and integrity,

access control and authorization, and public key infrastructure. In the domain the

Program and External Program are involved, I would definitely choose to implement the

encryption and digital signing of these SOAP messages for added security.

8.2. JAX-RPC vs. JAX-WS

The Java API for XML-Based RPC (JAX-RPC) and the Java API for XML-Based Web

Services (JAX-WS) are technologies designed to simplify the development of SOAP-based

web services and web service clients in Java. JAX-WS, the successor version to JAX-RPC,

was created after the Java Community Process (JCP) identified the need to align with

industry direction. The name was changed to adopt because industry was now developing

message-oriented web services in addition to RPC oriented web services.

For a simple comparison of the two versions of this technology, Figure 8-1 summarizes the

two JAX-RPC version features in a convenient table. As shown, JAX-WS supports many

different protocols. JAX-WS supports both SOAP 1.1 and 1.2. From the developer

perspective, these SOAP specifications are not much different, but this parameter would

come into play if a web services client could only process the newer version of SOAP



messages. JAX-WS has also moved to supporting the newest Java SE and EE versions. JAX-

WS includes support for building RESTful web services endpoints. With RESTFul web

services, there is a natural mapping between the HTTP methods and most business operations

that many services expose (e.g. create, remove, update, delete).

One of the most significant improvements of JAX-WS over JAX-RPC is the newly provided

library of annotations to simplify the development of converting Enterprise Java Beans

(EJBs) or Plain Old Java Objects (POJOs) to web services, and a toolkit of Ant tasks and

command-line utilities that hide the complexity of the underlying SOAP protocol. With this

feature, the server and client components are prevented from manually generating or parsing

the SOAP messages. The PSN-WS project took advantage of using these annotations to

generate the WS-Eventing Subscription Manager and External Program Consumer web

services.

JAX-RPC JAX-WS

SOAP 1.1 1.2

Java Java SE 1.4 or later, J2EE 1.4 Java SE 5.0 or later, Java EE 5.0

Encodings

RPC/encoded

RPC/literal

Document/literal

RPC/literal

Document/literal

Annotations No Yes

Asynchronous No Yes

RESTful WS Support No Yes

Data Mapping Model Custom, Supports 90% Schema Type JAXB 2.0, Supports 100% Schema Type

Handler Model SAAJ 1.2 SAAJ 1.3

When to Use

• You want to stay with something that's been around awhile, JAX-RPC will continue to be supported for some time to come.

• You don't want to step up to Java 5.

• You want to send SOAP encoded messages or create RPC/encoded style WSDL.

• You want to use the new message-oriented APIs.

• You want better support for XML schema through JAXB.

• You want to use an asynchronous programming model in your Web service clients.

• You need to have clients or services that can handle SOAP 1.2 messages.

• You want to eliminate the need for SOAP in your Web services and just use the XML/HTTP binding.

• You like playing with leading edge technology.

Link to Specification JAX-RPC JAX-WS

Figure 8-1: Tabular comparison of JAX-RPC v. JAX-WS

According to RPC Under Fire14

, RPC has many challenges to overcome in today’s world of

web services and XML messaging. Some challenges with RPC include mapping issues

similar to the object/relational mapping problem, exposure of Java exceptions and other

implementation details in the interface which may not be interoperable, and latency issues

caused from blocking times and network failures. Suggested improvements over RPC were

JAX-WS and RESTful web services. JAX-WS provides access to the messages and message



payloads, thereby bypassing the mapping problem found in JAX-RPC. Representational State

Transfer (REST) relies on a fixed set of interface verbs (e.g. HTTP GET/POST) rather than

custom interface definitions, which results in a more message-focused architecture. For

future applications staying current in today’s technology, JAX-WS is the best option.

Another article, Scripting JAX-WS15

, discusses an innovative approach to using JavaScript to

develop web services. JAX-WS provides a natural path for developing JavaScript-based

endpoints and provides more reason to move towards JAX-WS to support leading edge

technologies.

JAX-WS offers simplified development of web services and of web-service-based SOA

architectures, better platform- and language-independence, and an end to the issues

associated with the earlier JAX-RPC framework. Where possible, JAX-WS should be chosen

over JAX-RPC as it is based on the most recent industry standards.

8.3. References

8.3.1. Web Services Standards Road Map10

Web Services Standards Generic Road Map (WSSGRM) proposes a high-level

“road map” that defines the various classifications of available standards.

Research focuses on one standard or references multiple standards making it difficult for

organizations to determine which standards to focus on. The proposed Web Services

Standards Generic Road Map (WSSGRM) provides a high-level view of the available

standards and guides the user through various classifications of web services standards:

programming, foundation, core, extending, supporting, and companion.

When I discovered this paper, I thought I found the perfect reference for discussing web

services standards. I hoped the paper would discuss the core standards and best practices

for which standards are best suited for different scenarios. Despite my disillusionment,

the paper was actually valuable in providing clarity in the areas of web services

standards. With the sheer number of web services standards, it is necessary to get this

top-level view, or “road map”, when getting started in web services. The biggest lesson

gained for me from this paper was the alternatives for deploying web services

technologies. Although the paper did not discuss the figure very much, the figure

affirmed my beliefs that the PSN-WS was very tools-based and less standards-based, as

well as the fact that using a tools-based paradigm requires experience with these tools.

A note of interest from this paper is that the authors found no representation for academia

or professional organizations (e.g. IEEE, ACM, etc.) in standards development. I found

this claim hard to believe since W3 “is open to all types of organizations (including

commercial, educational and governmental entities) and individuals”11

. I could not

substantiate this claim, but W3 requests academia participation in workshops and other

events to pull together diverse ideas and perspectives, and the W3 member list includes

such universities as George Washington University and Stanford University.

8.3.2. Standards for XML and Web Services Security12

Discusses standards that establish a framework for integrating security into XML-

based application, e.g. XML DSig, SAML, XACML, XKMS, and WS-Security.

This paper discussed a comprehensive framework for integrating security into XML-

based applications. The standards discussed address different areas of security such as



message transport, confidentiality and integrity, security tokens for authentication, access

control and authorization, and public key infrastructure.

The standards addressed included XML signatures (XML DSig) that proves the data

integrity and who created it, XML encryption (XML Enc) protect the confidentiality of

the data through encryption, Security Assertion Markup Language (SAML) that provides

XML-based authentication, possibly to provide single sign-on (SSO) between disparate

systems, Extensible Access Control Markup Language (XACML) that provides access-

control policies, Extensible Rights Markup Language (XrML) overlaps XACML for

digital rights management, XML Key Management Specification (XKMS) manages

public keys for use with confidentiality and integrity protocols, and WS-Security

provides SOAP extensions for per-message authentication, confidentiality, and integrity.

As a novice to security in general, I found this paper to be quite beneficial to

understanding the varying degrees of security in distributed application development. The

article clearly described the different web services standards for security in a way that I

could understand their purpose and why I would want them in my application.

8.3.3. An Analysis of Notification Related Specifications for Web/Grid

Applications13

Compares two competing notification specifications – WS-Notification and WS-

Eventing. Selection of specification depends on application requirements.

WS-Notification is part of the Web Service Resource Framework (WSRF) that

encapsulates several other specifications and WS-Eventing is from IBM and Microsoft.

WS-Notification supports raw messages and Notify messages since it uses topic

information, but WS-Eventing only supports raw application-specific messages. WS-

Notification provides Subscribe, Pause, and Resume operations, while WS-Eventing

provides Subscribe, Renew, Unsubscribe, Subscription-End operations. Figure 8-2 shows

a comparison of these specifications.

WS-Notification WS-Eventing

Message Support Notify, Raw Raw

Topic Management Yes No

Operations

• Subscribe

• Pause

• Resume

• Subscribe

• Renew

• Unsubscribe

• Subscription-End

Retrieve Last Message Yes No

Subscription Manager Yes Yes

Link to Specification http://www.ibm.com/developerworks/library/ws-resource/ws-notification.pdf

http://www.w3.org/Submission/WS-Eventing/

Figure 8-2: Tabular comparison of WS-Notification v. WS-Eventing

These two specifications are not mutually exclusive, they can be deployed concurrently

and interact with each other. The selection of WS-Notification or WS-Eventing depends

on the specific application requirements.

Despite the selection of WS-Eventing in the Program and External System ICD, I believe

that either specification is applicable to this problem space. From the paper discussion,



the WS-Notification seems more complex, robust, and supported by a larger portion of

industry based on the fact that it falls within the WSRF. I agree with the authors that the

selection depends on the problem. But since the two are so similar, I believe that in the

interest of interoperability and standardization, the two specifications should be

combined into a single specification.

8.3.4. RPC Under Fire14

Given the challenges associated with using RPC in today’s world of web services

and XML messaging, the days of RPC are likely numbered.

With distributed computing on the rise, Remote Procedure Call (RPC) was developed to

simplify writing distributed applications by hiding the details of the networked

environment. With the recent technological advances of web services and XML

messaging, RPC has come “under fire.” Specifically, the author cites a publication by HP

Laboratories that discusses many issues with the RPC model. This report criticizes RPC’s

object-to-XML mapping by comparing it to the object/relational mapping problem that

has been present for decades, citing a specific problem mapping an XML schema type

(postal code) to a Java object (String). Another problem is that Java exceptions are

exposed to the other distributed web services, causing interoperability problems the client

application does not use JAX-RPC or Java (e.g. legacy system). Also cited are latency

issues when using the RPC model and there are long blocking times and/or retry

requirements for network failures. The RPC model is characterized as “contract-last”

because the contract is so heavily focused on Java and implementation details leak in to

the interface specification, and is driven due to the complexity and unfamiliarity of

WSDL/XML to developers.

To solve some of these issues associated with RPC, the author discusses going in the

direction of a more XML-centric approach like Microsoft’s current work, Cω, a complex,

alternative programming language extension of C#. In particular, Cω supports streams,

anonymous structs, and query operators, all which align with XML Schemas. Approaches

are available to avoid the challenges of RPC, including Cω, JAX-WS which allows direct

access to messages and message payloads, and the message-focused Representational

State Transfer (REST) which relies on fixed set of interface verbs (e.g. HTTP GET/POST

versus specialized interface verbs like getBalance). Given the challenges associated with

using RPC in today’s world of web services and XML messaging, and the recent

development of alternatives and support for those alternatives, the days of RPC are likely

numbered.

8.3.5. Scripting JAX-WS15

Integrating JavaScript and JAX-WS to develop web service end-points allow us to

create flexible and lightweight applications that avoid the RPC issues.

This author’s goal is to shrink the “language divide” between dynamic programming

languages and the traditional middleware community, e.g. Java and C++. In line with this

goal, he proposes the integration of JavaScript and JAX-WS to implement web services.

JavaScript is used to create dynamic web pages but is not limited to browser applications.

An extension of JavaScript is E4X, which allows JavaScript to handle XML.



JAX-RPC issues are discussed in RPC Under Fire, and JAX-WS moves away from these

issues and offers dispatch and provider interfaces, which provide a natural path for

developing JavaScript-based endpoints. The author develops a JAX-WS implementation

using Celtix open-source enterprise service bus (ESB) and the popular, Java-based

JavaScript engine Mozilla Rhino. The author seemed to select the Celtix ESB due to a

personal interest in the product. After creating an implementation, the author concluded

that integrating JavaScript and JAX-WS to develop web service end-points allow us to

create flexible and lightweight applications that avoid the RPC issues.

8.3.6. A Framework for Application Server Based Web Services Management16

FASWSM is an efficient, application server-based web services management

strategy that provides enhanced performance over JAX-RPC.

Web services are used to integrate applications in an enterprise environment. Developing

these applications involve 20% effort implementing the interface and server component,

and 80% effort ensuring the web service is sufficiently operable. To address this problem,

this paper provides an efficient management solution for web services running on an

application server using two components, web service adaptation and dynamic

reconfiguration.

The FASWSM web service adaptation is a managed service within the application server

defined by a web service adapter descriptor (WSAD) XML file, which describes

invocation details, accessor factory information, and registered event listeners. Dynamic

reconfiguration of web services is provided by FASWSM to dynamically modify

infrastructure services, provide access to alternate web services when another web service

cannot be accessed, allow application server to administrate the FASWSM adapters and

services.

Stress and concurrency performance tests were completed using JAX-RPC and

FASWSM to invoke a dummy web service. During this performance testing, FASWSM

showed a significant improvement in service response times over the JAX-RPC method.

The description of these performance tests led me to believe that the use of the Façade

pattern greatly enhanced performance over the JAX-RPC APIs.

Since the bulk of this paper was focused on the implementation of the FASWSM

management solution, I would like to have seen the reference implementation. The

solution seemed to be a compartmentalized, clean approach to managing web services

using many understood software patterns (e.g. façade, observer, factory). The authors

selected an obscure application server that was developed by the Institute of software,

Chinese Academy of Sciences. I would like to see the same implementation deployed to

open-source application server like Apache Tomcat or JBoss.

8.3.7. Java2 Distributed Application Development (Socket, RMI, Servlet, CORBA)

Approaches, XML-RPC and Web Services Functional Analysis and

Performance Comparison17

Analyzes performance for various distributed programming methods in Java.

Sockets and RMI have best performance, JAX-WS needs improvements.

This paper provides and overview of common distributed application development

techniques using Java, JAX-RPC, and JAX-WS, as well as performance analysis using



these methods. The Java methods for distributed programming that are available in

versions of the Sun JDK are sockets, RMI, CORBA, RMI-IIOP, XML RPC, and Web

Services (JAX-WS)

For convenience, I’ve copied the performance results into Figure 8-3 to summarize the

comparison between remote invocations using these diverse methods of Java distributed

application development. The results show that sockets and RMI are clearly yield the best

performance but are not feasible when working in large scale distributed systems due

firewall restrictions. Servlets are often used for web-based, distributed applications. XML

RPC performance was similar to RMI and servlets, but is undesirable due to the lack of

strong data typing. JAX-WS supports SOA concepts and provides strong specifications,

but it is still needed performance improvements.

This paper was very interesting because it shows the immaturity of web services over the

incumbent distributed application development techniques. Although web services

provide great potential for interoperability and extensibility, the performance of JAX-WS

was significantly worse than any of the others. This is a great area of research to pursue

in the future, as SOA and web services gain more momentum in industry.

Figure 8-3: Performance Comparison for Remote Invocation using Various Java Techniques

8.4. Influence on PSN-WS

The research topics discussed here were drawn from IEEE resources. To gain the greatest

educational value, I selected diverse topics that would discuss different applications of web

services standards, JAX-RPC, and JAX-WS. The topics were interesting and had relevant

information pertaining to the various standards, specifications, management, and

performance of web services. Unfortunately, due to the nature of the PSN-WS project being

modeled after real-life work, I was unable to influence the web services design and

management as much as I would have liked based on this research and the knowledge gained

about web services standards and best practices. The ICD was developed by engineers

unfamiliar with SOA and web services, and as a result, the ICD contained many

incompatibilities with core web services standards and specifications. The ICD was the

driving requirement of the PSN-WS design and thus, drove a design that did not incorporate

the web services standards and best practices I discovered through my research.



However, if I had the opportunity to re-architect the PSN-WS system and software design

based on what I’ve learned, I would use some of the web services standards and best

practices discovered, including:

• Application Server – In the context of the Program, using BEA WebLogic Server was

an obvious choice of application server. However, if re-architecting PSN-WS as a simple

graduate project, I would have made use of the open-source JBoss application server for

the fact that the WS-Eventing specification is already implemented in JBoss and is simple

to use. Using JBoss, the only work required to develop a WS-Eventing web service is to

create an event source WSDL that points to the JBoss WS-Eventing endpoint

implementation. BEA WebLogic Server supports WS-Eventing but does not come with

the implementation out of the box.

• Security – Based on the standards discussed in Standards for XML and Web Services

Security12

, I realized that the initial design for the PSN-WS project does sufficiently

secure the message transmission. Although the PSN-WS does incorporate WS-Security

specification, it only implements the security authentication token portion of the

specification. In addition to the currently implemented authentication and message

transport security through SSL, I would implement message confidentiality through the

use of XML encryption and integrity through the use of XML digital signatures.

• Interface – The ICD was used as the contract between the Program and the External

System to provide publish-subscribe functionality between web services. The ICD is a

SOAP-focused Word document that describes each valid SOAP message in detail. This is

an error-prone method to describe a specification because the XML listed in this textual

format cannot be validated against a data or WS-* schema from within the Word

document. Indeed, the ICD contained many inconsistencies, including errors in dateTime

formatting, WS-Addressing tags, and namespaces to name a few. These issues could be

easily resolved had the two programs been funded equally and on the same development

cycle. But the External Program implemented their endpoint prior to the Program and

was no longer funded at the time these issues were discovered and could not fix the

implementation. Since the External System implemented their endpoint strictly per the

ICD, these errors were included in the implementation and the Program was driven to

write the consumer web services to comply with the External System implementation.

To design web services standards as they are intended to be used, I would generate a

WSDL to act as the primary “contract” between the two endpoints so that the client or

server piece could be easily generated. Using this WSDL rather than a Word document

would remove many opportunities to introduce defects into the design. If both endpoints

use a WSDL as the contract, both endpoints can be generated and the projects can make

use of tools such as JAX-WS that hides the implementation details of the SOAP

messaging, again minimizing the opportunity for defects in the implementation.

9. LESSONS LEARNED

9.1. Backup Solution

After completing a significant portion of my PSN-WS project, the hard drive on my personal

computer (PC) became corrupted and almost completely unsalvageable. The problem was not

a lack of configuration management processes, but a lack of a backup solution. The PC hard



drive was a single point of failure. To prevent such a disaster from striking twice, I not only

continued to perform the original configuration management processes of saving weekly

versions of the source code and documentation. I matured my processes in include weekly

hard copy backups on compact disk (CD). By maintaining versions on both hard disk and

compact disk, I lower the risk of complete loss of the project.

9.2. Version Management

The design of PSN-WS leverages the use of many Free and Open Source Software (FOSS)

products as well as Commercial Off-the-Shelf (COTS) products to integrate the two disparate

software systems. As with any popular software product, there are a wide variety of versions

available offering different features and capabilities. During the course of my project, I found

that different components of my project were using different versions of these FOSS and

COTS products. These discrepancies caused incompatibilities between the components and

the functionality of the software.

To implement version management for PSN-WS, I maintained a listing of my FOSS and

COTS products and versions, as well as a central library repository for all FOSS and COTS

version dependencies and libraries. Specifically, this central repository can be found in the

extracted source code package under C:\vobs_netserver\lib. By providing this central

repository, all dependencies on these FOSS and COTS products are maintained by pointing

to only this area.

In addition to keeping a centralized version of the dependencies, constant values were

defined in the ant.properties file for the locations of these libraries. These constants were

continually reused throughout the various component build files to point to the PSN-WS-

specific FOSS or COTS dependency. An additional benefit to defining these constants is the

ability to change out a library version without modifying the build file for each component

depending on this library. For example, the log4j library is defined as follows:

lib.log4j=${dir.tools}/log4j-1.2.13.jar

To upgrade from log4j version 1.2.13, I could simply download the newest log4j version

1.2.15, place it in the centralized repository, and change the log.log4j property. All

component build files using this property pull the new library dependency.

9.3. Documentation

During PSN-WS source code development, the requirement to “provide maintainability by

implementing source code functionality documentation per function/method” became very

cumbersome and frustrating. My code development habits often include writing verbose

comments, but not typically in the method JavaDocs. However, I found this associated

documentation to be very helpful throughout the lifecycle of the project.

In addition to the source code documentation, another documentation task that contributed

greatly to the success of the project was keeping a general project notebook. Maintaining

notes on compilation, dependency, and technological anomalies allowed me to keep a pulse

on the progress of the project. In the beginning of the development stage of the project, I did

not maintain a log of issues, to-dos, or moving forward tasks and found that I would be very

inefficient when coming up to speed after a brief break. Once I implemented this project log,

I was able to identify and quickly resolve known issues, remember my thoughts and ideas

when I last touched the project, and keep track of the items left to complete.



However tedious the documentation activities were, they played a large role in the successful

completion of the PSN-WS project. Using these documentation techniques provided a

roadmap of my thoughts and intentions, allowing me to be more efficient and productive

while working on the project.

9.4. Learning Curve

During the proposal phase of the PSN-WS project, I was working on this project with a small

team of developers. With my background in Java/J2EE and WebLogic Server, I believed this

project would be very achievable on my own with the guidance of my development team.

However, after this real-life project was canceled and I no longer worked with this

development team, I found the project very challenging to complete on my own. The

challenge was inherent in the number of unfamiliar, new tools and technologies. I was

interested in this project topic to learn web services, XML binding, and reinforce my limited

experience in J2EE concepts. The challenges I faced could have been less painful with

training and guidance. I have a more realistic outlook on taking on new technologies and the

efforts associated with that, and respect the need for training and tools for software

development.

10. PRODUCT TURNOVER

10.1. Maintenance

Maintenance for the PSN-WS project is being addressed in many ways. JavaDoc is delivered

as part of the PSN-WS delivery. This documentation aids the maintenance effort by

providing a roadmap of the PSN-WS Application Programming Interfaces (APIs). By

fulfilling the PSN-WS requirement to provide maintainability through using the Program

coding standards for all source code, the source code is also standardized, creating a more

navigable, orderly packaging structure.

In addition to the coding standards and documentation, the PSN-WS project provides test

harnesses that can be utilized to regression test the system during maintenance to ensure all

functionality originally developed is still in working order. These test capabilities are

delivered and maintained with the complete PSN-WS package from the configuration

managements system.

10.2. Future Enhancements

10.2.1. Functionality

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.

• Services through JavaScript – Through the PSN-WS research, I discovered the

Scripting JAX-WS15

article, which described an implementation of web services using

JavaScript as a web service end-point. By removing the heavyweight Java/C++

components, our services can be flexible to changing business requirements and

rapidly deployable. This area could be a potential future enhancement or R&D area of

interest for other opportunities.

10.2.2. Research & Development (R&D)

The government-wide push toward SOA is driving our company to embrace net centricity

to meet the needs of our customers. The PSN-WS is a foray into the world of net

centricity, a strategic direction for these programs and for the company. As such, the

PSN-WS will be added to the R&D archive at my employer until the funding challenges

are resolved and further development can be continued.

11. CONCLUSION

The goal of this project was to establish a reusable pattern for implementing web services within

the existing system architecture of the Program to fulfill the customer goal of supporting a

Service Oriented Architecture (SOA) to allow sharing of data across information systems. The

PSN-WS project met the customer need to support SOA and provide a common situational

awareness for the end user. But our internal goal of creating a reusable pattern for web services

was not meet. This project was a great learning experience in SOA and web services and with all

the lessons learned from this effort, I think we have the foundational knowledge to create a

successful web services framework in future endeavors.



12. APPENDICES



12.1. Masters Project Proposal



CS-701 MASTERS PROJECT PROPOSAL

PUBLISH-SUBSCRIBE NOTIFICATION FOR WEB SERVICES

BY LEAH ROSENBURG

I. ADVISORY COMMITTEE

The advisory committee is comprised of three computer science graduate faculty members.

The committee members are responsible for providing any necessary direction during the

project duration, reviewing submitted project deliverables, attending any scheduled review

meetings, and administering the final project evaluation. The following computer science

graduate faculty members have agreed to serve on the advisory committee for this project.

The signatures below indicate approval of this project proposal and the agreement of

project scope.

II. OVERVIEW

This project will be modeled after my real-life missile defense work at my employer. 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.

This web service will be asynchronous and conform to the WS-Eventing1 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. As a member of the infrastructure team, I have been tasked with developing the

web service interface, distributing the data to internal consumers, and providing

administration capabilities.

III. PROJECT DESCRIPTION

A. Process

The Program uses an iterative, spiral development cycle and the duration of this

project will fall under one spiral. At this time, the systems engineering group has

Advisory Committee Project Approval

Chairman Dr. Tim Chamillard Date

Member Dr. Lewis Pinson Date

Member Dr. Edward Chow Date



submitted system level requirements to the development team. I am responsible for

refining and extending these into software requirements, providing a complete

software design, implementing the design, and integrating the two information

systems. The project will use object-oriented development.

B. Technical

This project will be developed using Java and J2EE.

• Web Services. The web service messages will be exchanged via Simple Object

Access Protocol (SOAP) over HTTP. This web service will be asynchronous and

conform to the WS-Eventing specification. This 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.

• 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 a

technology such as JiBX2 or XMLBeans

3.

• Administration. The systems engineering group has provided us with system

level requirements of system administration. Since I am working within the realm

of J2EE, I plan to provide this capability through server and platform independent

JavaServer Pages (JSP) user interfaces.

• Security. Security information will be contained in the SOAP message header

according to the WS-Security4 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. In addition to the security portion

of the message headers, IP filtering will be used to manage the finite list of IP

addresses that are allowed to connect to the server. However, I will not be

implementing IP filtering. The network team of the Program is responsible for

implementing this portion of security.

• Testing. Testing in a distributed environment, especially between two distinct

programs, presents many challenges. To alleviate these challenges, I will provide

a robust test harness to invoke the web services interface. To further test the

implementation, I will use Cactus5 and/or JUnit

6 technologies.

C. Research

Having little to no experience with web services and XML, there is a lot of research

potential in this project. To keep the scope of this project achievable, I am selecting

the following for research.



• Investigate JAX-RPC7 vs. JAX-WS

8

• Investigate Web Services Standards

I will study of the capabilities, differences, and advantages of using these approaches

for this software development project.

IV. METHODOLOGIES AND TECHNOLOGY

This section provides a convenient listing of the methodologies and technologies that will

be used for this project.

• Object-Oriented Development

• Eclipse with WTP Plug-in

• Java 5.0

• J2EE: EJB, JMS, JSP, Web Services

• BEA WebLogic Server 9.1

• SOAP / XML

• JUnit / Cactus

• Apache Ant

V. PROJECT PLAN

A. Project Scope

• Design web services interface conforming to WS-Eventing

• Develop subscriber web service

• Distribute XML data to internal consumers

• Translate XML data to Java object

• Provide administration capabilities

• Create test harness

B. Proposed Schedule

Activity COMPLETION DATE

Project Proposal 3 Oct 06

Requirements Specification 9 Oct 06

Design Specification 23 Oct 06

Test Plan 23 Oct 06

Software Development 20 Nov 06

Software Test 30 Nov 06

Software Complete 30 Nov 06

Final Report 04 Dec 06

Final Presentation 12 Dec 06

C. Deliverables

• Project Proposal (this document)

• Software Requirements Specification (SRS)



• Software Design Document (SDD)

• Test Plan

• Source Code

• Final Report and Presentation

VI. REFERENCES

[1] WS-Eventing Specification

http://www.w3.org/Submission/WS-Eventing

[2] JiBX: Binding XML to Java Code

http://jibx.sourceforge.net/

[3] XMLBeans – Technology for accessing XML by binding it to Java types.

http://xmlbeans.apache.org/

[4] WS-Security Specification

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-

1.0.pdf

[5] Cactus – Test framework for unit testing server-side java code.

http://jakarta.apache.org/cactus/

[6] JUnit – Test framework

http://www.junit.org/index.htm

[7] JAX-RPC – Java API for XML-Based RPC

http://java.sun.com/webservices/jaxrpc/

[8] JAX-WS – Java API for XML Web Services

http://java.sun.com/webservices/jaxws/



12.2. Proposal Presentation

MESE Project ProposalMESE Project Proposal

PublishPublish--Subscribe Notification for Web ServicesSubscribe Notification for Web Services

Leah RosenburgLeah Rosenburg

CSCS--701 Masters Project701 Masters Project

October 4, 2006October 4, 2006

OverviewOverview

� Project Description– Objectives

– Process

– Technical

– Research

� Methodologies and Technology

� Project Plan – Scope

– Deliverables

– Metrics

– Schedule



Project DescriptionProject Description

� Objectives

– Model masters project after real-life work

– Support Service Oriented Architecture (SOA) for data sharing

– Establish a reusable pattern for implementing web services

– Provide mission display data from an external system

– Use industry WS-* Specifications

Net Server(WebSvc)

Net Server(WebSvc)

External System My Program

Control Msgs

Event Msgs

Program Server

Clients

Event Msgs

Project Description (continued)Project Description (continued)

� Process– Use spiral development cycle

– Develop using object-oriented principles

� Technical– Use Asynchronous Web Services

– Conform to WS-Eventing specification

– Distribute XML Payload using JMS

– Translate XML Payload to Java Object

– Provide user administration with JSP interface

– Secure message transfer using WS-Security specification

� Research– Investigate Web Services Standards

– Investigate JAX-RPC vs. JAX-WS

– Reference IEEE/ACM Resources



Methodologies and TechnologyMethodologies and Technology

� OOA/OOD

� Eclipse with WTP Plug-in

� Java 5.0

� J2EE: EJB, JMS, JSP, Web Services

� BEA WebLogic Server 9.1

� SOAP / XML

� JUnit / Cactus

� Apache Ant

Project PlanProject Plan

� Scope– Design web services interface conforming to WS-Eventing

– Develop subscriber web service

– Distribute XML data to internal consumers

– Translate XML data

– Provide administration capabilities

– Create test harness

� Deliverables (via email)– Project Proposal

– Software Requirements Specification (SRS)

– Software Design Document (SDD)

– Test Plan

– Source Code

– Final Report and Presentation



Project Plan (continued)Project Plan (continued)

Activity Completion Date

Project Proposal 3 Oct 05

Requirements Specification 9 Oct 05

Design Specification 23 Oct 05

Test Plan 23 Oct 05

Software Development 20 Nov 05

Software Test 30 Nov 05

Software Complete 30 Nov 05

Final Report 04 Dec 05

Final Presentation 12 Dec 05

� Metrics

– Resource Expenditure (per Activity)

– Java SLOC

� Schedule

My QuestionsMy Questions

� Each Committee Member:

What will be your primary focus area?

� Are there any project requirements that I have not

addressed?



Your QuestionsYour Questions



12.3. Software Requirements Specification (SRS)



CS-701 SOFTWARE REQUIREMENTS SPECIFICATION (SRS)


BY LEAH ROSENBURG

I. INTRODUCTION

A. PURPOSE

The purpose of this software requirements specification (SRS) is to fully

describe the desired behavior of the Publish and Subscribe Notification for

Web Services (PSN-WS) project software system. The functional and

nonfunctional software requirements are detailed in this SRS document, as

well as design constraints and any other factors needed to provide a complete,

comprehensive description of the software requirements

B. SYSTEM OVERVIEW

The PSN-WS project is modeled after real-life missile defense work at my employer.

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-

Eventing 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.

C. REFERENCES

The SRS content was completed using the background information provided in the

approved Interface Content Description (ICD) between the Program and the External

System.

D. ASSUMPTIONS AND DEPENDENCIES

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.

E. STAKEHOLDER NEEDS



The stakeholder needs describe business problems that must be addressed in

order to justify consideration or use of a new system. These needs illustrate

the key problems the software application should solve. Refer to TABLE I for

a complete listing of the stakeholder needs for the PSN-WS project.

Need ID Need Text Link to

Stakeholder Link to Feature

1 Support a Service Oriented Architecture (SOA) Colonel Sanders

2, 5

2 Facilitate collaboration between operators with a common situational awareness.

Colonel Sanders

1, 3, 4

TABLE I: STAKEHOLDER NEEDS

F. FEATURES

The software application features are services that the system provides to

fulfill one or more stakeholder needs. Features describe what a software

system must provide at a very high level to meet the stakeholder needs. Refer

to TABLE II for a detailed listing of the elicited features for the PSN-WS

project.

Feature ID Feature Text Feature Priority Link to Req

1 Distribute External System event to all Program users HIGH 4

2 Provide administration capabilities MED 7, 8

3 Log Event Notifications LOW 5, 6

5 Conform to web service ICD with External System HIGH 1, 2, 3

TABLE II: FEATURES

II. USE-CASE MODEL

The following use case model describes the set of user functions available to each of the

system actors for the system.



Table III: User Functions

III. ACTOR SURVEY

The actor survey section of the SRS describes all the actors depicted in the use-case

model. The actor name and a brief description are listed for each actor in TABLE IV.

Actor ID Actor Name Actor Description

1 External Producer Represents a producer of external system event notifications

2 Internal Consumer Represents a consumer of the external system event notifications that resides within the Program

3 Administrator User of the PSN-WS software having permissions to access the WS interface administration capabilities

TABLE IV: ACTOR SURVEY

IV. REQUIREMENTS

A. FUNCTIONAL REQUIREMENTS



The functional requirements of the system are listed in TABLE V.

Req ID

Requirement Text

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

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

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

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

5 PSN-WS shall log the date and time of message receipt and the message contents of all messages received from External System.

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

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

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

TABLE V: FUNCTIONAL REQUIREMENTS

B. NON-FUNCTIONAL REQUIREMENTS

Non-functional requirements are recorded in TABLE VI of the SRS.

Req ID

Req Text

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

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

TABLE VI: NONFUNCTIONAL REQUIREMENTS

V. DESIGN CONSTRAINTS

The PSN-WS project will be developed using the Java language version that is used by the

Program. The design is constrained by the specific details located in the Interface Content

Description between the Program and the External System.



VI. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

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



12.4. Software Design Specification (SDS)



CS-701 SOFTWARE DESIGN SPECIFICATION (SDS)


BY LEAH ROSENBURG

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 my employer. 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.



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-Eventing

2 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-1: High-Level System Architecture

Figure 5-2: High-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.

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. 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

Receive

GetStatus failure,

SubscriptionEnd

Receive UnsubscribeResponse Send Unsubscribe

Figure 7-1: State Diagram: WS-Eventing Subscription States

7.2. USE CASE DIAGRAMS

The use case diagram in Figure 7-2 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: 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 and Figure 7-4 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: Data Flow Diagram: Incoming Data Message (Server)

Figure 7-4: 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-5: Class Diagram: Server Subscription Manager Design

Figure 7-6: Class Diagram: Server Handler Design



Figure 7-7: Class Diagram: Server Dispatch Design

7.4.2. CLIENT

Figure 7-8: Class Diagram: Client Data Consumer Design



Figure 7-9: 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-10.

Figure 7-10: 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-11: 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-12: Home > The Program > Monitoring > Status Statistics

7.5.4. CONTROL CONFIGURE


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-13: Home > The Program > Control > Configure

7.5.5. CONTROL SUBSCRIBE/UNSUBSCRIBE


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-14: Home > The Program > Control > Subscribe/Unsubscribe

7.5.6. CONTROL GETSTATUS


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-15: 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-16: 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)

Client

Subscriber

(Event Sink)

Subscription

Subscription includes:

1) Client credentials2) Topic of interest3) Callback URL

Notification

Notification includes:1) Server credentials

2) Message data

Net Server

(Event Source)

Client

Subscriber

(Event Sink)

Subscription

Subscription includes:

1) Client credentials2) Topic of interest3) Callback URL

Notification

Notification includes:1) Server credentials

2) Message data

Figure 7-17: 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.



Net Server

(Event Source)

ClientSubscriber

(Event Sink)Notification (Data) Messages

Control Messages

Control Messages:• Subscribe

• SubscribeResponse

• GetStatus

• GetStatusResponse

• Unsubscribe

• UnsubscribeResponse

• SubscriptionEnd

Net Server

(Event Source)

ClientSubscriber


Control Messages



• GetStatus


• Unsubscribe


• SubscriptionEnd

Figure 7-18: 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-19 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.



Net Server

(Event Source)

ClientSubscriber


Control Messages



• GetStatus


• Unsubscribe


• SubscriptionEnd

Net Server

(Event Source)

ClientSubscriber


Control Messages



• GetStatus


• Unsubscribe


• SubscriptionEnd

Figure 7-20: Program Server Message Types

Message Description

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

Figure 7-21: Testing Process for PSN-WS.

Test procedure development feeds the integration and acceptance testing for ultimate signoff.

8. REQUIREMENTS TRACEABILITY

The traceability from software requirements to software design is shown in Table 8-1. 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

Client



all locations.

F5 PSN-WS shall log the date and time of message receipt and the message contents of all messages received from External System.

Server, Log4J

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

Administration

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

Administration

F8 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 8-1: Requirements to Design Traceability

9. GLOSSARY

ACRONYMS DEFINITIONS





WS Web Service

10. 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/



12.5. Software Test Plan (STP)



CS-701 SOFTWARE TEST PLAN (STP)


BY LEAH ROSENBURG

1. INTRODUCTION

1.1. PURPOSE

The purpose of this software test plan (STP) is to describe the verification and validation

testing process for the completed Publish-Subscribe Notification for Web Services (PSN-

WS) project software system and subsystems. The PSN-WS software test plan is derived

from the functional and nonfunctional software requirements detailed in the PSN-WS

software requirements specification (SRS).

1.2. SYSTEM OVERVIEW

The PSN-WS project is modeled after real-life missile defense work at my employer. 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.



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.

2. SCOPE AND OBJECTIVES

2.1. TESTING SCOPE

The testing process shall complete the validation and verification of the following critical

functional components:

• Operability of consumer web service configuration

• Event logging on consumer server

• Configuration of internal client messaging

• Security for control messages and event notification

• Ability to subscribe to producer web service

• Processing incoming control messages and event notification

• Distribution of external events to internal customers

• Administration of active subscriptions

2.2. TESTING PROCESS



Figure 2-1: Testing Process for PSN-WS.

Test procedure development feeds the integration and acceptance testing for ultimate signoff.

2.3. INTEGRATION TESTING

The integration testing will be conducted in two phases. First, testing will be completed in

the local development environment by using a ‘mock’ reproduction of the External System.

This system will serve as the event source to establish subscriptions and notify the event sink

of events. Second, testing will be completed in the local development environment with the

test tool for verifying the incoming event message processing.

Once the PSN-WS system has completed the local testing, the system will be moved to the

development environment where the PSN-WS will be deployed to the actual Program

servers that have access to connect with the External System for further testing.

2.4. ACCEPTANCE TESTING

Demonstrating the subscription and notification capability using the PSN-WS system

completes acceptance testing. The acceptance test is complete upon verification of the

following:

• PSN-WS system deploys and runs on the consumer Net Server

• PSN-WS system delivers external events to internal consumers

• PSN-WS system leaves no residue on system when removed from Net Server

2.4.1. ENTRANCE CRITERION

Entrance criterion for acceptance testing is the successful completion of integration

testing with all minor issues documented and no known major issues.

2.4.2. EXIT CRITERION

The exit criterion for acceptance testing is the successful subscription and notification

capability completed by a system administrator.

Project

Development

System Test

Development

Test Procedure

Development

Integration

Testing

Identify

Publisher WS

Acceptance

Testing Signoff



3. TEST PHASES AND CYCLES

3.1. SYSTEM TESTING CYCLES

In the spiral software development cycle, each software release is subject to developer unit

testing. This unit test phase is generally done at each functionality milestone. Once several

functionality milestones have been verified by unit testing, regression testing is completed to

ensure the integrity of previously developed code. End-to-end system testing takes place, also

in an incremental fashion.

The PSN-WS system must subscribe to a known External System producer of events. The

External System will be duplicated in the local development environment for unit testing

purposes. Once the PSN-WS completes unit testing in the local development environment,

the system will move on to the controlled development environment where the PSN-WS can

connect to the actual External System for system testing.

3.2. SOFTWARE DELIVERY

The PSN-WS system is deployed in phases such that once the application completes all

objectives contained within the scope of the phase, the system is bonded by SCM.

4. SYSTEM TEST SCHEDULE

Test Activity Start Date End Date

Unit Testing February 18, 2007 April 18, 2007

System Testing April 21, 2007 April 30, 2007

Acceptance Testing May 1, 2007 May TBD, 2007

Table 4-1: System Test Schedule for PSN-WS.

5. RESOURCES

5.1. HUMAN

Human resources required to complete the PSN-WS system testing can be limited to one

tester. The developer needs to be readily available during this testing phase if any questions

or issues happen to arise.

5.2. HARDWARE

Due to the nature of this work, I cannot discuss the hardware requirements of our deployed

systems, but the same configuration must be used for the PSN-WS system.

5.3. SOFTWARE

The PSN-WS system contains web services and web applications that must be deployed to a

WebLogic Server. For the application to be tested successfully, a functional External System

must be available for subscription and notification.



6. ERROR MANAGEMENT/CONFIGURATION MANAGEMENT

The PSN-WS system is placed in the Program’s software configuration management (SCM)

control during development. Development builds are built and deployed by the individual

developer in the local development environment. Any builds that are to be deployed in the

controlled development environment or in the actual fielded systems must be built by the SCM

team.

Error management is controlled through the software modification request (SMR) system.

During development phases, changes can be made to the PSN-WS system until there is a code

freeze for an integration event. Once baselined and delivered, the PSN-WS system cannot be

modified unless there is an issue with the code or functionality. Any issues located in the PSN-

WS system must be identified and submitted as SMRs in the SMR system. Each SMR is

reviewed, prioritized, and assigned by the software control review board.

7. ISSUES/RISKS/ASSUMPTIONS

7.1. ISSUES AND RISKS

• 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.

7.2. ASSUMPTIONS

• The External System will be available and conform to the Program-External

System Interface Content Description (ICD).

• System administrators will regulate access and coordinate site training on the

PSN-WS system administration and the External System administration.

8. SIGNOFF

Signoff comes when a representative from each stakeholder category verifies that the PSN-WS

system can successfully receive External System events, and they are willing to accept the risks

associated with fielding the PSN-WS system.



12.6. Final Presentation

Date: Monday, April 28, 2008 @ 11:00am

Location: Engineering Room 239

Attendees: Dr. Chamillard

Dr. Pinson

Dr. Chow

Presentation: http://cs.uccs.edu/~gsc/pub/master/lrosenbu/doc/MESE Final Presentation

- Rosenburg.ppt



12.7. Source Code

PSN-WS source code is located at http://cs.uccs.edu/~gsc/pub/master/lrosenbu/src.



12.8. JavaDocs

PSN-WS JavaDocs are located at http://cs.uccs.edu/~gsc/pub/master/lrosenbu/doc/Javadoc.



13. ACRONYMS

ACRONYM DESCRIPTION

ACM Association for Computing Machinery

AES Advanced Encryption Standard

API Application Programming Interface

CD Compact Disk

CORBA Common Object Request Broker Architecture

COTS Commercial Off-the-Shelf

EJB Enterprise Java Bean

FOSS Free and Open Source Software

HTTP Hypertext Transfer Protocol


IEEE Institute of Electrical and Electronics Engineers, Inc.

J2EE Java 2 Platform, Enterprise Edition

JAX-RPC Java API for XML-based Remote Procedure Call

JAX-WS Java API for XML Web Services

JDK Java SE Development Kit

JMS Java Message Service

JSP JavaServer Pages

PC Personal Computer

POJO Plain Old Java Object


R&D Research and Development

SAAJ SOAP with Attachments API for Java

SDD Software Design Document

SLOC Software Lines of Code


SOAP Simple Object Access Protocol


STP Software Test Plan

UDDI Universal Description Discovery and Integration

W3 World Wide Web

WLS WebLogic Server

WLST WebLogic Scripting Tool



WS Web Services

WSRF Web Service Resource Framework

WTP Web Tools Platform

XML eXtensible Markup Language



14. REFERENCES

[1] Sosnoski, D., JiBX Performance, http://www.ibm.com/developerworks/library/x-

databdopt2/index.html#h6, 1 January 2003

[2] W3, Extensible Markup Language (XML) 1.0 (4

th Edition) Specification,

http://www.w3.org/TR/xml/, 29 September 2006

[3] W3, XML Schema Specification, http://www.w3.org/XML/Schema, 28 October 2004

[4] W3, Web Services Description Language (WSDL) 1.1 Specification,

http://www.w3.org/TR/wsdl, 15 March 2001

[5] W3, SOAP Version 1.2 Specification, http://www.w3.org/TR/soap/, 27 April 2007

[6] W3, WS-Eventing, http://www.w3.org/Submission/WS-Eventing/, 15 March 2006

[7] W3, WS-Addressing, http://www.w3.org/Submission/ws-addressing/, 10 August 2004

[8] OASIS, WS-Security, http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-

spec-os-SOAPMessageSecurity.pdf, 1 February 2006

[9] Wolter, R., XML Web Services Basics, http://msdn2.microsoft.com/en-

us/library/ms996507.aspx, December 2001

[10

] Alkhatib, G.I., Web service standards road map, Next Generation Web Services Practices,

2005. NWeSP 2005. International Conference, 22-26 August 2005

[11

] W3, http://www.w3.org/Consortium/membership-faq, 2 Jan 2008

[12

] Naedele, M., Standards for XML and Web services security, Computer, April 2003, Volume

36, Issue 4, pp 96 – 98.

[13

] Pallickara, S., Fox, G., An Analysis of Notification Related Specifications for Web/Grid

applications, Proceedings of the International Conference on Information Technology: Coding

and Computing (ITCC’05), Volume 2, 4-6 April 2005, pp 762 - 763

[14

] Vinoski, S., RPC Under Fire, IEEE Internet Computing, October 2005

[15

] Vinoski, S., Scripting JAX-WS, IEEE Internet Computing, June 2006

[16

] Guan, H., A Framework for Application Server Based Web Services Management,

Proceedings of the 12th Asia-Pacific Software Engineering Conference (APSEC’05), 2005

[17

] Jagannandham, D., Java2 Distributed Application Development (Socket, RMI, Servlet,

CORBA) Approaches, XML-RPC and Web Services Functional Analysis and Performance

Comparison, 2007 International Symposium on Communications and Information Technologies

(ISCIT 2007), 2007, pp. 1337-1342

cs 701 masters project reportgsc/pub/master/lrosenbu/doc/rosenburg cs 701 fi… · cs 701 masters...

Documents