WO2013188697A1 - Système et procédé de prise en charge d'acheminement basé sur une version dans un environnement de machine à logiciel intermédiaire transactionnelle - Google Patents

Système et procédé de prise en charge d'acheminement basé sur une version dans un environnement de machine à logiciel intermédiaire transactionnelle Download PDF

Info

Publication number
WO2013188697A1
WO2013188697A1 PCT/US2013/045723 US2013045723W WO2013188697A1 WO 2013188697 A1 WO2013188697 A1 WO 2013188697A1 US 2013045723 W US2013045723 W US 2013045723W WO 2013188697 A1 WO2013188697 A1 WO 2013188697A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
version
transactional
request
requested
Prior art date
Application number
PCT/US2013/045723
Other languages
English (en)
Inventor
Huasheng FU
Sheng ZHU
Zhenyu Li
Original Assignee
Oracle International Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/915,482 external-priority patent/US10291486B2/en
Application filed by Oracle International Corporation filed Critical Oracle International Corporation
Priority to CN201380024093.5A priority Critical patent/CN104272259B/zh
Priority to KR1020147033885A priority patent/KR102103493B1/ko
Publication of WO2013188697A1 publication Critical patent/WO2013188697A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine

Definitions

  • the present invention is generally related to computer systems and software, and is particularly related to supporting a transactional middleware machine environment.
  • the business systems that provide various services using enterprise IT architecture may involve complex and numerous stages. These business systems may need to handle various scenarios, such as changing the service contract for the end users, offering new service contracts for new customers, upgrading old services to new services in a non-stop mode, and keeping the older services for some existing customers.
  • IT service providers may want to provide several versions of services in parallel, and offer specific variants to certain customers.
  • some services requesters may want to access different versions of services in a uniform manner or even switch between the different versions of services at runtime, while the others may not want to explicitly deal with the different service versions. This is the general area that embodiments of the invention are intended to address.
  • Atransactional service provider can dispatch at least one service using a plurality of service entries with different service versions, and determine whether a service version associated with a service entry matches a requested service version associated with a service request received from a service requester. Then, transactional service provider can allow the service requester to access the service entry that matches the requested service version associated with the service request.
  • An exemplary embodiment of the invention provides a system for supporting network management in a network environment, comprising a transactional service provider.
  • the transactional service provider may comprise a dispatching unit, a matching unit and an accessing unit.
  • the dispatching unit may operate to dispatch at least one service using a plurality of service entries with different service versions.
  • the matching unit may operate to determine whether a service version associated with a service entry matches a requested service version associated with a service request received from a service requester.
  • the matching unit may operate to match a service name of a service entry with a requested service name in the service request received from the service requester.
  • the accessing unit may operate to allow the service requester to access the service entry that matches the requested service version associated with the service request.
  • the transactional service provider may further comprise a returning unit that operates to return an error message to the service requester when all service entries with matching name can not match the requested service version.
  • the transactional service provider may further comprise a partitioner that operates to partition one or more applications into one or more application zones.
  • Each of the application zone is associated with a particular request version of the at least one service.
  • the transactional service provider may further comprise a comparing unit that operates to perform numeric comparison between the requested service version number and both boundary values of the version range.
  • the transactional service provider may further comprise a version determining unit that operates to determine the requested service version associated with the service request.
  • the transactional service provider may further comprise a configuration providing unit that operates to use at least one configuration file to provide the transactional service application configuration.
  • the transactional service provider may further comprise a configuration changing unit that operates to use a management interface to change the transactional service application configuration at runtime.
  • Figure 1 shows an illustration of supporting application service versioning in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • Figure 2 shows an illustration of supporting implicit versioning in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • Figure 3 illustrates an exemplary flow chart for supporting implicit versioning in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • Figure 4 shows an illustration of supporting version context in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • Figure 5 shows an illustration of supporting a Tuxedo application deployed in a multiprocess (MP) environment, in accordance with an embodiment of the invention.
  • MP multiprocess
  • FIG. 6 shows an illustration of supporting version based routing (VBR) in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • VBR version based routing
  • FIG. 7 shows an exemplary sequence chart for supporting version based routing (VBR) in a distributed transactional middleware machine environment, in accordance with an embodiment of the invention.
  • VBR version based routing
  • FIG. 8 illustrates an exemplary flow chart for supporting version based routing (VBR) in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • VBR version based routing
  • Figure 9 illustrates a functional block diagram of a transactional service provider in accordance with some embodiments.
  • Figure 10 illustrates an exemplary block diagram of a transactional service provider, in accordance with an embodiment of the invention.
  • the system comprises a combination of high performance hardware, e.g. 64-bit processor technology, high performance large memory, and redundant InfiniBand and Ethernet networking, together with an application server or middleware environment, such as WebLogic Suite, to provide a complete Java EE application server complex which includes a massively parallel in-memory grid, that can be provisioned quickly, and can scale on demand.
  • an application server or middleware environment such as WebLogic Suite
  • the system can be deployed as a full, half, or quarter rack, or other configuration, that provides an application server grid, storage area network, and InfiniBand (IB) network.
  • the middleware machine software can provide application server, middleware and otherfunctionality such as, for example, WebLogic Server, JRockit or Hotspot JVM, Oracle Linux or Solaris, and Oracle VM.
  • the system can include a plurality of compute nodes, IB switch gateway, and storage nodes or units, communicating with one another via an IB network. When implemented as a rack configuration, unused portions of the rack can be left empty or occupied by fillers.
  • the system is an easy-to-deploy solution for hosting middleware or application server software, such as the Oracle Middleware SW suite, or WebLogic.
  • middleware or application server software such as the Oracle Middleware SW suite, or WebLogic.
  • the system is a "grid in a box" that comprises one or more servers, storage units, an IB fabric for storage networking, and all the other components required to host a middleware application.
  • Significant performance can be delivered for all types of middleware applications by leveraging a massively parallel grid architecture using, e.g. Real Application Clusters and Exalogic Open storage.
  • the system delivers improved performance with linear I/O scalability, is simple to use and manage, and delivers mission-critical availability and reliability.
  • Tuxedo is a transaction processing system or transaction oriented middleware or enterprise application server for C, C++, and COBOL. It is a set of software modules that enables the construction, execution, and administration of high performance, distributed business applications and has been used as transactional middleware by a number of multi-tier application development tools. Additionally, a transactional middleware system, such as a Tuxedo system, can take advantage of fast machines with multiple processors, such as Exalogic middleware machine, and a high performance network connection, such as an InfiniBand (IB) network.
  • IB InfiniBand
  • a transaction middleware machine environment can support service versioning in order to reduce the client and server development effort.
  • a transactional service provider e.g. Tuxedo
  • Tuxedo can dispatch different services according to both a service name and a version that a service support.
  • a service requester e.g. a client or a server/service that requests for a transactional service, may only have access to the service entry that supports a corresponding version.
  • FIG. 1 shows an illustration of supporting application service versioning in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • a transactional service provider 1 10 in a transaction middleware machine environment 100 can provide various services, such as transactional services A-B 1 1 1- 1 12.
  • the transactional service A 1 1 1 can include multiple service entries, e.g. versions l-lll 121 - 123, while the transactional service B 1 12 can also include multiple service entries, e.g. versions l-ll 131 -132.
  • service versioning in a transactional middleware machine environment 100 can involve different people, such as the developers for client applications (e.g. clients A-B 101-102), the operation or management team, the deployment team 103, and the developers of services 104. Each of these parties may have their own different service version requirements.
  • client A 101 can access version 1 121 of transactional service A 1 1 1
  • client B 102 can access version II 122 of transactional service A 1 1 1 and version II 132 of transactional service B 1 12.
  • the developers of client applications A-B 101-102 can partition client requests into different transactional application services versions with the same service name.
  • the developers of client applications A-B 101 -102 can switch current request context for applying different business logic to the same transactional application according to the input of client.
  • the deployment team 103 can upgrade transactional applications logic in version III 123 of the transactional service A 1 1 1 in a non-stop mode, while continually handling old service logic in versions l-ll 121 -122. Also, the service developers 104 can update service logic in version I 131 of transactional service B 1 12 at the run time without disturbing current active service of version II 132 with the same service name. Implicit Versioning
  • the transaction middleware machine environment can support implicit versioning, which can be configuration driven and can provide a flexible way for a user to support application versioning.
  • FIG. 2 shows an illustration of supporting implicit versioning in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • a transactional server 201 in a transactional middleware machine environment 200 can provide a transactional service A 210 in different versions, e.g. versions l-lll 21 1-213.
  • one or more configuration files 209 can be used for supporting implicit versioning.
  • the configuration file 209 can define a hierarchy relationship among the different levels in a management hierarchy.
  • a user can partition various applications into different virtual zones, e.g. application zones A-B 203-204, based on version ranges.
  • Each of the application zones A-B 203-204 can be configured to handle the service requests with a specific version number.
  • application zone A 203 can handle the service requests with a request version A 223 (e.g. version I)
  • application zone B 204 can handle the service requests with a request version B 224 (e.g. version II).
  • the user can change the client request version and service version range at runtime.
  • Such change which can be made via a management interface unit, e.g. the MIB interface/API interface in Tuxedo, can take effect immediately at run time.
  • the users can enable/disable the application versioning feature through the configuration file 209. If application versioning is disabled, there can be no impact to an existing system. If application versioning is enabled, the system can provide a way for the users to set the client's/service's version and to configure the service support version range at different levels, e.g. at the application, and/or group level.
  • both the UBB configuration files and the DMCONFIG configuration files can be used for supporting implicit application versioning.
  • the customer can enable the application versioning feature by specifying a new application option, APPVE , in the OPTIONS section of the UBB configuration file.
  • the UBB configuration files and the DMCONFIG configuration files can include attributes, such as REQUEST_VERSION, VERSION_POLICY and VERSlON_RANGE, for specifying the versions and the allowable version ranges in a configured Tuxedo management entity.
  • the application versioning feature is enabled, a user can configure the application version related information in the UBB configuration file and the domain configuration files. On the other hand, if the application versioning feature is not enabled, the user may not configure the application version feature related configuration in UBB configuration file or through MIB interface. Also, if the customer disables the application versioning feature in UBB configuration file, the application version information in domain configuration may have no impact.
  • client applications A-B 206-207 can make a request for the transaction service A 210 provided on the transactional server 201.
  • the user can control the client request version and service range, via a configuration file 209.
  • the user can configure the application version related information on domain level and group level in UBB configuration file.
  • the REQUEST_VERSION in the UBB configuration file can be used to determine the version of the client that sends the request.
  • the value of REQUEST_VERSlON can be numeric, which is valid when it is equal to or greater than 0 and equal to or less than 65535(USHRT_MAX). Additionally, the default value for the REQUEST_VERSION can be ' * ', which indicates that the request version can be accepted by any version range and can call any versioned service.
  • the VERSION_POLICY in the UBB configuration file can be used to determine version control policy.
  • a value can be "PROPAGATE", which indicates that the service should propagate the incoming request version instead of using its own request version when start a new request.
  • the VERSlON_POLlCY can precede the REQUEST_VERSlON during service dispatching, i.e. if both the REQUEST_VERSlON and VERSlON_POLlCY attributes are configured for a service, the service may propagate the incoming request version when start a new request.
  • the service propagate the incoming request version
  • a remote service A 220 in a remote domain A 202 can make a request for a version of transactional service A 210 in a local domain. Also, the transaction service A 210 in the local domain can request for a remote service A 220 (i.e. version I 221 or version II 222) in the remote domain A 202.
  • a remote service A 220 i.e. version I 221 or version II 222
  • a user can use the configuration file 209 to configure the service version range for an imported service and to configure the service request version coming from a remote domain.
  • the user can configure the remote service, by introducing new attributes REQUEST_VERSlON, VERSlON_RANGE and VERSlON_POLlCY in domain configuration files.
  • the REQUEST_VERSION in the DMCONFIG configuration file can be used to define how to map the incoming service request version from specific remote domain, e.g. the remote domain A 202, to the configured request version in the local domain.
  • a domain gateway can change the incoming request version, when the user configures the REQUEST_VERSION in domain configuration file, otherwise the domain gateway may propagate the incoming request version.
  • the VERSION_RANGE in the DMCONFIG configuration file can be used to indicate the version range of an imported remote service.
  • This version range of the imported remote service can be the same as the version range of the corresponding exported service. Otherwise, the call may fail at remote domain even it can be accepted in the local domain.
  • the VERSION_POLICY in the DMCONFIG configuration file can be used to determine version control policy.
  • a value can be "PROPAGATE", which can be used to determine whether the domain gateway will propagate/map the request version of an incoming client request from a specified remote domain to the configured request version.
  • the version policy can override the request version in the DMCONFIG configuration file. I.e. the version policy can take precedence when both the VERSlON_POLlCY and the REQUEST_VERSlON are configured.
  • the domain gateway can propagate the client request version across the domain gateway.
  • the above domain configuration indicates that the request version for service request coming from REMOTEDOM1 may not be changed by the domain gateway, while the request version for service request coming from REMOTEDOM2 may be change to 4 by the domain gateway.
  • the domain gateway can import a remote service, R_SVC1, from REMOTEDOMl with the version range set as 1-3, which indicates that only the client with request version in this range can call the R_SVCl in local domain.
  • the domain gateway can also import the remote service, R_SVC2, from REMOTEDOM2 with the version range set as 4-6, so that only the client with request version in that range can call R_SVC2 in the local domain.
  • FIG. 3 illustrates an exemplary flow chart for supporting implicit versioning in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • a transactional service provider can dispatch at least one service that is associated with a plurality of service versions.
  • the system can partition one or more applications into one or more application zones, wherein each said application zone is associated with a particular request version of the at least one service.
  • the system allows a service requester in a said application zone to access the at least one service with a service version that is associated with said application zone.
  • version context can be implicitly created by a request initiator according to how it joins a versioned application.
  • FIG 4 shows an illustration of supporting version context in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • a versioned application 400 can be managed using a management hierarchy with multiple levels, such as a domain 401 with multiple groups A-B 41 1 -412.
  • the domain 401 can be configured with a domain request version 410, while group A 41 1 can be configured with a group request version A 413.
  • services A1 -A3 421-423 in group A 41 1 can have a request version that is consistent with the group request version A 413.
  • services B1-B4 431-434 can have a service version number, which is inherited from the domain request version 410.
  • the initial service requester can be implicitly put into a version context when joining a versioned application.
  • the implicit versioning can be hierarchically dependent on how a service requester joins the versioned application.
  • the user can use the version context to control whether the version information may be propagated in the whole lifecycle of a service request, including the subsequent service routing and dispatching.
  • client A 402 can join the versioned application 400 in group A 41 1 , and can be implicitly associated with a version context 432 when it joins group A 41 1 .
  • client B 403 can join the versioned application 400 in group B 412.
  • client B 403 can be implicitly associated with a version context 433 when it joins group B 412.
  • a server 404 can be implicitly versioned, with a version context 434, when the server 404 initiates a new service request at runtime, and a service 405 can be implicitly versioned, with a version context 435, when the service 405 initiates a new request at runtime.
  • implicit versioning can have different exceptions.
  • Tuxedo may not change the request version number in a forwarded request message, e.g. when calling tpforward, which forwards the input message to the specified service.
  • the version context value can be a runtime value, which may only be evaluated, according to the UBB configuration file, when a Tuxedo client, server or service starts a request as an initiator.
  • FIG. 5 shows an illustration of supporting a Tuxedo multi-process (MP) environment, in accordance with an embodiment of the invention.
  • a Tuxedo application can be deployed in a multi-process (MP) environment 500 with multiple machines, e.g. MACH1 501 and MACH2 502.
  • a configuration file can be used to configure the MP environment 500.
  • REQUEST_VERSION, VERSION_POLICY and VERSION_RANGE attributes can be configured in the RESOURCE, GROUPS sections of the UBB configuration file.
  • a group, GRP_Ll is configured the VERSlON_RANGE, REQUEST_VERSlON and VERSION_POLCIY attributes.
  • the VERSION_RANGE, REQUEST_VERSION and VERSION_POLICY of all the servers and services in this group can be determined as inhering from the group configuration.
  • the value of the VERSION_RANGE attributes for the servers, SVR_L1 533 and SVR_L2 541 , in the GRP_L1 are "1-40.”
  • the value of the REQUEST_VERSION attributes for SVR_L1 533 and SVR_L2 541 are 20; while both SVR_L1 533 and SVR_L2 541 can propagate the incoming request version.
  • no versioning attributes are configured for the group, GRP_L2, and the versioning attributes can be determined as inhering from the domain level (as specified in the RESOURCE section).
  • the VERSlON_RANGE of all the servers and/or services in this group is "0- 2000;” the REQUEST_VERSlON of all the servers and/or services in this group is l. Because there is no VERSlON_POLlCY on domain level, all the servers and/or services in this group may use the request version l, instead of propagating the incoming request version.
  • the request version from a workstation client can be determined according to the request version of the group that a related WSL server belongs to. Otherwise, the request version from a workstation client can be determined according to the request version for the domain (i.e. the REQUEST_VERSlON value of WSL group and RESOURCES).
  • workstation clients e.g. /WS-01 51 1 and /WS-01 521
  • handlers such as WSH_01 514 and WSH_02 515, which are managed by the server listeners, WSGRP_L1_1 :WSL 517 and WSGRP_L1_2:WSL 518 respectively.
  • the workstation client, /WS-01 521 can access the service on MACH2 502 via a handler, WSH_01 523, which is managed by the server listener, WSGRP_L1_2:WSL 525.
  • the workstation client, /WS-01 51 1 can implicitly own the same REQUEST_VERSION context value as the WSGRP_L1_1 :WSL 517, which is determined by the request version configuration of WSGRP_L1_1.
  • the implicit version context value for /WS-01 51 1 can also be 4, which means that, when a workstation client in /WS-01 51 1 starts a request, its request version value is 4.
  • the version context number of /WS- 02 512 can be 1, which means that, when a workstation client from /WS-02 512 starts a new request, the request version of the request is l.
  • service request from different Jolt clients on /JC-01 513 or /JC-01 5522 can be handled by different handlers such as JSH_01 516 and JSH_01 524.
  • the request version for service request from a Jolt client e.g. /JC-01 513
  • JGRP_Ll the request version of the group
  • JGRP_L2 the request version of the group
  • JGRP_L2 the request version of the group
  • the request version for service request from a Jolt client based on the request version of the local domain as specified in the RESOURCE section.
  • the native client can get the request version value at runtime from group/domain hierarchy tree, if the native client joins the application with specific group. Otherwise, the native client gets the request version value from the domain level.
  • a native client e.g. requesting the server XASVR_L1 532 on MACH1 501
  • the native client can join the application with the specified group, e.g. XAGRP_Ll.
  • the native client can get the request version value from the group configuration, which is 11, at the run time.
  • the native client if the native client joins the application without a specified group, the native client can get the request version value from group/domain hierarchy tree at the run time.
  • the server/service when a server/service starts a new request, can get the request version value from the group level that the server belongs to, or get the request version value from the domain level when no request version is defined at group level, at runtime.
  • the implicit version can be determined by the REQUEST_VERSlON value of server group and the REQUEST_VERSlON value in the RESOURCES at the domain level. This version can be used as the request version when the server calls other services during server initialization or server termination.
  • the implicit version can be determined by the REQUEST_VERSlON value of server group and the REQUEST_VERSlON value in the RESOURCES at the domain level. It may also be impacted by the VERSlON_POLlCY configuration.
  • This version can be used as the request version when the service calls other services during the service lifetime. If the service propagates the incoming request version, the service uses the incoming request version as the initial request version when calling other services.
  • system servers such as DBBL 535, BBL 536 and 542, BRIDGE 510 and 520, DMGRP:GWT 534, and event brokers
  • TMS server such as TMS_XAGRP_L1 531
  • TLISTEN processes 551 and 561 and other interface processes (such as CLI_L1_1 552, CLI_L1_1 562, CLI_L1_2 553 and CLI_L1_2 563) may not be versioned.
  • TMS server such as TMS_XAGRP_L1 531
  • TLISTEN processes 551 and 561 such as CLI_L1_1 552, CLI_L1_1 562, CLI_L1_2 553 and CLI_L1_2 563
  • These system servers may always use the default version value, which is any.
  • the request version and version range can be set up during conversation connection setup phase (i.e. in tpconnect()). There may not be version check in the conversation procedure on the established connection (i.e. in tpsend()/tprecv()).
  • the system can support the version concept in FORWARD queue, to/from which the clients can send tpenqueue()/tpdequeue() messages.
  • the FORWARD queue can forward the queued message to the service that supports the client request version.
  • VBR version based routing
  • FIG. 6 shows an illustration of supporting version based routing (VBR) in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • a transactional service provider 609 in a transactional middleware machine environment 600 can provide a transactional service A 610 on different transactional servers, e.g. transactional servers A-B 601-602.
  • the transactional server A 601 can provide the service entries of versions l-ll 61 1-612 (i.e. with a version range of 1-2), while the transactional server B 602 can provide the service entries of versions lll-IV 613-614 (i.e. with a version range of 3-4).
  • the transactional service provider 609 can receive service requests from different service requesters, e.g. service requesters A-B 605-606.
  • the transactional service provider 609 can match the requested service name in the service requests received the service requesters A-B 605-606 with the various service entries available.
  • the transactional service provider 609 can locate transactional servers A-B 601 -602 because both transactional servers A-B 601-602 provide the transactional service A 610.
  • the transactional service provider 609 can use a version based routing (VBR) 620 mechanism for making service routing decision, after one or more service entries that match the requested service name in a service request can be found.
  • VBR 620 can perform a numeric comparison of the request version number of a service request received from a service requester, e.g. either the service requester A 605 or the service requester B 606, with the two boundary values of the version range for both transactional server A 601 and transactional server B 602.
  • the service request received from either the service requester A 605 or the service requester B 606 may not explicitly specify the the request version number.
  • the transactional service provider 609 can determine the requested service version associated with each service request. As shown in Figure 6, a service requester A 605 in application zone A 603 is associated with a request version A 615 (e.g. version I), while a service requester B 606 in application zone B 604 is associated with a request version B 616 (e.g. version III).
  • VBR 620 can route the service request received from the service requester A 605 in application zone A 603 to transactional server A 601 , which provides version 1 61 1 of the transactional service A 610. Also, VBR 620 can route the service request received from the service requester B 606 in application zone B 604 to transactional server B 602, which provides version III 613 of the transactional service A 610. Additionally, VBR can return "no entry is found" error to the caller when all of services with matching requested service name are not appropriate for a versioned service request.
  • VBR 620 can be used together with the other routing mechanisms.
  • VBR 620 can be used together with several routing mechanisms, such as DDR (Data Dependent Routing) 621 , TAR (Transaction Affinity Routing) 622, and RAR (Request Affinity Routing) 623.
  • DDR Data Dependent Routing
  • TAR Transaction Affinity Routing
  • RAR Request Affinity Routing
  • VBR 620 can be implemented using functions similar to those for the existing routing algorithms. Tuxedo can choose the services that match all criteria when there are multiple routing mechanisms. Also, the user can implement more complex routing scheme based on their understanding of how these routing mechanisms interact when multiple routing mechanisms are used together.
  • a transactional service provider e.g. Tuxedo
  • Tuxedo can offer various service selection and routing algorithms to the users, so that the users can plan, develop, scale, deploy, and upgrade their applications.
  • Application versioning can be used for avoiding the use of special routing contexts and for meeting various partition requirements.
  • Tuxedo as a part of infrastructure products in Oracle Fusion Middleware family, can support the service versioning concept in the core framework.
  • FIG. 7 shows an exemplary sequence chart for supporting version based routing (VBR) in a distributed transactional middleware machine environment, in accordance with an embodiment of the invention.
  • a transactional middleware machine environment 700 can include several transactional servers (e.g. SERVER1 712, SERVER2 713, and SERVER1 3 714) that can provide various services (e.g. SVC1 , SVC2, and SVC 3) to different clients (e.g. client 71 1 ).
  • one or more configuration files can be used to configure the transactional middleware machine environment 700.
  • the following Listing 5 is an exemplary Tuxedo DUBB configuration file.
  • SVC1 and SVC2 with a version range of "1-2;” and at step 702, SERVER2 713 starts and advertises services, SVC1 , SVC2, and SVC3 with a version range of "3-4.”
  • SERVER3 714 starts and can request a service of SVC2, e.g. via calling "tpcall SVC2.”
  • SERVER3 714 belongs to a group " GRP3," the request version of which is evaluated as "3.”
  • the system can route the service request to SERVER2 713, since the request version, "3,” associated with the service request matches to the version range of SVC2 as advertised by the SERVER2 703.
  • SERVER2 713 can execute SVC2 before SERVER3 704 can advertise services, SVC2 and SVC3 with a version range of "1-3.”
  • the client 711 can initialize a transaction with a service request for SVC1 , e.g. via calling "tpcall SVC1," with the request version "1.”
  • the system can route this service request to SERVER1 712, the version range of which matches the request version "1" of the service request received from the client 711.
  • SERVER1 712 can execute SVC1 , which in turn calls "tpcall SVC3.”
  • the system can route this call to SERVER3 714.
  • SERVER3 714 can execute SVC3, and can place a call to REMOTEDOM1 715 for service, R_SVC1 , e.g.
  • REMOTEDOM1 715 can execute the remote service, R_SVC1.
  • the local domain may recieve service requests from remote domains (e.g. REMOTEDOM1 715 and REMOTEDOM2 716).
  • remote domains e.g. REMOTEDOM1 715 and REMOTEDOM2 716.
  • REMOTEDOM1 715 and REMOTEDOM2 716 both initiate a service request operation of "tpcall SVC1," at steps 709 and 710 respectively.
  • the service request received from REMOTEDOM1 715 which has an original request version of "2" can be propagated.
  • the system can route this service request to SERVER1 712. Then, the system can perform the steps 706-708 for providing the requested service toa service requester in REMOTEDOM1 715.
  • the service request received from REMOTEDOM1 716 which has an original request version of "6”
  • the system can route this service request to SERVER2 703 and execute the requeseted service, SVC1 , at step 724.
  • FIG. 8 illustrates an exemplary flow chart for supporting version based routing (VBR) in a transactional middleware machine environment, in accordance with an embodiment of the invention.
  • a transactional service provider can dispatch at least one service using a plurality of service entries with different service versions.
  • the transactional service provider can determine whether a service version associated with a service entry matches a requested service version associated with a service request received from a service requester.
  • the transactional service provider allows the service requester to access the service entry that matches the requested service version associated with the service request.
  • Figure 9 illustrates a functional block diagram of a transactional service provider 900 configured in accordance with the principles of the invention as described above.
  • the functional blocks of the device may be implemented by hardware, software, or a combination of hardware and software to carry out the principles of the invention. It is understood by persons of skill in the art that the functional blocks described in Figure 9 may be combined or separated into sub-blocks to implement the principles of the invention as described above. Therefore, the description herein may support any possible combination or separation or further definition of the functional blocks described herein.
  • an exemplary embodiment of the invention provides a transactional service provider 900.
  • the transactional service provider 900 may be used in the system for supporting application versioning in a transactional middleware machine environment as described above.
  • the transactional service provider 900 may comprise a dispatching unit 910, a matching unit 920 and an accessing unit 930.
  • the dispatching unit 910 may operate to dispatch at least one service using a plurality of service entries with different service versions.
  • the matching unit 920 may operate to determine whether a service version associated with a service entry matches a requested service version associated with a service request received from a service requester.
  • the matching unit 920 may operate to match a service name of a service entry with a requested service name in the service request received from the service requester.
  • the accessing unit 930 may operate to allow the service requester to access the service entry that matches the requested service version associated with the service request.
  • the transactional service provider 900 may further comprise a returning unit 940 that operates to return an error message to the service requester when all service entries with matching name can not match the requested service version.
  • the transactional service provider 900 may further comprise a partitioner 950 that operates to partition one or more applications into one or more application zones. Each of the application zone is associated with a particular request version of the at least one service.
  • the transactional service provider 900 may further comprise a comparing unit 960 that operates to perform numeric comparison between the requested service version number and both boundary values of the version range.
  • the transactional service provider 900 may further comprise a version determining unit 970 that operates to determine the requested service version associated with the service request.
  • the transactional service provider 900 may further comprise a configuration providing unit 980 that operates to use at least one configuration file to provide the transactional service application configuration.
  • the transactional service provider 900 may further comprise a configuration changing unit 990 that operates to use a management interface to change the transactional service application configuration at runtime
  • FIG. 10 illustrates an exemplary block diagram of transactional service provider 1 10, in accordance with an embodiment of the invention.
  • Transactional service provider 1 10 includes a dispatcher 1010, a determination module 1020 and an access controller 1030.
  • Transactional service provider 1 10 is configured to receive a service request from service requestor 1060.
  • Dispatcher 1010 dispatches at least one service 1040 using a plurality of service entries 1050 with different service versions.
  • Determination module 1020 determines whether a service version associated with a service entry 1040 matches a requested service version associated with a service request received from service requester 1060.
  • Access controller 1030 allows service requester 1060 to access service entry 1050 that matches the requested service version associated with the service request.
  • the present invention may be conveniently implemented using one or more conventional general purpose or specialized digital computer, computing device, machine, or microprocessor, including one or more processors, memory and/or computer readable storage media programmed according to the teachings of the present disclosure.
  • Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.
  • the present invention includes a computer program product which is a storage medium or computer readable medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention.
  • the storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un système et un procédé peuvent prendre en charge une gestion de service dans un environnement de machine à logiciel intermédiaire transactionnelle. Un fournisseur de service transactionnel peut distribuer au moins un service en utilisant une pluralité d'entrées de service avec différentes versions de service, et déterminer si une version de service associée à une entrée de service correspond à une version de service demandée associée à une demande de service reçue d'un demandeur de service. Ensuite, le fournisseur de service transactionnel peut permettre au demandeur de service d'accéder à l'entrée de service qui correspond à la version de service demandée associée à la demande de service.
