WO1999062239A1 - Prestation de services multiples - Google Patents

Prestation de services multiples Download PDF

Info

Publication number
WO1999062239A1
WO1999062239A1 PCT/GB1999/001662 GB9901662W WO9962239A1 WO 1999062239 A1 WO1999062239 A1 WO 1999062239A1 GB 9901662 W GB9901662 W GB 9901662W WO 9962239 A1 WO9962239 A1 WO 9962239A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
session
class
framework
service session
Prior art date
Application number
PCT/GB1999/001662
Other languages
English (en)
Inventor
Martin John Ellis
Jeffrey Roger Farr
Duncan Charles James-Bell
Daniel Christopher Creswell
Michael Robert Hosking
Christopher John Smith
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GBGB9811264.2A external-priority patent/GB9811264D0/en
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Priority to AU41537/99A priority Critical patent/AU753789B2/en
Priority to EP99925146A priority patent/EP1080570A1/fr
Priority to CA002331102A priority patent/CA2331102A1/fr
Priority to GB0024392A priority patent/GB2351823A/en
Publication of WO1999062239A1 publication Critical patent/WO1999062239A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0054—Service creation techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

Definitions

  • This invention relates to a telecommunications service session control system, in particular one for implementing multi-party services of different types. It also relates to apparatus equipped with application programming interfaces and development tools for use in developing multi-party services.
  • the Internet and in particular, the Worldwide Web (“the Web”) has proved a successful system for distributing information and accessing applications
  • a terminal equipped with a browser application program (such as Microsoft Internet Explorer (trade mark)) and a TCP/IP connection.
  • a browser application program such as Microsoft Internet Explorer (trade mark)
  • TCP/IP connection a TCP/IP connection
  • HTML Markup Language
  • URL uniform resource locator
  • GUI graphical user interface
  • CGIs provide access to server application programs which produce such customisation.
  • the Telecommunications Information Networking Architecture Consortium (TINA-C) is defining a model for the provision of telecommunications services.
  • the model includes a service architecture layer and a network architecture layer, which are based on a distributed processing environment (DPE) .
  • the DPE is provided on distributed computational nodes connected via a transport network.
  • the service architecture layer provides service control functions such as authentication, identification, subscription control, billing and service usage.
  • the network architecture provides network connections to services and network management.
  • the TINA-C service architecture is itself split into two layers - the access layer and the service usage layer.
  • the access layer is concerned with the provision of a secure communications link between a user and a notional service retailer, referred to as an "access session".
  • services can be accessed by the user in the context of a "service session" which includes a notional service provider.
  • a service session which includes a notional service provider.
  • the implementation preferably provides for a wide variety of possible services to be supported, thus placing fewer generic constraints in the system.
  • Service developers may be aided by the use of a service session control system which takes away from the service developer the need to implement service generic functions.
  • the present invention is based on an object-oriented programming model.
  • software objects consist of information defining properties of the objects which are both data variables and the methods (functions) which operate on those variables.
  • Objects are instances of a class, which is an object template insofar as it defines the variables and methods which the object possesses.
  • An object is created by instantiating the class to which the object belongs.
  • Object classes may be arranged in a class hierarchy.
  • a base class may be used to derive sub-classes by inheritance.
  • the sub-classes inherit the methods and variables of the base class. Additional variables and methods may also be defined in the sub-classes.
  • Sub-classes may also override, that is to say further define or modify, functionality defined in the base class.
  • the sub-class defines a variable or method which has the same name as the property defined in the base class.
  • a set of base classes may be defined to provide a framework.
  • a framework consists of a set of cooperating classes which makes up a reusable design for a specific type of software.
  • a framework provides architectural guidance by partitioning the design into abstract framework classes and defining their responsibilities and collaborations.
  • a developer customises the framework classes to a particular application by sub-classing and composing concrete classes.
  • a telecommunications service session control system comprising at least one server and in use interacting with software objects derived from an application programming interface, said application programming interface comprising: a first framework object class for deriving service specific object classes to be instantiated on a client machine during participation in a service session; a second framework object class for deriving service specific object classes to be instantiated on a server during a service session, said second class representing said service session; and a third framework object class for deriving service specific object classes to be instantiated on a server during participation in a service session, said third class representing said participation.
  • a data store holding an application programming interface for use in developing multiparty services to be implemented on a telecommunications service session control system, said application programming interface comprising: a first framework object class for deriving service specific object classes to be instantiated on a client machine during participation in a service session; a second framework object class for deriving service specific object classes to be instantiated on a server during a service session, said second class
  • the invention provides an application programming interface which allows
  • a service development system for generating service specific application parts to be implemented in a distributed manner in a telecommunications service session control system, said system comprising: a service component constructor: for storing data defining a plurality of framework components to be distributed between a client station and a server, and a plurality of customisation components for customising said framework components in a service-specific
  • a service tester for generating interactions between said control system simulator and said customised components; and for generating data defining a second user interface for representing participation in a service session via said telecommunications service session control system, on a visual display means, in response to said interactions.
  • FIG. 1 is a schematic block diagram of a communications system in accordance with an embodiment of the present invention.
  • Figure 2 is a schematic block diagram of system components in the client, retailer and service provider domains of the system illustrated in Figure 1 ;
  • Figure 3 is a schematic block diagram illustrating an embodiment of the arrangement illustrated in Figures 1 and 2, consisting of interrelated software objects;
  • Figure 4 is a diagram schematically illustrating a session lifecycle in accordance with an embodiment of the present invention.
  • FIG. 5 to 1 3 illustrate interactions between the objects illustrated in
  • Figure 14 is a diagram schematically illustrating interaction relationships
  • Figure 1 5 illustrates the inheritance relationships between service-specific object classes and framework object classes in accordance with an aspect of the
  • Figure 1 6 illustrates an embodiment of service-specific software components providing a particular service supported by the system of the present invention
  • Figure 1 7 is a schematic block diagram showing apparatus for developing services in accordance with an embodiment of the invention.
  • Figures 1 8 to 20 are diagrams schematically illustrating graphical user interfaces provided by the apparatus of Figure 1 7.
  • FIG. 1 is a block diagram illustrating a telecommunications system in accordance with an embodiment of the present invention.
  • the system consists of a retailer server RS and a plurality of third party servers TPS1 , TPS2 ... TPSn.
  • User terminals T1 , T2 ... Tn are connected to the retailer server RS via a data communications network, in this embodiment the Internet.
  • the third party servers TPS 1 , TPS2 ... TPSn are either remotely connected to the retailer server RS via communication links 2, which may be separate physical links and/or logical links, as shown, or are co-located with the retailer server RS.
  • Each third party server has access to a database TPDB1 , TPDB2 ... TPDBn for the storage and retrieval of service-related data.
  • the servers RS TPS1 , TPS2 ... TPSn are illustrated in Figure 1 as consisting of single servers, each may consist of one or more servers interconnected in a network.
  • the servers each may be implemented on a computing resource, such as a workstation computer.
  • Each of the user terminals are illustrated in Figure 1 as consisting of single servers, each may consist of one or more servers interconnected in a network.
  • the servers each may be implemented on a computing resource, such as a workstation computer.
  • Each of the user terminals are illustrated in Figure 1 as consisting of single servers, each may consist of one or more servers interconnected in a network.
  • the servers each may be implemented on a computing resource, such as a workstation computer.
  • Each of the user terminals are illustrated in Figure 1 as consisting of single servers, each may consist of one or more servers interconnected in a network.
  • the servers each may be implemented on a computing resource, such as a workstation computer.
  • Each of the user terminals are illustrated in Figure 1 as consisting of
  • T1 , T2 ... Tn may be implemented in the form of a workstation computer, a net computer, a mobile communications terminal, etc.
  • Figure 2 schematically illustrates further details of the telecommunications system, exemplifying components present in a single user terminal, the retailer server and a single third party server.
  • a service browser application program 4 provides access and support to a range of services provided by the various third party servers TPS1 , TPS2 ... TPSn via the retailer server RS.
  • the retailer server RS includes an access control part 5, whereby a client terminal may initially access the system, an authentication part 6 whereby users of the system may be authenticated such as by means of a password checking procedure, and a subscription part 7 which maintains subscription data for users of the system.
  • the retailer server and the third party server include application program parts, including on the client side, a service-specific application program part 8, on the retailer side, a session control application program part 9 and on the service provider side, a service control application program part 10.
  • the retailer server also includes a billing part 1 1 which handles the billing of event records by the session control application program part 9 during service sessions.
  • a billing part 1 1 which handles the billing of event records by the session control application program part 9 during service sessions.
  • the service provider service control part 10 may be held on a server controlled by the retailer, such as that holding the retailer server RS itself.
  • FIG. 3 illustrates an embodiment of the invention in which the system is implemented as a software object system.
  • each of the computing elements T1 , T2 ... Tn; RS; TPS1 , TPS2 ... TPSn illustrated in Figure 1 is supported by a distributed processing environment (DPE), whereby distributed software objects in different physical parts of the system may interact by the passing of messages, for example using CORBA (Common Object Request Broker
  • Java (trade mark), which is not intended to be limiting.
  • Other, and indeed heterogeneous mixtures of object-oriented languages may also be used to implement the system.
  • the distributed object system includes service generic code and service specific code, which is distributed between the client side and the server side during a service session.
  • the part of the system including service generic code is referred to herein as the service session control system.
  • Service specific code in the client domain is referred to herein as a "front" object.
  • the front object in this embodiment is a Java applet which runs on the client machine
  • the front object 1 3 communicates with other system objects, to support and control a user's participation in a session.
  • the front object 1 3 also provides service specific front end functionality, such as the service GUI and handling user input relating to the service.
  • the back object 32 represents the session and its participants and may interact with other back end systems, such as servers and databases in the service provider domain. It co-ordinates the interaction between participants in a session and stores service specific state information while a participant is suspended. The back object 32 can also exert control over a session, for example it can initiate suspend and exit for one or more participants. As will be described later, the back object 32 includes a number of cooperating software objects. Service Session Control System - Client Domain Software Objects
  • a retail workspace object (RWS) 1 2 runs on the client machine and provides the client with a means of accessing services.
  • the RWS 1 2 may be a downloadable Java applet which runs in a known
  • Java-enabled browser or a stand-alone Java application program.
  • the RWS allows the user to log on to the service session control system, to access service sessions by downloading front objects 1 3 and to log off via a GUI.
  • the RWS 1 2 is multi-threaded to allow front objects 1 3 to be used in parallel, both with each other and with the RWS 1 2.
  • a user may participate in two services simultaneously and at the same time receive, via the RWS 1 2, an invitation to join a third service.
  • a user may have multiple front objects 1 3 of the same or different services running simultaneously on the client terminal.
  • a gateway object 1 4 provides an initial point of contact for user access to
  • the system It mediates the authentication of the user's identity and password with the RWS 1 2. Thereafter, the RWS 1 2 connects to a user account object 1 8 and the gateway plays no further part.
  • the gateway 14 is multi-threaded to ensure availability. That is to say, the gateway 14 is able, during the processing of a logon request received from one 5 client terminal, to process logon requests arriving from different client terminals.
  • a user administration object 1 6 provides functionality to create new user accounts.
  • the user account object 1 8 serves as a single user's account within the retailer domain. It holds a record of all the services to which the user is 10 subscribed. The user account 1 8 also receives and stores, or obtains as needed, information from other objects in the retailer domain about any suspended sessions the user may have, all public sessions available and any session invitations the user may have received.
  • the user account object 1 8 also mediates interactions between the RWS 1 5 1 2 and the remainder of the retailer domain to start, join and resume sessions. It handles notifications from a session object 30 that sessions have been suspended or ended.
  • User account objects 1 8 are present in the retailer domain even when the user which they represent are logged off the system. 20
  • a user account manager object 20 creates and maintains the user account objects 1 8 and provides a reference to the appropriate user account object 1 8 when a user logs on to the system to start a communications session with the retailer server RS.
  • An authentication server object 22 uses stored user authentication data to 25 authenticate log on requests.
  • a service provider portfolio object (SPP) 24 maintains information on available services, including the service provider identities and their network addresses, and which session manager 28 is to be used to support a service (this allows loads to be managed across a plurality of session managers 28) .
  • a session manager object 28 prompts a session factory object 26, and a back factory object 34 (which is in the service provider domain) to instantiate session objects 30 and back objects 32 to support service sessions and then mediates between the user accounts 1 8, the session objects 30 and the back objects 32 to support further service interactions (e.g. invite, join, suspend, resume).
  • the session object 30 is a service generic object (i.e. an object used in multiple different types of services) which controls a service session and coordinates the interaction of the objects involved in that session. It handles generic session behaviour such as invitations and suspensions. For example, when a client front 1 3 suspends a user's session, the session object 30 responds by calls on the user account 1 8 and the custom back 32 and by transmitting an event message to the event handler 31 .
  • the session object 30 is created when the first participant starts the session and is destroyed when the last participant exits the session. The session object 30 is otherwise not destroyed, even if all its participants are suspended.
  • a back factory object 34 is provided in the service provider domain.
  • Back objects 32 are instantiated by the back factory object 34 at the initiation of the session manager 28. There is a single back object 32 per session object 30. Each custom back object 32 exists only as long as the session object 30 handling the same service session exists.
  • objects in the service session support system in particular the gateway 14, the user account manager 20, the authentication server 22 and the service provider portfolio 24 may consist of multiple federated copies forming a single logical object, in order to provide scalability of the system.
  • Figure 4 illustrates an example of a session hfecycle.
  • the session is begun when a first participant (participantD starts the session. Throughout the lifetime of the session, various numbers of participants may join the session, suspend, and exit the session. The session exists until the last participant (in the example shown, participants) exits the session, when the session terminates.
  • Figures 5 to 1 3 illustrate interactions between objects in the system during changes in the session-related status of a user of the system.
  • Messages sent between objects are indicated by solid arrows, and are numbered to indicate the sequence in which the messages are sent.
  • Event channels (indicated by dotted solid arrows) are used in various cases by the session object 30. Messages are sent by event channels to avoid blocking the session object 30, as would occur if request-response procedures were used, and which would impact on the service to other participants.
  • Several of the interactions between the RWS 1 2 and the user account 1 8 identify particular session instances. Passing direct references to the session objects 30 to the RWS 1 2 may compromise security. To avoid this, the sessions are identified by the RWS 1 2 using stored "cookie" references, previously passed to it by the user account 1 8, whereby the user account 1 8 is able to identify the actual session object 30 being referred to.
  • the gateway 14 is the initial point of contact for user access to the system.
  • the RWS 1 2 initiates a data communications session with the gateway and sends a logon message with the user name and password supplied by the user. Provided these values are authenticated by the authentication server 22, the gateway 14 then retrieves a reference to the user's user account from the user account manager 20 and then contacts the appropriate user account 18 to confirm that the user is now logged on.
  • the RWS 1 2 when the user initiates a session via the client terminal, the RWS 1 2 sends a session starting message to the user account 1 8 specifying the service requested.
  • the RWS 1 2 spawns a thread to download the appropriate front object, and downloads the appropriate front object 1 3 for the service from the retailer server RS.
  • the user account 1 8 obtains details for the service requested from the SPP 24, including the identity of the session manager 28 to support the service session, and sends a message to the session manager 28 to create a new session
  • the session manager 28 sends a message to the back factory 34 to instantiate a new back object 32 and sends a message to the session factory 26 to instantiate a new session object 30.
  • the back factory 34 and the session factory 26 return references to the new back object 32 and session object 30 respectively, which are then used by the session manager 28 to instruct the new session object 30 to attach to the new back object 32.
  • the session object's reference is also passed back to the front 1 3 subsequently via the RWS 1 2 to allow the front object 1 3 to attach to the session object 30.
  • the user account 1 8 then sends a join-service message to the session manager 28 which in turn sends a request-join message to the created session object 30 to cause the user to join a session.
  • the RWS 1 2 instructs the front object 1 3 to send an attach message to the session 30 This establishes the communications channel between the front object 1 3 and the session object 30.
  • the session object 30 then sends a participant-joined message to the back object 32.
  • a user can join a session to which he has received an invitation.
  • the RWS 12 transmits a joined-session message to the user account object 1 8, which passes a "cookie" reference to indicate which invite the user wishes to accept.
  • the user account 1 8 obtains details of the service from the SPP 24 and sends a message to the session manager 28 to verify that the session is still current.
  • the session manager 28 pings the session object 30 and the custom back 32 to confirm this.
  • the RWS 1 2 spawns a thread to download the appropriate front object 1 3 for the selected service.
  • the user account object 1 8 sends a join message to the session manager 28, which results in a request-join message sent by the session manager 28 to the appropriate session object 30. If the join request succeeds, the RWS 1 2 sends a message to instruct the front object 1 3 to attach to the session object 30, identified by the reference transmitted by the user account 18. The session object 30 then sends a participant-joined message to the back object 32, by event channel. Referring to Figure 8, the suspension of a user from a session can be initiated by the front 1 3 sending a suspend message to the session object 30. The front object 1 3 then destroys itself. The session object 30 sends a participant- suspended message to the back object 32, by event channel, and marks the participant in question as suspended. The session object 30 also sends a message to the user account 1 8 to notify it of the user's new status.
  • the user account 1 8 sends a message to inform the RWS 1 2 of the new suspension, passing a cookie reference to the session 30, so that the user is able to resume the session thereafter.
  • an alternative session suspension procedure can be initiated from the custom back 32.
  • suspension is initiated by the custom back 32 sending a suspend message to the session object 30.
  • the session object 30 sends a suspend message to the front object 1 3 in question, which then destroys itself.
  • the session object 30 proceeds by sending a participant-suspended message to the back object 32. The process continues as described in relation to Figure 8.
  • the RWS 1 2 is made aware of all suspended sessions for the user by the user account 1 8 immediately when the user is logged on, and throughout an access session Therefore, when a user elects to resume a session, the RWS 1 2 sends a resume message to the user account 1 8, which indicates the session to be resumed, by means of a cookie reference
  • the user account 18 sends a ve ⁇ fy-session message to the appropriate session manager 28, which pings the session object 30 and back object 32 to verify that the session is still in progress.
  • the RWS 1 2 downloads the appropriate front object 1 3 for the selected service
  • the RWS 1 2 instructs the front object 1 3 to send an attach-front message to the session object 30 to restore the front connection with the session object 30.
  • the session object 30 then sends a participant-resumed message to the back object 32, by event channel.
  • the state of the participation may be stored in the back object 32 for the duration of the suspension, and recovered when the participant opts to resume participation. Destruction of the front object on suspension allows for efficient management of the client terminal resources, as a new front object may be readily downloaded on resumption.
  • the front object 1 3 when a user wishes to exit a session, the front object 1 3 sends an end-participation message to the session object 30, and then destroys itself
  • the session object 30 sends a participant-left message to the back object 32
  • the session object 30 also transmits a message to the event handler 31 to inform it of the participant leaving event.
  • the session object 30 then sends a message to the user account 1 8 to notify it that the user has left the session.
  • the session object 30 then destroys itself if there are no active or suspended participants left in the session. Exiting the session may alternatively be initiated, as a result of service logic processing, from the back object 32 as illustrated in Figure 1 2.
  • exit is initiated by the back object 32 sending an end-participation message to the session object 30.
  • the session object 30 sends an end-participation message to the front object 1 3, which then destroys itself.
  • the session object 30 then sends a participant-left message to the back object 32. The process then continues as described in relation to Figure 1 1 .
  • the RWS 1 2 sends a logoff message to the user account 1 8.
  • a service session may be considered in a service specific manner, as shown in Figure 14, without the generic components present.
  • a service session consists of a single back object 32, deployed within the service provider domain, together with an arbitrary number of objects 1 3.
  • One front object 1 3 is present per participation in the service.
  • the front objects 1 3 may be distributed in several client terminals, and/or within a single client terminal .
  • the interactions between the front objects 1 3 and the back object 32 are mediated by the remainder of the system.
  • a service developer need not be concerned when developing a service with implementing the multi-party session control functions provided by the system. All that the service provider needs to develop are the code for the service specific front object 1 3 and the code for the service specific back object 32.
  • three framework object classes are provided, as part of an application programming interface (API) which the service developer uses by inheritance in their own service specific classes.
  • the framework object classes are provided to a service 5 developer, for example by the service developer downloading same from a networked server, in the form of traditional object classes, written in C + + , Java or suchlike.
  • the service provider may customise these classes, using a development tool, into front and back object classes which are service specific.
  • the compiled classes may then be uploaded onto the retailer server RS for use as
  • Figure 1 5 illustrates the relationship between the actual classes which are to be instanced as the front object 1 3 and the back object 32, being Custom Applet 40, Custom Session 44 and Custom Participant 42, respectively, and the three framework object classes, being API Applet class 50, API Participant class
  • Each of the three framework object classes include predefined methods which the service developer may call in their service code. Furthermore, in order to take advantage of the session control messages automatically generated by the service session control system, the service developer may override particular
  • Callback methods provided in the framework classes will be called by the system, in particular the session object 30, as a result of specific occurrences during a session hfecycle.
  • Figure 1 6 illustrates the service specific software objects provided in a particular service session, exemplifying three separate participants.
  • the back object 32 consists of a Custom Session object 60, and a number of
  • Custom Participant objects 62 which have a one-to-one relationship with the
  • Custom Applet objects 64 (the front objects) participating in the session.
  • the system in particular the session object 30, automatically transmits callback messages to each of the fronts Custom Applet objects 64, each of the Custom Participant objects 62 and the Custom Session object 60 whenever a relevant session event occurs. For example, if a new participant joins, the back factory 34 is prompted to initiate a new Custom Participant object 62 to be included in the back object 32, as a result of the system procedures illustrated in
  • Participant objects 62 and the Custom Session object 60.
  • a user starting a session or who has already joined a session may invite individual users.
  • the method provided on the API Applet class is invite.
  • a user starting a session may invite all users logged on to the system.
  • the method provided on the API Applet class is pub/icAnnounce. Changes in Other Participant Status
  • a user has responded to an invitation by declining an offer to join the session.
  • the invitation will have been sent out prior to this.
  • a human readable description in the invitation may be included in the callback.
  • a participant has joined the session. This includes both people who join as a result of responding to an invitation or public announcement, and the first person into the session who joins it as a result of starting the session.
  • the callback includes the participant ID of the user. A human readable description in the invitation may be included in the callback. participantLeft
  • the callback includes the participant ID of the user. participantSuspended
  • a participant has suspended their participation in the session, and may resume at a later date.
  • the callback includes the participant ID of the user.
  • participan tResumed A participant has resumed their participation in the session, after suspending at some earlier time.
  • the callback includes the participant ID of the user. Locating Participants
  • API Participant and API Session classes also provide a number of methods to help find participants in the session. These methods are: to talParticipan ts
  • This method returns the total number of participants in the session. rese t Participan tltera tor
  • participantByld Get further information about a participant given its participant ID (e.g. from a participantJoined callback). getUserName
  • An iterator method allows the object to identify and circulate round all the participants currently in the session. For example, from a particular instance of Custom Participant, it is possible to invoke a method on all other instances of Custom Participant. This is accomplished by using the iterator and checking the participant IDs to miss out the participant from which the code is invoked. Messages
  • the framework object classes provide the ability to send messages, via the service session control system, from the back objects to the front objects, and vice versa.
  • the following API methods are provided: sendMessage
  • API Applet This is provided in each of the API Applet, API Session and API Participant classes.
  • API Session In the case of the method on the API Session class, a particular participant ID is specified.
  • This method is provided on the API Applet class to create a thread awaiting a return message from the back object.
  • Messages may for example be sent from the back object to the front object, to inform the front whenever a participant joins, leaves, suspends, resumes, or is invited to the session.
  • the participant status callbacks on the API Participant class are overridden, and the sendMessage API method is used to send a corresponding message to the front object.
  • More complex parameters may be also sent using separators to put arguments into a string, and then using string tokenizers to separate the arguments at the front object.
  • the corresponding front object for this example may include a GUI which is provided with a label to display the message arriving from the back object.
  • a thread is created in the front object to wait for messages using the getMessage method. Using Personal Preferences
  • the API Participant framework class provides the ability to store information unique to a user of the system which can be retrieved, changed and stored each time the particular user participates in a particular service.
  • the API calls to support this provide the storage and retrieval of a string, which may contain attributes or arguments.
  • the two API calls are: getServiceData
  • Participation in a session can be ended or suspended from both the back object or front object.
  • the API methods common to the framework classes are as follows: endParticipation
  • API Applet callback methods are as follows: forcedEndParticipation
  • suspendParticipation Called when a back object has called suspendParticipation . stop This is the last called method on the Custom Applet object, allowing the code to shut down threads, etc.
  • the endParticipant call is used on the Custom Applet. This results in a callback to justLeft on the corresponding
  • CustomSession Finally stop is called on the Custom Applet, as a result of which it would be destroyed.
  • the endParticipation method is used. This will result in a forcedEndParticipation callback on the Custom Applet, as well as a participantLeft callback on all other Custom Participants and the Custom Session.
  • a similar call from Custom Session can also be used which takes the participant ID of the participant who is to leave the session.
  • the procedures illustrated include single callbacks on the back object 32.
  • the back object consists of a number of objects derived from the framework classes.
  • the callbacks described will in fact be made on each of the objects in the back object, including the Custom Session object and each of the Custom Participant objects to allow the service developer to include code in each of the back object classes which implements functionality resulting from such callbacks.
  • the callbacks illustrated in Figures 5 to 13 are only a subset of the callbacks provided by the system, further such callbacks being described above.
  • the provision of two separate framework classes whereby to derive service specific classes to be used in a back object 32, the two distinct classes including a session object class and a participant object class, provide a flexible yet meaningful framework for service designers.
  • the session object class may be used to control the session specific functions, and to maintain a session state for a service
  • the participant object class may be used to control the service provided to individual participants in a session, to control participant-specific functions on the server side, to maintain participant-specific state information and to control the parameters of a service in accordance with individual participant preferences.
  • the service developer is provided with the capability to distribute service logic amongst the front object and the back object as appropriate.
  • the present invention provides a visual, iconic, programming development tool for use by service developers to develop the service-specific application program parts to be implemented in the front and back objects of a service supported by the service session control system of the present invention.
  • the development tool includes a service builder software application program 100, a tester software application program 200 and a control system simulator application program 300.
  • the development tool runs within the workstation or network of the software developer.
  • the development tool is installed in the working memory of a computer workstation 400 having known features, including a data processor, random access memory, read only memory, a hard drive memory, a display monitor, keyboard and a pointing device such as a mouse.
  • the development tool is JavaBeans-enabled.
  • the service development tool may be implemented in a similar manner to an existing JavaBeans-enabled design tool, such as SunSoft's Java Studio, Borland JBuilder or Symantec's Visual Cafe 2 (all trademarks).
  • the service builder 100 allows the customisation of the framework JavaBeans to build the service-specific application program parts, as will be detailed below.
  • the control system simulator 300 contains components showing the interfaces and functionality provided by the service session control system for which the service-specific application parts are being developed. These components have the session lifecycle control, object factory, event message handling and call back generation functions of the service-generic control system components described in relation to Figures 2 to 1 3.
  • the tester 200 provides a simulation of the client graphical user interfaces (GUIs) which would be presented in the client terminals connected to the control system during participation in the service being built, to allow the testing of services as they are built in the service builder 100.
  • GUIs client graphical user interfaces
  • FIGS 18, 1 9 and 20 illustrate the GUI provided on the service developer workstation display in programming and testing modes of the development tool.
  • FIGS 1 8 and 1 9 illustrate the GUI provided by the service builder 100.
  • the GUI includes a JavaBeans palette 102, an applet composition window 104, a custom session composition window 106 and a custom participant composition window 108.
  • the palette 102 contains a standard range of customiser JavaBeans provided with the development tool. In addition, a service developer may add further JavaBeans to the palette.
  • composition windows 104, 106, 108 contain, as a basic component, a framework applet JavaBean 1 10, a framework session JavaBean 1 1 2 and a framework participant JavaBean 1 14, respectively.
  • Each of the framework JavaBeans 1 10, 1 1 2, 1 14 is a mapping of the API framework classes previously described on to a JavaBean component.
  • the API methods and callbacks provided on the API framework classes are mapped on to JavaBean properties and methods.
  • the callback methods provided on the framework classes are mapped to unbound properties of the JavaBeans 1 10, 1 1 2, 1 14.
  • Other JavaBeans dropped into the composition windows from the palette may be connected to these unbound properties to register for API event notifications.
  • the API methods of the framework object classes are mapped on to either bound properties which may be customised by the service developer using property tables provided for each of the framework JavaBeans 1 10, 1 1 2, 1 14, or, alternatively, methods which JavaBeans from the palette 102 dropped into the composition windows may call.
  • the framework JavaBeans 1 10, 1 1 2, 1 14 also have events and methods which are uncustomisable. There are those which represent the interactions of the framework classes with the service session control system as previously described. In the development tool, these uncustomisable events and methods and are called by components in the control system simulator 300.
  • JavaBeans from the palette 102 are dropped into the composition windows 104, 106, 108 and interconnected with the framework JavaBeans 1 10, 1 1 2, 1 14 to customise the framework JavaBeans.
  • the service developer also sets properties of the framework JavaBeans 1 1 0, 1 1 2, 1 1 4 and properties of the other JavaBeans which are placed in the composition windows 104, 106, 108 from the palette 102.
  • the service developer may test the service under development by use of the tester application program 200 in a testing mode of the development tool.
  • Figure 20 illustrates the GUI provided by the tester 200, which includes control buttons 202, 204, 206 which are used to start and close a simulated service session and to produce new potential participants which may be joined into the session and to resume previous participations.
  • button 202 is a open start/close session button.
  • button 204 is a system logon button and button 206 is a resume participation button.
  • buttons 202, 204, 206 cause the control system simulator 300 to instantiate new service specific objects from the customised framework JavaBeans visually programmed in the service builder 100, and to destroy them when desired.
  • the control system simulator 300 provides the underlying service-generic functionality of the service session control system of the present invention, whereby the service-specific application parts being built interact in the test mode of the developer tool.
  • the customised JavaBeans application parts present in each of the composition windows of the service builder 100 are interpreted by the tester application program 200 in order to provide the client GUI windows 208.
  • the service developer may view and interact with the service displays which would be provided in the client terminals during an actual service session, thereby testing the application parts under development.
  • the service developer operates the start/close session button, which causes the tester 100, through the control system simulator 300, to instantiate an instance of each of the currently customised session framework JavaBeans, the currently customised participant framework JavaBean and the currently customised applet framework JavaBean.
  • a single client GUI window 208 appears. New participants may be joined into the simulated control system using the system logon button 204, causing additional client GUI windows 208 to appear in the tester GUI, which windows may be selected and viewed by the service developer.
  • the service developer may simulate any of the actions a user of the service will during actual access and service sessions be able to perform.
  • the service developer may simulate the invitation of a participant by interaction with one of the client GUI windows, which would result in invitation messages appearing in other of the client GUI windows 208.
  • the service developer may then simulate acceptance of the invitation by interaction with one of the client GUI windows displaying the invitation.
  • the service developer may simulate suspension of a user's participation in the service, by interaction with one of the client GUI windows 208. Suspension results in disappearance of the client GUI window 208 from the tester GUI. Subsequently, the service developer may simulate resumption of participation by actuation of the resume participation button 206, which causes reappearance of the client GUI window 208 in the tester GUI.
  • the development tool provides the service developer with the ability to build a distributed application supported by the service session control system of the present invention, visually using iconic programming.
  • the service developer may test the service under development immediately and dynamically as the service is built. The effects of changes to the customisation of the framework JavaBeans 1 10, 1 1 2, 1 14 in the service building mode are immediately apparent in the service testing mode, which the service developer may readily toggle to and from.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un système de commande de session de commande de services de télécommunications destiné à prendre en charge de multiples sessions de services à parties multiples. Ledit système comporte au moins un serveur connecté à un réseau de transport. Le système est configuré pendant une session de service de sorte que soient produits des moyens de commande de session, comprenant des moyens pour assurer l'interface avec des objets logiciels clients spécifiques de service et des moyens pour assurer l'interface avec des objets logiciels serveurs spécifiques de service. Le moyen d'interface avec l'objet serveur comporte une interface avec un objet spécifique d'un service commandant au moins partiellement ladite session et au moins une interface avec un autre objet spécifique d'un service commandant au moins partiellement une participation à ladite session. Les objets spécifiques de service peuvent être dérivés, de sorte que le développeur de service n'ait pas à connaître les détails du système sur lequel le code de service sera exploité. Les fonctions périphériques de services communes, telles que les fonctions d'authentification, de facturation et de gestion, ne doivent pas à être considérées pendant la phase de développement de service. Un outil de développement de programmation iconique, visuel est également prévu. Il est destiné à être utilisé par les développeurs de services pour le développement de parties de programmes d'application spécifiques de service, à implanter dans un service pris en charge par le système de commande de session de service.
PCT/GB1999/001662 1998-05-26 1999-05-26 Prestation de services multiples WO1999062239A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
AU41537/99A AU753789B2 (en) 1998-05-26 1999-05-26 Multiple service provision
EP99925146A EP1080570A1 (fr) 1998-05-26 1999-05-26 Prestation de services multiples
CA002331102A CA2331102A1 (fr) 1998-05-26 1999-05-26 Prestation de services multiples
GB0024392A GB2351823A (en) 1998-05-26 1999-05-26 Multiple service provision

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP98304143 1998-05-26
GB9811264.2 1998-05-26
GBGB9811264.2A GB9811264D0 (en) 1998-05-26 1998-05-26 Multiple service provision
EP98304143.5 1998-05-26

Publications (1)

Publication Number Publication Date
WO1999062239A1 true WO1999062239A1 (fr) 1999-12-02

Family

ID=26151277

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1999/001662 WO1999062239A1 (fr) 1998-05-26 1999-05-26 Prestation de services multiples

Country Status (5)

Country Link
EP (1) EP1080570A1 (fr)
AU (1) AU753789B2 (fr)
CA (1) CA2331102A1 (fr)
GB (1) GB2351823A (fr)
WO (1) WO1999062239A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001031900A2 (fr) * 1999-10-26 2001-05-03 Pingtel Corporation Reseau de communications distribue comprenant un ou plusieurs dispositifs de communication telephonique a fonctionnalite programmable
WO2001043397A2 (fr) * 1999-12-13 2001-06-14 Sherkin Communications Systems Limited Communication de donnees
EP1170962A1 (fr) * 2000-07-05 2002-01-09 Alcatel Méthode pour la prestation de services dans un réseau de communications et modules de programmes et moyens s'y rapportant
FR2833442A1 (fr) * 2001-12-12 2003-06-13 Cegetel Groupe Procede d'acces d'un terminal a des donnees d'un reseau externe, base sur la notion de domaine de services
US7287093B2 (en) 2000-08-04 2007-10-23 Mobileaware Technologies Limited E-business mobility platform

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
GENETTE M ET AL: "INTELLIGENT NETWORK: THE SERVICE CREATION ENVIRONMENT", COMMUTATION ET TRANSMISSION, vol. 17, no. 2, 1 January 1995 (1995-01-01), pages 13 - 20, XP000505610 *
HELLEMANS P ET AL.: "TINA SERVICE ARCHITECTURE: FROM SPECIFICATION TO IMPLEMENTATION", PROCEEDINGS TINA '97 - GLOBAL CONVERGENCE OF TELECOMMUNICATIONS AND DISTRIBUTED OBJECT COMPUTING, 17 November 1997 (1997-11-17) - 20 November 1997 (1997-11-20), SANTIAGO (CL), pages 174 - 183, XP002082032 *
LICCIARDI C A ET AL.: "TINA AND THE INTERNET: AN EVALUATION OF SOME SCENARIOS", PROCEEDINGS TINA '97 - GLOBAL CONVERGENCE OF TELECOMMUNICATIONS AND DISTRIBUTED OBJECT COMPUTING, 17 November 1997 (1997-11-17) - 20 November 1997 (1997-11-20), SANTIAGO (CL), pages 22 - 35, XP002082033 *
MAGEDANZ T: "TINA - Architectural basis for future telecommunications services", COMPUTER COMMUNICATIONS, vol. 20, no. 4, 1 June 1997 (1997-06-01), pages 233-245, XP004126681 *
MINERVA R ET AL: "A NEW PARADIGM FOR NETWORK INTELLIGENCE: FROM BUNDLED TO OPEN AND PROGRAMMABLE SYSTEMS", ISS '97. WORLD TELECOMMUNICATIONS CONGRESS. (INTERNATIONAL SWITCHIN SYMPOSIUM), GLOBAL NETWORK EVOLUTION: CONVERGENCE OR COLLISION? TORONTO, SEPT. 21 - 26, 1997, vol. 2, 21 September 1997 (1997-09-21), ABDALLAH ABI-AAD ET AL, pages 77 - 84, XP000704458 *
TAG M: "SERVICE CREATION ENGINEERING ENVIRONMENT SCREEN", GLOBAL INFORMATION INFRASTRUCTURE (GII) EVOLUTION: INTERWORKING ISSUES, INTERWORKING '96. THIRD INTERNATIONAL SYMPOSIUM ON INTERWORKING NARA (JAPAN), OCT. 1-3, 1996, 1 October 1996 (1996-10-01), RAO;S; UOSE; H; LUETCHFORD; J C (EDS ), pages 664 - 671, XP000754613 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001031900A2 (fr) * 1999-10-26 2001-05-03 Pingtel Corporation Reseau de communications distribue comprenant un ou plusieurs dispositifs de communication telephonique a fonctionnalite programmable
WO2001031900A3 (fr) * 1999-10-26 2002-12-27 Pingtel Corp Reseau de communications distribue comprenant un ou plusieurs dispositifs de communication telephonique a fonctionnalite programmable
AU777728B2 (en) * 1999-10-26 2004-10-28 Pingtel Corporation Distributed communications network including one or more telephony communication devices having programmable functionality
WO2001043397A2 (fr) * 1999-12-13 2001-06-14 Sherkin Communications Systems Limited Communication de donnees
WO2001043397A3 (fr) * 1999-12-13 2002-01-03 Sherkin Comm Systems Ltd Communication de donnees
EP1170962A1 (fr) * 2000-07-05 2002-01-09 Alcatel Méthode pour la prestation de services dans un réseau de communications et modules de programmes et moyens s'y rapportant
US7287093B2 (en) 2000-08-04 2007-10-23 Mobileaware Technologies Limited E-business mobility platform
FR2833442A1 (fr) * 2001-12-12 2003-06-13 Cegetel Groupe Procede d'acces d'un terminal a des donnees d'un reseau externe, base sur la notion de domaine de services
EP1322092A1 (fr) * 2001-12-12 2003-06-25 Cegetel Groupe Procédé d'accès d'un terminal à des données d'un réseau externe, basé sur la notion de domaine de services

Also Published As

Publication number Publication date
AU4153799A (en) 1999-12-13
CA2331102A1 (fr) 1999-12-02
AU753789B2 (en) 2002-10-31
GB0024392D0 (en) 2000-11-22
GB2351823A (en) 2001-01-10
EP1080570A1 (fr) 2001-03-07

Similar Documents

Publication Publication Date Title
US6782420B1 (en) Telecommunications network with a distributive network management system
US6360250B1 (en) Apparatus and method for sharing information in simultaneously viewed documents on a communication system
CN105593835B (zh) 通过主云服务管理器管理多个二级云
AU753801B2 (en) Service provision support system
CN108415710B (zh) 在智能对话开发平台上发布、调用api的方法和系统
Gall et al. Promondia: A Java-based framework for real-time group communication in the Web
AU753789B2 (en) Multiple service provision
CN112799970B (zh) 测试数据处理方法、装置、电子设备及介质
Magedanz TINA–Architectural basis for future telecommunications services
Cabri et al. A proxy‐based framework to support synchronous cooperation on the Web
Bræk et al. ServiceFrame whitepaper
Batteram et al. Design and implementation of the MESH services platform
Sinnott et al. Engineering telecommunication services with SDL
Ochoa et al. Designing the communications infrastructure of groupware systems
Rodgers Java and its future in biomedical computing
Fuentes et al. Towards an open multimedia service framework
Bates A framework to support large-scale active applications
Beca et al. Component architecture for building web-based synchronous collaboration systems
Adamopoulos et al. Continuous media support in the distributed component object model
Verhoosel et al. Rapid service development on a TINA-based service deployment platform
El Saddik et al. Collaborative Use of Instructional Visualizations
Sinnott et al. Creating telecommunication services based on object-oriented frameworks and SDL
Blum et al. A software platform for distributed multimedia applications
Gundoju Distributed observable/observer: A distributed object-communication mechanism
Verhoosel et al. The FRIENDS Platform: Conquering Complexity using Distributed Software Components

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AT AU AZ BA BB BG BR BY CA CH CN CU CZ CZ DE DE DK DK EE EE ES FI FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref country code: GB

Ref document number: 200024392

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 1999925146

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 41537/99

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 09674173

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2331102

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: KR

WWP Wipo information: published in national office

Ref document number: 1999925146

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWG Wipo information: grant in national office

Ref document number: 41537/99

Country of ref document: AU

WWW Wipo information: withdrawn in national office

Ref document number: 1999925146

Country of ref document: EP