US20100229244A1 - Traffic manager for distributed computing environments - Google Patents
Traffic manager for distributed computing environments Download PDFInfo
- Publication number
- US20100229244A1 US20100229244A1 US12/782,261 US78226110A US2010229244A1 US 20100229244 A1 US20100229244 A1 US 20100229244A1 US 78226110 A US78226110 A US 78226110A US 2010229244 A1 US2010229244 A1 US 2010229244A1
- Authority
- US
- United States
- Prior art keywords
- soap message
- soap
- rule
- message
- computer
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
Definitions
- the present invention relates to distributed computing environments, and more particularly to communication between various programs operating in the distributed computing environments.
- SOAP uses Extensible Markup Language (XML) and a transport protocol (such as HTTP, SMTP, MQ, etc.) as the mechanisms for information exchange.
- SOAP specifies how to encode an XML file so that a computer program running in one computer can call a computer program in another computer. This allows the computer program running in the first computer to send information to the program running in the other computer (e.g., one program to call another program).
- SOAP specifies how the called program can return a response. Since HTTP and XML Web protocols are usually installed and available for use in most operating platforms, SOAP provides a readily available solution to the difficult problem of allowing computer programs running in different environments to communicate with each other.
- SOAP can be used as a lightweight protocol for exchange of information in a decentralized, distributed environment.
- SOAP can consist of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls (RPC) and responses.
- the SOAP envelope construct defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory.
- the SOAP encoding rules define a serialization mechanism that can be used to exchange instances of application-defined data types.
- the SOAP RPC representation defines a convention that can be used to represent remote procedure calls and responses.
- SOAP does not itself define any application semantics, such as a programming model or implementation specific semantics. Instead, it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems. Accordingly, it highly desirable to provide a communication environment which can use SOAP or similar protocols.
- FIG. 1 depicts a conventional distributed computing environment 100 . As shown in FIG. 1 , several interfaces are implemented and maintained to facilitate communication between a few client and server programs.
- the invention relates to techniques suitable for facilitating communication between various computer programs operating on various nodes in a distributed computing environment.
- a traffic manager is disclosed.
- the traffic manager is capable of monitoring traffic exchanged between client and server programs operating in the distributed computing environment.
- the traffic manager can be used to implement a variety of desirable features across different computing environments. These computing environments are typically separated by one or more distinguishing characteristics.
- the traffic manager provides an integral and cost effective solution which can bridge these distinguishing characteristics as well as define and enforce policies across disparate applications and computing environments.
- this is achieved by centralizing the generation of interfaces which allow interaction between any of the nodes in a distributed computing system. That is, instead of enabling each node to generate the necessary interfaces for communicating with each other type of node in the system, the present invention abstracts and centralizes this function so that a single node or set of nodes is responsible for affecting the communications between disparate nodes. This avoids the redundancy and inefficiency inherent, particularly in complex systems, in building these capabilities in each node. Another advantage is that the present invention can provide control for enforcing Information Technology (IT) an/or business policies and procedures. This can be achieved when the interfaces are compatible or incompatible.
- IT Information Technology
- the invention can be implemented in numerous ways, including as a method, an apparatus, and computer readable media. Several embodiments of the invention are discussed below.
- one embodiment of the invention includes the acts of: receiving a SOAP message; determining whether at least one security rule is associated with the SOAP message, the least one security rule being associated with a security policy for SOAP messages which can be exchanged between at least one client program and at least one server program; and performing at least one operation based on the at least one security rule when the determining determines that at least one security rule is associated with the SOAP message.
- one embodiment of the invention includes the acts of: receiving a SOAP message; determining whether at least one rule is associated with the SOAP message; collecting data that may be required to evaluate the at least one rule; evaluating the at least one rule at least partially based on the collected data; and determining whether the SOAP message constitutes a service attack based on the evaluating of the at least one rule.
- one embodiment of the invention includes the acts of: identifying a SOAP interface for which publication or access is requested; determining whether one or more rules are associated with the SOAP interface, evaluating the SOAP interface; and determining whether publication of or access to the SOAP interface should be granted based on the evaluating of the SOAP interface.
- the one or more rules can describe one or more policies with respect to publication of or access to the SOAP interface.
- another embodiment of the invention includes the acts of: receiving a SOAP message; determining whether at least one rule is associated with the SOAP message; evaluating the at least one rule based on at least one portion of the SOAP message; and determining whether an action should be taken with respect to the SOAP message based on the evaluating of the at least one rule.
- FIG. 1 depicts a conventional distributed computing environment.
- FIG. 2 is a simplified block diagram of a computing environment with reference to which a generalized embodiment of the present invention is described.
- FIGS. 3A-3B illustrate a traffic manager operating in a distributed computing environment in accordance with a more specific embodiment of the invention.
- FIG. 3C illustrates a method for facilitating communication between a client node and a server node in a distributed computing environment in accordance with one embodiment of the invention.
- FIG. 3D illustrates a method for processing SOAP messages in accordance with one embodiment of the invention.
- FIG. 4 illustrates a security method suitable for providing security for SOAP messages exchanged between a client and a server program in accordance with one embodiment of the invention.
- FIG. 5 illustrates a security method suitable for providing security for SOAP messages exchanged between a client and a server program in accordance with another embodiment of the invention.
- FIG. 6 illustrates a security method for providing security for server programs running in one or more computing nodes in accordance with yet another embodiment of the invention.
- FIG. 7 illustrates a method for controlling access to and/or publication of SOAP interfaces.
- FIG. 8 illustrates a processing method for processing SOAP messages in accordance with one embodiment of the invention.
- the invention pertains to techniques suitable for facilitating communication between various computer programs operating on various nodes in a distributed computing environment.
- a traffic manager is disclosed.
- the traffic manager is capable of monitoring traffic exchanged between client and server programs operating in the distributed computing environment.
- the traffic manager can be used to implement a variety of desirable features across different computing environments. These computing environments are typically separated by one or more distinguishing characteristics.
- the traffic manager provides an integral and cost effective solution which can bridge these distinguishing characteristics as well as define and enforce policies across disparate applications and computing environments.
- this is achieved by centralizing the generation of interfaces which allow interaction between any of the nodes in a distributed computing system. That is, instead of enabling each node to generate the necessary interfaces for communicating with each other type of node in the system, the present invention abstracts and centralizes this function so that a single node or set of nodes is responsible for affecting the communication between disparate nodes. This avoids the redundancy and inefficiency inherent in building these capabilities in each node, particularly in complex systems. Another advantage is that the present invention can provide control for enforcing Information Technology (IT) and/or business policies and procedures. This can be achieved when the interfaces are compatible or incompatible.
- IT Information Technology
- FIG. 2 is a simplified block diagram of a computing environment 201 with reference to which a generalized embodiment of the present invention will be described.
- the distributed computing environment 201 which can be any of a wide variety of distributed computing environments, includes computing nodes A, B and C which can communicate with the computing node D.
- various client programs can be running in each of the computing nodes A, B, and C and a server program can be running in the node D.
- the client programs running in the computing nodes A, B and C request one or more services from one or more server programs running in the computing node D.
- These requests for services are managed by the intermediary traffic manager 200 as described below.
- the traffic manager 200 can be implemented using one or more physical components (physical components 1 -N). Each of these physical components can, for example, be a computing node with memory and a central processing unit. In any case, the traffic manager 200 facilitates communication between any of the computing nodes in the distributed computing environment 201 .
- Traffic manager 200 can publish one or more message interfaces, for example, message Interfaces 202 , 203 and 204 .
- the message Interfaces 202 , 203 and 204 can respectively be used by the computing nodes A, B and C.
- various client programs running on different computing nodes in the computing environment 201 can use a different message interface in order to invoke services which are provided by one or more programs running on computing node D.
- the traffic manager 200 operates to manage the data traffic in the computing environment 201 . That is, the traffic manager 200 monitors the data generated by the computing nodes A, B and C and determines whether the data should be transmitted to the computing node D. Moreover, the traffic manager 200 maps a set of service requests generated by the client programs running in computing nodes A, B and C into a set of service requests which are directed to one or more server programs running in the computing node D. As such, the traffic manager 200 may perform a mapping between two application interfaces.
- the traffic manager 200 can facilitate mapping of, for example, the message interface 202 to a second message interface 205 . As will be appreciated, this mapping can be done based on at least one policy. Such policies are typically implemented to bridge one or more disparate characteristics that exist between the computing nodes A, B, C, and D, and/or to enforce common procedures or policies within a homogenous environment and may be implemented using rules stored in a storage medium 206 associated with the traffic manager 200 .
- FIG. 3A illustrates a traffic manager 300 operating in a distributed computing environment 301 in accordance with a more specific embodiment of the invention.
- the traffic manager 300 uses the Simple Object Access Protocol (SOAP) in order to facilitate communication between a client program 302 and a server program 304 .
- SOAP Simple Object Access Protocol
- Programs 302 and 304 may each reside on one or more computing nodes in any of a wide variety of network topologies.
- client program 302 may reside on a single client machine while server program 304 is distributed across a plurality of servers.
- the nodes on which programs 302 and 304 reside may be on the same local area network (LAN) or in a wide area network (WAN) such as the Internet or World Wide Web.
- LAN local area network
- WAN wide area network
- the traffic manager 300 allows the client program 302 to access (or invoke) one or more services provided by the server program 304 using the Simple Object Access Protocol.
- the data transmitted between programs 302 and 304 can be, for example, in Extensible Markup Language (XML) format.
- XML Extensible Markup Language
- other formats for example, multimedia formats or office file formats (e.g., .jpeg, .wav, .doc, etc.) can be attached.
- the traffic manager 300 can read a Web Services Description Language (WSDL) file 306 associated with server program 304 .
- the WSDL 306 provides a detailed technical description specifying a SOAP interface 308 .
- the SOAP interface 308 is the interface to the one or more services which are provided by the server program 304 .
- the WSDL provides information about interface 308 so that these services can be accessed.
- an optional Universal Description, Discovery and Integration directory (UDDI) 310 may initially be accessed in order to, among other things, get information about the WSDL file 306 .
- UDDI Universal Description, Discovery and Integration directory
- the traffic manager 300 can generate and/or publish one or more corresponding WSDL file 312 and a corresponding SOAP interface 314 .
- the traffic manager 300 can generate one or more SOAP interfaces (e.g., SOAP Interface 314 shown in FIG. 3A ).
- the traffic manager 300 may generate multiple variants of the underlying interface (not shown). For example, different variants of the SOAP interface for each security model and/or for different business partners can be generated.
- the SOAP Interface 314 may also provide a Common interface by which client program 302 and any other program or node in the system may transparently invoke one or more services associated with the server program 304 .
- WSDL file 312 and SOAP interface 314 are generated at least partially based on data stored in a persistent storage medium 315 .
- the data stored in the persistent storage medium 315 can, for example, include rules, policies, a mapping of users with organizational roles (e.g., an LDAP directory), etc. As will be appreciated, these can be used, for example, to define interfaces, approve interfaces, define policies and rules, review operational data, etc.
- a person e.g., application developer and/or business analyst, etc.
- the traffic manager 300 may interact with the traffic manager 300 , for example, through a Graphical User Interface.
- the WSDL file 312 and SOAP Interface 314 can be generated by the traffic manager 300 at least partly based on input provided by a person.
- the traffic manager 300 may optionally publish the WSDL file 312 in a UDDI 319 .
- the traffic manager 300 generates the corresponding SOAP Interface 314 for the SOAP Interface 308 .
- the client program 302 can access (or invoke) the services provided by the server program 304 through the SOAP interface 314 .
- the client program 302 reads the WSDL file 312 in order to obtain information regarding the SOAP Interface 314 .
- the client program 302 may initially access the optional UDDI 319 in order to locate the WSDL 312 file. In any case, after the client program 302 reads the WSDL file 312 , the client program 302 can use the SOAP interface 314 to communicate with the traffic manager 300 .
- the client program 302 transmits a SOAP message 320 through the SOAP interface 314 .
- the SOAP message can be a request for one or more services from the server program 304 .
- the SOAP message 320 can, for example, include data in an XML format.
- the SOAP message may also include other attachments (e.g., .gif files, .wav files, etc.).
- the traffic manager 300 can, in turn, perform a variety of operations on the SOAP message 320 .
- the traffic manager 300 may discard, hold, store, or forward the SOAP message 320 .
- the traffic manager 300 may also transform the SOAP message 320 into another SOAP message 322 which is sent to the server program 304 and/or one or more other programs (not shown) in the distributed computing environment 301 .
- the SOAP message 320 can be a request for one or more services.
- the traffic manager 300 can determine whether a request for invocation of the same and/or different services should be made from the server program 304 and/or other server programs (not shown) in the distributed computing environment 301 . This determination can be made at least partially based on the data stored in the persistent storage 315 . Based on this determination, the traffic manager 300 can map a request made by the client program 302 through the SOAP Interface 314 to a request for services from the server program 304 through the SOAP Interface 308 . In other words, a SOAP message 322 can be generated by the traffic manager 300 and transmitted to the server program 304 and/or other server programs (not shown).
- the SOAP message 322 corresponds to the SOAP message 320 and can be a request for the same or different set of services provided by the server program 304 . Accordingly, the traffic manager 300 can monitor the data traffic between the client program 302 and server program 304 and/or other server or client programs in the distributed computing environment 301 .
- the traffic manager 300 can be used to manage the services provided by the server program 304 and/or other server programs in the distributed computing environment 301 . This allows the services which are offered by the server program to be mapped to possibly a different set of services which are actually provided to the client program 302 . This provides control over the access of services in a distributed computing environment and allows implementation of various policies across different computing nodes which typically possess one or more disparate characteristics.
- FIG. 3C illustrates a method 350 for facilitating communication between a client node and a server node in a distributed computing environment.
- the method 350 can, for example, be used by the traffic manager 300 of FIGS. 3A and 3B .
- a first UDDI is read to locate the appropriate WSDL file associated with an interface to one or more server programs.
- the WSDL file is read.
- the WSDL file typically describes a first interface which can be used to access one or more services provided by one or more server programs.
- at least one interface (a second interface) is generated (or published) based on at least one policy. This provides one or more interfaces to the services provided by the one or more servers.
- security mapping function can be abstracted and centralized. Again, this avoids the redundancy and inefficiency inherent in building these capabilities in each node, particularly in complex systems. Furthermore, control over enforcement of Information Technology (IT) and/or business policies and procedures can be achieved. It should be noted that this can be achieved when the interfaces are compatible or incompatible.
- IT Information Technology
- a second WSDL file which describes the at least one generated (or published) interface is generated (or published).
- at operation 360 at least one UDDI entry associated with the generated (or published) WSDL file is created (or updated). The method 350 ends following operation 360 .
- FIG. 3D illustrates a method 380 for processing SOAP messages in accordance with one embodiment of the invention.
- the method 380 can, for example, be used by the traffic manager 300 of FIGS. 3A and 3B .
- a SOAP message is received.
- a determination is made as to whether at least one rule is associated with the SOAP message. Such rules are typically generated with reference to one or more policies. If it is determined at operation 384 that no rule is associated with the SOAP message, the method 380 ends. However, if it is determined at operation 384 that at least one rule is associated with the SOAP message, the method 380 proceeds to operation 386 where any such rule is evaluated for the SOAP message. Thereafter, at operation 388 , the SOAP message is processed based on the result of the evaluation. The method 380 ends following operation 388 .
- FIG. 4 illustrates a security method 400 suitable for providing security for SOAP messages exchanged between a client and a server program in accordance with one embodiment of the invention.
- the security method 400 is suitable for providing a security model mapping between the client and server programs which operate in a distributed operating environment.
- security mapping function can be abstracted and centralized so a single node or set of nodes which are responsible for affecting the communications between disparate nodes. Again, this avoids the redundancy and inefficiency inherent in building these capabilities in each node, particularly in complex systems.
- a SOAP message is received.
- a message type is determined for the SOAP message.
- the rules associated with the message type are looked up. Accordingly, at operation 408 , a determination is made as to whether at least one decryption rule is associated with the SOAP message. If it is determined at operation 408 that at least one decryption rule is associated with the SOAP message, the security method 400 proceeds to operation 410 where a determination is made as to whether the SOAP message is encrypted.
- the security method 400 proceeds to operation 412 where an attempt is made to decrypt the SOAP message using one or more keys which are identified by at least one decryption rule.
- the decryption keys typically correspond to (or are managed by) an organization or an organizational rule.
- the security method 400 can proceed to operation 418 where a determination is made as to whether at least one encryption rule is associated with the SOAP message. If it is determined at operation 418 that no encryption rule is associated with the SOAP message, the security method 400 proceeds to operation 420 where the SOAP message is sent to one or more server programs. The security method 400 ends following operation 420 . However, if it is determined at operation 418 that at least one encryption rule is associated with the SOAP message, the security method 400 proceeds to operation 422 where the SOAP message is encrypted using one or more keys which are associated with the encryption rule before the message is sent to one or more server programs at operation 420 . In any case, the security method 400 ends following operation 420 .
- FIG. 5 illustrates a security method 500 suitable for providing security for SOAP messages exchanged between a client and a server program in accordance with another embodiment of the invention.
- the security method 500 is suitable for providing a security model mapping between the client and server programs which operate in a distributed operating environment.
- security mapping function can be abstracted and centralized so a single node or set of nodes which are responsible for affecting the communications between disparate nodes. Again, this avoids the redundancy and inefficiency inherent in building these capabilities in each node, particularly in complex systems.
- the security method 500 can, for example, be used to verify signatures and/or sign messages using keys (or identifiers) which are recognized or used by the client and server programs. Initially, at operation 502 , a SOAP message is received. Next, at operation 504 , a message type is determined for the SOAP message. Thereafter, at operation 506 , the rules associated with the message type are looked up. Accordingly, at operation 508 , a determination is made as to whether at least one signature verification rule is associated with the SOAP message. If it is determined at operation 508 that a signature verification rule is associated with the SOAP message, the security method 500 proceeds to operation 510 where at least one signature associated with the SOAP message is verified according to the at least one signature verification rule.
- the security method 500 proceeds to operation 518 where the SOAP message is processed (e.g., the SOAP message is sent to one or more servers). The method 500 ends following operation 518 . However, if it is determined at operation 516 that there is at least one signing rule associated with the SOAP message, the security method 500 proceeds to operation 520 where at least one portion of the SOAP message is signed using one or more keys which are associated with the at least one signing rule. Thereafter, at operation 518 the SOAP message is processed. The method 500 ends following the operation 518 .
- FIG. 6 illustrates a security method 600 for providing security for server programs running in one or more computing nodes in accordance with yet another embodiment of the invention.
- the security method 600 can, for example, be used by the traffic manager 300 of FIGS. 3A and 3B .
- the method 600 is especially suited for protecting server programs against service attacks which are typically initiated by one or more client programs.
- a SOAP message is received.
- the SOAP message is typically a request for one or more services from one or more server programs.
- the message type, sender node, and recipient node are respectively determined.
- applicable rules for the message type, sender node, and recipient node are retrieved.
- the determination made at operation 612 can, for example, determine the extent of the history (or log) for the SOAP messages that need to be considered. Histories (or logs) can be maintained for various message categories. These message categories can, for example, include messages of a particular type, all messages sent by a sender node, messages received by the recipient node, etc.
- the security method 600 proceeds to operation 614 where the first rule associated with the SOAP message is tested using the collected data.
- operation 616 a determination is made as to whether the first rule indicates that a service attack has been made. If it is determined at operation 616 that a service attack has been made, the security method 600 proceeds to operation 618 where service is denied and remedial action is taken.
- the remedial action taken can, for example, include notifying an administrator, holding the SOAP message, etc.
- the security method 600 ends following operation 618 .
- the security method 600 proceeds to operation 620 where a determination is made as to whether there are more rules associated with the SOAP message. If it is determined at operation 620 that there are no additional rules associated with the SOAP message, the security method 600 proceeds to operation 624 where the SOAP message is processed (e.g., transformed and/or forwarded). The security method 600 ends following operation 624 .
- the security method 600 proceeds to operation 622 where the next rule associated with the SOAP message is tested using the collected data.
- the security method 600 proceeds to operation 616 where a determination is made as to whether the rule indicates a service attack. Thereafter, the security method 600 proceeds in the same manner as discussed above.
- the security method 600 ends either following operation 618 where service is denied and remedial action is taken or after the operation 624 where the SOAP message is processed.
- a traffic manager (e.g., traffic manager 300 of FIGS. 3A and 3B ) is used to facilitate control over access and/or publication of SOAP interfaces.
- the traffic manager provides a user interface which is used to interact with the traffic manager.
- the user interface can be used, for example, by a programmer to make a request with respect to a particular SOAP interface (e.g., publication of a new SOAP interface, modification and/or access to an existing SOAP interface, etc.).
- the traffic manager may also facilitate the approval process of such requests. That is, the traffic manager can provide a user interface that can be used, for example, by an administrator to facilitate the approval process through interaction with the user interface.
- FIG. 7 illustrates a method 700 for controlling access to and/or publication of SOAP interfaces.
- the method 700 can, for example, be used by the traffic manager 300 of FIGS. 3A and 3B .
- This allows centralized control over the access to and/or publication of the SOAP interfaces.
- this allows implementation and enforcement of policies with respect to access to and/or publication of the SOAP interfaces.
- these policies can be implemented while avoiding the redundancy and inefficiencies inherent in conventional approaches.
- a SOAP interface is identified.
- the SOAP interface can, for example, be a pre-existing SOAP interface or a SOAP interface which has just been developed.
- a programmer or developer may identify the SOAP interface by interacting with a user interface of a traffic manager which facilitates the process of controlling access and/or publication of SOAP interfaces.
- the programmer may, for example, identify a newly developed SOAP interface in order to request approval for publication of the SOAP interface.
- the programmer may seek permission to access an existing SOAP interface and/or request modifications to it, and so forth.
- a WSDL file for the SOAP interface is identified.
- the rules which apply to the SOAP interface are input. This operation can be performed, for example, by the programmer through a user interface associated with the SOAP traffic manager.
- the SOAP traffic manager can perform a search and output the rules which apply to the SOAP interface.
- one or more additional rules for the SOAP interface and/or existing rules to be associated with the interface are specified. Again, this operation can be performed, for example, by the programmer through a user interface associated with the SOAP traffic manager.
- a determination is made as to whether any modifications should be made to what has been requested for approval (e.g., whether modification should be made to the SOAP interface and/or one or more rules). If it is determined at operation 716 that there is a need to make modifications to what has been requested for approval, the method 700 proceeds to operation 718 where appropriate modifications to the request can be made. Next, the method 700 proceeds to operation 720 where a determination is made as to whether the request should be approved. It should be noted that if it is determined at operation 716 that there is no need to make any modifications, the method 700 bypasses operation 718 and proceeds directly to operation 720 where a determination is made as to whether the request should be approved.
- FIG. 8 illustrates a processing method 800 for processing SOAP messages in accordance with one embodiment of the invention.
- the processing method 800 can, for example, be used by the traffic manager 300 of FIGS. 3A and 3B .
- a SOAP message is received.
- the message type, sender node, and recipient node are respectively determined.
- one or more authentication identifiers are determined.
- the authentication identifiers can, for example, be associated with the sender or receiver nodes.
- any rules associated with the message type, sender node, and recipient node are identified.
- actions can, for example, include holding the SOAP message, archiving the SOAP message, failing SOAP message delivery, sending a notification, logging special notification, modifying the data in the message, sending side-effect SOAP messages, invoking Java methods and so on.
- the processing method 800 proceeds to operation 822 where a determination is made as to whether there are more data review/conditional flow rules to evaluate. It should be noted that if it is determined at operation 818 that no action is required, the processing method 800 bypasses operation 820 and directly proceeds to operation 822 .
- the processing method 800 proceeds to operation 814 where data is gathered from the SOAP message as specified by the data review/conditional flow rule. Thereafter, the processing method 800 proceeds in a similar manner as discussed above. On the other hand, if it is determined at operation 822 that there are no data review/conditional flow rules to evaluate, the processing method 800 proceeds to 824 where the processing of the SOAP message is completed (e.g., the SOAP message is delivered). The processing method 800 ends following operation 824 .
Abstract
Techniques suitable for facilitating communications between various computer programs operating on various nodes in a distributed computing environment are disclosed. The techniques can be used by a traffic manager operating in such environments. The traffic manager is capable of monitoring traffic exchanged between client and server programs operating in the distributed computing environment. Moreover, the traffic manager can be used to implement a variety of desirable features across different computing environments. These computing environments are typically separated by one or more distinguishing characteristics. As will be appreciated, the traffic manager provides an integral and cost effective solution which can bridge these distinguishing characteristics as well as define and enforce policies across disparate computing environments. This is achieved by centralizing the generation of interfaces which allow interaction between any of the nodes in a distributed computing system. This avoids the redundancy and inefficiency inherent in building these capabilities in each node, particularly in complex systems.
Description
- The present application is a continuation of U.S. patent application Ser. No. 12/341,742, entitled “TRAFFIC MANAGER FOR DISTRIBUTED COMPUTING ENVIRONMENTS,” filed on Dec. 22, 2008; the entire contents of the foregoing are incorporated herein by reference. This application is related to U.S. patent application Ser. No. 10/015,501, entitled “TRAFFIC MANAGER FOR DISTRIBUTED COMPUTING ENVIRONMENTS,” filed on Dec. 11, 2001, and hereby incorporated herein by reference. This application is also related to U.S. patent application Ser. No. 10/015,502 entitled “TRAFFIC MANAGER FOR DISTRIBUTED COMPUTING ENVIRONMENTS,” filed on Dec. 11, 2001, and hereby incorporated herein by reference.
- 1. Field of the Invention
- The present invention relates to distributed computing environments, and more particularly to communication between various programs operating in the distributed computing environments.
- 2. Description of the Related Art
- Recently, distributed computing environments have become widespread. Accordingly, extensive efforts have been made to facilitate communication between the various computing nodes which typically operate in such environments. One such effort is the development of the Simple Object Access Protocol (SOAP). SOAP is a standard which can be used to facilitate communication between different computing nodes operating in different platforms (or operating systems). As such, SOAP provides a way for a computing program (program) running in one kind of operating system (e.g., Windows 2000) to communicate with another computer program which is running in another kind of operating system (e.g., Linux).
- Typically SOAP uses Extensible Markup Language (XML) and a transport protocol (such as HTTP, SMTP, MQ, etc.) as the mechanisms for information exchange. SOAP specifies how to encode an XML file so that a computer program running in one computer can call a computer program in another computer. This allows the computer program running in the first computer to send information to the program running in the other computer (e.g., one program to call another program). In addition; SOAP specifies how the called program can return a response. Since HTTP and XML Web protocols are usually installed and available for use in most operating platforms, SOAP provides a readily available solution to the difficult problem of allowing computer programs running in different environments to communicate with each other.
- A major design goal for SOAP is simplicity and extensibility. This means that there are several features of traditional messaging systems and distributed object systems that are not part of the core SOAP specification. Accordingly, SOAP can be used as a lightweight protocol for exchange of information in a decentralized, distributed environment. As an XML based protocol, SOAP can consist of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls (RPC) and responses. The SOAP envelope construct defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory. The SOAP encoding rules define a serialization mechanism that can be used to exchange instances of application-defined data types. The SOAP RPC representation defines a convention that can be used to represent remote procedure calls and responses. SOAP does not itself define any application semantics, such as a programming model or implementation specific semantics. Instead, it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems. Accordingly, it highly desirable to provide a communication environment which can use SOAP or similar protocols.
- Unfortunately, conventional approaches fail to solve many other problems associated with communication between computer programs in distributed computing environments. One such shortcoming is that the conventional approaches fail to provide a solution which can simultaneously and efficiently bridge the many disparate characteristics which typically exist between the nodes that make up a distributed computing environment. Even in cases where a solution can be provided to account for a particular type of difference (e.g., relating to security features) between various nodes, typically a costly and/or ad hoc approach is used. To illustrate,
FIG. 1 depicts a conventional distributed computing environment 100. As shown inFIG. 1 , several interfaces are implemented and maintained to facilitate communication between a few client and server programs. - Accordingly, conventional approaches do not provide a comprehensive approach to bridging these differences. This means that in order to facilitate communication between the numerous nodes and programming environments that typically make up a distributed computing environment, a tremendous amount of resources have to be deployed to painstakingly implement each desirable feature between each and every program on each and every node. The inefficiencies inherent in such an approach are manifest.
- In view of the foregoing, improved techniques for allowing communication in distributed computing environments are needed.
- Broadly speaking, the invention relates to techniques suitable for facilitating communication between various computer programs operating on various nodes in a distributed computing environment. In accordance with one aspect of the invention, a traffic manager is disclosed. The traffic manager is capable of monitoring traffic exchanged between client and server programs operating in the distributed computing environment. Moreover, the traffic manager can be used to implement a variety of desirable features across different computing environments. These computing environments are typically separated by one or more distinguishing characteristics. As will be appreciated, the traffic manager provides an integral and cost effective solution which can bridge these distinguishing characteristics as well as define and enforce policies across disparate applications and computing environments.
- According to various embodiments, this is achieved by centralizing the generation of interfaces which allow interaction between any of the nodes in a distributed computing system. That is, instead of enabling each node to generate the necessary interfaces for communicating with each other type of node in the system, the present invention abstracts and centralizes this function so that a single node or set of nodes is responsible for affecting the communications between disparate nodes. This avoids the redundancy and inefficiency inherent, particularly in complex systems, in building these capabilities in each node. Another advantage is that the present invention can provide control for enforcing Information Technology (IT) an/or business policies and procedures. This can be achieved when the interfaces are compatible or incompatible.
- The invention can be implemented in numerous ways, including as a method, an apparatus, and computer readable media. Several embodiments of the invention are discussed below.
- As a computer-implemented method for implementing security for SOAP messages which can be exchanged between client and server programs, one embodiment of the invention includes the acts of: receiving a SOAP message; determining whether at least one security rule is associated with the SOAP message, the least one security rule being associated with a security policy for SOAP messages which can be exchanged between at least one client program and at least one server program; and performing at least one operation based on the at least one security rule when the determining determines that at least one security rule is associated with the SOAP message.
- As a computer-implemented method for protecting a server program from service attacks, one embodiment of the invention includes the acts of: receiving a SOAP message; determining whether at least one rule is associated with the SOAP message; collecting data that may be required to evaluate the at least one rule; evaluating the at least one rule at least partially based on the collected data; and determining whether the SOAP message constitutes a service attack based on the evaluating of the at least one rule.
- As a computer-implemented method of controlling publication of or access to a SOAP interface associated with one or more server programs, one embodiment of the invention includes the acts of: identifying a SOAP interface for which publication or access is requested; determining whether one or more rules are associated with the SOAP interface, evaluating the SOAP interface; and determining whether publication of or access to the SOAP interface should be granted based on the evaluating of the SOAP interface. It should be noted that the one or more rules can describe one or more policies with respect to publication of or access to the SOAP interface.
- As a computer-implemented method for processing SOAP messages, another embodiment of the invention includes the acts of: receiving a SOAP message; determining whether at least one rule is associated with the SOAP message; evaluating the at least one rule based on at least one portion of the SOAP message; and determining whether an action should be taken with respect to the SOAP message based on the evaluating of the at least one rule.
- Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.
- The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:
-
FIG. 1 depicts a conventional distributed computing environment. -
FIG. 2 is a simplified block diagram of a computing environment with reference to which a generalized embodiment of the present invention is described. -
FIGS. 3A-3B illustrate a traffic manager operating in a distributed computing environment in accordance with a more specific embodiment of the invention. -
FIG. 3C illustrates a method for facilitating communication between a client node and a server node in a distributed computing environment in accordance with one embodiment of the invention. -
FIG. 3D illustrates a method for processing SOAP messages in accordance with one embodiment of the invention. -
FIG. 4 illustrates a security method suitable for providing security for SOAP messages exchanged between a client and a server program in accordance with one embodiment of the invention. -
FIG. 5 illustrates a security method suitable for providing security for SOAP messages exchanged between a client and a server program in accordance with another embodiment of the invention. -
FIG. 6 illustrates a security method for providing security for server programs running in one or more computing nodes in accordance with yet another embodiment of the invention. -
FIG. 7 illustrates a method for controlling access to and/or publication of SOAP interfaces. -
FIG. 8 illustrates a processing method for processing SOAP messages in accordance with one embodiment of the invention. - As noted in the background, extensive efforts have been made to facilitate communication between various computing nodes which make up a distributed computing environment. Unfortunately, conventional approaches fail to solve many problems associated with communication between computer programs in distributed computing environments. One such shortcoming is that the conventional approaches fail to provide a solution which can simultaneously and efficiently bridge the many disparate characteristics which typically exist between the nodes that make up a distributed computing environment.
- Accordingly, the invention pertains to techniques suitable for facilitating communication between various computer programs operating on various nodes in a distributed computing environment. In accordance with one aspect of the invention, a traffic manager is disclosed. The traffic manager is capable of monitoring traffic exchanged between client and server programs operating in the distributed computing environment. Moreover, the traffic manager can be used to implement a variety of desirable features across different computing environments. These computing environments are typically separated by one or more distinguishing characteristics. As will be appreciated, the traffic manager provides an integral and cost effective solution which can bridge these distinguishing characteristics as well as define and enforce policies across disparate applications and computing environments.
- According to various embodiments, this is achieved by centralizing the generation of interfaces which allow interaction between any of the nodes in a distributed computing system. That is, instead of enabling each node to generate the necessary interfaces for communicating with each other type of node in the system, the present invention abstracts and centralizes this function so that a single node or set of nodes is responsible for affecting the communication between disparate nodes. This avoids the redundancy and inefficiency inherent in building these capabilities in each node, particularly in complex systems. Another advantage is that the present invention can provide control for enforcing Information Technology (IT) and/or business policies and procedures. This can be achieved when the interfaces are compatible or incompatible.
- Embodiments of the invention are discussed below with reference to
FIGS. 2-8 . However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments. -
FIG. 2 is a simplified block diagram of acomputing environment 201 with reference to which a generalized embodiment of the present invention will be described. The distributedcomputing environment 201, which can be any of a wide variety of distributed computing environments, includes computing nodes A, B and C which can communicate with the computing node D. By way of example, various client programs can be running in each of the computing nodes A, B, and C and a server program can be running in the node D. Typically, the client programs running in the computing nodes A, B and C request one or more services from one or more server programs running in the computing node D. These requests for services are managed by theintermediary traffic manager 200 as described below. - As will be appreciated, the
traffic manager 200 can be implemented using one or more physical components (physical components 1-N). Each of these physical components can, for example, be a computing node with memory and a central processing unit. In any case, thetraffic manager 200 facilitates communication between any of the computing nodes in the distributedcomputing environment 201.Traffic manager 200 can publish one or more message interfaces, for example, message Interfaces 202, 203 and 204. The message Interfaces 202, 203 and 204 can respectively be used by the computing nodes A, B and C. In other words, various client programs running on different computing nodes in thecomputing environment 201 can use a different message interface in order to invoke services which are provided by one or more programs running on computing node D. - According to a more specific embodiment, the
traffic manager 200 operates to manage the data traffic in thecomputing environment 201. That is, thetraffic manager 200 monitors the data generated by the computing nodes A, B and C and determines whether the data should be transmitted to the computing node D. Moreover, thetraffic manager 200 maps a set of service requests generated by the client programs running in computing nodes A, B and C into a set of service requests which are directed to one or more server programs running in the computing node D. As such, thetraffic manager 200 may perform a mapping between two application interfaces. - As illustrated in
FIG. 2 , thetraffic manager 200 can facilitate mapping of, for example, themessage interface 202 to asecond message interface 205. As will be appreciated, this mapping can be done based on at least one policy. Such policies are typically implemented to bridge one or more disparate characteristics that exist between the computing nodes A, B, C, and D, and/or to enforce common procedures or policies within a homogenous environment and may be implemented using rules stored in a storage medium 206 associated with thetraffic manager 200. -
FIG. 3A illustrates atraffic manager 300 operating in a distributedcomputing environment 301 in accordance with a more specific embodiment of the invention. In the described embodiment, thetraffic manager 300 uses the Simple Object Access Protocol (SOAP) in order to facilitate communication between aclient program 302 and a server program 304.Programs 302 and 304 may each reside on one or more computing nodes in any of a wide variety of network topologies. For example,client program 302 may reside on a single client machine while server program 304 is distributed across a plurality of servers. In addition, the nodes on whichprograms 302 and 304 reside may be on the same local area network (LAN) or in a wide area network (WAN) such as the Internet or World Wide Web. Regardless of the network topology in which the programs are operating, thetraffic manager 300 allows theclient program 302 to access (or invoke) one or more services provided by the server program 304 using the Simple Object Access Protocol. The data transmitted betweenprograms 302 and 304 can be, for example, in Extensible Markup Language (XML) format. It should be noted that other formats, for example, multimedia formats or office file formats (e.g., .jpeg, .wav, .doc, etc.) can be attached. - In response, for example, to a request received from the
client program 302, thetraffic manager 300 can read a Web Services Description Language (WSDL) file 306 associated with server program 304. The WSDL 306 provides a detailed technical description specifying aSOAP interface 308. TheSOAP interface 308 is the interface to the one or more services which are provided by the server program 304. As such, the WSDL provides information aboutinterface 308 so that these services can be accessed. It should be noted that an optional Universal Description, Discovery and Integration directory (UDDI) 310 may initially be accessed in order to, among other things, get information about the WSDL file 306. - In any case, after the
traffic manager 300 reads the WSDL file 306, the traffic manager can generate and/or publish one or morecorresponding WSDL file 312 and acorresponding SOAP interface 314. In other words, thetraffic manager 300 can generate one or more SOAP interfaces (e.g.,SOAP Interface 314 shown inFIG. 3A ). Typically, thetraffic manager 300 may generate multiple variants of the underlying interface (not shown). For example, different variants of the SOAP interface for each security model and/or for different business partners can be generated. - The
SOAP Interface 314 may also provide a Common interface by whichclient program 302 and any other program or node in the system may transparently invoke one or more services associated with the server program 304. According to specific embodiments, WSDL file 312 andSOAP interface 314 are generated at least partially based on data stored in apersistent storage medium 315. The data stored in thepersistent storage medium 315 can, for example, include rules, policies, a mapping of users with organizational roles (e.g., an LDAP directory), etc. As will be appreciated, these can be used, for example, to define interfaces, approve interfaces, define policies and rules, review operational data, etc. - According to one embodiment, a person (e.g., application developer and/or business analyst, etc.) 316 may interact with the
traffic manager 300, for example, through a Graphical User Interface. Accordingly, theWSDL file 312 andSOAP Interface 314 can be generated by thetraffic manager 300 at least partly based on input provided by a person. It should also be noted that thetraffic manager 300 may optionally publish theWSDL file 312 in aUDDI 319. - As noted above, the
traffic manager 300 generates the correspondingSOAP Interface 314 for theSOAP Interface 308. Accordingly, theclient program 302 can access (or invoke) the services provided by the server program 304 through theSOAP interface 314. Referring toFIG. 3B , theclient program 302 reads theWSDL file 312 in order to obtain information regarding theSOAP Interface 314. It should be noted that theclient program 302 may initially access theoptional UDDI 319 in order to locate theWSDL 312 file. In any case, after theclient program 302 reads theWSDL file 312, theclient program 302 can use theSOAP interface 314 to communicate with thetraffic manager 300. Typically, theclient program 302 transmits aSOAP message 320 through theSOAP interface 314. The SOAP message can be a request for one or more services from the server program 304. TheSOAP message 320 can, for example, include data in an XML format. The SOAP message may also include other attachments (e.g., .gif files, .wav files, etc.). - The
traffic manager 300 can, in turn, perform a variety of operations on theSOAP message 320. For example, thetraffic manager 300 may discard, hold, store, or forward theSOAP message 320. Thetraffic manager 300 may also transform theSOAP message 320 into anotherSOAP message 322 which is sent to the server program 304 and/or one or more other programs (not shown) in the distributedcomputing environment 301. - As noted above, the
SOAP message 320 can be a request for one or more services. Accordingly, thetraffic manager 300, among other things, can determine whether a request for invocation of the same and/or different services should be made from the server program 304 and/or other server programs (not shown) in the distributedcomputing environment 301. This determination can be made at least partially based on the data stored in thepersistent storage 315. Based on this determination, thetraffic manager 300 can map a request made by theclient program 302 through theSOAP Interface 314 to a request for services from the server program 304 through theSOAP Interface 308. In other words, aSOAP message 322 can be generated by thetraffic manager 300 and transmitted to the server program 304 and/or other server programs (not shown). TheSOAP message 322 corresponds to theSOAP message 320 and can be a request for the same or different set of services provided by the server program 304. Accordingly, thetraffic manager 300 can monitor the data traffic between theclient program 302 and server program 304 and/or other server or client programs in the distributedcomputing environment 301. - Moreover, the
traffic manager 300 can be used to manage the services provided by the server program 304 and/or other server programs in the distributedcomputing environment 301. This allows the services which are offered by the server program to be mapped to possibly a different set of services which are actually provided to theclient program 302. This provides control over the access of services in a distributed computing environment and allows implementation of various policies across different computing nodes which typically possess one or more disparate characteristics. -
FIG. 3C illustrates amethod 350 for facilitating communication between a client node and a server node in a distributed computing environment. Themethod 350 can, for example, be used by thetraffic manager 300 ofFIGS. 3A and 3B . Initially, atoperation 352, a first UDDI is read to locate the appropriate WSDL file associated with an interface to one or more server programs. Next, atoperation 354, the WSDL file is read. The WSDL file typically describes a first interface which can be used to access one or more services provided by one or more server programs. Thereafter, atoperation 356, at least one interface (a second interface) is generated (or published) based on at least one policy. This provides one or more interfaces to the services provided by the one or more servers. Accordingly, security mapping function can be abstracted and centralized. Again, this avoids the redundancy and inefficiency inherent in building these capabilities in each node, particularly in complex systems. Furthermore, control over enforcement of Information Technology (IT) and/or business policies and procedures can be achieved. It should be noted that this can be achieved when the interfaces are compatible or incompatible. - Accordingly, at
operation 358, a second WSDL file which describes the at least one generated (or published) interface is generated (or published). Finally, atoperation 360, at least one UDDI entry associated with the generated (or published) WSDL file is created (or updated). Themethod 350ends following operation 360. -
FIG. 3D illustrates amethod 380 for processing SOAP messages in accordance with one embodiment of the invention. Themethod 380 can, for example, be used by thetraffic manager 300 ofFIGS. 3A and 3B . Initially, atoperation 382, a SOAP message is received. Next, atoperation 384, a determination is made as to whether at least one rule is associated with the SOAP message. Such rules are typically generated with reference to one or more policies. If it is determined atoperation 384 that no rule is associated with the SOAP message, themethod 380 ends. However, if it is determined atoperation 384 that at least one rule is associated with the SOAP message, themethod 380 proceeds to operation 386 where any such rule is evaluated for the SOAP message. Thereafter, atoperation 388, the SOAP message is processed based on the result of the evaluation. Themethod 380ends following operation 388. - As noted above, one aspect of the invention allows implementation of various policies across different computing nodes which typically possess one or more disparate characteristics. By way of example,
FIG. 4 illustrates asecurity method 400 suitable for providing security for SOAP messages exchanged between a client and a server program in accordance with one embodiment of the invention. As will be appreciated, thesecurity method 400, for example, is suitable for providing a security model mapping between the client and server programs which operate in a distributed operating environment. Accordingly, security mapping function can be abstracted and centralized so a single node or set of nodes which are responsible for affecting the communications between disparate nodes. Again, this avoids the redundancy and inefficiency inherent in building these capabilities in each node, particularly in complex systems. - Referring to back to
FIG. 4 , initially, at operation 402, a SOAP message is received. Next, at operation 404, a message type is determined for the SOAP message. Thereafter, at operation 406, the rules associated with the message type are looked up. Accordingly, atoperation 408, a determination is made as to whether at least one decryption rule is associated with the SOAP message. If it is determined atoperation 408 that at least one decryption rule is associated with the SOAP message, thesecurity method 400 proceeds tooperation 410 where a determination is made as to whether the SOAP message is encrypted. If it is determined atoperation 410 that the SOAP message is encrypted, thesecurity method 400 proceeds tooperation 412 where an attempt is made to decrypt the SOAP message using one or more keys which are identified by at least one decryption rule. The decryption keys typically correspond to (or are managed by) an organization or an organizational rule. - Next, at operation 414, a determination is made as to whether the attempt to decrypt the SOAP message was successful. If it is determined at operation 414 that the attempt to decrypt the SOAP message was not successful, the
security method 400 proceeds to operation 416 where appropriate action is taken, as defined by the decryption rule. For example, an alarm can be sent. However, operation 416 is bypassed if it is determined at operation 414 that the attempt to decrypt the SOAP message was successful. - In any case, following operation 416 or directly from
operations security method 400 can proceed tooperation 418 where a determination is made as to whether at least one encryption rule is associated with the SOAP message. If it is determined atoperation 418 that no encryption rule is associated with the SOAP message, thesecurity method 400 proceeds to operation 420 where the SOAP message is sent to one or more server programs. Thesecurity method 400 ends following operation 420. However, if it is determined atoperation 418 that at least one encryption rule is associated with the SOAP message, thesecurity method 400 proceeds tooperation 422 where the SOAP message is encrypted using one or more keys which are associated with the encryption rule before the message is sent to one or more server programs at operation 420. In any case, thesecurity method 400 ends following operation 420. -
FIG. 5 illustrates a security method 500 suitable for providing security for SOAP messages exchanged between a client and a server program in accordance with another embodiment of the invention. Similar to thesecurity method 400 ofFIG. 4 , the security method 500, for example, is suitable for providing a security model mapping between the client and server programs which operate in a distributed operating environment. Accordingly, security mapping function can be abstracted and centralized so a single node or set of nodes which are responsible for affecting the communications between disparate nodes. Again, this avoids the redundancy and inefficiency inherent in building these capabilities in each node, particularly in complex systems. - According to a specific embodiment, the security method 500 can, for example, be used to verify signatures and/or sign messages using keys (or identifiers) which are recognized or used by the client and server programs. Initially, at
operation 502, a SOAP message is received. Next, at operation 504, a message type is determined for the SOAP message. Thereafter, at operation 506, the rules associated with the message type are looked up. Accordingly, atoperation 508, a determination is made as to whether at least one signature verification rule is associated with the SOAP message. If it is determined atoperation 508 that a signature verification rule is associated with the SOAP message, the security method 500 proceeds to operation 510 where at least one signature associated with the SOAP message is verified according to the at least one signature verification rule. Next, at operation 512, a determination is made as to whether the signatures have successfully been verified. If it is determined at operation 512 that the one or more signatures have not been successfully verified, the security method 500 proceeds tooperation 514 where appropriate action is taken as defined by the signature verification rule. For example, an alarm can be sent. Thereafter, the security method 500 proceeds to operation 516 where a determination is made as to whether there is at least one signing rule associated with the SOAP message. It should be noted that if it is determined at operation 512 that the one or more signatures have been successfully verified, the security method 500 bypassesoperation 514 and proceeds directly to operation 516. It should also be noted that if it is determined atoperation 508 that there are no signature verification rules associated with the SOAP message, the security method 500 also directly proceeds to the operation 516. - If it is determined at operation 516 that there are no signing rules associated with the SOAP message, the security method 500 proceeds to operation 518 where the SOAP message is processed (e.g., the SOAP message is sent to one or more servers). The method 500 ends following operation 518. However, if it is determined at operation 516 that there is at least one signing rule associated with the SOAP message, the security method 500 proceeds to operation 520 where at least one portion of the SOAP message is signed using one or more keys which are associated with the at least one signing rule. Thereafter, at operation 518 the SOAP message is processed. The method 500 ends following the operation 518.
-
FIG. 6 illustrates asecurity method 600 for providing security for server programs running in one or more computing nodes in accordance with yet another embodiment of the invention. Thesecurity method 600 can, for example, be used by thetraffic manager 300 ofFIGS. 3A and 3B . As will be appreciated, themethod 600 is especially suited for protecting server programs against service attacks which are typically initiated by one or more client programs. Initially, at operation 602, a SOAP message is received. The SOAP message is typically a request for one or more services from one or more server programs. Next, atoperations 604, 606 and 608 the message type, sender node, and recipient node are respectively determined. Thereafter, at operation 610, applicable rules for the message type, sender node, and recipient node are retrieved. Accordingly, at operation 612, a determination is made as to whether data needs to be collected to evaluate the retrieved rules. The determination made at operation 612 can, for example, determine the extent of the history (or log) for the SOAP messages that need to be considered. Histories (or logs) can be maintained for various message categories. These message categories can, for example, include messages of a particular type, all messages sent by a sender node, messages received by the recipient node, etc. - In any case, after data has been collected, the
security method 600 proceeds to operation 614 where the first rule associated with the SOAP message is tested using the collected data. Next, at operation 616, a determination is made as to whether the first rule indicates that a service attack has been made. If it is determined at operation 616 that a service attack has been made, thesecurity method 600 proceeds tooperation 618 where service is denied and remedial action is taken. The remedial action taken can, for example, include notifying an administrator, holding the SOAP message, etc. Thesecurity method 600ends following operation 618. - On the other hand, if it is determined at operation 616 that the first rule does not indicate a service attack, the
security method 600 proceeds tooperation 620 where a determination is made as to whether there are more rules associated with the SOAP message. If it is determined atoperation 620 that there are no additional rules associated with the SOAP message, thesecurity method 600 proceeds to operation 624 where the SOAP message is processed (e.g., transformed and/or forwarded). Thesecurity method 600 ends following operation 624. - However, if it determined at
operation 620 that there is at least one additional rule associated with the SOAP message, thesecurity method 600 proceeds to operation 622 where the next rule associated with the SOAP message is tested using the collected data. Next, thesecurity method 600 proceeds to operation 616 where a determination is made as to whether the rule indicates a service attack. Thereafter, thesecurity method 600 proceeds in the same manner as discussed above. Thesecurity method 600 ends either followingoperation 618 where service is denied and remedial action is taken or after the operation 624 where the SOAP message is processed. - As will be appreciated, one aspect of the invention allows for the enforcement of various policies with respect to the various services provided in a distributed computing environment. In one embodiment, a traffic manager (e.g.,
traffic manager 300 ofFIGS. 3A and 3B ) is used to facilitate control over access and/or publication of SOAP interfaces. The traffic manager provides a user interface which is used to interact with the traffic manager. The user interface can be used, for example, by a programmer to make a request with respect to a particular SOAP interface (e.g., publication of a new SOAP interface, modification and/or access to an existing SOAP interface, etc.). The traffic manager may also facilitate the approval process of such requests. That is, the traffic manager can provide a user interface that can be used, for example, by an administrator to facilitate the approval process through interaction with the user interface. -
FIG. 7 illustrates a method 700 for controlling access to and/or publication of SOAP interfaces. The method 700 can, for example, be used by thetraffic manager 300 ofFIGS. 3A and 3B . This allows centralized control over the access to and/or publication of the SOAP interfaces. As will be appreciated, this allows implementation and enforcement of policies with respect to access to and/or publication of the SOAP interfaces. Moreover, these policies can be implemented while avoiding the redundancy and inefficiencies inherent in conventional approaches. - Referring back to
FIG. 7 , initially, atoperation 702, a SOAP interface is identified. The SOAP interface can, for example, be a pre-existing SOAP interface or a SOAP interface which has just been developed. By way of example, a programmer (or developer) may identify the SOAP interface by interacting with a user interface of a traffic manager which facilitates the process of controlling access and/or publication of SOAP interfaces. The programmer may, for example, identify a newly developed SOAP interface in order to request approval for publication of the SOAP interface. Alternatively, the programmer may seek permission to access an existing SOAP interface and/or request modifications to it, and so forth. - Similarly, at operation 704, a WSDL file for the SOAP interface is identified. Next, at operation 706, the rules which apply to the SOAP interface are input. This operation can be performed, for example, by the programmer through a user interface associated with the SOAP traffic manager. The SOAP traffic manager can perform a search and output the rules which apply to the SOAP interface. Next, at
operation 708, one or more additional rules for the SOAP interface and/or existing rules to be associated with the interface are specified. Again, this operation can be performed, for example, by the programmer through a user interface associated with the SOAP traffic manager. - At
operation 710, a request is queued for approval. Next, at operation 712, the approval process for the request is initiated. The approval process can, for example, be initiated by an administrator. The administrator can interact with a user interface of the SOAP traffic manager which facilitates the approval process. At operation 714, a review is made as to whether any existing rules apply to the request (e.g., whether any rules apply to the identified SOAP interface). Again, this determination can, for example, be made by the administrator who uses an interface of the SOAP traffic manager to initiate a search for the applicable rules. - At operation 716 a determination is made as to whether any modifications should be made to what has been requested for approval (e.g., whether modification should be made to the SOAP interface and/or one or more rules). If it is determined at operation 716 that there is a need to make modifications to what has been requested for approval, the method 700 proceeds to
operation 718 where appropriate modifications to the request can be made. Next, the method 700 proceeds tooperation 720 where a determination is made as to whether the request should be approved. It should be noted that if it is determined at operation 716 that there is no need to make any modifications, the method 700 bypassesoperation 718 and proceeds directly tooperation 720 where a determination is made as to whether the request should be approved. - In any case, if it is determined at
operation 720 that the request should not be approved, the method 700 proceeds to operation 722 where appropriate action can be taken (e.g., the programmer who made the request can be notified). The method 700 ends following operation 722. However, if it is determined atoperation 720 that the request should be approved, the method 700 proceeds tooperation 724 where the request is approved and/or implemented (e.g., a SOAP interface is published, access to the SOAP interface is allowed, new rules or modification to rules are in effect, etc.). The method 700ends following operation 724. - Yet another aspect of the invention provides for conditional data processing (or conditional data flow) of messages exchanged between client and server programs in a distributed computing environment. The conditional data processing (or conditional data flow) of messages is another example of the many functionalities that can be provided using the invention. Moreover, this functionality can be abstracted and centralized so as to avoid the redundancy and inefficiency inherent in building these capabilities into each node, particularly in complex systems. Another advantage is that control over enforcement of Information Technology (IT) and/or business policies and procedures can be achieved. This can be achieved when the interfaces are compatible or incompatible.
-
FIG. 8 illustrates aprocessing method 800 for processing SOAP messages in accordance with one embodiment of the invention. Theprocessing method 800 can, for example, be used by thetraffic manager 300 ofFIGS. 3A and 3B . Initially, at operation 802 a SOAP message is received. Next, atoperations operation 809, one or more authentication identifiers are determined. The authentication identifiers can, for example, be associated with the sender or receiver nodes. Thereafter, atoperation 810, any rules associated with the message type, sender node, and recipient node are identified. Accordingly, atoperation 812, a determination is made as to whether at least one data review or conditional flow rule is associated with the SOAP message. If it is determined atoperation 812 that at least one rule is associated with the SOAP message, theprocessing method 800 proceeds tooperation 814 where data is gathered from the SOAP message as specified by the data review/conditional flow rule. Next, at operation 816, the data review/conditional flow rule is evaluated using the data gathered from the SOAP message. - Accordingly, at
operation 818, a determination is made as to whether action is required. If it is determined atoperation 818 that action is required, theprocessing method 800 proceeds tooperation 820 where appropriate action can be taken. These actions can, for example, include holding the SOAP message, archiving the SOAP message, failing SOAP message delivery, sending a notification, logging special notification, modifying the data in the message, sending side-effect SOAP messages, invoking Java methods and so on. - After appropriate action is taken, the
processing method 800 proceeds tooperation 822 where a determination is made as to whether there are more data review/conditional flow rules to evaluate. It should be noted that if it is determined atoperation 818 that no action is required, theprocessing method 800 bypassesoperation 820 and directly proceeds tooperation 822. - If it is determined at
operation 822 that there is at least one data review/conditional flow rule to evaluate, theprocessing method 800 proceeds tooperation 814 where data is gathered from the SOAP message as specified by the data review/conditional flow rule. Thereafter, theprocessing method 800 proceeds in a similar manner as discussed above. On the other hand, if it is determined atoperation 822 that there are no data review/conditional flow rules to evaluate, theprocessing method 800 proceeds to 824 where the processing of the SOAP message is completed (e.g., the SOAP message is delivered). Theprocessing method 800 ends following operation 824. - The many features and advantages of the present invention are apparent from the written description, and thus, it is intended by the appended claims to cover all such features and advantages of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation as illustrated and described. For example, several embodiments of the invention are described with reference to SOAP and SOAP interfaces. It will be understood, however, that the scope of the present invention includes other protocols and mechanisms by which the interaction of disparate nodes in a distributed computing environment may be facilitated. Hence, all suitable modifications and equivalents may be resorted to as falling within the scope of the invention.
Claims (20)
1. A computer-implemented method of processing SOAP messages, the method comprising:
receiving a SOAP message;
determining whether at least one rule is associated with the SOAP message;
evaluating the at least one rule based on at least a portion of the SOAP message; and
determining whether an action should be taken with respect to the SOAP message based on the evaluating of the at least one rule.
2. The method of claim 1 wherein at least one portion of the SOAP message comprises data in an XML format.
3. The method of claim 2 wherein the SOAP message comprises an attachment having at least one of a multimedia format and an office file format.
4. The method of claim 1 wherein the SOAP message comprises a request for one or more services.
5. The method of claim 1 wherein determining whether at least one rule is associated with the SOAP message comprises:
determining for the SOAP message: (1) a message type; (2) a sender node; (3) a recipient node; and (4) one or more authentication identifiers; and
identifying rules associated with the message type, the sender node, the recipient node and the one or more identifiers.
6. The method of claim 5 wherein the one or more authentication identifiers are associated with one of the sender node and the recipient node.
7. The method of claim 1 wherein the at least one rule associated with the SOAP message comprises at least one of a data review rule and a conditional flow rule.
8. The method of claim 1 wherein the at least one rule associated with the SOAP message is generated based on a policy.
9. The method of claim 1 wherein evaluating the at least one rule based on at least a portion of the SOAP message comprises:
gathering data from the SOAP message as specified by the at least one rule; and
evaluating the at least one rule based on the gathered data.
10. The method of claim 1 wherein the action comprises at least one of holding the SOAP message, archiving the SOAP message, failing SOAP message delivery, sending a notification, logging special notification, modifying data in the SOAP message, sending side-effect SOAP messages and invoking Java methods.
11. A computer program product comprising a computer usable medium including a computer readable program, wherein the computer readable program when executed on a computer causes the computer to:
receive a SOAP message;
determine whether at least one rule is associated with the SOAP message;
evaluate the at least one rule based on at least a portion of the SOAP message; and
determine whether an action should be taken with respect to the SOAP message based on the evaluating of the at least one rule.
12. The computer program product of claim 11 wherein at least one portion of the SOAP message comprises data in an XML format.
13. The computer program product of claim 12 wherein the SOAP message comprises an attachment having at least one of a multimedia format and an office file format.
14. The computer program product of claim 11 wherein the SOAP message comprises a request for one or more services.
15. The computer program product of claim 11 wherein the computer readable program when executed on a computer also causes the computer to:
determine for the SOAP message: (1) a message type; (2) a sender node; (3) a recipient node; and (4) one or more authentication identifiers; and
identify rules associated with the message type, the sender node, the recipient node and the one or more identifiers.
16. The computer program product of claim 15 wherein the one or more authentication identifiers are associated with one of the sender node and the recipient node.
17. The computer program product of claim 11 wherein the at least one rule associated with the SOAP message comprises at least one of a data review rule and a conditional flow rule.
18. The computer program product of claim 11 wherein the at least one rule associated with the SOAP message is generated based on a policy.
19. The computer program product of claim 11 wherein the computer readable program when executed on a computer also causes the computer to:
gather data from the SOAP message as specified by the at least one rule; and
evaluate the at least one rule based on the gathered data.
20. The computer program product of claim 11 wherein the action comprises at least one of holding the SOAP message, archiving the SOAP message, failing SOAP message delivery, sending a notification, logging special notification, modifying data in the SOAP message, sending side-effect SOAP messages and invoking Java methods.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/782,261 US20100229244A1 (en) | 2001-12-11 | 2010-05-18 | Traffic manager for distributed computing environments |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/015,502 US7480799B2 (en) | 2001-12-11 | 2001-12-11 | Traffic manager for distributed computing environments |
US12/341,742 US7743250B2 (en) | 2001-12-11 | 2008-12-22 | Traffic manager for distributed computing environments |
US12/782,261 US20100229244A1 (en) | 2001-12-11 | 2010-05-18 | Traffic manager for distributed computing environments |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/341,742 Continuation US7743250B2 (en) | 2001-12-11 | 2008-12-22 | Traffic manager for distributed computing environments |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100229244A1 true US20100229244A1 (en) | 2010-09-09 |
Family
ID=21771776
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/015,502 Expired - Lifetime US7480799B2 (en) | 2001-12-11 | 2001-12-11 | Traffic manager for distributed computing environments |
US12/341,742 Expired - Fee Related US7743250B2 (en) | 2001-12-11 | 2008-12-22 | Traffic manager for distributed computing environments |
US12/782,261 Abandoned US20100229244A1 (en) | 2001-12-11 | 2010-05-18 | Traffic manager for distributed computing environments |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/015,502 Expired - Lifetime US7480799B2 (en) | 2001-12-11 | 2001-12-11 | Traffic manager for distributed computing environments |
US12/341,742 Expired - Fee Related US7743250B2 (en) | 2001-12-11 | 2008-12-22 | Traffic manager for distributed computing environments |
Country Status (1)
Country | Link |
---|---|
US (3) | US7480799B2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103475565A (en) * | 2012-06-08 | 2013-12-25 | 中兴通讯股份有限公司 | Method of transmitting message attachment on enterprise service bus (ESB) and apparatus thereof |
US20150222444A1 (en) * | 2014-02-04 | 2015-08-06 | Dipankar Sarkar | System and method for reliable multicast data transport |
Families Citing this family (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7739328B1 (en) | 2001-12-11 | 2010-06-15 | Actional Corporation | Traffic manager for distributed computing environments |
US7480799B2 (en) * | 2001-12-11 | 2009-01-20 | Actional Corporation | Traffic manager for distributed computing environments |
US20040015578A1 (en) * | 2002-02-22 | 2004-01-22 | Todd Karakashian | Web services runtime architecture |
US7769825B2 (en) * | 2002-02-22 | 2010-08-03 | Bea Systems, Inc. | System and method for web services Java API-based invocation |
US20030217044A1 (en) * | 2002-05-15 | 2003-11-20 | International Business Machines Corporation | Method and apparatus of automatic method signature adaptation for dynamic web service invocation |
US20040003033A1 (en) * | 2002-06-27 | 2004-01-01 | Yury Kamen | Method and system for generating a web service interface |
US20040006653A1 (en) * | 2002-06-27 | 2004-01-08 | Yury Kamen | Method and system for wrapping existing web-based applications producing web services |
US7512975B2 (en) * | 2002-08-16 | 2009-03-31 | Intel Corporation | Hardware-assisted credential validation |
US20040039812A1 (en) * | 2002-08-22 | 2004-02-26 | Connelly Stephen P. | Method of collecting data from heterogeneous test and measurement device and apparatus using same |
US7356616B2 (en) * | 2002-11-06 | 2008-04-08 | Microsoft Corporation | Maintaining structured time data for electronic messages |
US7991827B1 (en) * | 2002-11-13 | 2011-08-02 | Mcafee, Inc. | Network analysis system and method utilizing collected metadata |
JP3969654B2 (en) * | 2003-03-07 | 2007-09-05 | インターナショナル・ビジネス・マシーンズ・コーポレーション | SOAP message creation method and processing method, information processing method, information processing apparatus, and program |
US7711832B1 (en) * | 2003-09-22 | 2010-05-04 | Actional Corporation | Enabling existing desktop applications to access web services through the use of a web service proxy |
US8453196B2 (en) * | 2003-10-14 | 2013-05-28 | Salesforce.Com, Inc. | Policy management in an interoperability network |
US7822826B1 (en) * | 2003-12-30 | 2010-10-26 | Sap Ag | Deployment of a web service |
US7827608B2 (en) * | 2005-02-08 | 2010-11-02 | International Business Machines Corporation | Data leak protection system, method and apparatus |
KR100678903B1 (en) * | 2005-09-07 | 2007-02-05 | 삼성전자주식회사 | Apparatus for providing web service, apparatus for managing web service and method for the same |
US8078671B2 (en) * | 2005-09-21 | 2011-12-13 | Sap Ag | System and method for dynamic web services descriptor generation using templates |
US20070067388A1 (en) * | 2005-09-21 | 2007-03-22 | Angelov Dimitar V | System and method for configuration to web services descriptor |
US20070067384A1 (en) * | 2005-09-21 | 2007-03-22 | Angelov Dimitar V | System and method for web services configuration creation and validation |
US9454616B2 (en) * | 2005-09-28 | 2016-09-27 | Sap Se | Method and system for unifying configuration descriptors |
US8700681B2 (en) | 2005-09-28 | 2014-04-15 | Sap Ag | Method and system for generating schema to java mapping descriptors |
US20070073771A1 (en) | 2005-09-28 | 2007-03-29 | Baikov Chavdar S | Method and system for directly mapping web services interfaces and java interfaces |
US8250522B2 (en) | 2005-09-28 | 2012-08-21 | Sap Ag | Method and system for generating a web services meta model on the java stack |
US7698684B2 (en) * | 2005-09-28 | 2010-04-13 | Sap Ag | Method and system for generating schema to Java mapping descriptors and direct mapping of XML schema and Java interfaces |
US20070156872A1 (en) * | 2005-12-30 | 2007-07-05 | Stoyanova Dimitrina G | Method and system for Web services deployment |
US7814060B2 (en) * | 2005-12-30 | 2010-10-12 | Sap Ag | Apparatus and method for web service client deployment |
US8024425B2 (en) * | 2005-12-30 | 2011-09-20 | Sap Ag | Web services deployment |
US8010695B2 (en) * | 2005-12-30 | 2011-08-30 | Sap Ag | Web services archive |
US20070245018A1 (en) * | 2006-04-12 | 2007-10-18 | International Business Machines Corporation | Dynamic access control in a content-based publish/subscribe system with delivery guarantees |
US20080178010A1 (en) | 2007-01-18 | 2008-07-24 | Vaterlaus Robert K | Cryptographic web service |
US20080259930A1 (en) * | 2007-04-20 | 2008-10-23 | Johnston Simon K | Message Flow Model of Interactions Between Distributed Services |
KR100900989B1 (en) * | 2007-10-09 | 2009-06-04 | 오토스테크 주식회사 | Device for supplying air for welding mask |
US7805485B2 (en) | 2008-01-28 | 2010-09-28 | Sharp Laboratories Of America, Inc. | Web services interface extension channel |
CN102812431A (en) | 2010-03-22 | 2012-12-05 | Lrdc系统有限公司 | A method of identifying and protecting the integrity of a set of source data |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020010781A1 (en) * | 1999-12-30 | 2002-01-24 | Tuatini Jeffrey Taihana | Shared service messaging models |
US20020026473A1 (en) * | 2000-08-31 | 2002-02-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Application-programming-interface-based method and system including triggers |
US20020161826A1 (en) * | 2001-01-25 | 2002-10-31 | Carlos Arteaga | System and method for remote communication transactions |
US20030005174A1 (en) * | 2001-06-29 | 2003-01-02 | Coffman Daniel M. | System and method for providing dialog management and arbitration in a multi-modal environment |
US20030061404A1 (en) * | 2001-09-21 | 2003-03-27 | Corel Corporation | Web services gateway |
US20030074579A1 (en) * | 2001-10-16 | 2003-04-17 | Microsoft Corporation | Virtual distributed security system |
US6732175B1 (en) * | 2000-04-13 | 2004-05-04 | Intel Corporation | Network apparatus for switching based on content of application data |
US6801604B2 (en) * | 2001-06-25 | 2004-10-05 | International Business Machines Corporation | Universal IP-based and scalable architectures across conversational applications using web services for speech and audio processing resources |
US6807636B2 (en) * | 2002-02-13 | 2004-10-19 | Hitachi Computer Products (America), Inc. | Methods and apparatus for facilitating security in a network |
US7313822B2 (en) * | 2001-03-16 | 2007-12-25 | Protegrity Corporation | Application-layer security method and system |
US7464154B2 (en) * | 2001-05-18 | 2008-12-09 | Network Resonance, Inc. | System, method and computer program product for analyzing data from network-based structured message stream |
US7480799B2 (en) * | 2001-12-11 | 2009-01-20 | Actional Corporation | Traffic manager for distributed computing environments |
US7739328B1 (en) * | 2001-12-11 | 2010-06-15 | Actional Corporation | Traffic manager for distributed computing environments |
-
2001
- 2001-12-11 US US10/015,502 patent/US7480799B2/en not_active Expired - Lifetime
-
2008
- 2008-12-22 US US12/341,742 patent/US7743250B2/en not_active Expired - Fee Related
-
2010
- 2010-05-18 US US12/782,261 patent/US20100229244A1/en not_active Abandoned
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020010781A1 (en) * | 1999-12-30 | 2002-01-24 | Tuatini Jeffrey Taihana | Shared service messaging models |
US6732175B1 (en) * | 2000-04-13 | 2004-05-04 | Intel Corporation | Network apparatus for switching based on content of application data |
US20020026473A1 (en) * | 2000-08-31 | 2002-02-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Application-programming-interface-based method and system including triggers |
US20020161826A1 (en) * | 2001-01-25 | 2002-10-31 | Carlos Arteaga | System and method for remote communication transactions |
US7313822B2 (en) * | 2001-03-16 | 2007-12-25 | Protegrity Corporation | Application-layer security method and system |
US7464154B2 (en) * | 2001-05-18 | 2008-12-09 | Network Resonance, Inc. | System, method and computer program product for analyzing data from network-based structured message stream |
US6801604B2 (en) * | 2001-06-25 | 2004-10-05 | International Business Machines Corporation | Universal IP-based and scalable architectures across conversational applications using web services for speech and audio processing resources |
US20030005174A1 (en) * | 2001-06-29 | 2003-01-02 | Coffman Daniel M. | System and method for providing dialog management and arbitration in a multi-modal environment |
US20030061404A1 (en) * | 2001-09-21 | 2003-03-27 | Corel Corporation | Web services gateway |
US20030074579A1 (en) * | 2001-10-16 | 2003-04-17 | Microsoft Corporation | Virtual distributed security system |
US7480799B2 (en) * | 2001-12-11 | 2009-01-20 | Actional Corporation | Traffic manager for distributed computing environments |
US7739328B1 (en) * | 2001-12-11 | 2010-06-15 | Actional Corporation | Traffic manager for distributed computing environments |
US6807636B2 (en) * | 2002-02-13 | 2004-10-19 | Hitachi Computer Products (America), Inc. | Methods and apparatus for facilitating security in a network |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103475565A (en) * | 2012-06-08 | 2013-12-25 | 中兴通讯股份有限公司 | Method of transmitting message attachment on enterprise service bus (ESB) and apparatus thereof |
US20150222444A1 (en) * | 2014-02-04 | 2015-08-06 | Dipankar Sarkar | System and method for reliable multicast data transport |
US9900168B2 (en) * | 2014-02-04 | 2018-02-20 | Dipankar Sarkar | System and method for reliable multicast data transport |
Also Published As
Publication number | Publication date |
---|---|
US7480799B2 (en) | 2009-01-20 |
US20090106841A1 (en) | 2009-04-23 |
US20030110373A1 (en) | 2003-06-12 |
US7743250B2 (en) | 2010-06-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7743250B2 (en) | Traffic manager for distributed computing environments | |
US7903656B2 (en) | Method and system for message routing based on privacy policies | |
JP4594621B2 (en) | Supplying aggregate services in a distributed computing environment | |
CN101194233B (en) | System and method of testing wireless component applications | |
US7412501B2 (en) | Event consumers for an event management system | |
US7752431B2 (en) | Virtual distributed security system | |
US7562388B2 (en) | Method and system for implementing security devices in a network | |
JP5043950B2 (en) | Method and system for synchronization policy control in a web service environment | |
US6985958B2 (en) | Messaging infrastructure for identity-centric data access | |
JP3995338B2 (en) | Network connection control method and system | |
US20030130953A1 (en) | Systems and methods for monitoring the presence of assets within a system and enforcing policies governing assets | |
US20020161903A1 (en) | System for secure access to information provided by a web application | |
US20030074579A1 (en) | Virtual distributed security system | |
US20080222652A1 (en) | Method and Apparatus for Data Transfer Across a Network | |
US20020133535A1 (en) | Identity-centric data access | |
US20060106748A1 (en) | System and method for orchestrating composite web services in constrained data flow environments | |
JP2000112848A (en) | Data exchange management system | |
US20060155812A1 (en) | Management of network devices via email | |
US7523492B2 (en) | Secure gateway with proxy service capability servers for service level agreement checking | |
US7739328B1 (en) | Traffic manager for distributed computing environments | |
US8301800B1 (en) | Message processing for distributed computing environments | |
Ferris | Web services architecture | |
Neumann et al. | Universal Utility Data Exchange (UUDEX)–Protocol Design-Rev 1 | |
WO2003060800A2 (en) | Systems and methods for monitoring the availability of assets within a system and enforcing policies governing assets | |
EP1669865A1 (en) | Message communication over a computer network including a message store |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |