[0041] In the description below, the preferred embodiment of the invention will be referred to by the name given to it within British Telecommunications plc., namely “COMPOSE”. COMPOSE is a channel for component software distribution, and service creation, which stretches from initial component production right through to final instantiation of the resultant service by the customer. It provides an infrastructure for supporting service providers to promote their own component services for use by third parties, and also for supporting service developers who may wish to have rapid access to “best of breed” components written by others.

[0042] An overview of COMPOSE is shown in FIG. 1 . The channel starts with the Component Service Provider (CSP) 10 whose task is to write and to make available to service providers reusable software components.

[0043] Each component is described by a Component Service Descriptor (CSD) and, as indicated by the arrow 11 , is placed by the Component Service Provider into a Service Directory (SD) 12 from where it may be selected by service providers.

[0044] A service provider wishing to provide a software service to a consumer, downloads the necessary components from the Service Directory 12 , as indicated by the arrow 13 , and, within a Service Development Environment (SDE) 14 , “glues” them together to create a service application template.

[0045] Typically, the service provider will add additional functionality to the service, over and above that provided by the various components that have been taken from the Service Directory 12 . The application template is used to create a variety of individual session announcements, each session announcement including not only the template information but also additional session-specific information. As indicated by the arrow 15 , the session announcements are then uploaded by the service provider into a Session Directory 16 . Session announcements are described in Service Announcement Format (SAF).

[0046] An end user or customer, wishing to make use of a service which is announced in the Session Directory 16 , downloads the corresponding SAF file, as indicated by the arrow 17 into the Service Instantiation Environment (SIE) 18 . This will typically be the end user's PC or other computer system.

[0047] A program running on the SIE 18 parses the statements within the SAF file to determine which components are necessary to implement the service. If the appropriate components are not already stored on the SIE, the system downloads them as appropriate, for example across the Internet, and then binds them together to create the final application which may then be executed in the usual way.

[0048] While COMPOSE in its broadest form may be used for all types of component software distribution and service creation, in one embodiment it may be used to enable the provision of broadband services such as multicast audio and video services to the customer. In that example, the service provider may for example be in the business of supplying multicast movies. He uses the system to develop a generic template, which will be used for all movies, and he then uses that as the basis for creating the individual movie session announcements. Each movie session announcement includes the basic information about the components to be used, along with session-specific information such as the name of the movie, the IP multicast address, the port, and the media format. This information, when downloaded by the user, provides the SIE 18 with everything it needs to create and execute the movie-viewing program, and to find and handle receipt of the media stream.

[0049] In the embodiment of FIG. 1 , service reuse may occur at two different stages. Firstly, service providers may reuse individual components which have been supplied by the Component Service Provider, and made available on the Service Directory 12 . Secondly, the template created by the service provider in the Service Development Environment 14 allows reuse of services and/or components within multiple sessions as announced in the Session Directory 16 . In either case, the reuse is entirely transparent to the end user, who simply selects and makes use of any of the session announcements contained within the Session Directory 16 . In the specific example given above, the session announcements listed in the Session Directory may be video-on-demand listings, the selection of any one of those listings allowing the customer access to the corresponding video steam without any need to understand, or even to know about, the individual components that are being used or the additional functionality provided by the service provider.

[0050] The specific implementation of the embodiment shown in FIG. 1 will now be described in more detail. We will start with a description of the Component Service Descriptor (CSD), the purpose of which is to define and encapsulate the attributes and characteristics of the components supplied by the Component Service Provider 10 .

[0051] The Component Service Descriptor (CSD) defines not only the attributes of each component, but also represents and encapsulates a legally-binding contractual agreement between the component supplier (the CSP 10 ) and the user of the component (normally the Application Service Provider, operating within the SDE 14). In making use of a particular component, and incorporating it within a service which is going to be offered to customers, the Application Service Provider becomes party to and becomes bound by the contractual agreement incorporated within the CSD.

