Feedback
Table Of Contents
Introduction
The SDK software and the Cisco BBSM 5.3 Interface SDK Developer Guide are used to develop the custom modules that you need for the Cisco BBSM 5.3 software release. This guide describes how to use the SDK with the BBSM 5.3 architecture to add to BBSM functionality. The guide provides the following:
•
An overview of BBSM extensible components and architecture and information on getting started
•
•
•
•
Note
Caution
This chapter provides the following information:
•
•
BBSM Extensible Components
BBSM ships with various default extensible components that are developed using various technologies. Developers must understand these technologies to customize these components. These components and technologies are described below.
Page Sets
BBSM uses page sets that consist of a set of active server page (ASP) files, commonly called pages. When the end user starts a session, the page set ASP files execute on the BBSM server and on the end user's browser. Different page sets contain different types of ASP files. By choosing specific page sets, you are choosing ASP files that associate an access policy and, if applicable, an accounting policy with a specific port. (In general, page sets are named by combining the access and accounting policy names, such as DailyHotel and BlockICS.) These policies define the access and accounting methods for the end user's session. To develop custom page sets, developers must be familiar with Microsoft ASP technology, JScript, JavaScript, and HTML.
Note
Access Policy Modules
The access policy defines the end user's process when connecting to the Internet. The module controls the web end-user interface and session behavior. Although BBSM ships with several access policy modules, a developer can create an access policy module to customize session behavior. To write access policy modules, developers must be familiar with writing MFC extension DLLs and Microsoft ActiveX server components in Microsoft Visual Studio .NET.
The object instance and lifetime for an access policy module are as follows:
•
•
Even though the access policy instances in IIS and AtDial share code, they cannot share data through member variables, because the instances exist in different processes. To share data between the processes, you should send a message from IIS to AtDial that contains the data you wish to share.
Accounting Policy Modules
The accounting policy determines how end users are billed for BBSM Internet services. Although BBSM ships with several accounting policy modules, a developer can write an accounting policy module to add a customized billing interface. To write these modules, developers must be familiar with writing MFC extension DLLs in Microsoft Visual Studio .NET.
An accounting policy instance exists only in the AtDial process, and its lifetime extends from AtDial startup to AtDial shutdown. Only one instance of each accounting policy exists, and all sessions share the single instance.
PMS Protocol Modules
A property management system (PMS) protocol module sends accounting information to the hotel PMS. BBSM ships with support for various PMS protocols. You can add support for a PMS protocol by writing a new PMS protocol module DLL in Microsoft Visual Studio .NET.
A PMS protocol object exists in the Athdmn process. Its lifetime extends from Athdmn startup to Athdmn shutdown.
BBSM System Architecture
BBSM is composed of many processes, including the following architectural processes that you may need to be aware of to develop custom modules:
•
•
•
These processes contain components that you can use as shipped with BBSM or you can customize them. Figure 1-1 shows the interaction of these components within the BBSM architecture. Note that some of these components, whether standard or customized, interact with more than process.
The Notify Billing object and packet processing components, shown in bold in the figure, implement BBSM's core functionality and cannot be customized.
Figure 1-1 BBSM Architectural Components
The following sections describe the processes and components in greater detail.
Internet Information Server
IIS is Microsoft's web server software, which includes the ability to execute server-side logic to implement the user interface presented to an end user. The highest layer of the user interface is a page set, which is a collection of ASP files used to access the Internet. This process, in turn, invokes an access policy module. BBSM enables you to add your own page set and an access policy module to the system so that you can customize the user experience to your needs.
BBSM invokes the NotifyBilling object that runs within IIS to determine the end user's location; that is, which network element port the end user is connected to. This end-user lookup logic is central to the application of per-port policy. The NotifyBilling object, a core BBSM component, invokes one or more network device modules to determine the location and status of the end user's client.
BBSM page set logic directs IIS to communicate with the AtDial process to activate and deactivate sessions. Generally, an access policy ActiveX Server Component DLL provides a SendActivateSession method that sends an activate session message to AtDial to activate a session. The NotifyBilling object contains a ClientBye method that sends another message to deactivate a session.
AtDial
The AtDial process performs BBSM session management. AtDial receives messages from IIS to perform actions, such as activate or deactivate, on behalf of a session. Associated with each session is an access policy that AtDial invokes through an access policy module. The access policy must conform to the access policy interface, which contains the following three primary methods:
•
•
•
When AtDial activates a session, it also invokes the ActivateSession method, which gives the access policy a chance to deny the activation or perform accounting activities.
While the session is active, AtDial periodically invokes the access policy's MonitorSession method, which gives the access policy a chance to deactivate the session (for example, if time expires) or perform accounting functions. Finally, when AtDial detects the end of the session (whether indicated by MonitorSession or other methods), AtDial invokes the DeactivateSession method, which gives the access policy a chance to perform cleanup or final accounting activities.
Although all accounting functions occur within the AtDial process, AtDial code does not directly call any method of an accounting policy module. Instead, the access policy decides if and when to invoke an accounting policy module. The accounting policy must conform to the accounting policy interface, which contains three primary methods:
•
•
•
Because AtDial invokes the access policy at the key points during the life of the session, great flexibility is available to provide a variety of custom services.
In addition to invoking the access policy's MonitorSession method, AtDial also invokes methods of a network device module to determine if the client is still physically connected to the network equipment. For example, some network device modules report a change of link status from Up to Down, which AtDial interprets as a deactivate session request.
The packet-processing component represents functions that AtDial invokes at session activation and deactivation. Before session activation, the packet processing code inspects and manipulates packets to restrict an end user to a subset of the Internet. Once AtDial activates a session, the packet processing code changes its behavior so that the end user can access the entire Internet.
Athdmn
The Athdmn process is used only by the hotel accounting policy to provide an interface to a PMS. It functions as follows:
•
•
•