PCT/US2013/045723 2012-06-13 2013-06-13 Système et procédé de prise en charge d'acheminement basé sur une version dans un environnement de machine à logiciel intermédiaire transactionnelle WO2013188697A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201380024093.5A CN104272259B (zh) 2012-06-13 2013-06-13 用于在事务中间件机器环境中支持基于版本的路由的系统和方法
KR1020147033885A KR102103493B1 (ko) 2012-06-13 2013-06-13 트랜잭셔널 미들웨어 기계 환경에서 버전 기반 라우팅을 지원하는 시스템 및 방법

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201261659307P 2012-06-13 2012-06-13
US61/659,307 2012-06-13
US13/915,482 US10291486B2 (en) 2012-06-13 2013-06-11 System and method for supporting implicit versioning in a transactional middleware machine environment
US13/915,495 US10263854B2 (en) 2012-06-13 2013-06-11 System and method for supporting version based routing in a transactional middleware machine environment
US13/915,482 2013-06-11
US13/915,495 2013-06-11

Publications (1)

Publication Number Publication Date
WO2013188697A1 true WO2013188697A1 (fr) 2013-12-19

Family

ID=48699319

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/US2013/045717 WO2013188691A1 (fr) 2012-06-13 2013-06-13 Système et procédé de prise en charge de contrôle de version implicite dans un environnement de machine à logiciel médiateur transactionnel
PCT/US2013/045723 WO2013188697A1 (fr) 2012-06-13 2013-06-13 Système et procédé de prise en charge d'acheminement basé sur une version dans un environnement de machine à logiciel intermédiaire transactionnelle

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/US2013/045717 WO2013188691A1 (fr) 2012-06-13 2013-06-13 Système et procédé de prise en charge de contrôle de version implicite dans un environnement de machine à logiciel médiateur transactionnel

