Pequeño Telecommunications Design

Transcription

1 Pequeño Telecommunications Design Objective Pequeño Telecommunications (PT) aims to be an all-in-one telecommunications provider. The services offered will include: local, long distance, mobile, and internet tele services. The services will be contracted out to various providers who will then provide the actual service. Thus, PT will serve as a mediator between the customers and actual service provider(s). PT will provide a web-based portal that allows customers to register, receive, and cancel service from the various provider(s). Service providers can be located through searching or by selection from a list. The search criteria can include: pricing information, reliability ratings, etc. PT will also provide a web-based portal that allows service providers to register and publish available services automatically. This will provide a fast and efficient manner for the provider to enter or leave the community at any time. Overview The goal of PT is to successfully integrate heterogeneous service providers and thus provide a ubiquitous façade to the end customer. This façade will provide the customers with a wide range of available telecommunication services at competitive prices. The inclusion of willing providers is the main hurdle in achieving the design goal, ubiquitous telecommunications. To achieve this goal, several accepted communication paradigms will be employed to exchange information with the provider(s). The methods are: tightly-coupled synchronous RPC, loosely-coupled synchronous XML RPC, and loosely-coupled asynchronous messaging using JMS. PT will use BEA Weblogic to provide the aforementioned services and coordinate the customer and provider ends of the system. Functionality The client functionality will include: register user account - setup and account to receive services. tele service - register for available telecommunication services. search tele service - search for available telecommunication services by a given criteria. subscribe service plan - sign up for a given service plan with a provider.

2 unsubscribe service plan - cancel a current service plan with a provider. The provider functionality will include: register provider account - setup an account to the join the community. tele service - register to publish what telecommunication services are offered. advertise service service plan - publish available service plans for respective services. maintain vendor records negotiate service provide service The use-case diagram below illustrates the B2B scenarios present in the system.

3 Front End register user account internet Customer tele service long distance search subscribe local mobile service plan unsubscribe register provider account advertise service Provider maintain vendor service record Back End negociate service provide service to vendo <<extend>> <<extend>> persist records provide service to custom Vendor maintain client service record

4 Integration The integration with available service providers will be accomplished using Weblogic, serving as the middleware. The process will involve the customers, PT, and providers as illustrated below. provides service Customer subscribes subscribes publishes <<mediator>> Vendor <<service provider>> Provider In the illustration, the B2B exchange mediator will be the Weblogic server which coordinates all operations involved in the telecommunications domain. The customer will be connected to the vendor through a web browser and a web server. The web browser will display dynamic content to the user that is generated within the application server. The providers will be integrated using one of the three available communication methods. This design will focus on the vendor side of the integration paradigm and assume the providers have software capable of using one of the three communication methods. To maintain coordination between the provider and vendor records, legacy names will be supported for services and plans. Middleware Architecture The middleware tier is composed of the application server, Weblogic, and the database, MySQL. Within the application server, the front end is composed of the web container. The web container provides the HTTP services necessary for the client and provider to interact with the server using a web browser. All business logic is contained within session beans resident in the EJB container. The data gathered from interaction with the session beans is stored in the database using Object-Relational (OR) mapping with entity beans. The back end is composed of three

5 listening services: RMI to provide RPC, XML to provide RPC, and JMS to provide messaging. The services then using a translation layer to merge the heterogeneous services and thus provide a single business interface. This interface then performs the necessary operations within the respective session beans and uses OR mapping to persist all necessary information gathered during the B2B transactions. The diagram below illustrates this framework. Application Server Web Container EJB Container Web Browser 0..* request 1 servlets JSPs response beans session beans B2B Engine <<tightly coupled/synchronous> RMI Interface translation layer entity beans store 1..* retrieve 1 database Provider Service 1..* subscribe 1 publish <<loosely coupled/synchronous> XML Interface messaging beans <<loosely coupled/asynchronous JMS Interface Information Persistence The database scheme will be composed of relational mappings for the storage of customer and provider information. The customer information will include: personal information residence information subscribed tele service information rate plan information for the subscribed services service usage information for the subscribed services

6 The provider information will include: business information business contact information tele services offered rate plans for the respective services communication integration method information service usage information for the active services The E-R diagram below represents the database schema.

7 User username address_name(fk) first_name last_name age business_age type customer residence plan subscription Address address_name address city state zip customer usage Billing username(fk) plan_name(fk) balance subscription billing Subscription username(fk) plan_name(fk) since active plan subscription Usage id service_name(fk) begin end record service usage Service service_name type description legacy_name provider usage Provider provider_name plan_name(fk) service_name(fk) integration_name(fk) business_age description provider service provider plan service plan Plan plan_name service_name(fk) minutes weekend_minutes rate weekend_rate price legacy_name provider integration Integration integration_name provider contact Contact provider_name(fk) address_name(fk) contact residence protocol translator description name