[0052] Alternatively, the contractual agreement within the CSD may be between the Component Service Provider 10 and the ultimate customer at the SIE 18 . In such a case, the ultimate customer would become bound by the agreement when selecting and/or attempting to use a service which includes that particular component. Of course, it would be possible for the CSD to represent a three-way contractual agreement, requiring acceptance both by the service provider and also by the ultimate customer before the component is capable of being used within an application on the SIE.

[0053] The Component Service Descriptor is preferably implemented in XML, and includes the following information:

[0054] Component interface: the contract states what other client components have to do to use the interface, and what a third party provider must implement to meet the service which has been promised by the component provider.

[0055] Session interface: the contract sets out the resources (media and functionality) which the component service is authorised to use. For example, the contract may permit the use of a specific IP address to download a movie.

[0056] Policies: the contract specifies what the policies are for use of the service. Policies explain, for example, how the client will be charged (the “charging policy”), and how the client will be authorised to use the service (the “security policy”).

[0057] The component interface, session interface and policies, as advertised on the Service Directory 12 , enable the application service provider to identify the appropriate component services and to set up interactions between them, thereby establishing a composite component service.

[0058] In addition to the above, the Component Service Descriptor also encapsulates implementation details, dependencies to software and hardware resources, mechanisms for accessing the provisioning services, and a mechanism for locating the component to the network and downloading and installing it to the client's machine.

[0059] In more detail, the Component Service Descriptor comprises an XML file including the following elements:

[0060] (a) Basemodule; this provides general information for a component;

[0061] (b) Componentmodule: this contains the individual components that may be built up into a composite service;

[0062] (c) Service: this describes the component service interface via a set of methods and variant conditions that constrain the methods execution;

[0063] (d) Implementation: this is responsible for the implementation specification of the component service;

[0064] (e) Service dependency: this describes the dependencies of the service to other software and hardware resources;

[0065] (f) Policy: this links to charging and security XML descriptors, which illustrate the charging and security policies which are applied to the respective component service; and

[0066] (g) SessionInterface: this includes those attributes that allow the session provider to configure the attributes of a session.

[0067] To elucidate these elements more fully, we will now describe an example which assumes the advertisement of a realplayer component service used for streaming real-time content (for example video or audio). Realplayer is a Java-based component, which uses at a lower level the JMF component framework, as well as other Java components to implement media player services.

[0068] The CSD starts with a route element, as shown in listing 1, below: 1

[0069] The basemodule, shown in Listing 2, provides general information for the realplayer component including the ID, name, version, category, service description and details for the owner of the component: 2

[0070] The basemodule provides an overview of the component service as an independent entity. Other responsibilities include the following:

[0071] Helps to classify the component service in the Service Directory 12 . For example, version discriminates different versions of the same (realplayer) component; category classifies, for instance, realplayer under a media player component category; and id uniquely identifies the component.

[0072] Enables the service developer to search for announced component services in the Service Directory and to allow for the differences between alternative components.

[0073] The componentmodule (see listing 3) encapsulates information for the plugin components that will build the entire component service. For each component, the component module advises the service developer/provider of information relating to implementation, distribution and installation requirements: 3

[0074] The implementation element addresses requirements for the client machine on which the components will be installed and executed. These include the following:

[0075] the set of operating systems and their versions, which might support the component execution;

[0076] the minimum processing power required (processor) as well as storage, memory and performance requirements; and

[0077] details for the component deployment (compiler, programming language), and the runtime necessary for component instantiation.

[0078] The implementation location guides the distribution of the component from the component service provider down to the client's machine. The distribution is addressed by the codebase element, which indicates the location of the component. Then, the system will need to know what happens after the component is installed to the computer's registry. The answer is given by the codetype attribute, which explains how the component will be accessed (e.g. a jar file); the run attribute, which indicates the final configuration of the component at the client's machine (e.g. java com.real.util.JMFConfig); and the class attribute, which indicates the main object which instantiates the component (e.g. JMF).

[0079] It should be noted that CSD may be used to describe not only individual components, but also component services (i.e. services which consist of two or more components). Where there is more than one component within the component service, the component element will be repeated within the component module as many times as necessary.

