WO2008046287A1 - Procédé et système permettant de coordonner les services fournis par différents fournisseurs de services - Google Patents

Procédé et système permettant de coordonner les services fournis par différents fournisseurs de services Download PDF

Info

Publication number
WO2008046287A1
WO2008046287A1 PCT/CN2007/002371 CN2007002371W WO2008046287A1 WO 2008046287 A1 WO2008046287 A1 WO 2008046287A1 CN 2007002371 W CN2007002371 W CN 2007002371W WO 2008046287 A1 WO2008046287 A1 WO 2008046287A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
receiving end
service request
request
sadc
Prior art date
Application number
PCT/CN2007/002371
Other languages
English (en)
French (fr)
Inventor
Qiuling Pan
Yang Zhao
Original Assignee
Huawei Technologies Co., Ltd.
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
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to BRPI0719254-1A priority Critical patent/BRPI0719254A2/pt
Priority to EP07785281A priority patent/EP2079197A4/en
Publication of WO2008046287A1 publication Critical patent/WO2008046287A1/zh
Priority to US12/422,513 priority patent/US20090196308A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42136—Administration or customisation of services

Definitions

  • the present invention relates to the field of communications, and in particular to techniques for coordinating services provided by different service providers. Background technique
  • OS A/Parlay Open Service Architecture/Parlay
  • OSE Open Systems Environment
  • Open Mobile Alliance Open Mobile Alliance
  • the application architecture of the OSA/Parlay mechanism is as shown in FIG. 1, and includes an Application Server, a Parlay Gateway, and an API (Application Programming Interface).
  • the Parlay gateway is composed of a framework and one or more service capability features (SCFs).
  • SCFs service capability features
  • the service capability feature is an abstraction of functions provided by the network.
  • the API is located between the application server and the Parlay gateway. Through this open, standard interface, the service developer, independent software provider (ISV), etc. can be used. The ability of existing network resources to develop new services conveniently and flexibly, thus providing customers with the services they need.
  • the Application Server is provided by a third-party service provider or a network operator to develop various services for use by the end user.
  • the Parlay Gateway includes a Parlay server, which provides various basic service capabilities for the Parlay client, so that the services of the Parlay client can be controlled and securely entered into each communication network. Parlay client access by calling API Parlay servers, which can communicate with distributed object technologies such as CORBA (Common Object Request Broker Architecture), WEB Service (WEB Service), and JAIN SPA (JAVA Advanced Intelligent Network Service Provider Interface).
  • CORBA Common Object Request Broker Architecture
  • WEB Service WEB Service
  • JAIN SPA Java Advanced Intelligent Network Service Provider Interface
  • the OSE mechanism is another technology that provides open services proposed by the OMA organization, which provides a layered, modular, open business generation and execution environment to meet the needs of fast, efficient, and low-cost development of the business. It abandons the original vertical business model "Silo", which divides the business into various engines (such as presentation, location, device management, MMS, etc.) and then manages and employs them in the OSE execution environment.
  • the application architecture is as shown in FIG.
  • an execution environment includes: an execution environment, various engines, a policy execution entity, and an underlying network resource, where the various engines obtain the underlying network resources through the 12 interfaces, and apply the underlying network resources to generate services;
  • the execution environment manages the services in the various engines through the II interface; the respective engines also have respective exposed 10 interfaces connected to the policy execution entity for acquiring policy information, when performing the inherent functions of the respective engines Also consider the setting strategy of the operator or end user.
  • the iFC (Initial Filter Criteria) is configured in the network to solve the problem that different service providers can process the same service request.
  • the way of configuring the core network does not conform to the business independence and layering, which limits the flexibility of the service environment.
  • the complicated iFC configuration will increase the burden on the network, which will result in the efficiency of the entire network processing service.
  • frequently modifying iFC is likely to cause network instability, which may bury huge hidden dangers. Summary of the invention
  • the present invention provides a method and system for coordinating services provided by different service providers.
  • different service providers in different architectures can provide corresponding services for users, providing a more flexible way for service development. , a richer means.
  • the present invention provides a method for coordinating services provided by different service providers, including: After the service adaptation distribution center SADC obtains the service request of the sender, the service request is converted into a standard supported by the receiver according to the relevant service data of the receiver. Form, and then transmitting the service request to the receiving end.
  • the present invention also provides a system for coordinating services provided by different service providers, including: a sending end, configured to send a service request;
  • the service adaptation distribution center SADC is configured to: after obtaining the service request of the sender, convert the service request into a standard form supported by the receiving end according to the relevant service data of the receiving end, and then transmit the service request to the receiving end.
  • the present invention also provides a service adaptation distribution center, which includes:
  • the information transmission unit is configured to receive a service request from the sender and transmit the service request to the service switching unit, and send the converted service request sent by the service switching unit to the receiving end;
  • the service switching unit is configured to: after obtaining the service request of the sender, convert the service request into a standard form supported by the receiver according to the related service data of the receiver, and then transmit the service request to the information transmission unit.
  • the SADC converts the service request into a standard form supported by the receiver according to the relevant service data of the receiver, and then the service request.
  • the invention is transmitted to the receiving end, so that different service providers in different architectures can provide corresponding services to users, and the services provided by different service providers in different architectures are provided for the users.
  • Business development provides a more flexible approach and a richer approach.
  • it can coordinate the deployment and provision of services provided to mobile users based on Parlay and OSE-based technology, and realize the configuration of the existing Parlay components into the OSE environment developed in recent years, which not only saves resources, but also protects the investment of operators. Provides a more flexible approach to business development, a richer approach.
  • the present invention modifies the calling format of the interaction information between the service provider and the upper application entity through the SADC, and provides a unified interface for the upper application entity.
  • FIG. 1 is a schematic diagram of an application architecture of an OSA/Parlay mechanism provided by the background technology
  • FIG. 2 is a schematic diagram of an application architecture of an OSE mechanism provided by the background technology
  • Figure 3 is a flow chart of the first embodiment of the present invention.
  • FIG. 4 is a process flow in a case where a client serving as a service requester subscribes to a presence service and the service provider supports the presence service in the first embodiment of the present invention
  • FIG. 5 is a flowchart of a process in the case where the SADC modifies related data in the SIP request message according to the supported service data supported by the service provider in the first embodiment of the present invention
  • FIG. 6 is a second flowchart of the present invention. Flow chart of an embodiment
  • FIG. 7 is a flowchart of a process in a case where a client serving as a service requester subscribes to a presence service and the service provider does not support some functions in the presence service according to the second embodiment of the present invention
  • Figure 8 is a flow chart of a third embodiment of the present invention.
  • Figure 9 is a schematic structural view of a fifth embodiment of the present invention.
  • Figure 10 is a structural schematic view of a sixth embodiment of the present invention.
  • PAM Presence and Availability Management, Presentation Service Management
  • the service requester as the sender and the service provider as the receiver, and/or the service as the sender A SADC (Service Adaptor/Dispatcher Center) is set up between the service provider and the upper application entity that is the service provider of the receiving end.
  • SADC Service Adaptor/Dispatcher Center
  • the SADC When the SADC is set between the service requester as the sender and the service provider as the receiver, since the call format supported by the service requester and the service provider is the same, the SADC is mainly used to process the service request.
  • the SADC selects the appropriate service provider according to the requested service content in the service request message of the service requester and other accompanying information, such as the number segment, through policy control, and according to
  • the service data of the receiving end converts the service request that is not supported by the service provider, and then sends the service request message conforming to the standard form to the selected service provider; the service provider returns the corresponding service result.
  • the SADC may not directly convert the service request, but directly suspend the service request.
  • the SADC When the SADC is set between the service provider as the sender and the upper application entity as the service provider of the receiver, the service content supported by the service provider and the upper application entity of the service provider is consistent, and the service is The provider knows that the service technology format used by the upper application entity will be different.
  • the call format supported by the service provider using OSA/Parlay technology is the function call format
  • the upper application entity supported by the OSE technology supports the format.
  • the call format is a message call format.
  • the SADC is mainly used to convert a call format that does not meet the service request supported by the upper application entity, and then send a service request message conforming to the standard form to the upper layer entity, so that Provide a unified interface for the upper application entities of the service provider.
  • the first embodiment of the present invention is a method for coordinating services provided by different service providers.
  • the SADC selects a corresponding service provider according to the received service request and the set policy, and then according to the service as the receiving end.
  • the provider's related business data determines whether the service provider supports The service requested in the service request, if supported, transmits the service request to the service provider; if not, the message content in the service request is modified according to related service data of the service provider, The modified business request is transmitted to the corresponding service provider.
  • the specific implementation process of this embodiment is shown in FIG. 3, and includes the following contents:
  • Step S101 The service requester as the sender sends a service request to the core network, and the core network forwards the service request to the service adaptation distribution center SADC.
  • the destination address carried in the request message is the address of the SADC.
  • the service request also contains information such as the service data, as well as the number used by the service requester, the priority level of the service requester, and/or the load balancing principle.
  • Step S102 The SADC selects a corresponding service provider as the receiving end according to the service request and the set policy.
  • the set policy includes the correspondence principle between the segment and the service provider, the correspondence principle between the priority level and the service provider, and/or the load balancing principle.
  • the SADC matches the information in the set policy according to the number of the service requester included in the service request, the priority level of the service requester, and/or the load balancing principle, and if it matches, the The principle corresponding to the matched policy information selects the corresponding service provider as the receiving end.
  • Step S103 determining, according to the service provider's related service data, whether the service provider, such as the Parlay gateway and the OSE engine gateway, supports the service requested in the service request, if yes, executing step S104; if not, executing Step S105.
  • the service provider such as the Parlay gateway and the OSE engine gateway
  • Step S104 the service request is transmitted to the service provider, and then step S106 is performed.
  • step S105 the related data in the service request is modified according to the service data of the service provider, and the modified service request is transmitted to the corresponding service provider, and then step S106 is performed.
  • step S105 after the SADC finds that the service provider does not support the service requested in the service request, it modifies the related data in the service request message according to the service provider's related service data, so that the service conforms to the service.
  • the content of the message supported by the provider There are two ways in which SADC can get relevant business data from a service provider: The first method: the SADC saves the service data supported by the service provider in advance, and periodically obtains the corresponding service data from the service provider, and updates the saved service data by using the acquired service data.
  • the SADC After obtaining the service request of the service requester, the SADC obtains the relevant service data in the corresponding service provider by querying according to the service request.
  • Step S106 The service provider performs corresponding processing according to the service requested in the service request message, and returns a corresponding service result.
  • step S106 after the service provider receives the service request message, the call format of the service request message may be modified by the SADC to make it conform to the service provision.
  • the service provider may not modify the format of the service request message, but in this way, the upper application entity connected by different service providers is not easy to be unified, and the upper layer service application must be modified. .
  • Step S107 The SADC returns the business result to the service requester.
  • step S107 the SADC carries the service result through some messages, and before sending the message, the content of the message needs to be modified to the message content supported by the service requester, and then sent to the service requester. .
  • the client of the service requester acts as a sender, and sends a SIP request message for subscribing to the service to the core network SIP/IP Core, and the destination address carried in the request message is the address of the SADC.
  • the request message further includes information of a subscription presentity, and the trigger event is a message content such as a presence service, and a segment information used by the service request.
  • the SIP/IP Core forwards the SIP subscription request message to the SADC through the destination address carried in the SIP subscription request message.
  • the SADC matches the number segment in the set policy according to the number used by the service request. If it matches, the service provider is selected as the receiving end according to the principle in the set policy, and may be a Parlay gateway. , can also be the OSE engine gateway.
  • the SADC determines whether the service provider supports the requested presence service according to the service data supported by the selected service provider, and modifies the SIP request message after learning that the service provider supports the requested service. Carrying the destination address, and sending the SIP request message to the service provider.
  • the service provider returns a 200 OK SIP response message to the SADC according to the SIP request message, where the corresponding service result is carried.
  • the SADC returns a 200 OK SIP response message to the SIP/IP Core.
  • the SIP/IP Core returns a 200 OK SIP response message to the client.
  • the rendering service in the OSE architecture supports the filtering function, that is, it can be set Receive presentation information such as Presentity.
  • the filtering function that is, it can be set Receive presentation information such as Presentity.
  • Early Parlay gateways did not support this Filtering (or other features such as Partial Notification, Partial Publication).
  • the client in the OSE domain sends the subscription message to the Parlay presentation service requesting the filtering function, if the Parlay gateway cannot support the Parlay presentation service requiring the filtering function, the service processing inconsistency will occur.
  • the SADC is required to modify related data in the SIP request message according to the related service data supported by the service provider.
  • the client of the service requester serves as the sender, and sends a SIP subscription request message; the destination address carried in the SIP subscription request message is the address of the SADC.
  • the service request further includes information such as service data, and a number used by the service requester, a priority level of the service requester, and/or a load balancing principle.
  • the core network SIP/IP Core sends a SIP subscription request message to the SADC;
  • the SADC selects the service provider as a Parlay gateway according to the SIP subscription request message and the set policy.
  • the specific implementation is similar to the related description in the above examples, and will not be described in detail herein.
  • the SADC determines that it does not support the filtering function, and then removes the information requesting the filtering function in the SIP request message to reach the message content that the Parlay gateway can support.
  • the SADC then sends the modified SIP subscription request message to the Parlay gateway;
  • the Parlay gateway returns a 200 OK SIP response message to the SADC.
  • the SADC returns a 200 OK SIP response message to the SIP/IP Core.
  • the SIP/IP Core returns a 200 OK SIP response message to the client.
  • the second embodiment of the present invention is another method for coordinating services provided by different service providers.
  • the SADC selects a corresponding service provider as a receiving end according to the received service request and the set policy, and then according to the The service provider's related service data determines whether the service provider supports the service requested in the service request, and if so, transmits the service request to the service provider; if not, discards the service request and returns Provide information about business failures and corresponding failure cause values.
  • the service provider modifies the calling format in the service request according to the service data supported by the upper application entity, so that it conforms to the calling format supported by the upper application entity, and then The upper application entity interacts with the service provider to complete the task provided by the service.
  • the specific implementation process of this embodiment is shown in FIG. 6, and includes the following contents:
  • Step S201 The service requester as the sender sends a service request to the core network, and the core network forwards the service request to the service adaptation distribution center SADC.
  • the destination address carried in the request message is the address of the SADC.
  • the service request also contains information such as the service data, as well as the number used by the service requester, the priority level of the service requester, and/or the load balancing principle.
  • Step S202 The SADC selects a corresponding service provider as the receiving end according to the service request and the set policy.
  • the policy information included in the set policy, and the specific implementation of the step S202 are the same as those in the first embodiment, and will not be described in detail herein.
  • Step S203 the SADC determines, according to the service provider's related service data, whether the service provider, such as the Parlay gateway and the OSE engine gateway, supports the service requested in the service request, and if yes, executing step S204; If not, the process proceeds to step S205, that is, the service request is discarded, and the information indicating the failure of the service and the corresponding failure cause value are returned.
  • Step S204 the service request is transmitted to the service provider, and then step S206 is performed.
  • Step S206 The service provider performs corresponding processing according to the service requested in the service request message, and returns a corresponding service result.
  • the format of the service request message may be modified by the SADC to conform to the upper layer of the service provider.
  • the calling format that the application entity can support, and then the modified service request message is sent to the upper application entity of the service provider, and then the upper application entity of the service provider interacts with the service provider to complete the service provision.
  • the task return the corresponding business results. It can be seen that after the service provider processes this through SADC, it can provide a unified interface for the upper application entity.
  • the service provider may not modify the calling format of the service request message, but after the processing, the upper application entity connected by different service providers is not easy to be unified, and the upper layer service application must be performed. modify.
  • Step S207 the SADC returns the business result to the service requester.
  • step S207 the SADC carries the service result through some messages, and before sending the message, the content of the message needs to be modified to the message content supported by the service requester, and then sent to the service request.
  • the second embodiment of the present invention is described in detail below by taking a service as a service requester, and the service provider does not support some functions in the presence service, as shown in FIG.
  • the client of the service requester serves as a sender, and sends a SIP subscription request message, where the SIP subscription request message carries a presence service that requires a subscription filtering function;
  • the core network SIP/IP Core sends a SIP subscription request message to the SADC;
  • the SADC selects the service provider as a Parlay gateway according to the set policy;
  • the SADC determines that it does not support the filtering function according to the service data of the service provider Parlay gateway, and then discards the SIP subscription request message, and returns information for providing service failure and corresponding failure reason value to the SIP/IP Core. .
  • the SIP/IP Core returns information providing the service failure and the corresponding failure cause value to the client.
  • the third embodiment of the present invention is a third method for coordinating services provided by different service providers.
  • the SADC is based on the upper application entity of the service provider as the receiving end.
  • Related business data converting the service request into a calling format supported by the upper application entity of the service provider, and then transmitting the service request to the upper application entity of the service provider.
  • the specific implementation process of this embodiment is shown in FIG. 8, and includes the following contents:
  • Step S301 After receiving the service request, the service provider as the sender sends the service request to the SADC.
  • Step S302 The SADC modifies the calling format in the service request according to the related service data of the upper application entity of the service provider, and transmits the modified service request to the corresponding upper application entity.
  • the calling format supported by the Parlay gateway in the service request message needs to be converted into an upper layer.
  • the calling format supported by the application entity is an application entity that uses OSE technology and the service provider is a Parlay gateway that uses OSA/Parlay technology
  • the function call format of a Parlay gateway is: SubscribePresence(SbuscribePresenceRequest, SubscribeResponse) where the request message SbuscribePresenceRequest contains the following two parameters:
  • the business request for the subscription function of the rendering service of the OSE obtained after converting to the message invocation format is as follows: SUBSCRIBE sip:user2@soho.com SIP/2.0
  • Presentity(xsd:anyURI) corresponds to the ⁇ sip:user2 soho.com> of the OSE presenting subscription message, which is used to provide the address of the subscriber to which the service is presented
  • Attributes corresponds to the Content-Type in the subscription message in the OSE: Application/simple-filter+xml , which is used to specify the type of presence information for the subscription.
  • step S302 the SADC obtains related service data of the upper application entity of the service provider in two ways:
  • the first method the SADC pre-stores the service data supported by the upper application entity of the service provider, and periodically obtains the corresponding service data from the upper application entity of the service provider, and uses the acquired service data. Update the saved business data.
  • the second method After obtaining the service request of the service provider as the sender, the SADC obtains the relevant service data in the upper application entity of the corresponding service provider by querying according to the service request.
  • Step S303 After obtaining the service request, the upper-layer application entity performs information interaction with the service provider, completes the task of the service provision, and then returns the service result to the SADC.
  • Step S304 the SADC returns the service result to the service provider as the sender.
  • the SADC carries the service result through some messages. Before sending the message, the call format of the message needs to be modified to the calling format supported by the service requester, and then sent to the service as the sender. provider.
  • a fourth embodiment of the present invention is a system for coordinating services provided by different service providers, including a sender, a receiver, and an SADC.
  • the SADC After obtaining the service request from the sender, the SADC converts the service request into a standard form supported by the receiver according to the relevant service data of the receiver, and then transmits the service request to the receiver; after the receiver provides the corresponding service result according to the service request, The SADC sends the business result to the sender.
  • the system may further include a core network, configured to forward the service request sent by the service requester as the sender to the SADC; and, for forwarding the service result returned by the SADC Business requester.
  • a core network configured to forward the service request sent by the service requester as the sender to the SADC; and, for forwarding the service result returned by the SADC Business requester.
  • the service requester as the sender sends a service request message to the core network, and the core network forwards the service request message to the SADC through the core component therein;
  • the SADC After obtaining the service request of the service requester, the SADC selects the corresponding service provider according to the set policy, and then determines whether the service provider supports the service requested in the service request according to the related service data of the service provider as the receiving end. The function, if supported, forwards the service request message to the service provider.
  • the specific implementation process is similar to the related description in the first embodiment provided by the present invention, and will not be described in detail herein.
  • the first type modifying the content in the received service request message, removing the service function that is not supported by the service provider in the service request message, and then transmitting the modified service request message to the corresponding service provider.
  • the specific implementation process is the same as that in the first embodiment of the present invention, and will not be described in detail herein.
  • the second type directly discarding the service request message, and returning information that provides service failure and The reason for the failure.
  • the specific implementation process is the same as that in the second embodiment of the present invention, and will not be described in detail herein.
  • the SADC sends the business result to a service requester.
  • the signal transmission relationship between the components in the system is as follows:
  • the service provider as the sender After the service provider as the sender receives the service request, it sends it to the SADC;
  • the SADC modifies the calling format in the service request according to the related service data of the upper application entity of the service provider, and transmits the modified service request to the corresponding upper application entity.
  • the process of obtaining the relevant service data of the upper application entity by the SADC is the same as that in the third embodiment, and will not be described in detail herein.
  • the upper application entity After obtaining the service request, the upper application entity performs information interaction with the service provider, completes the task provided by the service, and then returns the business result to the SADC.
  • SADC returns the business results to the service provider as the sender.
  • the specific implementation process of this part is similar to the related description in the first embodiment, and will not be described in detail here.
  • a fifth embodiment of the present invention is a service adaptation distribution center.
  • the structure thereof is as shown in FIG. 9, and includes a service switching unit and an information transmission unit.
  • the service adaptation distribution center may further include a service data acquiring unit.
  • the service data acquisition unit stores the service data supported by the upper application entity as the service provider of the receiving end, and periodically acquires corresponding service data from the receiving end, and saves the saved service data.
  • Business data Or, after the service request arrives at the service adaptation distribution center, the service adaptation distribution center obtains the relevant service data in the corresponding receiving end by using the service data obtaining unit according to the service request.
  • the information transmission unit After the service request of the service provider as the sender arrives at the service adaptation distribution center, the information transmission unit receives the message and transmits it to the service switching unit.
  • the service switching unit modifies the service request according to the service data of the upper application entity of the service provider, so that it conforms to the calling format supported by the upper application entity of the service provider, And transmitting the modified service request to the upper application entity of the service provider.
  • the specific processing procedure of the service adaptation distribution center is the same as the related description in the third embodiment provided by the present invention, and will not be described in detail herein.
  • the upper application entity of the service provider interacts with the service provider as the sender according to the received service request, and provides corresponding service results according to the interaction information, and returns the service result to the service adaptation distribution center;
  • the service adaptation distribution center modifies the calling format of the message carrying the service result through the service switching unit, so that it can conform to the calling format supported by the service provider as the sender, and then sends the call format through the information transmission unit. Go out.
  • the sixth embodiment provided by the present invention is a service adaptation distribution center, and its structure is as shown in FIG. 10, and includes a policy management unit, a route determining unit, a service switching unit, and an information transmission unit.
  • the service adaptation distribution center may further include a service data acquisition unit when there is no service data information supported by the service provider in the service adaptation distribution center.
  • the policy management unit manages some set policy information; the detailed description of the set policy information is the same as the related description in the first embodiment, and will not be described in detail herein.
  • the service data obtaining unit stores the service data supported by the service provider as the receiving end, and periodically acquires corresponding service data from the receiving end, and updates the saved service data by using the acquired service data. Or, after the service request arrives at the service adaptation distribution center, the service data obtaining unit obtains, according to the service request, the related service data in the corresponding service provider as the receiving end by means of the query.
  • the route determining unit selects a corresponding service provider as the receiving end according to the policy information in the policy management unit; and then notifies the selected service provider of the service.
  • Exchange unit After the service request arrives at the service adaptation distribution center, the route determining unit selects a corresponding service provider as the receiving end according to the policy information in the policy management unit; and then notifies the selected service provider of the service.
  • Exchange unit After the service request arrives at the service adaptation distribution center, the route determining unit selects a corresponding service provider as the receiving end according to the policy information in the policy management unit; and then notifies the selected service provider of the service.
  • the service data of the user modifies the content of the service request to conform to the message content supported by the service provider, and transmits the modified service request to the service provider.
  • the specific processing procedure of the service adaptation distribution center is the same as that in the first embodiment provided by the present invention, and will not be described in detail herein.
  • the service provider provides a corresponding business result according to the received service request, and returns the business result to the service adaptation distribution center.
  • the service adaptation distribution center modifies the content of the message carrying the service result through the service switching unit, so that it can conform to the message content that the service requester as the sender can support, and then send it out.
  • the present invention is not limited to the application only presentation service, and the present invention can also be applied to any services provided by Parlay and OSE, such as a location service location, a policy service policy, and the like.
  • the present invention is not limited to application to a system in which OSA/Parlay and OSE technologies coexist, and can also be applied to solve the same problem encountered in service providers having different service providing capabilities in other systems, such as ParlayX system. .
  • the service adaptation distribution center SADC obtains the service request of the service requester
  • the service request is converted into the receiving end according to the related service data of the receiving end.
  • the service request is transmitted to the receiving end, so that the present invention can coordinate services provided by different service providers to mobile users, for example, can coordinate services provided to mobile users based on Parlay and OSE-based technologies.
  • the deployment and provisioning of the existing Parlay components into the OSE environment developed in recent years, can also protect the previously developed applications using new engines, not only save resources, protect operators' investment, and develop for business. Provides a more flexible approach, a richer means.
  • the embodiment of the present invention can modify the corresponding service request message by using the SADC, and can prevent the occurrence of inconsistency in the service provided to the mobile user.
  • the embodiment of the present invention modifies the calling format of the interaction information between the service provider and the upper application entity through the SADC, and provides a unified interface for the upper application entity.
  • the spirit and scope of the invention Thus, it is intended that the present invention cover the modifications and variations of the inventions