Country Status (1)

Country Link
WO (2) WO2013188691A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106294377A (zh) * 2015-05-15 2017-01-04 北京大学 一种划版方法及装置
CN111447120B (zh) * 2020-03-30 2021-08-20 中国建设银行股份有限公司 基于Tuxedo的压力测试方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060155857A1 (en) * 2005-01-06 2006-07-13 Oracle International Corporation Deterministic session state management within a global cache array
US20060174252A1 (en) * 2004-11-18 2006-08-03 Besbris David G Service versioning
US20060294038A1 (en) * 2003-07-03 2006-12-28 Elena Grossfeld Method and system for managing data transaction requests
WO2007044230A2 (fr) * 2005-10-07 2007-04-19 Citrix Systems, Inc. Procedes de selection entre un nombre predetermine de procedes d'execution pour un programme d'application
US20090296711A1 (en) * 2008-05-30 2009-12-03 International Business Machines Corporation Affinity-based transaction processing

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060294038A1 (en) * 2003-07-03 2006-12-28 Elena Grossfeld Method and system for managing data transaction requests
US20060174252A1 (en) * 2004-11-18 2006-08-03 Besbris David G Service versioning
US20060155857A1 (en) * 2005-01-06 2006-07-13 Oracle International Corporation Deterministic session state management within a global cache array
WO2007044230A2 (fr) * 2005-10-07 2007-04-19 Citrix Systems, Inc. Procedes de selection entre un nombre predetermine de procedes d'execution pour un programme d'application
US20090296711A1 (en) * 2008-05-30 2009-12-03 International Business Machines Corporation Affinity-based transaction processing