[0080] The service element, illustrated by Listing 4, represents one of the three contractual states of a component, namely the component interface. In this way, the component interface may be separated from its implementation, allowing the abstraction of the service component behaviour at a higher level while hiding implementation details: 4

[0081] The service developer will access information for the services a component offers in order to build a combined service of more than one component services connected via their interfaces. The role of the service element is to:

[0082] retain the location of the component interface (codebase) remotely. For instance, the file realjar stores the interface of the realplayer component. It is used for introspecting the methods, events, properties the realplayer makes available to an application.

[0083] indicate the parameters and the constraints which characterise each of the methods of the interface. The interface methods provided by a component are considered the facade of the component to the outside world and a key mechanism of interaction with other component services. A method has a name (mname), input and output parameters and an actual description of its role in the interface. Before a method is invoked it is necessary to know the types of its input and output parameters, any constraints applied on them, and their role in the method. In general, the method features (e.g. method constraints) of a component interface may but need not be exploited within COMPOSE.

[0084] Service dependency describes any external resource component that the individual components of the composite service will depend on for their deployment and instantiation (eg a java class, a dll, or another resource). The service dependency description is similar to the component implementation specification given above. In addition, a comname attribute is used to recognize uniquely a resource component. The codebase of the resource component interface might be specified if it is to be accessed through an interface.

[0085] The policy element links both to charging and security XML descriptors, which prescribe the charging and security models to be applied to this particular component.

[0086] The purpose of the charging policy is to capture details allowing the system to charge users for service usage, and to set up a legally binding contract between service providers and their users. The charging policy holds the necessary details of a charging service contract, that could either be bundled or unbundled. These terms are described below:

[0087] A bundled charging service contract determines a legal relation between the various entities involved such that:

[0088] a customer pays its service provider who provides the overall service,

[0089] the service provider pays its individual component service providers for using the individual component services, the service provider pays the customer's network provider for network access, and

[0090] the service provider pays its network provider for network access.

[0091] An unbundled charging service contract determines a legal relation between the various entities such that:

[0092] a customer pays the service provider who provides the overall service,

[0093] the customer pays the individual service providers for their individual component services,

[0094] the customer pays its network provider for network access, and

[0095] the service provider pays its network provider for network access.

[0096] COMPOSE supports the provision of both bundled and unbundled service contracts.

[0097] The charging policy (part of the policy element) comprise a charging description, the tariff packages it offers, the payment methods, and references to any dependent policies that also require payments. An example is shown in Listing 5 which follows: 5

[0098] The description may include details such as the type of policy (bundled or unbundled), along with details of the validity of the policy.

[0099] The tariff-package may specify different pricing models, such as flat rate or time charge. Users could also be charged on the basis of how much traffic is requested and generated: the same tariff could apply to both downloaded and uploaded traffic, or different tariffs could be applied. Combinations of the above would also be possible.

[0100] The payment entry specifies the type of payment method, such as using a particular payment server at a particular address and port number.

[0101] The references to other charging policies may comprise a link to charging policies of dependent service components.

[0102] The second part of the policy element is the security policy. The application developer/service provider uses the security element to obtain security certificates which verify the Component Service Provider who has supplied this particular component. An example of a security element, within the policy element, is set out in Listing 6, below: 6

[0103] The security element includes information for accessing the certificate (including server location and port) as well as perameters for authorising the communication between service providers and developers (merchant_ID, service_ID).

[0104] The session interface element defines the interface between third parties and service providers. Session attributes are dynamically defined in the session interface to configure the communication between the client components and the associated remote services. For instance, in Listing 7 (below), the realplayer component has to configure the value of a mediaFile parameter with the remote address of the video file which will be delivered through the component instantiation: 7

[0105] Turning now to FIG. 2 , there is shown in more detail the structure of the Service Directory (SD) 12 of FIG. 1 . The Service Directory consists of a core service 20 along with a number of other registered services, namely a security service/store 22 , a component store 24 and a description store 26 . The core service 20 provides access for the service users, namely the Component Service Providers 10 and the Service Developers at the SDEs 14 .

