WO2008045890A2 - Service proxy - Google Patents

Service proxy Download PDF

Info

Publication number
WO2008045890A2
WO2008045890A2 PCT/US2007/080841 US2007080841W WO2008045890A2 WO 2008045890 A2 WO2008045890 A2 WO 2008045890A2 US 2007080841 W US2007080841 W US 2007080841W WO 2008045890 A2 WO2008045890 A2 WO 2008045890A2
Authority
WO
WIPO (PCT)
Prior art keywords
destination
message
service proxy
service
proxy instance
Prior art date
Application number
PCT/US2007/080841
Other languages
French (fr)
Other versions
WO2008045890A3 (en
Inventor
Gregory J. Simpson
Gregory M. Jewell
Original Assignee
Raytheon Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Raytheon Company filed Critical Raytheon Company
Publication of WO2008045890A2 publication Critical patent/WO2008045890A2/en
Publication of WO2008045890A3 publication Critical patent/WO2008045890A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/59Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable

Definitions

  • This invention relates generally to the field of programming computers, and more specifically to a method of emulating a service in a computer infrastructure.
  • a collection of one or more computers and their associated software is commonly called a computer infrastructure.
  • Each computer in the computer infrastructure is generally operable to communicate with each other computer in the infrastructure.
  • Computer infrastructures having a service oriented architecture ("SOA") are increasingly being developed.
  • a computer infrastructure having a SOA has core functions that are partitioned into a plurality of loosely coupled functional core services.
  • Such functional core services which are hereinafter referred to as services, are representations of one or more functions performed by the SOA computer infrastructure. For example, one service in a SOA computer infrastructure may perform a printing function, while another service may perform a file storage function.
  • a service may be executed on one or more computer of a SOA computer infrastructure in accordance with computer readable instructions embodied in software or firmware.
  • a service may be embodied in Java computer code and executed on a single computer of a SOA computer infrastructure.
  • a service may be embodied in C++ computer code that is executed in a distributed manner on three computers of a SOA computer infrastructure,
  • a SOA computer infrastructure generally includes a message-oriented middleware (“MOM”) application that implements messaging services within the infrastructure.
  • the messaging services allow elements of the SOA computer infrastructure, such as services, to exchange information by exchanging messages between destinations.
  • An example of a MOM application is a Java Messaging Service (“JMS").
  • a message may include information such as data, requests, commands, and/or instructions.
  • a message may also include message identification and routing information, commonly collectively referred to as a header, For example, a header may include a "reply-to" field that specifies where a response to the message should be delivered.
  • a destination is a logical point or construct that serves as a relay point during a message exchange; the destination provides a logical place for two or more elements (e.g services) of a SOA infrastructure to exchange a message.
  • a service may publish a message to a destination or monitor the destination for receipt of a message. For example, a first service may publish a message to the destination, and a second service may monitor the destination in order to receive the message.
  • a given service may be operable to communicate with a plurality of destinations at a give time.
  • An example of SOA computer infrastructure is a order processing system that allows a user to purchase an airline ticket.
  • the order processing system includes a plurality of computers, some of which are located in different physical locations, and a plurality of services, which perform specific functions required by the order processing system.
  • the order processing system may include a query service, which is used to query an airline's database for available flights, and a purchasing service, which is used to purchase a ticket from the airline.
  • the order processing system may include a financial transaction processing service, which may be used to process a user's credit card, and an itinerary service, which may be used to generate a user's flight itinerary.
  • Each service may be executed on one or a plurality of the order processing system computers
  • SOA computer infrastructures are typically developed incrementally - the framework of the infrastructure is typically developed before the services. Individual services are then added to the framework as they become available. Even if a service is available, it may not be completely functional due to it being incomplete and/or defective.
  • the service proxy and applications thereof herein disclosed advance the art and may overcome at least one of the problems articulated above by providing a service proxy that may be used to emulate a service in a computer infrastructure
  • a method of emulating a service in a computer infrastructure includes the steps of providing a service proxy instance as a stand-in for the service and running the service proxy instance on a computer accessible to the computer infrastructure.
  • the service proxy instance is configured at run time in accordance with a configuration file, wherein the configuration file includes an operating mode specification.
  • the service proxy instance communicates with at least one destination in adherence to the operating mode specification and a communication protocol.
  • a computer system for emulating a service includes a processing unit, a memory storage device coupled to the processing unit, an input device coupled to the processing unit, and an output device coupled to the processing unit.
  • the processing unit is operative to run a service proxy instance and configure the service proxy instance at run time in accordance with a configuration file, wherein the configuration file includes an operating mode specification. Additionally, the processing unit is operative to enable the service proxy instance to communicate with at least one destination in adherence to the operating mode specification and a communication protocol.
  • a software product includes instructions, stored on computer-readable media, wherein the instructions, when executed by a computer, perform the steps of emulating a service in a computer infrastructure.
  • the instructions perform the steps of running a service proxy instance and configuring the service proxy instance at ran time in accordance with a configuration file, wherein the configuration file includes an operating mode specification.
  • the instructions also perform the step of communicating between the service proxy instance and at least one destination in adherence to the operating mode specification and a communication protocol.
  • FIG. 1 is block diagram of a SOA computer infrastructure having a plurality of services, according to an embodiment
  • FIG. 2 is block diagram of a SOA computer infrastructure having a service proxy, according to an embodiment.
  • FIG. 3 is a block diagram illustrating a subset of a SOA computer infrastructure including a plurality of service proxy instances, according to an embodiment.
  • FIG. 4 is a flowchart of a method foi operating a service proxy in an audit mode, according to an embodiment.
  • FIG. 5 is a flowchart of a method for operating a service proxy in a pub- sub mode, according to an embodiment.
  • FIG 6 is a flowchart of a method for operating a service proxy in an interceptor mode, according to an embodiment.
  • FIG. 7 is a flowchart of a method for operating a service proxy in a routing mode, according to an embodiment.
  • FIG 8 schematically illustrates a computer system, according to an embodiment.
  • FIG 1 is block diagram of SOA computer infrastructure 100 having computers 102, 104, and 106
  • Computers 102 and 104 are connected via communications network 122; computers 102 and 106 are connected via communications network 124; and computers 104 and 106 are connected via communications network 126.
  • SOA computer infrastructure 100 is illustrated as having three computers, other embodiments of SOA computer infrastructure 100 may have a different quantity of computers.
  • Computers 102, 104, and 106 may be any general purpose or specialty computeis.
  • computers 102, 104, and/or 106 may be personal computers or servers.
  • computers 102, 104, and/or 106 may each represent a cluster of a plurality of computeis
  • Communication links 122, 124, and 126 may be any suitable communication links to enable computers 102, 104, and 106 to communicate with each other.
  • communication links 122, 124, and/or 126 may be wired, optical, or wireless Ethernet links.
  • Computeis 102, 104, and/oi 106 may each individually host one oi more services; computers 102, 104, and/or 106 may each also jointly host one oi more services with one or more computers.
  • computer 102 is illustrated as individually hosting services 108, 110, and 112.
  • Computer 104 is illustrated as individually hosting services 114, 116, and 118.
  • Computers 104 and 106 jointly host service 120.
  • a service represents one or more functions performed by the computer infrastructure.
  • SOA computer infrastructure 100 is illustrated as having a total of seven services distributed among three computers, other embodiments of SOA computer infrastructure 100 may have other quantities of services, and each computer may host any quantity of services.
  • the services may communicate using a MOM application
  • the services may communicate using a protocol that adheres to a Java Messaging Service (“JMS”) specification.
  • JMS Java Messaging Service
  • the framework of a SOA computer network is often developed before one or more of the services.
  • computers 102, 104, and 106 as well as communication links 122, 124, and 126 may be developed and/or integrated together before any services in SOA computer infrastructure 100 are available.
  • one or more services of the infrastructure may be emulated using service proxy 200
  • Service proxy 200 may be used to emulate a missing, defective, or incomplete service.
  • FIG. 2 illustrates SOA computer infrastructure 100 having service 108 substituted with service proxy 200; service proxy 200 emulates service 108 Stated in another manner, service proxy 200 operates as a stand-in for service 108 Service 108 may be missing, defective, or incomplete.
  • service proxy 200 is illustrated as emulating service 108 in computer 102, service proxy 200 may be used to emulate other services
  • service proxy 200 may be used in other computers and in other SOA computer infrastructures.
  • Service proxy 200 is a computer application embodied by computer readable instructions or computer code that can be executed on any of the computers of SOA computer infrastructure 100 to emulate a service.
  • the computer code may be embodied as a software product stored on a computer readable media, such as a magnetic or optical disk.
  • multiple instantiations of the routines of the software product may be executed substantially concurrently.
  • Service proxy 200 may be written in computer programming code adhering to a Java specification, such as Sun Microsystems Java 1.4.2 SDK
  • a plurality of service proxies 200 may be executed at a given time.
  • Each of the plurality of service proxies 200 is referred to as an instance of service proxy 200
  • two instances of service proxy 200 may be used to emulate two respective services of SOA computer infrastructure 100
  • Service proxy 200 is operable to communicate with destinations in SOA computer infrastructure 100 by sending and/or receiving messages using a MOM application.
  • service proxy 200 may be operable to exchange messages with destinations using a MOM communication protocol adhering to a JMS specification.
  • the JMS specification may include the implementations provided by Sonic Software's SonicMQ, BEA's Weblogic, and/or JBoss.
  • Service proxy 200 may be executed on a computer other than the computer that the service being emulated is expected to executed on.
  • Service proxy 200 may be executed on any computer accessible to SOA computer infrastructure 100
  • Service proxy 200 is operable according to a plurality of operating modes, including an audit operating mode, an injector operating mode, a pub-sub operating mode, an interceptor mode, and a routing mode, each of which are discussed in more detail below.
  • Service proxy 200 is configured at run time using a configuration file.
  • the configuration file instructs service proxy 200 how it is to operate and communicate with destinations, and the configuration file includes an operating mode specification.
  • the configuration file is embodied by an extensible markup language file.
  • each of a plurality of instances of service proxy 200 are configured via a respective configuration file. In other embodiments, each of a plurality of instances of service proxy 200 are configured via one common configuration file [0037]
  • One service proxy 200 instance may operate along side other service proxy 200 instances, as may noted by studying FIG. 3, which is a block diagram illustrating subset 300 of a SOA computer infrastructure including a plurality of service proxy 200 instances.
  • Subset 300 is illustrated as including service proxies 302, 306, and 308, each of which are emulating a service
  • Subset 300 also includes service 304, which is a fully functional service, and destinations 310, 312, 314, 316.
  • subset 300 is illustrated as having three instances of service proxy 200, one instance of a fully functional service, and four destinations, subset 300 can have any quantity of each of these elements.
  • FIG. 3 illustrates arrow 318 pointing from service proxy instance 302 to destination 310; arrow 318 denotes a message being sent from service proxy instance 302 to destination 310
  • an instance of service proxy 200 can coexist with one or more other instances of service proxy 200 in a common SOA computer infrastructure.
  • one or more instances of service proxy 200 can coexist with one or more fully functional services in a common SOA computer infrastructure
  • Each instance of service proxy 200 in a common SOA computer infrastructure may be configured to operate in a different operating mode
  • service proxy instance 302 may be configured to operate in the injector mode
  • service proxy instance 306 may be configured to operate in the pub-sub mode
  • service proxy instance 308 may be configured to operate in the routing mode.
  • Service proxy 200 may be multi-threaded, which may enable it to simultaneously communicate with a plurality of destinations.
  • service proxy instance 306 is illustrated in FIG. 3 as simultaneously communicating with destinations 312, 314, and 316
  • service proxy instance 308 is illustrated as simultaneously communicating with destinations 312, 314, and 316.
  • a given destination may communicate with a plurality of service proxy 200 instances
  • destination 312 is illustrated as communicating with service proxy instances 306 and 308 as well as service 304.
  • Service proxy 200 may be configured such that it will continue to operate until it is manually interrupted or until it receives a kill message.
  • a kill message may be sent to one or more service proxy 200 instances instructing each instance to terminate.
  • a kill message may be sent to all service proxy 200 instances in a SOA computer infrastructure instructing each instance to terminate.
  • the injector operating mode which is discussed in below, may be used to send a kill message
  • service proxy 200 can be operated in the audit mode, an example of which is embodied by method 400 of FIG. 4.
  • Method 400 begins with step 402, wherein service proxy 200 monitors at least one destination for receipt of a message A message received by a destination will hereinafter be referred to as a received message.
  • service proxy 200 logs such receipt in a suitable manner in step 404
  • the receipt may be logged in a database housed in SOA computer infrastructure 100; alternately, the receipt may logged in a database external to SOA computer infrastructure 100.
  • Method 400 proceeds from step 404 back to step 402; consequently, method 400 continues to operate until it is manually interrupted or until it detects a kill message on the first destination
  • Service proxy 200 can also be operated in the injector mode, as specified above.
  • service proxy 200 publishes at least one predetermined message to at least one destination
  • the predetermined message may be housed in a message file, which may be identified in the configuration file
  • a common message file houses a plurality of predetermined messages; in other embodiments, each of a plurality of predetermined messages is housed in a respective message file.
  • An example of a use of the injector mode is to send a kill message to one or more service proxy 200 instances As discussed above, a service proxy 200 instance will terminate upon receipt of a kill message by a destination that it is monitoring.
  • Service proxy 200 can be further operated in the pub-sub mode, as discussed above.
  • An example of the pub-sub mode is embodied by method 500, which is illustrated in FIG 5.
  • Method 500 begins with step 502, wherein service proxy 200 monitors at least one first destination for receipt of a received message. Upon the first destination's receipt of the received message, service proxy 200 determines in step 504 whether it is to publish the received message to at least one second destination, or if alternately, service proxy 200 is to publish a predetermined message to the second destination. In an embodiment, service proxy 200 compares the received message to processing information housed in the configuration file in order to execute decision 504.
  • the predetermined message may be housed in a message file, which may be identified in the configuration file.
  • a common message file houses a plurality of predetermined messages; in other embodiments, each of a plurality of predetermined message is housed in a respective message file.
  • Steps 506 and 508 each proceed to step 510, wherein the message placed in the queue is published to at least one second destination.
  • service proxy 200 may wait a configurable time delay after executing steps 506 or 508 and before executing step 510.
  • Method 500 proceeds from step 510 back to step 502; consequently, method 500 continues to operate until it is manually interrupted or until it detects a kill message on the first destination.
  • service proxy 200 may publish a message to a destination housed in the "reply-to" field and/or to a predetermined destination included in the configuration file. Stated in another manner, the second destination may be specified by the "reply-to" field of the message or by the configuration file.
  • service proxy 200 can be operated in the interceptor mode.
  • the interceptor mode is similar to the pub-sub mode, however, the inceptor mode further includes an additional graphical user interface ("GUI") which may be used to control execution of service proxy 200.
  • GUI graphical user interface
  • the interceptor mode may be embodied by method 600 which is illustrated in FIG. 6.
  • Method 600 begins with step 602, wherein service proxy 200 opens a GUI indicating that a service proxy 200 instance has been launched.
  • service proxy 200 monitors at least one first destination for receipt of a received message.
  • service proxy 200 determines in step 606 whether it is to publish the received message to at least one second destination, or if alternately, service proxy 200 is to publish a predetermined message to the second destination.
  • service proxy 200 compares the received message to processing information housed in the configuration file in order to execute decision 606.
  • service proxy 200 places the received message in a queue in step 608.
  • the queue may be located internal or external to SOA computer infrastructure 100.
  • service proxy 200 places the predetermined message in the queue in step 610
  • the predetermined message may be housed in a message file, which may be identified in the configuration file.
  • a common message file houses a plurality of predetermined messages; in other embodiments, each of a plurality of predetermined messages is housed in a respective message file
  • Steps 608 and 610 proceed to step 612, wherein a representation of the received message in displayed in the GUI.
  • service proxy 200 waits for a request to proceed. Such waiting period may be used to allow a user to pause operation of service proxy 200, which may be useful during debugging and/or demonstrating SOA computer infrastructure 100.
  • a user may provide service proxy 200 a request to proceed via the GUI, such as by selecting an icon on the GUI.
  • step 616 the message placed in the queue is published to at least one second destination.
  • Method 600 proceeds from step 616 back to step 602; consequently, method 600 continues to operate until it is manually interrupted or until it detects a kill message on the first destination.
  • service proxy 200 may publish a message to a destination housed in the "reply-to" field and/or to a predetermined destination included in the configuration file Stated in another manner, the second destination may be specified by the "reply-to" field of the message or by the configuration file
  • service proxy 200 may be operated in the routing mode.
  • the routing mode is similar to the pub-sub mode, however, a user may be able to select between at least one primary destination or at least one alternate destination to publish a message to in the routing mode.
  • the primary destination is a default destination that service proxy 200 will publish one or more messages to;
  • the alternate destination is a destination that service proxy 200 will publish one or more messages to as an alternate to the primary destination.
  • the routing mode specification in the configuration file may contain solely one or more primary destinations; alternately, the configuration file may contain both primary and alternate destinations.
  • FIG. 7 is a flowchart of method 700 for operating service proxy 200 in the routing mode.
  • Method 700 begins with step 702, wherein service proxy 200 monitors at least one first destination for receipt of a received message.
  • step 704 a GUI is opened, and a representation of the received message is displayed in the GUI in step 706
  • Service proxy 200 determines in step 708 whether it is to publish the received message to at least one second destination, or if alternately, service proxy 200 is to publish a predetermined message to the second destination.
  • service proxy 200 compares the received message to processing information housed in the configuration file in order to execute decision 708.
  • service proxy 200 places the received message in a queue in step 710
  • the queue may be located internal or external to SOA computer infrastructure 100.
  • service proxy 200 places the predetermined message in the queue in step 712.
  • the predetermined message may be housed in a message file, which may be identified in the configuration file.
  • a common message file houses a plurality of predetermined messages; in other embodiments, each predetermined message is housed in a respective message file
  • service proxy 200 determines whether the configuration file includes any applicable alternate destinations in addition to the primary destination. If decision 714 determines that there are no applicable alternate destinations, service proxy 200 is to publish the message placed in the queue solely to the primary destination Accordingly, a confirmation prompt, which informs the user that solely the primary destination is available, is displayed in the GUI step 716.
  • a user may direct that service proxy 200 publish the message placed in the queue to either each primary destination or each alternate destination Accordingly, primary and alternate prompts are displayed in the GUI in step 718 to allow the user to choose between the primary and alternate destination.
  • Steps 716 and 718 proceed to step 720, wherein service proxy 200 receives a user prompt in response to the one or more prompts displayed in step 716 or 718 If there are no applicable alternate destinations in the configuration file, the user prompt must be a confirmation prompt In the event there are applicable alternate destinations in the configuration file, the user prompt may consist of a primary destination prompt or a secondary destination prompt.
  • service proxy 200 publishes the message placed in the queue to the primary destination in step 722. If the user prompt consists of an alternate destination prompt, the service proxy 200 publishes the message placed in the queue to the alternate destination in step 724.
  • Method 700 proceeds from steps 722 or 724 back to step 702; consequently, method 700 continues to operate until it is manually interrupted or until it detects a kill message on a destination that it is monitoring.
  • Service proxy 200 may be executed on computer system 800 of FIG 8
  • Computer system 800 includes processing unit 802, input device 804, memory storage device 806, and output device 808.
  • Processing unit 802 executes instructions and processes data received by computer system 800.
  • Processing unit 802 may be a general purpose or custom designed central processing unit, such as a microprocessor. Additionally, processing unit 802 may represent a plurality of central processing units. Processing unit 802 is operable to operate service proxy 200 in the audit, injector, pub-sub, interceptor, and routing modes.
  • Input device 804 is coupled to processing unit 802.
  • Input device 804 provides a means for inputting data or instructions, such as a configuration file and/or computer code embodying service proxy 200, to processing unit 802.
  • Input device 804 may be any acceptable device that allows data to be transferred to computer system 800.
  • input device 804 may be a keyboard, a pointing device, a network interface device, a modem, a magnetic disk or tape drive, and/or an optical drive.
  • input device 804 obtains a configuration file and/or an embodiment of the service proxy from computer readable media 810.
  • Memory storage device 806 is coupled to processing unit 802
  • Memory storage device 806 provides a means for processing unit 802 to store data or instructions for later use.
  • Memory storage device 806 may consist or any one or more apparatuses operable to store data for use by processing unit 802
  • memory storage device 806 may consist of random access memory.
  • Output device 808 is coupled to processing unit 802.
  • Output device 808 provides a means for processing unit 802 to output data
  • Output device 808 may be any acceptable device that allows data to be transferred out of computer system 800.
  • output device 808 may be a monitor, a printer, a network interface device, a modem, a magnetic disk or tape drive, and/or an optical drive.

Abstract

A method of emulating a service in a computer infrastructure includes the steps of providing a service proxy instance as a stand-in for the service and running the service proxy instance on a computer accessible to the computer infrastructure. The service proxy instance is configured at a run time in accordance with a configuration file, wherein the configuration file includes an operating mode specification. The service proxy instance communicates with at least one destination in adherence to the operating mode specification and a communicaiton protocol.

Description

SERVICE PROXY FIELD
[0001] This invention relates generally to the field of programming computers, and more specifically to a method of emulating a service in a computer infrastructure.
BACKGROUND
[0002] A collection of one or more computers and their associated software is commonly called a computer infrastructure. Each computer in the computer infrastructure is generally operable to communicate with each other computer in the infrastructure. Computer infrastructures having a service oriented architecture ("SOA") are increasingly being developed. A computer infrastructure having a SOA has core functions that are partitioned into a plurality of loosely coupled functional core services. Such functional core services, which are hereinafter referred to as services, are representations of one or more functions performed by the SOA computer infrastructure. For example, one service in a SOA computer infrastructure may perform a printing function, while another service may perform a file storage function.
[0003] A service may be executed on one or more computer of a SOA computer infrastructure in accordance with computer readable instructions embodied in software or firmware. For example, a service may be embodied in Java computer code and executed on a single computer of a SOA computer infrastructure. As another example, a service may be embodied in C++ computer code that is executed in a distributed manner on three computers of a SOA computer infrastructure,
[0004] A SOA computer infrastructure generally includes a message-oriented middleware ("MOM") application that implements messaging services within the infrastructure. The messaging services allow elements of the SOA computer infrastructure, such as services, to exchange information by exchanging messages between destinations. An example of a MOM application is a Java Messaging Service ("JMS").
[0005] A message may include information such as data, requests, commands, and/or instructions. A message may also include message identification and routing information, commonly collectively referred to as a header, For example, a header may include a "reply-to" field that specifies where a response to the message should be delivered. [0006] As stated above, messages are generally exchanged between destinations. A destination is a logical point or construct that serves as a relay point during a message exchange; the destination provides a logical place for two or more elements (e.g services) of a SOA infrastructure to exchange a message. A service may publish a message to a destination or monitor the destination for receipt of a message. For example, a first service may publish a message to the destination, and a second service may monitor the destination in order to receive the message. A given service may be operable to communicate with a plurality of destinations at a give time.
[0007] An example of SOA computer infrastructure is a order processing system that allows a user to purchase an airline ticket. The order processing system includes a plurality of computers, some of which are located in different physical locations, and a plurality of services, which perform specific functions required by the order processing system. For example, the order processing system may include a query service, which is used to query an airline's database for available flights, and a purchasing service, which is used to purchase a ticket from the airline. As additional examples, the order processing system may include a financial transaction processing service, which may be used to process a user's credit card, and an itinerary service, which may be used to generate a user's flight itinerary. Each service may be executed on one or a plurality of the order processing system computers
[0008] SOA computer infrastructures are typically developed incrementally - the framework of the infrastructure is typically developed before the services. Individual services are then added to the framework as they become available. Even if a service is available, it may not be completely functional due to it being incomplete and/or defective.
[0009] It is problematic that SOA computer infrastructures frequently cannot be fully tested during their development due to one or more services being unavailable or not fully functional. Consequently, the service's interaction with the infrastructure and/or other services may not be tested Unavailability or lack of functionality of a service may therefore result in increased development time, development costs, and/or development complexity of a SOA computer infrastructure. Furthermore, a service's unavailability or lack of functionality may impede demonstration of the SOA computer infrastructure to an interested party. For example, a lack of one or more services may prevent a demonstration of a SOA computer infrastructure to a prospective purchaser of the infrastructure. [0010] Accordingly, what is needed is a service proxy that can be used to emulate one or more missing and/or not fully functional services in a computer infrastructure during its development.
BRIEF SUMMARY
[0011] The service proxy and applications thereof herein disclosed advance the art and may overcome at least one of the problems articulated above by providing a service proxy that may be used to emulate a service in a computer infrastructure
[0012] In particular, and by way of example only, a method of emulating a service in a computer infrastructure includes the steps of providing a service proxy instance as a stand-in for the service and running the service proxy instance on a computer accessible to the computer infrastructure. The service proxy instance is configured at run time in accordance with a configuration file, wherein the configuration file includes an operating mode specification. The service proxy instance communicates with at least one destination in adherence to the operating mode specification and a communication protocol.
[0013] According to another embodiment, a computer system for emulating a service includes a processing unit, a memory storage device coupled to the processing unit, an input device coupled to the processing unit, and an output device coupled to the processing unit. The processing unit is operative to run a service proxy instance and configure the service proxy instance at run time in accordance with a configuration file, wherein the configuration file includes an operating mode specification. Additionally, the processing unit is operative to enable the service proxy instance to communicate with at least one destination in adherence to the operating mode specification and a communication protocol.
[0014] In yet another embodiment, a software product includes instructions, stored on computer-readable media, wherein the instructions, when executed by a computer, perform the steps of emulating a service in a computer infrastructure. The instructions perform the steps of running a service proxy instance and configuring the service proxy instance at ran time in accordance with a configuration file, wherein the configuration file includes an operating mode specification. The instructions also perform the step of communicating between the service proxy instance and at least one destination in adherence to the operating mode specification and a communication protocol. BRIEF DESCRIPTION OF THE DRAWINGS
[0015] FIG. 1 is block diagram of a SOA computer infrastructure having a plurality of services, according to an embodiment
[0016] FIG. 2 is block diagram of a SOA computer infrastructure having a service proxy, according to an embodiment.
[0017] FIG. 3 is a block diagram illustrating a subset of a SOA computer infrastructure including a plurality of service proxy instances, according to an embodiment.
[0018] FIG. 4 is a flowchart of a method foi operating a service proxy in an audit mode, according to an embodiment.
[0019] FIG. 5 is a flowchart of a method for operating a service proxy in a pub- sub mode, according to an embodiment.
[0020] FIG 6 is a flowchart of a method for operating a service proxy in an interceptor mode, according to an embodiment.
[0021] FIG. 7 is a flowchart of a method for operating a service proxy in a routing mode, according to an embodiment.
[0022] FIG 8 schematically illustrates a computer system, according to an embodiment.
DETAILED DESCRIPTION OF THE INVENTION
[0023] The present teaching is by way of example only, not by way of limitation The concepts herein are not limited to use or application with a specific type service proxy. Thus, although the instrumentalities described herein are for the convenience of explanation, shown and described with respect to exemplary embodiments, it will be appreciated that the principles herein may be applied equally in other types of service proxies To avoid unnecessary repetition in the discussion, the respective figures of the drawings retain like numbering of identical features.
[0024] FIG 1 is block diagram of SOA computer infrastructure 100 having computers 102, 104, and 106 Computers 102 and 104 are connected via communications network 122; computers 102 and 106 are connected via communications network 124; and computers 104 and 106 are connected via communications network 126. Although SOA computer infrastructure 100 is illustrated as having three computers, other embodiments of SOA computer infrastructure 100 may have a different quantity of computers. [0025] Computers 102, 104, and 106 may be any general purpose or specialty computeis. For example, computers 102, 104, and/or 106 may be personal computers or servers. Furthermore, computers 102, 104, and/or 106 may each represent a cluster of a plurality of computeis
[0026] Communication links 122, 124, and 126 may be any suitable communication links to enable computers 102, 104, and 106 to communicate with each other. For example, communication links 122, 124, and/or 126 may be wired, optical, or wireless Ethernet links.
[0027] Computeis 102, 104, and/oi 106 may each individually host one oi more services; computers 102, 104, and/or 106 may each also jointly host one oi more services with one or more computers. For example, computer 102 is illustrated as individually hosting services 108, 110, and 112. Computer 104 is illustrated as individually hosting services 114, 116, and 118. Computers 104 and 106 jointly host service 120. As stated above, a service represents one or more functions performed by the computer infrastructure. Although SOA computer infrastructure 100 is illustrated as having a total of seven services distributed among three computers, other embodiments of SOA computer infrastructure 100 may have other quantities of services, and each computer may host any quantity of services.
[0028] In an embodiment of SOA computer infrastructure 100, the services may communicate using a MOM application For example, the services may communicate using a protocol that adheres to a Java Messaging Service ("JMS") specification.
[0029] As discussed above, the framework of a SOA computer network is often developed before one or more of the services. For example, computers 102, 104, and 106 as well as communication links 122, 124, and 126 may be developed and/or integrated together before any services in SOA computer infrastructure 100 are available. In order to facilitate testing and/or demonstration of SOA computer infrastructure 100, or any other SOA computer infrastructure, one or more services of the infrastructure may be emulated using service proxy 200 Service proxy 200 may be used to emulate a missing, defective, or incomplete service.
[0030] As an example, FIG. 2 illustrates SOA computer infrastructure 100 having service 108 substituted with service proxy 200; service proxy 200 emulates service 108 Stated in another manner, service proxy 200 operates as a stand-in for service 108 Service 108 may be missing, defective, or incomplete. Although service proxy 200 is illustrated as emulating service 108 in computer 102, service proxy 200 may be used to emulate other services Furthermore, service proxy 200 may be used in other computers and in other SOA computer infrastructures.
[0031] Service proxy 200 is a computer application embodied by computer readable instructions or computer code that can be executed on any of the computers of SOA computer infrastructure 100 to emulate a service. The computer code may be embodied as a software product stored on a computer readable media, such as a magnetic or optical disk. In one aspect, multiple instantiations of the routines of the software product may be executed substantially concurrently. Service proxy 200 may be written in computer programming code adhering to a Java specification, such as Sun Microsystems Java 1.4.2 SDK
[0032] A plurality of service proxies 200 may be executed at a given time. Each of the plurality of service proxies 200 is referred to as an instance of service proxy 200 For example, two instances of service proxy 200 may be used to emulate two respective services of SOA computer infrastructure 100
[0033] Service proxy 200 is operable to communicate with destinations in SOA computer infrastructure 100 by sending and/or receiving messages using a MOM application. For example, service proxy 200 may be operable to exchange messages with destinations using a MOM communication protocol adhering to a JMS specification. By way of example and not of limitation, the JMS specification may include the implementations provided by Sonic Software's SonicMQ, BEA's Weblogic, and/or JBoss.
[0034] Service proxy 200 may be executed on a computer other than the computer that the service being emulated is expected to executed on. Service proxy 200 may be executed on any computer accessible to SOA computer infrastructure 100
[0035] Service proxy 200 is operable according to a plurality of operating modes, including an audit operating mode, an injector operating mode, a pub-sub operating mode, an interceptor mode, and a routing mode, each of which are discussed in more detail below. Service proxy 200 is configured at run time using a configuration file. The configuration file instructs service proxy 200 how it is to operate and communicate with destinations, and the configuration file includes an operating mode specification. In an embodiment, the configuration file is embodied by an extensible markup language file.
[0036] In an embodiment of service proxy 200, each of a plurality of instances of service proxy 200 are configured via a respective configuration file. In other embodiments, each of a plurality of instances of service proxy 200 are configured via one common configuration file [0037] One service proxy 200 instance may operate along side other service proxy 200 instances, as may noted by studying FIG. 3, which is a block diagram illustrating subset 300 of a SOA computer infrastructure including a plurality of service proxy 200 instances. Subset 300 is illustrated as including service proxies 302, 306, and 308, each of which are emulating a service Subset 300 also includes service 304, which is a fully functional service, and destinations 310, 312, 314, 316. Although subset 300 is illustrated as having three instances of service proxy 200, one instance of a fully functional service, and four destinations, subset 300 can have any quantity of each of these elements.
[0038] Communication between a service proxy 200 instance and a destination is denoted by an arrow in FIG. 3. The direction of the arrow indicates the direction of travel of a message between the service proxy instance and the destination. For example, FIG 3 illustrates arrow 318 pointing from service proxy instance 302 to destination 310; arrow 318 denotes a message being sent from service proxy instance 302 to destination 310
[0039] As implied by FIG. 3, an instance of service proxy 200 can coexist with one or more other instances of service proxy 200 in a common SOA computer infrastructure. As is also implied by FIG. 3, one or more instances of service proxy 200 can coexist with one or more fully functional services in a common SOA computer infrastructure Each instance of service proxy 200 in a common SOA computer infrastructure may be configured to operate in a different operating mode For example, service proxy instance 302 may be configured to operate in the injector mode, service proxy instance 306 may be configured to operate in the pub-sub mode, and service proxy instance 308 may be configured to operate in the routing mode.
[0040] Service proxy 200 may be multi-threaded, which may enable it to simultaneously communicate with a plurality of destinations. For example, service proxy instance 306 is illustrated in FIG. 3 as simultaneously communicating with destinations 312, 314, and 316, and service proxy instance 308 is illustrated as simultaneously communicating with destinations 312, 314, and 316. Furthermore, a given destination may communicate with a plurality of service proxy 200 instances For example, destination 312 is illustrated as communicating with service proxy instances 306 and 308 as well as service 304.
[0041] Service proxy 200 may be configured such that it will continue to operate until it is manually interrupted or until it receives a kill message. A kill message may be sent to one or more service proxy 200 instances instructing each instance to terminate. For example, a kill message may be sent to all service proxy 200 instances in a SOA computer infrastructure instructing each instance to terminate. The injector operating mode, which is discussed in below, may be used to send a kill message
[0042] As discussed above, service proxy 200 can be operated in the audit mode, an example of which is embodied by method 400 of FIG. 4. Method 400 begins with step 402, wherein service proxy 200 monitors at least one destination for receipt of a message A message received by a destination will hereinafter be referred to as a received message. Upon the destination's receipt of a received message, service proxy 200 logs such receipt in a suitable manner in step 404 For example, the receipt may be logged in a database housed in SOA computer infrastructure 100; alternately, the receipt may logged in a database external to SOA computer infrastructure 100. Method 400 proceeds from step 404 back to step 402; consequently, method 400 continues to operate until it is manually interrupted or until it detects a kill message on the first destination
[0043] Service proxy 200 can also be operated in the injector mode, as specified above. In the injector mode, service proxy 200 publishes at least one predetermined message to at least one destination In an embodiment, the predetermined message may be housed in a message file, which may be identified in the configuration file In some embodiments, a common message file houses a plurality of predetermined messages; in other embodiments, each of a plurality of predetermined messages is housed in a respective message file.
[0044] An example of a use of the injector mode is to send a kill message to one or more service proxy 200 instances As discussed above, a service proxy 200 instance will terminate upon receipt of a kill message by a destination that it is monitoring.
[0045] Service proxy 200 can be further operated in the pub-sub mode, as discussed above. An example of the pub-sub mode is embodied by method 500, which is illustrated in FIG 5.
[0046] Method 500 begins with step 502, wherein service proxy 200 monitors at least one first destination for receipt of a received message. Upon the first destination's receipt of the received message, service proxy 200 determines in step 504 whether it is to publish the received message to at least one second destination, or if alternately, service proxy 200 is to publish a predetermined message to the second destination. In an embodiment, service proxy 200 compares the received message to processing information housed in the configuration file in order to execute decision 504.
[0047] If the result of decision 504 is that service proxy 200 should publish the received message, service proxy 200 places the received message in a queue in step 506 The queue may be located internal or external to SOA computer infrastructure 100. If the result of decision 504 is that service proxy 200 should publish the predetermined message, service proxy 200 places the predetermined message in the queue in step 508. In an embodiment of method 500, the predetermined message may be housed in a message file, which may be identified in the configuration file. In some embodiments, a common message file houses a plurality of predetermined messages; in other embodiments, each of a plurality of predetermined message is housed in a respective message file.
[0048] Steps 506 and 508 each proceed to step 510, wherein the message placed in the queue is published to at least one second destination. In an embodiment of method 500, service proxy 200 may wait a configurable time delay after executing steps 506 or 508 and before executing step 510. Method 500 proceeds from step 510 back to step 502; consequently, method 500 continues to operate until it is manually interrupted or until it detects a kill message on the first destination.
[0049] In an embodiment of method 500, service proxy 200 may publish a message to a destination housed in the "reply-to" field and/or to a predetermined destination included in the configuration file. Stated in another manner, the second destination may be specified by the "reply-to" field of the message or by the configuration file.
[0050] As discussed above, service proxy 200 can be operated in the interceptor mode. The interceptor mode is similar to the pub-sub mode, however, the inceptor mode further includes an additional graphical user interface ("GUI") which may be used to control execution of service proxy 200. The interceptor mode may be embodied by method 600 which is illustrated in FIG. 6.
[0051] Method 600 begins with step 602, wherein service proxy 200 opens a GUI indicating that a service proxy 200 instance has been launched. In step 604, service proxy 200 monitors at least one first destination for receipt of a received message. Upon receipt of the received message by the first destination, service proxy 200 determines in step 606 whether it is to publish the received message to at least one second destination, or if alternately, service proxy 200 is to publish a predetermined message to the second destination. In an embodiment, service proxy 200 compares the received message to processing information housed in the configuration file in order to execute decision 606.
[0052] If the result of decision 606 is that service proxy 200 should publish the received message, service proxy 200 places the received message in a queue in step 608. The queue may be located internal or external to SOA computer infrastructure 100. If the result of decision 606 is that service proxy 200 should publish the predetermined message, service proxy 200 places the predetermined message in the queue in step 610 In an embodiment, the predetermined message may be housed in a message file, which may be identified in the configuration file. In some embodiments, a common message file houses a plurality of predetermined messages; in other embodiments, each of a plurality of predetermined messages is housed in a respective message file
[0053] Steps 608 and 610 proceed to step 612, wherein a representation of the received message in displayed in the GUI. In step 614, service proxy 200 waits for a request to proceed. Such waiting period may be used to allow a user to pause operation of service proxy 200, which may be useful during debugging and/or demonstrating SOA computer infrastructure 100. A user may provide service proxy 200 a request to proceed via the GUI, such as by selecting an icon on the GUI.
[0054] In step 616, the message placed in the queue is published to at least one second destination. Method 600 proceeds from step 616 back to step 602; consequently, method 600 continues to operate until it is manually interrupted or until it detects a kill message on the first destination.
[0055] In an embodiment of method 600, service proxy 200 may publish a message to a destination housed in the "reply-to" field and/or to a predetermined destination included in the configuration file Stated in another manner, the second destination may be specified by the "reply-to" field of the message or by the configuration file
[0056] As discussed above, service proxy 200 may be operated in the routing mode. The routing mode is similar to the pub-sub mode, however, a user may be able to select between at least one primary destination or at least one alternate destination to publish a message to in the routing mode. The primary destination is a default destination that service proxy 200 will publish one or more messages to; the alternate destination is a destination that service proxy 200 will publish one or more messages to as an alternate to the primary destination. The routing mode specification in the configuration file may contain solely one or more primary destinations; alternately, the configuration file may contain both primary and alternate destinations.
[0057] FIG. 7 is a flowchart of method 700 for operating service proxy 200 in the routing mode. Method 700 begins with step 702, wherein service proxy 200 monitors at least one first destination for receipt of a received message. In step 704, a GUI is opened, and a representation of the received message is displayed in the GUI in step 706 Service proxy 200 determines in step 708 whether it is to publish the received message to at least one second destination, or if alternately, service proxy 200 is to publish a predetermined message to the second destination. In an embodiment, service proxy 200 compares the received message to processing information housed in the configuration file in order to execute decision 708.
[0058] If the result of decision 708 is that service proxy 200 should publish the received message, service proxy 200 places the received message in a queue in step 710 The queue may be located internal or external to SOA computer infrastructure 100. If the result of decision 708 is that service proxy 200 should publish the predetermined message, service proxy 200 places the predetermined message in the queue in step 712. In an embodiment, the predetermined message may be housed in a message file, which may be identified in the configuration file. In some embodiments, a common message file houses a plurality of predetermined messages; in other embodiments, each predetermined message is housed in a respective message file
[0059] In decision 714, service proxy 200 determines whether the configuration file includes any applicable alternate destinations in addition to the primary destination. If decision 714 determines that there are no applicable alternate destinations, service proxy 200 is to publish the message placed in the queue solely to the primary destination Accordingly, a confirmation prompt, which informs the user that solely the primary destination is available, is displayed in the GUI step 716.
[0060] Conversely, if decision 714 determines that both primary and alternate destinations exist, a user may direct that service proxy 200 publish the message placed in the queue to either each primary destination or each alternate destination Accordingly, primary and alternate prompts are displayed in the GUI in step 718 to allow the user to choose between the primary and alternate destination.
[0061] Steps 716 and 718 proceed to step 720, wherein service proxy 200 receives a user prompt in response to the one or more prompts displayed in step 716 or 718 If there are no applicable alternate destinations in the configuration file, the user prompt must be a confirmation prompt In the event there are applicable alternate destinations in the configuration file, the user prompt may consist of a primary destination prompt or a secondary destination prompt.
[0062] If the user prompt consists of a confirmation prompt or a primary destination prompt, service proxy 200 publishes the message placed in the queue to the primary destination in step 722. If the user prompt consists of an alternate destination prompt, the service proxy 200 publishes the message placed in the queue to the alternate destination in step 724. Method 700 proceeds from steps 722 or 724 back to step 702; consequently, method 700 continues to operate until it is manually interrupted or until it detects a kill message on a destination that it is monitoring.
[0063] Service proxy 200 may be executed on computer system 800 of FIG 8 Computer system 800 includes processing unit 802, input device 804, memory storage device 806, and output device 808.
[0064] Processing unit 802 executes instructions and processes data received by computer system 800. Processing unit 802 may be a general purpose or custom designed central processing unit, such as a microprocessor. Additionally, processing unit 802 may represent a plurality of central processing units. Processing unit 802 is operable to operate service proxy 200 in the audit, injector, pub-sub, interceptor, and routing modes.
[0065] Input device 804 is coupled to processing unit 802. Input device 804 provides a means for inputting data or instructions, such as a configuration file and/or computer code embodying service proxy 200, to processing unit 802. Input device 804 may be any acceptable device that allows data to be transferred to computer system 800. For example, input device 804 may be a keyboard, a pointing device, a network interface device, a modem, a magnetic disk or tape drive, and/or an optical drive. In an embodiment, input device 804 obtains a configuration file and/or an embodiment of the service proxy from computer readable media 810.
[0066] Memory storage device 806 is coupled to processing unit 802 Memory storage device 806 provides a means for processing unit 802 to store data or instructions for later use. Memory storage device 806 may consist or any one or more apparatuses operable to store data for use by processing unit 802 For example, memory storage device 806 may consist of random access memory.
[0067] Output device 808 is coupled to processing unit 802. Output device 808 provides a means for processing unit 802 to output data Output device 808 may be any acceptable device that allows data to be transferred out of computer system 800. For example, output device 808 may be a monitor, a printer, a network interface device, a modem, a magnetic disk or tape drive, and/or an optical drive.
[0068] Changes may be made in the above methods, systems and structures without departing from the scope hereof. It should thus be noted that the matter contained in the above description and/or shown in the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to covet all generic and specific features described herein, as well as all statements of the scope of the present method, system and structure, which, as a matter of language, might be said to fall therebetween.

Claims

1 A method of emulating a service in a computer infrastructure, comprising the steps of: providing a service proxy instance as a stand-in for the service; running the service proxy instance on a computer accessible to the computer infrastructure; configuring the service proxy instance at run time in accordance with a configuration file, the configuration file including an operating mode specification; and communicating between the service proxy instance and at least one destination in adherence to the operating mode specification and a communication protocol.
2. The method of claim 1 , wherein the configuration file further comprises an extensible markup language file.
3 The method of claim 1, wherein the communication protocol adheres to a Java Messaging Service specification
4. The method of claim 1, further comprising emulating a missing, defective, or incomplete service.
5 The method of claim 1 , further comprising communicating between at least one fully functional service and at least one destination
6. The method of claim 1 , further comprising a plurality of service proxy instances communicating with a single destination.
7. The method of claim 1 , further comprising emulating a plurality of services with a respective service proxy instance for each service.
8. The method of claim 7, wherein each service proxy instance is configurable via a respective configuration file
9. The method of claim 7, wherein each service proxy instance is configurable via a common configuration file.
10. The method of claim 1, further comprising terminating the service proxy instance upon its receipt of a kill message.
11. The method of claim 1, wherein the service proxy instance is operable to process a plurality of threads
12. The method of claim 1, wherein the step of communicating further comprises operating in accordance with an audit operating mode specification, including the steps of: monitoring at least one destination for receipt of a message; and logging the destination's receipt of the message.
13. The method of claim 1 , wherein the step of communicating further comprises operating in accordance with an injector mode specification, including the step of publishing at least one predetermined message to at least one destination, the predetermined message housed in a message file.
14. The method of claim 1, wherein the step of communicating further comprises operating in accordance with a pub-sub mode specification, including the steps of: monitoring at least one first destination for receipt of a message ("received message"); determining whether the service proxy instance is to publish the received message or a predetermined message housed in a message file to at least one second destination; placing the received message in a queue if the service proxy instance is to publish the received message to the second destination; placing the predetermined message in the queue upon the first destination's receipt of the received message if the service proxy instance is to publish the predetermined message to the second destination; and publishing the message stored in the queue to the second destination.
15. The method of claim 14 further comprising waiting a delay time before publishing the message stored in the queue to the second destination.
16 The method of claim 14, wherein the second destination is housed in a "reply-to" field of the message.
17. The method of claim 14, wherein the second destination is a predetermined destination housed in the configuration file
18. The method of claim 1, wherein the step of communicating further comprises operating in accordance with an interceptor mode specification, including the steps of: opening a graphical user interface window; monitoring at least one first destination for receipt of a message ("received message"); determining whether the service proxy instance is to publish the received message or a predetermined message housed in a message file to at least one second destination; placing the received message in a queue if the service proxy instance is to publish the received message to the second destination; placing the predetermined message in the queue upon the first destination's receipt of the received message if the service proxy instance is to publish the predetermined message to the second destination; displaying a representation of the received message in the graphical user interface window; waiting until the service proxy instance receives a request to proceed; and publishing the message stored in the queue to the second destination
19. The method of claim 18, wherein the second destination is housed in a "reply-to" field of the message.
20. The method of claim 18, wherein the second destination is a predetermined destination housed in the configuration file.
21. The method of claim 1, wherein the step of communicating further comprises operating in accordance with a routing mode, including the steps of: monitoring at least one first destination for receipt of a message ("received message"); opening a graphical user interface window upon the first destination's receipt of the received message; displaying the received message in the graphical user interface window; determining whether the service proxy instance is to publish the received message or a predetermined message housed in a message file; placing the received message in a queue if the service proxy instance is to publish the received message; placing the predetermined message in the queue upon the first destination's receipt of the received message if the service proxy instance is to publish the predetermined message; determining whether the configuration file includes at least one alternate destination; displaying a confirmation prompt in the graphical user interface window if the configuration file does not include at least one alternate destination; displaying a primary destination prompt and an alternate destination prompt in the graphical user interface window if the configuration file includes at least one alternate destination; receiving a user prompt; publishing the message stored in the queue to each primary destination if the user prompt identifies the confirmation prompt or the primary destination prompt; and publishing the message stored in the queue to each alternate destination if the user prompt identifies the secondary destination prompt.
22. A computer system for emulating a service, comprising: a processing unit; a memory storage device coupled to the processing unit; an input device coupled to the processing unit; an output device coupled to the processing unit; the processing unit being operative to: running a service proxy instance; configuring the service proxy instance at run time in accordance with a configuration file, the configuration file including an operating mode specification; and communicating between the service proxy instance and at least one destination in adherence to the operating mode specification and a communication protocol.
23. A software product comprising instructions, stored on computer-readable media, wherein the instructions, when executed by a computer, perform the steps of emulating a service in a computer infrastructure, comprising: instructions for running a service proxy instance; instructions for configuring the service proxy instance at run time in accordance with a configuration file, the configuration file including an operating mode specification; and instructions for communicating between the service proxy instance and at least one destination in adherence to the operating mode specification and a communication protocol.
PCT/US2007/080841 2006-10-09 2007-10-09 Service proxy WO2008045890A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/545,129 2006-10-09
US11/545,129 US7634553B2 (en) 2006-10-09 2006-10-09 Service proxy for emulating a service in a computer infrastructure for testing and demonstration

Publications (2)

Publication Number Publication Date
WO2008045890A2 true WO2008045890A2 (en) 2008-04-17
WO2008045890A3 WO2008045890A3 (en) 2008-10-16

Family

ID=39275817

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/080841 WO2008045890A2 (en) 2006-10-09 2007-10-09 Service proxy

Country Status (2)

Country Link
US (1) US7634553B2 (en)
WO (1) WO2008045890A2 (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060282502A1 (en) * 2005-06-10 2006-12-14 Koshak Richard L Method and system for translation of electronic data and software transport protocol with reusable components
US8296718B2 (en) 2007-10-31 2012-10-23 International Business Machines Corporation SOA software components that endure from prototyping to production
US8775651B2 (en) * 2008-12-12 2014-07-08 Raytheon Company System and method for dynamic adaptation service of an enterprise service bus over a communication platform
US9268608B2 (en) * 2009-02-26 2016-02-23 Oracle International Corporation Automatic administration of UNIX commands
US9275369B2 (en) 2011-08-24 2016-03-01 Oracle International Corporation Demystifying obfuscated information transfer for performing automated system administration

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6606708B1 (en) * 1997-09-26 2003-08-12 Worldcom, Inc. Secure server architecture for Web based data management
US20050010661A1 (en) * 2003-07-08 2005-01-13 Southam Blaine R. Systems and methods for testing network services
US20060015584A1 (en) * 2004-07-13 2006-01-19 Teneros, Inc. Autonomous service appliance
US20060136555A1 (en) * 2004-05-21 2006-06-22 Bea Systems, Inc. Secure service oriented architecture

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6026452A (en) * 1997-02-26 2000-02-15 Pitts; William Michael Network distributed site cache RAM claimed as up/down stream request/reply channel for storing anticipated data and meta data
US6466992B2 (en) 1994-12-07 2002-10-15 Next Computer, Inc. Method for providing stand-in objects
US6223227B1 (en) 1994-12-07 2001-04-24 Next Software, Inc. Method for providing stand-in objects
US7020880B2 (en) * 1997-01-08 2006-03-28 International Business Machines Corporation Modular application collaborator for providing inter-operability between applications and monitoring errors to trigger execution of required compensating actions to undo interrupted transaction
US5946311A (en) * 1997-05-27 1999-08-31 International Business Machines Corporation Method for allowing more efficient communication in an environment wherein multiple protocols are utilized
US7225249B1 (en) * 1997-09-26 2007-05-29 Mci, Llc Integrated systems for providing communications network management services and interactive generating invoice documents
US6751670B1 (en) * 1998-11-24 2004-06-15 Drm Technologies, L.L.C. Tracking electronic component
WO2000049547A1 (en) * 1999-02-17 2000-08-24 Diebold, Incorporated Method and system for connecting services to an automated transaction machine
US6681243B1 (en) * 1999-07-27 2004-01-20 Intel Corporation Network environment supporting mobile agents with permissioned access to resources
US6842906B1 (en) * 1999-08-31 2005-01-11 Accenture Llp System and method for a refreshable proxy pool in a communication services patterns environment
US6502213B1 (en) * 1999-08-31 2002-12-31 Accenture Llp System, method, and article of manufacture for a polymorphic exception handler in environment services patterns
US7107347B1 (en) * 1999-11-15 2006-09-12 Fred Cohen Method and apparatus for network deception/emulation
US6922685B2 (en) * 2000-05-22 2005-07-26 Mci, Inc. Method and system for managing partitioned data resources
US7249195B2 (en) * 2001-03-30 2007-07-24 Minor Ventures, Llc Apparatus and methods for correlating messages sent between services
US7363374B2 (en) * 2001-04-27 2008-04-22 International Business Machines Corporation Method and system for fault-tolerant remote boot in the presence of boot server overload/failure with self-throttling boot servers
US7020797B2 (en) * 2001-09-10 2006-03-28 Optimyz Software, Inc. Automated software testing management system
US8001189B2 (en) * 2001-10-16 2011-08-16 Microsoft Corporation Routing of network messages
US7130891B2 (en) * 2002-02-04 2006-10-31 Datasynapse, Inc. Score-based scheduling of service requests in a grid services computing platform
US7552205B2 (en) * 2002-05-21 2009-06-23 Accenture Global Services Gmbh Distributed transaction event matching
US7487509B2 (en) * 2002-08-08 2009-02-03 Sun Microsystems, Inc. System and method for providing multiple embodiments of abstract software modules in peer-to-peer network environments
US7457865B2 (en) * 2003-01-23 2008-11-25 Redknee Inc. Method for implementing an internet protocol (IP) charging and rating middleware platform and gateway system
US7707564B2 (en) * 2003-02-26 2010-04-27 Bea Systems, Inc. Systems and methods for creating network-based software services using source code annotations
US7559065B1 (en) * 2003-12-31 2009-07-07 Emc Corporation Methods and apparatus providing an event service infrastructure
US8245201B2 (en) 2004-04-30 2012-08-14 International Business Machines Corporation Method and system for recording and replaying service interactions
US7752604B2 (en) 2004-09-02 2010-07-06 International Business Machines Corporation Method, system and program product for recording and replaying target service interaction data
US7487512B2 (en) * 2004-09-30 2009-02-03 Sap Ag Publish-subscribe event notifications
US20060090136A1 (en) * 2004-10-01 2006-04-27 Microsoft Corporation Methods and apparatus for implementing a virtualized computer system
EP1657876A1 (en) * 2004-11-12 2006-05-17 Sony Deutschland GmbH Method and apparatus for transferring data of a first standard and receiving data of a second standard at a predetermined security level in a layered network
US7467389B2 (en) * 2004-11-23 2008-12-16 Sybase, Inc. System and methodology providing service invocation for occasionally connected computing devices
US7483438B2 (en) * 2005-04-14 2009-01-27 Alcatel Lucent Systems and methods for managing network services between private networks
EP1818820A1 (en) * 2006-02-03 2007-08-15 Research In Motion Limited System and method for installing custom services on a component-based application platform
US7548843B2 (en) * 2006-04-10 2009-06-16 Microsoft Corporation Simulation of distributed networks

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6606708B1 (en) * 1997-09-26 2003-08-12 Worldcom, Inc. Secure server architecture for Web based data management
US20050010661A1 (en) * 2003-07-08 2005-01-13 Southam Blaine R. Systems and methods for testing network services
US20060136555A1 (en) * 2004-05-21 2006-06-22 Bea Systems, Inc. Secure service oriented architecture
US20060015584A1 (en) * 2004-07-13 2006-01-19 Teneros, Inc. Autonomous service appliance

Also Published As

Publication number Publication date
WO2008045890A3 (en) 2008-10-16
US7634553B2 (en) 2009-12-15
US20080086541A1 (en) 2008-04-10

Similar Documents

Publication Publication Date Title
JP7042317B2 (en) Flexible node configuration methods and systems for local or distributed computer systems
US10805213B2 (en) Controlling data communication between microservices
US10915382B2 (en) Event-driven serverless function orchestration
US9304827B2 (en) Systems and methods for providing hierarchy of support services via desktop and centralized service
US7984449B2 (en) In-band communication with virtual machines via a hypervisor message bus
CN101189595B (en) Solution deployment in a server farm
CN110658794B (en) Manufacturing execution system
US20080072277A1 (en) Evaluation systems and methods for coordinating software agents
US7752255B2 (en) Configuring software agent security remotely
US8538793B2 (en) System and method for managing real-time batch workflows
US7634553B2 (en) Service proxy for emulating a service in a computer infrastructure for testing and demonstration
CN102523242B (en) Goal state communication in computer clusters
US8055732B2 (en) Signaling partial service configuration changes in appnets
EP4123451A1 (en) Scheduling complex jobs in a distributed network
CN110011875A (en) Dial testing method, device, equipment and computer readable storage medium
US8607336B2 (en) Evaluation systems and methods for coordinating software agents
US8055797B2 (en) Transmitting aggregated information arising from appnet information
US20030212587A1 (en) Apparatus and methods for coordinating Web services using role based interpretation of coordination plans
US20080071793A1 (en) Using network access port linkages for data structure update decisions
CN108108234A (en) A kind of distributed task management method and system
US20150212504A1 (en) Method for providing functions within an industrial automation system, and industrial automation system
CN108667763A (en) Method, system, electronic equipment and the storage medium that communication protocol scheduling executes
US20210216342A1 (en) System, server, verification method and program
CN110221869A (en) Method and device for configuration data center running environment
JP2005251102A (en) Access monitoring and restriction system

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

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07844032

Country of ref document: EP

Kind code of ref document: A2