Description

协调不同业务提供者提供的业务的方法和系统 技术领域
本发明涉及通信领域， 尤其涉及协调不同业务提供者提供的业务的技术。 背景技术
随着电信业务的蓬勃发展， 各运营商逐步由单一的话音运营商向综合信 息运营商进行转型。 在向综合信息运营商的转型过程中， 运营商迫切需要大 量、 并且丰富多样的业务或信息。 然而随着业务的发展和深入， 业务呈现出 越来越多的特性和复杂度。 为了减少整个业务流程体系中业务之间的交互障 碍和复杂度， 以及满足人们日益广泛的需求， 迫切需要一种技术来规范业务 与业务之间的发现 /交互机制。
目前业界广泛使用的是提供业务服务的 OS A/Parlay ( Open Service Architecture,开放业务架构 /Parlay )机制，和基于 ΟΜΑ( Open Mobile Alliance, 开放移动联盟） 引擎环境提供的 OSE ( Open Systems Environment, 开放系统 环境）机制。
所述 OSA/Parlay机制的应用体系架构如图 1所示， 包括 Application Server (应用服务器）、 Parlay Gateway ( Parlay网关） 以及 API ( Application Programming Interface, 应用编程接口 )。 所述 Parlay网关由才匡架 ( Framework ) 和一个或多个业务能力特征（SCF )组成。 其中所述业务能力特征是对网络所 提供功能的抽象， 所述 API位于应用服务器与 Parlay网关之间， 通过这个开放、 标准的接口， 业务开发商、 独立软件提供商（ISV )等可以获得使用现有网络 资源的能力， 方便、 灵活的开发新业务， 从而为客户提供所需要的业务。
所述 Application Server, 由第三方业务供应商或网络运营商提供， 用以开 发各种业务， 以便提供给终端用户使用。 所述 Parlay Gateway包括 Parlay服务 器， 它为 Parlay客户端提供各种基本业务能力的支持， 使 Parlay客户端的业务 能够有控制的、 安全的进入到各通信网内。 Parlay客户端通过调用 API访问 Parlay服务器， 它们之间可以釆用 CORBA (公共对象请求代理架构）、 WEB Service ( WEB服务）、 JAIN SPA ( JAVA高级智能网业务提供者接口）等分布 对象技术进行通信。
所述 OSE机制是由 OMA组织提出的另一种提供开放业务的技术， 其提供 分层的、 模块化的、 开放的业务生成和执行环境， 满足业务快速、 有效、 低 成本发展的需要。 其摒弃原来垂直的业务模型 "Silo", 划分业务组成各种引擎 (如呈现， 位置， 设备管理， 彩信等等）， 再在 OSE的执行环境中进行管理和 雇用。 其应用体系架构如图 2所示， 包括： 执行环境、 各种引擎、 策略执行实 体和底层网络资源， 所述各种引擎通过 12接口获取底层网络资源， 并应用所述 底层网络资源生成业务； 所述执行环境通过 II接口管理所述各种引擎中的业 务； 所述各个引擎还有各自暴露的 10接口连接所述策略执行实体，用来获取策 略信息， 在执行各个引擎的固有功能之时同时考虑运营商或者终端用户的设 定策略。
随着 OSE技术的发展，众多业界企业开始研究融合重用 OSA/Parlay和 OSE 二者能力的技术， 以便在原有 OSA/Parlay技术的基础上，或者在将来部署的业 务网络里， 能够兼容 OSA/Parlay和 OSE两者的能力， 为业务开发和业务组合提 供更广泛的基础， 提供更统一的封装能力， 以便避免重复开发等浪费。 另一 方面， OS A/Parlay架构和 OSE架构中的业务提供者中所支持的业务能力会存在 不一致的情况， 因此若要实现二者的共同配置， 必须解决不同的业务提供者 能够对同一业务请求进行处理的问题， 以便协调不同业务提供者提供给移动 用户的业务。 系统 ) 网络里面配置 iFC ( Initial Filter Criteria; 初始过滤规则 )来解决不同的 业务提供者能够对同一业务请求进行处理的问题。 然而， 这种通过配置核心 网的方式不符合业务独立， 分层的思想， 限制了业务环境的灵活性； 同时， 复杂的 iFC配置会加重网络的负担， 会导致整个网络处理业务的效率下降。 并 且， 随着业务的增加， 经常修改 iFC容易引起网络不稳定，可能埋下巨大隐患。 发明内容
本发明提供一种协调不同业务提供者提供的业务的方法和系统， 通过本 发明， 能够使处于不同架构的不同业务提供者均能够为用户提供相应的业务， 为业务开发提供了更灵活的方式， 更丰富的手段。
本发明实施例通过如下的技术方案实现：
本发明提供一种协调不同业务提供者提供的业务的方法， 其包括： 业务适配分发中心 SADC获得发送端的业务请求后，根据接收端的相关业 务数据， 将业务请求转换为接收端所支持的标准形式， 然后将所述业务请求 传送到所述接收端。
本发明还提供一种协调不同业务提供者提供的业务的系统， 其包括： 发送端， 用于发送业务请求；
业务适配分发中心 SADC, 用于获得发送端的业务请求后， 根据接收端 的相关业务数据， 将业务请求转换为所述接收端所能够支持的标准形式， 然 后将所述业务请求传送到所述接收端。
本发明还提供一种业务适配分发中心， 其包括：
信息传输单元和业务交换单元；
所述信息传输单元， 用于接收发送端的业务请求， 并将其传送给所述业 务交换单元； 并将所述业务交换单元发送的经过转换处理后的业务请求发送 给接收端；
所述业务交换单元， 用于获得发送端的业务请求后， 根据接收端的相关 业务数据将业务请求转换为所述接收端所能够支持的标准形式， 然后将其传 送给所述信息传输单元。 由上述本发明提供的技术方案可以看出， 本发明中， SADC 获得发送端的业务请求后， 根据接收端的相关业务数据， 将业务请求 转换为接收端所支持的标准形式， 然后将所述业务请求传送到所述接收端， 因此通过本发明， 能够使处于不同架构的不同业务提供者均能够为用户提供 相应的业务， 协调了处于不同架构的不同业务提供者为用户提供的业务， 为 业务开发提供了更灵活的方式， 更丰富的手段。 例如能够协调基于 Parlay和 基于 OSE技术提供给移动用户的业务的部署和提供， 实现了将已有的 Parlay 组件配置到近年发展起来的 OSE环境中， 不仅能够节省资源， 保护运营商的 投资， 而且为业务开发提供了更灵活的方式， 更丰富的手段。
另外， 本发明通过 SADC修改业务提供者与上层应用实体间交互信息的 调用格式， 为上层应用实体提供了统一接口。 附图说明
图 1为背景技术提供的 OSA/Parlay机制的应用体系架构示意图； 图 2为背景技术提供的 OSE机制的应用体系架构示意图；
图 3为本发明第一实施例的流程图；
图 4为本发明第一实施例中， 在作为业务请求者的客户端订阅呈现业务， 并且业务提供者均支持所述呈现业务的情况下的处理流程；
图 5为本发明第一实施例中， 在所述 SADC根据业务提供者的所支持的 相关业务数据修改所述 SIP请求消息中的相关数据的情况下的处理流程； 图 6为本发明第二实施例的流程图；
图 7为本发明第二实施例中， 在作为业务请求者的客户端订阅呈现业务， 并且业务提供者不支持呈现业务中的一些功能的情况下的处理流程；
图 8为本发明第三实施例的流程图；
图 9为本发明第五实施例的结构原理图；
图 10为本发明第六实施例的结构原理图。
词语解释：
PAM ( Presence and Availability Management , 呈现业务管理）。 具体实施方式
本发明实施例为了对不同业务提供者提供的业务进行协调， 在作为发送 端的业务请求者和作为接收端的业务提供者之间， 和 /或， 在作为发送端的业 务提供者与作为接收端的业务提供者的上层应用实体之间，设置了一种 SADC ( Service Adaptor/Dispatcher Center, 业务适配分发中心 )。
当 SADC设置在作为发送端的业务请求者和作为接收端的业务提供者之 间时， 由于业务请求者与业务提供者之间所支持的调用格式是相同的， 此时 SADC 主要用来处理当业务请求者所请求的业务内容与业务提供者所能够支 持的业务内容不一致的情况。 当业务请求消息到达 SADC后， SADC根据业 务请求者的业务请求消息中的所请求的业务内容， 以及其它附带的信息， 比 如号段等信息， 通过策略的控制选取合适的业务提供者， 并根据接收端的业 务数据， 对不符合所述业务提供者所支持的业务请求进行转换， 然后将符合 标准形式的业务请求消息发送给所选择的业务提供者； 所述业务提供者返回 相应的业务结果。 这样能够在业务提供者提供给移动用户的业务与所述移动 用户所请求的业务中的某些业务功能出现不一致时， 继续提供所述移动用户 所请求的业务中的其它的业务功能。 当业务提供者提供给移动用户的业务与 所述移动用户所请求的业务出现不一致时， 所述 SADC也可以不对所述业务 请求进行转换， 而直接中止所述业务请求。
当所述 SADC设置在作为发送端的业务提供者与作为接收端的业务提供 者的上层应用实体之间时， 由于业务提供者与业务提供者的上层应用实体之 间所支持的业务内容一致， 并且业务提供者知道上层应用实体釆用的服务技 用格式会存在不同， 例如釆用 OSA/Parlay技术的业务提供者所支持的调用格 式为函数调用格式， 而釆用 OSE技术的上层应用实体所支持的调用格式为消 息调用格式， 此时所述 SADC主要用来将不符合上层应用实体所支持的业务 请求的调用格式进行转换， 然后将符合标准形式的业务请求消息发送给所述 上层实体， 这样可以为业务提供者的上层应用实体提供统一的接口。
本发明第一实施例是一种协调不同业务提供者提供的业务的方法， 该实 施例中， SADC根据接收到的业务请求和设定的策略选择相应的业务提供者， 然后根据作为接收端的业务提供者的相关业务数据判断业务提供者是否支持 所述业务请求中所请求的业务， 若支持， 则将所述业务请求传送到所述业务 提供者； 若不支持， 则根据业务提供者的相关业务数据修改所述业务请求中 的消息内容， 并将修改后的业务请求传送到相应的业务提供者。 该实施例的 具体实施过程如图 3所示， 包括如下内容：
步骤 S101 , 作为发送端的业务请求者发送业务请求到核心网， 所述核心 网将所述业务请求转发到业务适配分发中心 SADC。
请求消息中携带的目的地址为 SADC的地址。 业务请求中还包含有业务 数据等消息内容， 以及业务请求者所使用的号码、 业务请求者的优先级级别 和 /或负载均衡原则等信息。
步骤 S102 , SADC根据业务请求和设定的策略选择相应的业务提供者作为 接收端。
设定的策略包括号段与业务提供者间的对应原则、 优先级级别与业务提 供者间的对应原则和 /或负载均衡原则。
SADC根据所述业务请求中包含的业务请求者的所使用的号码、业务请求 者的优先级级别和 /或负载均衡原则等信息去匹配设定的策略中的信息， 如果 匹配到， 则按照所匹配到的策略信息对应的原则选择相应的业务提供者作为 接收端。
步骤 S103 , 根据业务提供者的相关业务数据判断业务提供者， 如 Parlay网 关、 OSE引擎网关， 是否支持所述业务请求中所请求的业务， 若支持， 则执行 步骤 S104; 若不支持， 则执行步骤 S105。
步骤 S104, 将该业务请求传送到业务提供者， 然后执行步骤 S106。
步骤 S105 , 根据业务提供者的相关业务数据修改所述业务请求中的相关 数据， 并将修改后的业务请求传送到相应的业务提供者， 然后执行步骤 S106。
步骤 S105中， 当 SADC发现业务提供者不支持业务请求中所请求的业务 后， 其会根据业务提供者的相关业务数据对所述业务请求消息中的相关数据 进行修改， 使其符合所述业务提供者所支持的消息内容。 SADC 获取业务提 供者的相关业务数据的方式有两种： 第一种方式： SADC 事先保存有业务提供者所支持的业务数据， 并周期 性地从所述业务提供者中获取相应的业务数据， 并用所获取到的业务数据更 新所保存的业务数据。
第二种方式： SADC 获得业务请求者的业务请求后， 根据所述业务请求 通过查询的方式获取到相应的业务提供者中的相关业务数据。
步骤 S106, 业务提供者根据业务请求消息中所请求的业务进行相应的处 理， 并返回相应的业务成果。
当在业务提供者和其上层应用实体间设置有 SADC时， 在步骤 S106中， 当业务提供者接收到业务请求消息后， 可以通过 SADC修改所述业务请求消 息的调用格式， 使其符合业务提供者的上层应用实体能够支持的调用格式， 然后再将修改后的业务请求消息发送给所述业务提供者的上层应用实体， 然 后由业务提供者的上层应用实体提供相应的业务成果。 可以看出， 业务提供 者通过 SADC这样处理后， 其可以为上层应用实体提供统一的接口。
当然， 在步骤 S106中， 业务提供者也可以不对业务请求消息的格式进行 修改， 但这样， 不同业务提供者连接的上层应用实体就不容易做到统一， 必 须对上层的业务应用进行^ ί 改。
步骤 S107, SADC将所述业务成果返回给所述业务请求者。
在步骤 S107中， SADC通过某些消息携带业务成果， 在发送所述消息之 前， 需要将所述消息的内容修改为所述业务请求者所支持的消息内容， 之后 再发送给所述业务请求者。
下面以业务请求者的客户端作为发送端订阅呈现业务， 并且业务提供者 Parlay网关或 OSE引擎网关作为接收端支持所述呈现业务为例对本发明提供 的第一实施例进行详细说明， 如图 4所示：
首先， 业务请求者的客户端作为发送端， 发送订阅呈现业务的 SIP请求 消息给核心网 SIP/IP Core, 请求消息中携带的目的地址为 SADC的地址。 所 述请求消息中还包括有订阅呈现体（presentity )的信息， 触发事件 Event为呈 现（Presence ) 业务等消息内容， 以及业务请求所使用的号段信息。 随后， 所述 SIP/IP Core通过 SIP订阅请求消息中携带的目的地址将所述 SIP订阅请求消息转发到 SADC。
接着， SADC根据业务请求所使用的号码去匹配设定的策略中的号段， 如果匹配到， 则根据所述设定的策略中的原则选定一个业务提供者作为接收 端， 可以是 Parlay网关， 也可以是 OSE引擎网关。
然后， SADC根据所选定的业务提供者所支持的业务数据判断所述业务 提供者是否支持所请求的呈现业务， 当获知到业务提供者支持所请求的业务 后，则修改所述 SIP请求消息携带的目的地址，将所述 SIP请求消息发送到所 述业务提供者。
业务提供者根据所述 SIP请求消息返回 200 OK的 SIP响应消息给所述 SADC, 其中携带着相应的业务成果。
SADC返回 200 OK的 SIP响应消息给所述 SIP/IP Core。
SIP/IP Core返回 200 OK的 SIP响应消息给所述客户端。
对于业务提供者不支持业务请求者所请求的业务的处理，主要针对 Parlay 架构和 OSE架构中所支持的业务数据不一致的情况：例如 OSE架构中的呈现 业务支持 Filtering (过滤）功能， 即能够设定接收 Presentity (呈现体）等呈 现信息。 而早期的 Parlay网关不支持这种 Filtering (或者其它功能， 如 Partial Notification, Partial Publication )功能。 此时， 如果在 OSE域的客户端发送订 阅消息订阅要求过滤功能的 Parlay呈现业务的信息时， 如果 Parlay网关不能 支持要求过滤功能的 Parlay呈现业务， 将会出现业务处理不一致的情况。 这 时需要所述 SADC根据业务提供者的所支持的相关业务数据修改所述 SIP请 求消息中的相关数据。 具体实现如图 5所示， 包括：
业务请求者的客户端作为发送端，发送 SIP订阅请求消息； 所述 SIP订阅 请求消息中携带的目的地址为 SADC的地址。 所述业务请求中还包含有业务 数据等消息内容， 以及业务请求者所使用的号码、 业务请求者的优先级级别 和 /或负载均衡原则等信息。
核心网 SIP/IP Core将 SIP订阅请求消息发送到 SADC； SADC根据 SIP订阅请求消息和设定的策略选定业务提供者为 Parlay网 关。 具体实现与上述实例中的相关描述雷同， 这里不再详细描述。
然后 SADC根据业务提供者 Parlay网关的相关业务数据判断出其不支持 过滤功能， 则将 SIP请求消息中要求过滤功能的信息去掉， 使其达到 Parlay 网关所能够支持的消息内容。
然后 SADC将修改后的 SIP订阅请求消息发送给所述 Parlay网关；
Parlay网关返回 200 OK的 SIP响应消息给所述 SADC。
SADC返回 200OK的 SIP响应消息给所述 SIP/IP Core。
SIP/IP Core返回 200OK的 SIP响应消息给所述客户端。
本发明第二实施例是另一种协调不同业务提供者提供的业务的方法， 该 实施例中， SADC根据接收到的业务请求和设定的策略选择相应的业务提供者 作为接收端， 然后根据业务提供者的相关业务数据判断业务提供者是否支持 业务请求中所请求的业务， 若支持， 则将所述业务请求传送到业务提供者； 若不支持， 则丟弃所述业务请求， 并返回提供业务失败的信息以及相应的失 败原因值。 当业务请求到达作为接收端的业务提供者后， 业务提供者根据其 上层应用实体所支持的业务数据对所述业务请求中的调用格式进行修改， 使 其符合上层应用实体所支持的调用格式， 然后发送给上层应用实体， 上层应 用实体与业务提供者进行交互共同完成业务提供的任务。 该实施例的具体实 施过程如图 6所示， 包括如下内容：
步骤 S201 , 作为发送端的业务请求者发送业务请求到核心网， 所述核心 网将业务请求转发到业务适配分发中心 SADC。
请求消息中携带的目的地址为 SADC的地址。 业务请求中还包含有业务 数据等消息内容， 以及业务请求者所使用的号码、 业务请求者的优先级级别 和 /或负载均衡原则等信息。
步骤 S202 , SADC根据所述业务请求和设定的策略选择相应的业务提供者 作为接收端。 设定的策略中包含的策略信息， 以及所述步骤 S202的具体实现 与第一实施例中的相关描述雷同， 这里不再详细描述。 步骤 S203， SADC根据所述业务提供者的相关业务数据判断所述业务提供 者， 如 Parlay网关、 OSE引擎网关， 是否支持所述业务请求中所请求的业务， 若支持， 则执行步骤 S204; 若不支持， 则执行步骤 S205 , 即丟弃所述业务请 求， 并返回提供业务失败的信息以及相应的失败原因值。
步骤 S204, 将业务请求传送到业务提供者， 然后执行步骤 S206,
步骤 S206 , 业务提供者根据业务请求消息中所请求的业务进行相应的处 理， 并返回相应的业务成果。
当在业务提供者和其上层应用实体间设置有 SADC时， 在步骤 S206中， 当业务提供者接收到业务请求消息后， 可以通过 SADC修改业务请求消息的 格式， 使其符合业务提供者的上层应用实体能够支持的调用格式， 然后再将 修改后的业务请求消息发送给业务提供者的上层应用实体， 然后由业务提供 者的上层应用实体与所述业务提供者进行信息交互， 共同完成业务提供的任 务， 返回相应的业务成果。 可以看出， 业务提供者通过 SADC这样处理后， 其可以为上层应用实体提供统一的接口。
当然， 在步骤 S206中， 业务提供者也可以不对业务请求消息的调用格式 进行修改， 但这样处理后， 不同业务提供者连接的上层应用实体就不容易做 到统一， 必须对上层的业务应用进行修改。
步骤 S207, SADC将所述业务成果返回给业务请求者。
在步骤 S207中， SADC通过某些消息携带业务成果， 在发送所述消息之 前， 同样需要将所述消息的内容修改为所述业务请求者所支持的消息内容， 之后再发送给所述业务请求者。
下面以作为业务请求者的客户端订阅呈现业务， 并且业务提供者不支持 所述呈现业务中的一些功能为例对本发明提供的第二实施例进行详细说明， 如图 7所示：
业务请求者的客户端作为发送端，发送 SIP订阅请求消息，所述 SIP订阅请 求消息携带要求订阅过滤功能的呈现业务；
核心网 SIP/IP Core将 SIP订阅请求消息发送到 SADC; SADC根据设定的策略选定业务提供者为 Parlay网关；
然后 SADC根据业务提供者 Parlay网关的相关业务数据判断出其不支持 过滤功能， 则丟弃所述 SIP订阅请求消息， 并返回提供业务失败的信息以及 相应的失败原因值给所述 SIP/IP Core。
SIP/IP Core返回提供业务失败的信息以及相应的失败原因值给所述客户 端。
本发明第三实施例是第三种协调不同业务提供者提供的业务的方法， 该 实施例中， SADC 获得作为发送端的业务提供者的业务请求后， 根据作为接 收端的业务提供者的上层应用实体的相关业务数据， 将业务请求转换为业务 提供者的上层应用实体所支持的调用格式， 然后将所述业务请求传送到所述 业务提供者的上层应用实体。 该实施例的具体实施过程如图 8 所示， 包括如 下内容：
步骤 S301 , 当作为发送端的业务提供者接收到业务请求后， 将所述业务 请求发送给 SADC。
步骤 S302, SADC根据业务提供者的上层应用实体的相关业务数据， 修改 所述业务请求中的调用格式， 并将修改后的业务请求传送到相应的上层应用 实体。
例如，如果所述上层应用实体是釆用 OSE技术的应用实体， 而业务提供者 为釆用 OSA/Parlay技术的 Parlay网关， 则需将业务请求消息中的 Parlay网关所 支持的调用格式转换为上层应用实体所支持的调用格式。
以呈现业务的订阅功能为例， 如某 Parlay网关的函数调用格式为： SubscribePresence(SbuscribePresenceRequest, SubscribeResponse) 其中， 请求消息 SbuscribePresenceRequest包含以下两个参数：
Presentity(xsd:anyURI)
Attributes (PresenceAttributeType)
转换为消息调用格式后得到的 OSE的呈现业务的订阅功能的业务请求如 下： SUBSCRIBE sip:user2@soho.com SIP/2.0
Via: SIP/2.0/UDP userl .huawei.com;branch=z9hG4bKnashds7
Max-Forwards: 70
From: <sip:userl@ soho . com>;tag=31415
To: <sip:user2@ soho.com>
Call-ID: b89rjhnedlrfjflslj40a222
CSeq: 61 SUBSCRIBE
Event: presence
Expires: 7200
Accept: application/pidf+xml
Contact: userl . soho.com
Content-Type: application/simple-filter+xml
Content-Length: ...
其中， Presentity(xsd:anyURI)对应 OSE呈现订阅消息的 <sip:user2 soho.com> ) , 用 来提供呈现业务被订 阅 者 的地址 ， Attributes (PresenceAttributeType)对应 OSE 中 呈 现 订 阅 消 息 中 Content-Type: application/simple-filter+xml , 用来指定订阅的 Presence信息的类型。
步骤 S302中， SADC获取业务提供者的上层应用实体的相关业务数据的 方式有两种：
第一种方式： SADC 事先保存有业务提供者的上层应用实体所支持的业 务数据， 并周期性地从所述业务提供者的上层应用实体中获取相应的业务数 据， 并用所获取到的业务数据更新所保存的业务数据。
第二种方式： SADC 获得作为发送端的业务提供者的业务请求后， 根据 业务请求通过查询的方式获取到相应的业务提供者的上层应用实体中的相关 业务数据。
步骤 S303 , 上层应用实体获得所述业务请求后， 与所述业务提供者进行 信息交互， 完成业务提供的任务， 然后将所述业务成果返回给 SADC。
步骤 S304, SADC将所述业务成果返回给所述作为发送端的业务提供者。 在步骤 S304中， SADC通过某些消息携带业务成果， 在发送所述消息之 前， 需要将所述消息的调用格式修改为所述业务请求者所支持的调用格式， 之后再发送给作为发送端的业务提供者。
本发明第四实施例是一种协调不同业务提供者提供的业务的系统， 其包 括发送端、 接收端和 SADC。
SADC 获得发送端的业务请求后， 根据接收端的相关业务数据将业务请 求转换为接收端所能够支持的标准形式， 然后将业务请求传送到接收端； 当 接收端根据业务请求提供相应的业务成果后， SADC 将所述业务成果发送给 发送端。
当发送端为业务请求者、 接收端为业务提供者时， 系统还可以包括核心 网， 用于转发作为发送端的业务请求者发送的业务请求给 SADC; 以及， 用 于转发 SADC返回的业务成果给业务请求者。 在这种情况下， 系统中的各个 元器件间的信号传递关系如下：
作为发送端的业务请求者发送业务请求消息到核心网， 核心网通过其内 的核心部件将业务请求消息转发到 SADC;
SADC 获得业务请求者的业务请求后， 根据设定的策略选定相应的业务 提供者， 然后根据作为接收端的业务提供者的相关业务数据， 判断业务提供 者是否支持业务请求中所请求的业务中的功能， 如果支持， 则将业务请求消 息转发到业务提供者。 具体实施过程与本发明提供的第一实施例中的相关描 述雷同， 这里不再详细描述。
如果所选定的业务提供者不支持业务请求中所请求的业务中的一些功 能， 则釆取两种措施转换所述业务请求：
第一种： 修改接收到的业务请求消息中的内容， 将所述业务请求消息中 业务提供者不支持的业务功能去掉， 然后将修改后的业务请求消息传送到相 应的业务提供者。 具体实施过程与本发明第一实施例中的相关描述雷同， 这 里不再详细描述。
第二种： 直接丟弃所述业务请求消息， 并返回提供业务失败的信息以及 失败原因值。 具体实施过程与本发明第二实施例中的相关描述雷同， 这里不 再详细描述。
所述 SADC将所述业务成果发送给业务请求者。
当发送端为业务提供者， 接收端为业务提供者的上层应用实体时， 所述 系统中的各个元器件间的信号传递关系如下：
当作为发送端的业务提供者接收到业务请求后， 将其发送给 SADC;
SADC根据业务提供者的上层应用实体的相关业务数据修改所述业务请 求中的调用格式， 并将修改后的业务请求传送到相应的上层应用实体。 SADC 获取上层应用实体的相关业务数据的处理过程与第三实施例中的相关描述雷 同， 这里不再详细描述。
上层应用实体获得所述业务请求后， 与所述业务提供者进行信息交互， 完成业务提供的任务， 然后将所述业务成果返回给 SADC。
SADC 将业务成果返回给作为发送端的业务提供者。 这一部分的具体实 施过程与第一实施例中的相关描述雷同， 这里不再详细描述。
本发明第五实施例是一种业务适配分发中心， 其结构如图 9所示， 包括 业务交换单元和信息传输单元。
当所述 SADC中没有业务提供者所支持的业务数据信息时， 所述业务适 配分发中心中还可以进一步包括业务数据获取单元。
所述业务数据获取单元保存有作为接收端的业务提供者的上层应用实体 所支持的业务数据， 并周期性地从所述接收端中获取相应的业务数据， 并用 所获取到的业务数据更新所保存的业务数据。 或者， 当业务请求到达业务适 配分发中心后， 业务适配分发中心通过所述业务数据获取单元根据所述业务 请求通过查询的方式获取到相应的接收端中的相关业务数据。
当作为发送端的业务提供者的业务请求到达业务适配分发中心后， 所述 信息传输单元接收到后， 将其传递给所述业务交换单元。
所述业务交换单元根据所述业务提供者的上层应用实体的业务数据修改 所述业务请求， 使其符合所述业务提供者的上层应用实体所支持的调用格式， 并将修改后的业务请求传送到所述业务提供者的上层应用实体。 业务适配分 发中心的具体处理过程与本发明提供的第三实施例中的相关描述雷同， 这里 不再详细描述。
所述业务提供者的上层应用实体根据接收到的业务请求与作为发送端的 业务提供者进行交互， 并根据交互信息提供相应的业务成果， 并将所述业务 成果返回给业务适配分发中心；
业务适配分发中心通过业务交换单元对携带所述业务成果的消息的调用 格式进行修改， 使其能够符合作为发送端的业务提供者所能够支持的调用格 式， 然后通过所述信息传输单元将其发送出去。
本发明提供的第六实施例是一种业务适配分发中心，其结构如图 10所示， 包括策略管理单元、 路由确定单元、 业务交换单元和信息传输单元。 当业务 适配分发中心中没有业务提供者所支持的业务数据信息时， 业务适配分发中 心还可以进一步包括业务数据获取单元。
所述策略管理单元管理一些设定的策略信息； 所述设定的策略信息的详 细描述与第一实施例中的相关描述雷同， 这里不再详细描述。
所述业务数据获取单元保存有作为接收端的业务提供者所支持的业务数 据， 并周期性地从所述接收端中获取相应的业务数据， 并用所获取到的业务 数据更新所保存的业务数据。 或者， 当业务请求到达业务适配分发中心后， 所述业务数据获取单元根据所述业务请求， 通过查询的方式获取到相应的作 为接收端的业务提供者中的相关业务数据。
当业务请求到达业务适配分发中心后， 所述路由确定单元根据所述策略 管理单元中的策略信息选定相应的业务提供者作为接收端； 然后将所选定的 业务提供者告知所述业务交换单元。
所述业务交换单元判断所述业务提供者是否支持所述业务请求中所请求 的业务， 若支持， 则将所述业务请求传送到所述业务提供者； 若不支持， 则 根据所述业务提供者的业务数据修改所述业务请求的内容， 使其符合所述业 务提供者所支持的消息内容， 并将修改后的业务请求传送到所述业务提供者。 业务适配分发中心的具体处理过程与本发明提供的第一实施例中的相关描述 雷同， 这里不再详细描述。
所述业务提供者根据接收到的业务请求提供相应的业务成果， 并将所述 业务成果返回给业务适配分发中心。
业务适配分发中心通过所述业务交换单元将携带所述业务成果的消息的 内容进行修改， 使其能够符合作为发送端的业务请求者所能够支持的消息内 容， 然后将其发送出去。
上述一些处理过程中是以呈现业务为例进行说明的， 但本发明不限于仅 仅应用呈现业务， 本发明还可以应用于任何 Parlay和 OSE提供的业务如位置 业务 Location, 策略业务 Policy等。 而且， 本发明不局限于应用到 OSA/Parlay 和 OSE这两种技术共存的系统中， 还可以应用于解决其它系统中具有不同业 务提供能力的业务提供者中遇到的同样问题， 例如 ParlayX系统。
由上述本发明实施例提供的具体实施方案可以看出， 本发明实施例中， 业务适配分发中心 SADC获得业务请求者的业务请求后，根据接收端的相关业 务数据， 将业务请求转换为接收端所支持的形式， 将所述业务请求传送到所 述接收端， 因此通过本发明， 能够协调不同业务提供者提供给移动用户的业 务， 例如能够协调基于 Parlay和基于 OSE技术提供给移动用户的业务的部署和 提供， 实现了将已有的 Parlay组件配置到近年发展起来的 OSE环境中， 也可保 护已往开发的应用运用新的引擎， 不仅能够节省资源， 保护运营商的投资， 并且为业务开发提供了更灵活的方式， 更丰富的手段。
另外， 本发明实施例通过 SADC修改相应的业务请求消息， 能够防止提 供给移动用户的业务出现不一致的现象发生。
另外， 本发明实施例通过 SADC修改业务提供者与上层应用实体间交互 信息的调用格式， 为上层应用实体提供了统一接口。 发明的精神和范围。 这样， 倘若本发明的这些修改和变型属于本发明权利要 求及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在内。

Claims

权 利 要 求
1、 一种协调不同业务提供者提供的业务的方法， 其特征在于， 包括： 业务适配分发中心 SADC获得发送端的业务请求后， 根据接收端的相关业 务数据， 将业务请求转换为接收端所支持的形式， 将所述业务请求传送到所述 接收端。
2、 如权利要求 1所述的方法， 其特征在于， 所述业务请求包括调用格式， 所述根据接收端的相关业务数据将业务请求转换为接收端所支持的形式， 将所 述业务请求传送到所述接收端的过程， 具体包括：
所述业务适配分发中心 SADC根据接收端的相关业务数据， 将业务请求中 的调用格式转换为接收端所支持的调用格式， 然后将所述业务请求传送到所述 接收端。
3、 如权利要求 1所述的方法， 其特征在于， 所述业务请求包括业务内容， 所述根据接收端的相关业务数据， 将业务请求转换为接收端所支持的形式， 将 所述业务请求传送到所述接收端的过程， 具体包括：
所述业务适配分发中心 SADC根据接收端的相关业务数据将业务请求中的 内容转换为接收端所支持的消息内容， 将所述业务请求传送到所述接收端。
4、 如权利要求 3所述的方法， 其特征在于， 还包括：
业务适配分发中心 SADC获得发送端的业务请求后， 根据业务请求和设定 的策略选择相应的接收端。
5、 如权利要求 3所述的方法， 其特征在于， 所述根据接收端的相关业务数 据将业务请求中的内容转换为接收端所支持的消息内容， 将所述业务请求传送 到所述接收端的过程， 具体包括：
所述 SADC根据所述接收端的相关业务数据， 判断所述接收端是否支持所 述业务请求所请求的业务， 若确定出所述接收端不支持所述业务请求所请求的 业务后， 将所述业务请求中的内容转换为接收端支持的消息内容， 将所述业务 请求传送到所述接收端； 或，
所述 SADC根据所述接收端的相关业务数据， 判断所述接收端支持所述业 务请求所请求的业务后， 若确定出所述接收端支持所述业务请求中所请求的业 务后， 则将所述业务请求传送到所述接收端。
6、 如权利要求 1至 5任意一项所述的方法， 其特征在于， 还包括： 所述 SADC获得发送端的业务请求后， 根据所述业务请求通过查询的方式 获取到相应的接收端中的相关业务数据； 或，
所述 SADC中保存有接收端所支持的业务数据， 并从所述接收端中获取相 应的业务数据， 并用所获取到的业务数据更新所保存的业务数据。
7、 如权利要求 6所述的方法， 其特征在于， 还包括：
SADC接收通过核心网转发的业务请求， 所述业务请求来自发送端。
8、 一种协调不同业务提供者提供的业务的系统， 其特征在于， 包括： 发送端， 用于发送业务请求；
业务适配分发中心 SADC,用于获得发送端的业务请求后，根据接收端的相 关业务数据， 将业务请求转换为所述接收端所能够支持的形式， 将所述业务请 求传送到所述接收端。
9、 如权利要求 8所述的系统， 其特征在于， 还包括： 核心网， 用于转发所 述发送端发送的业务请求给所述 SADC; 以及， 用于转发所述 SADC返回的业 务成果给所述发送端。
10、 一种业务适配分发中心， 其特征在于， 包括：
信息传输单元和业务交换单元；
所述信息传输单元， 用于接收发送端的业务请求， 并将其传送给所述业务 交换单元； 并将所述业务交换单元发送的经过转换处理后的业务请求发送给接 收端；
所述业务交换单元， 用于获得发送端的业务请求后， 根据接收端的相关业 务数据将业务请求转换为所述接收端所能够支持的形式 , 将其传送给所述信息 传输单元。
11、 如权利要求 10所述的业务适配分发中心， 其特征在于， 还包括： 业务数据获取单元， 用于当获得发送端的业务请求后， 根据所述业务请求 通过查询的方式获取到相应的接收端中的相关业务数据； 或， 用于保存有接收 端所支持的业务数据， 并从所述接收端中获取相应的业务数据， 并用所获取到 的业务数据更新所保存的业务数据。
12、 如权利要求 10或 11所述的业务适配分发中心， 其特征在于， 所述业 务交换单元还用于当所述业务适配分发中心获得发送端的业务请求后， 根据接 收端的相关业务数据将业务请求中的调用格式转换为接收端所支持的调用格 式， 将所述业务请求传送到所述信息传输单元。
13、 如权利要求 10或 11所述的业务适配分发中心， 其特征在于， 还包括： 策略管理单元和路由确定单元；
所述策略管理单元， 用于管理设定的策略信息；
所述路由确定单元， 用于根据所述策略管理单元中的策略信息选择相应的 接收端。
14、 如权利要求 13所述的业务适配分发中心， 其特征在于， 所述业务交换 单元还用于根据所述路由确定单元选择的接收端的相关业务数据， 判断所述接 收端是否支持所述业务请求所请求的业务， 若确定出所述接收端不支持所述业 务请求所请求的业务后， 将所述业务请求中的内容转换为所述接收端支持的消 息内容， 将所述业务请求传送到所述信息传输单元； 若确定出所述接收端支持 所述业务请求中所请求的业务后， 则将所述业务请求传送到所述信息传输单元。
PCT/CN2007/002371 2006-10-13 2007-08-08 Procédé et système permettant de coordonner les services fournis par différents fournisseurs de services WO2008046287A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
BRPI0719254-1A BRPI0719254A2 (pt) 2006-10-13 2007-08-08 Método e sistema para coordenar serviços fornecidos por diferentes provedores de serviços, e centro adaptador/despachante de serviço (cads)
EP07785281A EP2079197A4 (en) 2006-10-13 2007-08-08 METHOD AND SYSTEM FOR COORDINATING SERVICES PROVIDED BY DIFFERENT SERVICE PROVIDERS
US12/422,513 US20090196308A1 (en) 2006-10-13 2009-04-13 Method and system for coordinating services provided by different service providers

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200610140900.1 2006-10-13
CN200610140900.1A CN101163120B (zh) 2006-10-13 2006-10-13 协调不同业务提供者提供的业务的方法和系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/422,513 Continuation US20090196308A1 (en) 2006-10-13 2009-04-13 Method and system for coordinating services provided by different service providers

Publications (1)

Publication Number Publication Date
WO2008046287A1 true WO2008046287A1 (fr) 2008-04-24

Family

ID=39297948

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/002371 WO2008046287A1 (fr) 2006-10-13 2007-08-08 Procédé et système permettant de coordonner les services fournis par différents fournisseurs de services

Country Status (5)

Country Link
US (1) US20090196308A1 (zh)
EP (1) EP2079197A4 (zh)
CN (1) CN101163120B (zh)
BR (1) BRPI0719254A2 (zh)
WO (1) WO2008046287A1 (zh)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101686253A (zh) * 2008-09-23 2010-03-31 华为技术有限公司 服务选择方法、装置和系统
CN102196010A (zh) * 2010-03-12 2011-09-21 中兴通讯股份有限公司 一种终端侧应用开放接口的实现系统及方法
US8909786B2 (en) 2010-08-26 2014-12-09 Futurewei Technologies, Inc. Method and system for cross-stratum optimization in application-transport networks
US8380845B2 (en) 2010-10-08 2013-02-19 Microsoft Corporation Providing a monitoring service in a cloud-based computing environment
US8843632B2 (en) 2010-10-11 2014-09-23 Microsoft Corporation Allocation of resources between web services in a composite service
US8959219B2 (en) 2010-10-18 2015-02-17 Microsoft Technology Licensing, Llc Dynamic rerouting of service requests between service endpoints for web services in a composite service
US8874787B2 (en) 2010-10-20 2014-10-28 Microsoft Corporation Optimized consumption of third-party web services in a composite service
US8510426B2 (en) 2010-10-20 2013-08-13 Microsoft Corporation Communication and coordination between web services in a cloud-based computing environment
US8914465B2 (en) * 2010-10-27 2014-12-16 Samsung Electronics Co., Ltd. Platform system with provider controlling mechanism and method of operation thereof
CN102752315B (zh) * 2012-07-25 2015-03-18 烽火通信科技股份有限公司 一种灵活适应ims系统业务标签的业务解析方法
US10313349B2 (en) 2014-07-31 2019-06-04 Hewlett Packard Enterprise Development Lp Service request modification
GB201903098D0 (en) * 2016-11-01 2019-04-24 Hewlett Packard Development Co Service implementations via resource agreements
CN111338819A (zh) * 2020-02-24 2020-06-26 政采云有限公司 一种业务对象处理的方法、系统、设备及可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000070800A1 (en) 1999-05-19 2000-11-23 Telia Ab Communication network service management method and device
US6167450A (en) 1997-07-30 2000-12-26 International Business Machines Corporation Data communications management system and protocol replacement method for mobile communication environments
CN1494022A (zh) * 2002-10-30 2004-05-05 华为技术有限公司 一种通过协议代理方式访问数据库的方法
EP1523142A1 (en) 2002-06-18 2005-04-13 NTT DoCoMo, Inc. Gateway apparatus, and method for processing signals in the gateway apparatus

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080207178A1 (en) * 1997-07-30 2008-08-28 Steven Tischer Apparatus and method for restricting access to data
US7418513B2 (en) * 2000-12-15 2008-08-26 International Business Machines Corporation Method and system for network management with platform-independent protocol interface for discovery and monitoring processes
US20020146102A1 (en) * 2001-03-22 2002-10-10 Lang Alexander C. Method and system for multi-provider competitive telecommunications services
US8671132B2 (en) * 2003-03-14 2014-03-11 International Business Machines Corporation System, method, and apparatus for policy-based data management
US20070233883A1 (en) * 2004-05-04 2007-10-04 Paolo De Lutiis Method and System for Access Control in Distributed Object-Oriented Systems
US9245236B2 (en) * 2006-02-16 2016-01-26 Oracle International Corporation Factorization of concerns to build a SDP (service delivery platform)
US7827261B1 (en) * 2004-12-22 2010-11-02 Crossroads Systems, Inc. System and method for device management
US20070192465A1 (en) * 2006-02-10 2007-08-16 Modarressi Abdi R Methods, systems, and products for accessing common functions for multiple applications

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167450A (en) 1997-07-30 2000-12-26 International Business Machines Corporation Data communications management system and protocol replacement method for mobile communication environments
WO2000070800A1 (en) 1999-05-19 2000-11-23 Telia Ab Communication network service management method and device
EP1523142A1 (en) 2002-06-18 2005-04-13 NTT DoCoMo, Inc. Gateway apparatus, and method for processing signals in the gateway apparatus
CN1663204A (zh) * 2002-06-18 2005-08-31 株式会社Ntt都科摩 网关装置和在该网关装置中的信号处理方法
CN1494022A (zh) * 2002-10-30 2004-05-05 华为技术有限公司 一种通过协议代理方式访问数据库的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2079197A4

Also Published As

Publication number Publication date
CN101163120B (zh) 2011-12-21
EP2079197A4 (en) 2010-06-02
CN101163120A (zh) 2008-04-16
BRPI0719254A2 (pt) 2014-01-28
US20090196308A1 (en) 2009-08-06
EP2079197A1 (en) 2009-07-15

Similar Documents

Publication Publication Date Title
WO2008046287A1 (fr) Procédé et système permettant de coordonner les services fournis par différents fournisseurs de services
US20020159439A1 (en) Dynamically downloading telecommunication call services
EP1026867A2 (en) System and method to support configurable policies of services in directory-based networks
US20040230965A1 (en) Mobile handset network that facilitates interaction between a generic intelligent responsive agent and a service broker server
WO2005031573A1 (en) Method and system for providing access to web services
US6055424A (en) Intelligent terminal application protocol
JP2001344200A (ja) ユーザプロファイルデータ管理方法
US8799478B2 (en) Web services and session initiation protocol endpoint for converged communication over internet protocol networks
EP2334018A1 (en) Service selection method, device and system
CN115426391A (zh) 一种远程过程调用协议自适应方法、相关装置及服务器
WO2018059150A1 (zh) 一种能力开放实现方法和装置
JP4357835B2 (ja) 加入者へなされたコールのルーティング
CN100450067C (zh) 业务设备交换网络及交换方法
EP2086181A1 (en) Syatem, method, service control, and trigger device for controlling service invocation
Pailer et al. A service framework for carrier grade multimedia services using PARPLAY APIs over a SIP system
CN100586110C (zh) 用于将消息路由到暂时不可利用的网络用户的方法、系统和网络设备
EP1299982B1 (en) Opimization of service access
KR20200127614A (ko) 호 처리를 위한 릴레이 장치, 릴레이 장치에 의해 수행되는 호 처리 방법 및 호 처리 방법을 실행하는 프로그램이 기록된 기록매체
JP4593152B2 (ja) サーバ装置およびその制御方法
CN102469444A (zh) 通信设备上的特征能力的自动填充
KR101659326B1 (ko) ＶｏＩＰ 번호이동 가입자의 ＥＮＵＭ 가입자 정보를 활용한 번호이동가입자 정보 생성 방법 및 장치
EP2026548A1 (en) A method, system and device for implementing controlled charging
CN113826424B (zh) 用于向网络提供外部业务的实体
CN101102266B (zh) 基于分组网络的路由方法及系统
WO2012083599A1 (zh) 一种欠费控制方法、网关及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07785281

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2007785281

Country of ref document: EP

ENP Entry into the national phase

Ref document number: PI0719254

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20090413