[0106] In this model, all of the elements 20 to 26 represent services, and the service directory itself has minimal direct functionality. A Service Developer at the SDE who wishes to make use of the Directory first registers with the core service 20 , which provides a list of the local service providers, i.e. the services 22 , 24 , 26 . One of those is selected, and the user is then presented with a further list supplied by the local service.

[0107] By permitting each local service to register as proxies in the core service 20 , where they can be downloaded and used by either a CSP 10 or an SDE 14, the SD model may be quite small and dynamic.

[0108] The Description Store 26 holds the service descriptions, which may be viewed as an object (XML) database. The store includes functionality for adding, removing and querying objects within the database e.g. by means of keyword searches. Each service description within the database is conveniently signed by the service provider.

[0109] The Component Store 24 acts like a web server and, as its name suggests, simply stores components. To execute the service, the user downloads the components from a designated Component Store. Each component has a unique identify generated by the component provider.

[0110] The Security Service 22 provides the necessary authorisation, authentication and certification services. For example, the Component Store at start-up may require a digital certificate that establishes its credentials when its services are invoked. The Service Developer can use the security service to obtain the certificates to verify the Component Store, for example from a Certificate Authority 28 . Likewise, each component in a Component Store can be certified, to ensure that they are from a trusted third party, and that they are safe to execute on the client machine.

[0111] In use, the Component Service Provider 10 will first register the description of the component in a Description Store 26 , and will upload the packaged component to a Component Store 24 . Alternatively, the Component Provider could use his own Component Store, and define a link to it as part of the description. The package will typically include digital signatures and certificates.

[0112] The Service Directory preferably implements a Java JINI-based Lookup Service (LUS), which handles the registration, discovery and distribution of services. The LUS multicasts its presence on TCP IP networks to form a federation of Lookup Services, which advertise services to all the other Lookup Services within the federation. To access a service, the client or service developer downloads the LUS registrar object, and invokes the desired function (for example to find a service). The client then creates service templates to search for services based on unique IDs, types and/or objects. When successful, the LUS registrar will return one or more service proxies which may be downloaded to the developer's machine. This uses its own private and secure protocol to interact directly with the required service.

[0113] It will be understood of course that although the CSP 10 will frequently be advertising individual components on the Service Directory, the Service Directory could also be used for the advertisement of more complex component services, namely services which combine two or more individual components. Such component services may be accessed and used by the Service Developer as a distinct entities in their own right.

[0114] FIG. 3 shows the Service Development Environment (SDE) 14 of FIG. 1 .

[0115] The SDE enables a service developer to find and retrieve the “building block” components needed, which are then “glued together” to form an application which is described in Service Announcement Format (SAF)— see below. Firstly, the SDE enables retrieval and matching of component services from the Service Directory 12 , and secondly it encapsulates service generation and delivery.

[0116] A Service Agent 30 enables service developers to search the Service Directory 12 for advertised components or component services which will together form the combined application.

[0117] Once all the component services have been found, an Application Template Builder 32 is used to glue them together. This involves first customising the state of each service component, tailoring the component more specifically to the functionality required by the service, then organising the component services in order of execution, and binding them together using an event-based messaging mechanism. The result is an Application Template 34 which can be used as a “cookie cutter” to create many individual services.

[0118] Next, the developer uses a Service Session Builder 36 to create individual service announcements 38 , 40 , 42 from the Application Template 34 . Each service announcement includes the template information along with additional session-specific information (for example telling the resultant application where to locate and how to deal with multicast content).

[0119] During preparation of the Application Template 34 , or during preparation of the individual Session Announcements 38 , 40 , 42 , additional information may be incorporated by the service provider, including information about the service provider itself, and contractual policies covering charging and security. These policies, which may apply to all of the service announcements based on a particular template, or only some of them, are in addition to the charging and security policies which are applicable to the individual components or component services which underlie the service announcement.

