Software Analysis and Design
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
Software Analysis and Design
Sample Project
Specification
1. Introduction
In this project you will implement a prototype system that allows for the invocation of Web Services from within a SIP protocol environment. Specifically, you will use the Java API for Integrated Networks Session Initiation protocol (JAIN-SIP) which is the full implementation of the SIP Protocol RFC 3261 standard by the National Institute of Standards and Technology (NIST). This reference implementation that can be found on https://jain-sip.dev.java.net/ provides classes that implement the SIP Proxy, SIP Registrar, and SIP Presence server. You must obtain the source code of this implementation from the project’s CVS repository.
The SIP proxy servers help route requests to the user's current location, authenticate and authorize users for services, implement call-routing policies, and provide features to users.
The SIP Registar servers allows users to upload their current locations for use by the proxy servers. To access these servers a client application called SIP Communicator is used.
The SIP Communicator is a software-based IP phone. The SIP Communicator (Client Agent) is built on top of the JAIN-SIP-RI and Java Media Framework API (JMF). The SIP Communicator client application can be used to place VoIP phone calls between two PCs or between a PC and an IP Phone (see https://sip-communicator.dev.java.net/). In particular, this SIP Client Agent can create a SIP request, send it to the SIP proxy server and also generate a response to a SIP request. You must obtain the source code for this implementation of the SIP Communicator from the project’s CVS repository. The schematic operation of the main components of the SIP Protocol are illustrated in Figures 1 and 2 below.
Figure 1 . Registration process of a Client Agent
Figure 2. The schematic operation of the SIP Protocol with two SIP Client Agents, a Proxy Server, and an Location Server.
Based on the described configuration, the objectives of the project are:
a) To allow the Location server to contact a Web Service Registry, and obtain information on whether a user (i.e. the called party) has registered any Web Services to his or her account and information on the locations/handlers of these Services;
b) To allow the Proxy server to send this information to the caller, and finally
c) To allow the caller to invoke one of the Web Services the called party has registered. The underlying premise is that if a party has registered any Web Services then this party would decline calls and prefer these services to be invoked instead.
For the Web Service Registry you will use the Web Services Development Platform (WSDP) kit by Sun Microsystems. A public Service Registry has already been installed in the SUN EE machines and can be used to post and query your services. For a private installation of the Service Registry you can visit the WSDP Web site where you can obtain the appropriate class files ( http://java.sun.com/webservices/jwsdp/index.jsp).
More details of the functional and non-functional requirements of the system can be found in the sections below.
2. Operational Descriptions
2.1. Overall System Operation
The basic assumption is that the system you will implement will be consistent with the RFC 3261 standard. That means the system should not invalidate the operation of the RFC 3261 standard, and the exceptional cases (disconnects, dropped connections, as well as, proxy, registrar, location, and Client Agent failures), will be handled according to the RFC 3261 specification.
The normal system operation where no services are involved can be summarized in Figure 3 below.
Figure 3. Normal System Operation – No Services registered.
The normal system operation where services for Agent B have been registered at the Service Registry can be summarized in Figure 4 below.
Figure 4. Operation of the System when Agent B has registered Services
2.2. Service Registry Operation
The service Registry keeps track of Web Service handlers for Web Services registered by different organizations (business entities). For this project you will assume that each group is a different organization (business entity). You can consider two standards of service repositories for this project. The first is called Universal Discovery Description and Integration (UDDI). A good tutorial on UDDI can be found on http://www.onjava.com/pub/a/onjava/excerpt/jws_6/index1.html. The other standard is called ebXML by Sun Microsystems. Information on ebXML can be found in http://www.sun.com/products/soa/registry/ and in http://www.oasis-open.org/committees/document.php?document_id=12049. The ebXML Registry is more closely integrated with the WSDP environment and its use as a Service Registry technology for this project would be preferred. An ebXML Service Registry is installed in the SUN EE machines for public use by the groups of the class. Alternatively, you can install your own private copy of the registry for development purposes only on your home computer.
You can assume that the overall structure of Service Registry entries in a Registry has the following nested layout:
- Organization (Business Entity – Your own group)
o Services (Business Services. Contain descriptions of services, contact names etc.)
§ Service Bindings (Binding Template. Contain technical information about a service, and references to t-Models)
· External Links (Contain pointers to technical description of services. These external links reference wsdl files)
For the project you will consider that an organization (a project group) has registered services, and each service has a Service Binding. A Service Binding will reference an External Link that references a .wsdl file trough a URI. Eventually this URI will be passed to the SIP proxy and to the caller Client Agent to be used by Client Agent Wrapper (see Fig. 4) so that through the use of the appropriate libraries (JAXRPC or WSIF) to ubiquitously invoke a selected Web Service. The libraries we will use to call a Web service from a SIP Wrapper are either the WSIF (Web Services Invocation Framework) by IBM, or the JAX-RPC by Sun Microsystems. The Service Registry can keep also associations between entities for example between an Organization and Services (i.e. to keep track which Services are offered by an Organization).
Services and organizations can also be deleted from the registry by specifying the corresponding name or the entry Id (organization Id , service Id).
The service registry can be queried using the JAXR API that is part of the WSDP package. Sample code to query the Registry will be given to you and posted in the Web site of the course. For this project the query of the service Registry takes the form of obtaining the details (Service Bindings and External Links) of the posted services by an organization.
Templates for Web Services and their wsdl files or location access points will be given in the class and posted in the Web site of the course. For this project we will consider simple Web Services that send e-mail between clients. See section Web Services below for more details.
The overall Service Registry installation, maintenance, user account housekeeping, and database management is managed by the Registry Administrator.
2.3. Web Services Operation
For this project you will consider that SIP Agents can register one type of Web Services called Selective e-mail Service. The operational template for this service is
Service: S::Selective e-mail Service
Input: A::Agent /*Calling Agent */
Message::String
Local Variables: B::Agent /*Service Owner – Called Agent)
Output: R::Result status
/* Operational template */
if (A == A1 or A2 or …) then
{
mail-to:[email protected] (Message::String); R=OK;
}
elseif (A==A3 or . . . )
{
mail-to:[email protected](Message); R= OK
}
elseif . . . .
. . . . . . . .
else R=FAIL
You are free to consider and build other Web services if you like. However, you should not use existing real commercial services for your system. The Web service template and sample wsdl files will be given to you in the class and posted on the Web site of the course.
2.4. Location Server Operation
The normal operation of the Location Server is to provide the location details of the called party. This information is forwarded via the Proxy Server (see Figure 1) to the calling party (Agent A) to establish communication with the called Agent (Agent B).
In this project we will extend the functionality of the Location Server to first try to locate whether the called party (Agent B) has any service registered with the service registry.
Specifically, if there are no services registered for an Organization (group) then the Location server returns the location details of the called party (Agent B), and the protocol proceeds as in the normal SIP operation.
On the other hand, if Agent B has registered any Web Services with the Service Registry then the location server forwards to the proxy a message containing a list of descriptions of services, and service handlers, indicating from where and how the service can be invoked. The service handlers are in the form of URLs that specify the location of wsdl files or direct access points to the corresponding Web Service. The format of the list of descriptions and handlers that is returned by the location server in the corresponding message is:
. . . . . . --
An example message involving 3 services is:
3 -- EmailToOfficeService www.foo.com/sample1.wsdl -- EmailToHomeService www.test.com/sample2.wsdl -- EmailToMobile www.test.com/sample3.wsdl
Note that Web services can be registered off-line using a Web interface to access the Service Registry. If you are interested you can also build your own Java client that can be used to register and de-register services to the Registry using the JAXR API.
The Pseudo-code that describes the operational profile of the extended Location Server is:
..........
/* Point where Location server requests Agent’s location */
result = Query-Service-Registry(agent); /* Obtain services and service bindings */
if result == NULL then
find-agent-location-IP(agent)
else {
msg = build-message-to-proxy(result);
send-messgae-to-roxy(msg);
}
........
The Location Server is maintained and managed by the Location Server Administrator.
2.5. Proxy Server Operation
The normal operations of the Proxy Server are:
a) To contact the Location Server to obtain information on the called Agent;
b) To contact the called Agent and inform it of the call request by the calling party/and;
c) To obtain reply from the called Agent whether the call will be accepted, declined etc. and forward this reply to the calling party.
For the project, the extended operation of the Proxy Server is
1) Examine whether the location server sends a Web Service handler list or the specific Agent’s location address;
2) If the Location server sends the Agent’s IP location (that is no services are registeded for this client) then the proxy behaves in its normal operation and a call is established between the calling parties;
3) If the Location Server returns a list of service descriptions and service handlers then the Proxy Server builds a message to be send to the calling Agent. The message is a DECLINE message for establishing a connection with the called Agent, and attaches in the MESSAGE BODY section of the message the list of the service descriptions and service handlers. The message can be build using the JAIN-SIP API. In this case the called Agent is never contacted. The service descriptions and service handlers format in the MESSAGE BOBY is:
. . . . . .
--
An example message involving 3 services is:
3 -- EmailToOfficeService www.foo.com/sample1.wsdl -- EmailToHomeService www.test.com/sample2.wsdl -- EmailToMobile www.test.com/sample3.wsdl
Similarly, the Pseudo-code that describes the operational profile of the extended Location Server is:
..........
/* Point in Proxy Server where the information is received from */
/* Location Server */
if (result-from-Location-Server == NULL) /* No Services found */
{
proceed with normal operation as per the SIP specification
}
else /* A list of services is found */
{
msg = build-message(DECLINE, list-of-services-and-handlers);
send-message-to-calling-agent(msg, calling-agent);
}
........
The Proxy Server is managed and maintained by the Proxy Server Administrator.
2.6. SIP Agent Operation
The normal SIP Agent operation in the project is to obtain the reply from the Proxy Server and examine whether it is a DECLINE message with a MESSAGE BODY that lists the identified services and handlers. If the received message is a DECLINE message and its MESSAGE BODY (see RFC 3261) contains text listing the service descriptions and handlers in the format specified above, then the client displays these service descriptions in its panel for the user to select a service. Once the user selects a service then the corresponding handler is passed to the wrapper so that the service can be invoked.
The extended SIP client with the additional functionality to process, handle, display, the data in the MESSAGE BODY will be provided for you. A snapshot of the extended SIP client is illustrated in the Figure 5 below.
Figure 5. Layout of the extended Client Agent SIP-Communicator
2.7. SIP Agent Wrapper Operation
The Wrapper is a Java class that maintains a reference to the Agent that wraps. Similarly, the Agent maintains a reference of its wrapper. There can be only one wrapper per Agent (see Fig. 4).
The operation of the wrapper is to accept a Web Service handler (i.e. a wsdl file location), to call the corresponding Web Service, receive the result, and pass the result back to the Agent if needed.
The wrapper invokes the corresponding Web Service by building a SOAP message. In order to simplify the project, you can use a library such as WSIF to build a SOAP message by just providing the wsdl service description. Alternatively you can use the JAX-RPC libraries to call the Web Service. The JAX-RPC library is part of the WSDP package you use for the Service Registry, and the Service Registry query module. Information on the WSIF library can be found on http://ws.apache.org/wsif/. Information on WSDP and JAX-RPC can be found on http://java.sun.com/webservices/jwsdp/index.jsp and on https://jax-rpc.dev.java.net/ respectively.
3. Functional Requirements – Use Cases
3.1. Registration Scenaria
3.1.1. Client registration Scenario
Under this scenario, a Client Agent (Agent A) registers with a proxy. The scenario starts by the user starting a SIP Communicator session, and then proceeds to register with the Proxy Server. This is the standard registration operation for a SIP Communicator client. It assumes that a SIP Proxy is already running and the configuration file is set properly to denote sending and receiving port numbers.
3.1.2. Client registers Web Service Scenario
This scenario pertains to a user registering a new Web Service. The scenario starts by the user initiating a Web browser session and visiting the ebXML registration page. The user enters a new service entry and a new service binding for this entry. The user saves his/her choices every time it completes an entry (service, and service binding). The scenario assumes a service registry is already running and that the user has registered his or her organization name and details. For this project the name of the organization is the name of your group.
3.1.3. Client de-registers Web Service Scenario
This is a dual scenario with respect to registering a Web Service. This scenario pertains to a user de-registering an existing Web Service attached to his or her organization. The scenario starts by the user initiating a Web browser session and visiting the ebXML registration page. The user searches for his or her organization name and selects the services tab to list all services in the organization. The user selects the appropriate service and service binding that needs to be de-registered and confirms the choice. The scenario assumes that a service registry is already running and that the user has registered his or her organization name and details. For this project we will consider that the name of the organization is the name of the group.
3.2. Normal Operation Scenaria
3.2.1. Normal Operation with no Web Services (SIP call)
Under the normal operation scenario, the calling party (Agent A) is selecting a remote Agent to dial (Agent B). After entering the information Agent A clicks “Dial”. Agent’s B client is ringing and Agent B accepts the call. The conversation is established. This scenario follows the SIP standard messaging sequence as described in the RFC 3261.
3.2.2. Normal operation Scenario with Web Services (selective e-mail)
This scenario pertains to the invocation of a Web Service by the calling Agent. The scenario starts by the calling Agent (Agent A) initiating a call to Agent B. Assuming that Agent B has registered a Web Service under his or her organization (i.e. group) the scenario events proceed as specified in Figure 4. Agent B obtains a list of service handlers, selects one and passes it to its wrapper for processing. The wrapper calls the service. In our scenario the Service is an e-mail client that selectively sends and e-mail with the message format:
“Agent
3.3. Pathological Scenaria
3.3.1. Non-existent called agent Scenario
This scenario pertains to the situation where the location server does not have or can not obtain the location of the called Agent (Agent B). The scenario is handled as specified in the RFC.
3.3.2. Calling Agent crashes Scenario
This scenario pertains to the situation where the calling Agent (Agent A) crashes after it dials the called party (Agent B). The scenario is handled as specified in the RFC.
3.3.3. Called Agent crashes Scenario
This scenario pertains to the situation where the called Agent (Agent B) crashes after it accepted the call. The scenario is handled as specified in the RFC.
3.3.4. Proxy Server crashes Scenario
This scenario pertains to the situation where the Proxy Server has crashed after the calling Agent (Agent A) has registered. The scenario is handled as specified in the RFC.
3.3.5. Service Registry Not Available Scenario
This scenario pertains to the situation where the service registry has crashed or is not available. The scenario assumes that the Proxy and the Location server operate normally. The Location server (as per Figure 4) sends a query to the Service Registry before sends a reply to the Proxy Server. If the Service Registry is not available an exception should be raised and the Proxy should send to the calling party (Agent A) a TEMPORARILY UNAVAILABLE message (SIP Message ID: 480).
3.3.6. Not-accessible Web Service Scenario
This scenario pertains to the situation where the service is not accessible by the wrapper. In this case an exception is raised and the client is notified about the unavailable service.
4. Non-Functional Requirements
4.1. Platform Deployment
The system will be deployed on a Windows platform, and implemented using the Java programming language.
4.2. Security
The system should prevent reverse calls and invocation loops. For example, attention needs to be paid to not registering a Web Service that initiates a call to the original called Agent. Also, it must be verified that the Web Services registered for this project do not have side effects on other external systems. Finally, the max number of hops property of the RFC must be checked for any violations resulting from your programmatic extensions.
4.3. Performance
The service registry system should be able to return within 40 secs results for a query. The calling Agent should be able to get the corresponding message from the proxy server within 45 secs. of the initiation of the call. If the Proxy Server or the Location Server crashes and looses communication with the calling Agent, the expected operational behavior from the SIP RFC 3261 standard should be applied. To minimize the load please do not register more than 5 services in the registry per organization (group).
5. Customer acceptance criteria
The acceptance criteria will be for the system to pass the use case scenario outlined in Section 3. The acceptance criteria include also the test that the Web Service performs correctly (i.e. the right e-mails are sent).
6. Summary of Tasks and Available Resources
The programming tasks for this project are summarized as follows:
1. To modify the Location server to be able to query the service registry (sample code to query the registry using the JAXR API will be given to you), and pass the list of services or NULL to the Proxy for further processing.
2. To modify the proxy server to be able to accept service descriptions from the registry and to compose MESSAGE BODY strings as specified in Section 2.5.
3. To modify the Client Agent to reference a Wrapper. The code for the new Client Agent (SIP-communicator) UI as illustrated in Section 2.6 will be given to you
4. To create a Wrapper class that references the Client Agent. This Wrapper class should use the WSIF or the JAAX-RPC API to invoke the Web Service that has been selected using the Client Agent UI (see Figure 5).
5. To modify the template service and the wsdl specification file that will be given to you to create variant Web Services to use in your system.
The available resources for this project are:
1. The SIP Communicator and the JAIN SIP Proxy / Location / Registration Servers. You can also install these on your PCs if you decide to work and develop the system on your home computer. Keep in mind that the final demonstration must be done on the NEXUS machines.
2. The on-line Service Registry and the Web interface to register and de-register services. The Service registry is part of the WSDP toolkit that you can also download and install it on your home PCs. The JAXR libraries for querying the service registry and sample Java client code to query and update the registry will be provided.
3. A sample template Web Service and its handler. The service will do selective e-mail based on the calling Agent, and you can customize it to create several similar services to be posted on the Registry.
4. The extended SIP Client interface and the code to select a service from a list of services to pass to the wrapper for invoking the service.
5. The Web Services Invocation Framework WSIF and JAXRPC will be provided in the form of libraries. Sample Java code to use for invoking a Web service will be provided for your reference to help you during the implementation stage.
8. Deliverables
Your first deliverable is an SRS document that follows the template of the sample SRS posted in the course Web site. The SRS document will include the following:
1. Diagrams and specifications for the Use Cases discussed in Section 3.
- Use Case Description for scenaria 3.2.2
- Use Case diagrams for scenaria 3.2.2, 3.1.2
- Specification Level Collaboration Diagrams for scenaria 3.2.1, 3.2.2
- Sequencing Diagrams for scenaria 3.2.2, 3.1.3
2. Domain model class diagram,
3. Project activities work plan (GANTT diagram) (see example GANTT diagrams at http://wiki.phprojekt.com/index.php/Gantt-diagram and http://www.me.umn.edu/courses/me4054/assignments/gantt.html)
9. References and Downloads
References for different technologies used in the project and download links (for development at home) are listed below:
Eclipse: http://www.eclipse.org/downloads/index.php
WSDP: http://java.sun.com/webservices/jwsdp/index.jsp
JAXR: http://java.sun.com/webservices/jaxr/index.jsp
JAXRPC: http://java.sun.com/webservices/jaxrpc/index.jsp
WSIF: http://ws.apache.org/wsif/
JAIN-SIP: https://jain-sip.dev.java.net/
SIP-COMMUNICATOR: https://sip-communicator.dev.java.net/
ebXML (preferred Registry for our project): http://www.ebxml.org/
UDDI: http://www.uddi.org/
WSDL: http://www.w3schools.com/wsdl/default.asp
Java System Application Server: http://java.sun.com/j2ee/1.4/download.html#sdk
GANTT Diagrams: http://wiki.phprojekt.com/index.php/Gantt-diagram
2024-01-27