Also Published As

Publication number Publication date
WO2013188691A1 (fr) 2013-12-19

Similar Documents

Publication Publication Date Title
US10263854B2 (en) System and method for supporting version based routing in a transactional middleware machine environment
US10216545B2 (en) Method and system for modeling and analyzing computing resource requirements of software applications in a shared and distributed computing environment
US11374833B2 (en) System and method for providing a service management engine for use with a cloud computing environment
US8010651B2 (en) Executing programs based on user-specified constraints
US9767312B2 (en) System and method for integrating a cloud platform environment with an application server or other environment
US9357034B2 (en) System and method for orchestration of services for use with a cloud computing environment
US9201639B2 (en) System and method for service definition packages for use with a cloud computing environment
US9424024B2 (en) System and method for elasticity management of services with a cloud computing environment
US9323517B2 (en) System and method for dynamic modification of service definition packages with a cloud computing environment
US20220078230A1 (en) System and method for dynamic auto-scaling based on roles
US20190097895A1 (en) System and method for dynamic auto-scaling based on roles
US11645109B2 (en) Managing failures in edge computing environments
WO2013188697A1 (fr) Système et procédé de prise en charge d'acheminement basé sur une version dans un environnement de machine à logiciel intermédiaire transactionnelle
US12009999B2 (en) System and method for providing a service management engine for use with a cloud computing environment
US20240012631A1 (en) Remediation engine for updating desired state of inventory data to be replicated across multiple software-defined data centers

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: 13734551

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20147033885

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13734551

Country of ref document: EP

Kind code of ref document: A1