[0120] The individual service announcements 38 , 40 , 42 are described in Service Announcement Format (SAF), and are then deployed to the Session Directory 16 from which customers can retrieve the service offers.

[0121] Service Announcement Format (SAF) is used to describe the individual session announcements, and includes all of the information necessary to facilitate the customer's access to the actual service—for example access to the remote media sessions. SAF comprises the following modules:

[0122] A base module which prescribes user-oriented data for a given service (for example service name, owner, available media and time information);

[0123] A component service module which provides information for each of the component services making up the service application. A SAF description includes links to component service descriptors used to prescribe the session attributes, application component specifications and policy constraints of a component service. In general, the Component Service Module represents the resources (content and distributed functionality) necessary for delivering the overall service to the end user;

[0124] A component wiring module which specifies how the components interact and their order of execution; and

[0125] a policy module which specifies how the overall service should be charged, and how system security is implemented. As mentioned above, this policy module describes overall policies which are applicable in addition to the individual component policies.

[0126] The template-specific or the session-specific charging and security policies, added by the service developer, are described within SAF in a similar manner to the way in which those policies are described for individual component services within CSD. More particularly, the charging and security policies preferably comprise a collection of XML elements which are inserted into the CSD or into the SAF. Alternatively, it would be possible to use a link to a policy descriptor stored elsewhere: that approach would mean that any modification to the charging XML document would not affect the component or the session description. In the preferred COMPOSE embodiment, however, the former non-linked approach is used for simplicity.

[0127] The SAF description created by the service provider acts as a contractual agreement between the service provider and the user. In addition, it may also have encapsulated within it a contractual agreement between the Component Service Provider and the user.

[0128] The Service Instantiation Environment (SIE) 18 is shown in more detail in FIG. 4 .

[0129] The SIE is responsible for downloading an SAF file 40 from the Session Directory 16 and producing from it a running application. From the SAF 40 , the SIE uses the Service Descriptor modules and the wiring module in order to produce the application. The input into the application building process include the session, the available components and the charging and security policies of the overall service, as described in the SAF. Also, the application template in the wiring module provides details of the component configuration.

[0130] Once the user has decided to join a session, and the SAF file has been downloaded, it is passed to a Component Downloader 42 which checks which components are already installed on the local computer, and which components and their dependencies remain to be installed. The descriptor of each component service provides all the necessary information about component location and dependencies, enabling the component loader to locate and to download additional components 44 as necessary.

[0131] Once all the components are available, an Application Descriptor Transformer 46 uses them, along with input session attributes from the SAF, to product an Executable Application Script 48 . Finally, this is converted by an Application Builder 50 into a Running Application 52 .

[0132] When the available sessions are displayed to the user via the Session Directory 16 , both the description of the available sessions and their associated charges are displayed. The charges are computed by a Charging Component (described below) which forms part of the service and which performs its calculations on the basis of the component charging policies and/or the session charging policies.

[0133] As shown in FIG. 5 , the SAF file 40 for a particular session is downloaded into the Service Instantiation Environment 18 from the Session Directory 16 . The SIE, in order to parse the charging policies, requires a Charging Component 56 . Typically, such a component will be provided by a Payment Service Provider 58 and, if not already available in the SIE, will automatically be downloaded from an address specified in the SAF file. Alternatively, the SAF may simply include a pointer to the Payment Service Provider to be used, that provider specifying where the charging component may be downloaded from.

[0134] The Charging Component 56 will typically include functionality providing for direct communication between the user and the Payment Service Provider, for example the transfer of credit card information. The user must provide the necessary information before the application can be run.

[0135] Each entity within the system is preferably certified by a Certificate Authority, such as the Authority 28 shown in FIG. 2 . Not only does the Application Developer use the Security Service to obtain certificates to verify Component Service Providers, but all communications between the Component Service Providers, the Application Developers, and the ultimate customer are encrypted.

[0136] Finally, all stored entities (both components and descriptions) are signed.