WO2006027777A2

WO2006027777A2 - Method and system for message content based policy implementation, execution and management

Info

Publication number: WO2006027777A2
Application number: PCT/IL2005/000946
Authority: WO
Inventors: Eyal Maor; Eliezer Gur; Gideon Kaempfer
Original assignee: Silverkite Ltd.
Priority date: 2004-09-07
Filing date: 2005-09-07
Publication date: 2006-03-16
Also published as: WO2006027777A3

Abstract

A method and system for implementation, execution and management of policies. The system comprises a. a policy management layer (PML) operative to define policies using automatic identification of applications extracted from message content, each policy including at least one classifying condition and at least one action; and a policy execution layer (PEL) operative to perform the at least one action on each message following policy directives received from the PML. The method comprises steps of defining the policy using the automatic identification, executing the policy, and monitoring the execution of the policy, whereby the policy is defined and enforced centrally within the network fabric. The policies are applied to applicative messages and their content. Preferably, the messages are selected from the group consisting of a XML message, a SOAP message and an EDI message.

Description

METHOD AND SYSTEM FOR MESSAGE CONTENT BASED POLICY IMPLEMENTATION, EXECUTION AND MANAGEMENT

FIELD OF THE INVENTION The present invention relates to computer networks and, more particularly, to methods, apparatuses and systems facilitating the definition, execution, deployment and monitoring of policies based on document characteristics, schema language or similar script, in networks carrying messages generated in structured languages such as mark-up languages.

BACKGROUND OF THE INVENTION

The new wave in markup language evolution started from SGML (Standard Generalized Markup Language) and continues with XML (extensible Markup Language) for the purpose of not only representing data but also exchanging data between applications in a generic format.

The advantage of XML is mainly in its extensibility, in contrast to HTML, which is a closed standard. XML allows the definition of new elements and data structures and exchange of such definitions between devices. In addition it remains readable to humans and appropriate for representation. Thus, any data element in XML can be defined by a developer of a document and understood by any device that receives it. By providing a common method for identifying data, XML allows better, open, and standard business-to-business transactions. XML is expected to become the dominant format for electronic data interchange. In addition, as described above, XML is by nature a superset of HTML and therefore can also be used to generate HTML files that can be displayed by web browsers. When moving from static browser based usage to machine-to- machine data exchange, XML has moved to a different domain and has become an architecture building block for enterprise IT application infrastructures. Built on top of XML₅ Web Services are emerging to facilitate standard XML based message exchange in which different services are described.

The rapid adoption of XML and the importance of the information it represents require infrastructure software (SW) and hardware (HW) that are both flexible and robust to be able to manage in a more efficient manner the vast amount of new traffic being exposed to the network by applications and systems.

The Service Oriented Architecture (SOA) is aimed at creating a foundation layer where Web Services (WS) and XML based applications can be used in an efficient manner, thus enabling the benefit of their inherent flexibility efficiency and reusability. However, creating such an environment needs systems in place that can perform tasks like routing messages, enforcing security and privacy, transforming data and applying other policies to the data in the network.

Current networking equipment is focused on packet level screening. It filters the raw data of the first few packets in a data stream in order to make decisions such as load balancing and forwarding decisions that can then be applied to the rest of the packets in the data stream, with no further analysis of these packets. Typical data analysis of network equipment is performed exclusively on packet headers, and at best on HTTP headers (that may span more than a single packet). However, when payload analysis is required, this is typically performed only by the servers receiving the data streams in a distributed fashion that doesn't lend itself to policy driven control, which is based on a holistic network view. Moreover, performing this analysis on servers where the application resides contradicts the required separation between the governed application and the governing operation due to interdependencies within the same server.

In an SOA environment, an application can run on many different servers and identical services can be deployed in many different places. Therefore, it becomes inefficient to delegate applicative traffic control to the servers themselves. In an SOA environment where resources are dynamically allocated to Web Services, it becomes crucial that policies be defined and enforced centrally within the network fabric.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention and to show more clearly how it could be applied, reference will now be made, by way of example only, to the accompanying drawings in which:

FIG. 1 shows one embodiment of a three-layer schema based policy implementation and enforcement architecture of the present invention;

FIG. 2 shows schematically the structure of a policy;

FIG. 3 shows a schematic block diagram of an embodiment of the policy execution device of the present invention;

Figure 4 shows an exemplary schematic physical topology of a network in which the policy execution is implemented according to the present invention; Figure 5 shows an exemplary XML message. SUMMARY OF THE INVENTION

The present invention discloses a system and method for creating and managing policies for an SOA infrastructure based on message content in such a way that policy creation may be automated to a great extent, strongly reducing the need for tedious manual configuration. All this is done while still capturing the essence of application level policy management and enforcement typically required in Web Services and other distributed environments. In the present invention, a "policy" may refer to application governance, traffic control, data manipulation as well as system wide monitoring at the application level. Also disclosed are devices operative to execute the policies. According to the present invention there is provided a method for implementation, execution and management of policies comprising the steps of defining a policy using automatic identification of applications extracted from message content, the policy including at least one classifying condition and at least one action, executing the policy; and monitoring the execution of the policy, whereby the policy is defined and enforced centrally within the network fabric. According to one aspect of the method of the present invention, the step of defining a policy includes providing a policy management layer operative to perform the defining and the step of executing includes providing a policy execution layer having devices and operative to perform the at least one action.

According to another aspect of the method of the present invention, the step of defining a policy includes creating automatically a default policy.

According to yet another aspect of the method of the present invention, the step of defining a policy including at least one classifying condition and at least one action includes defining a policy including at least one condition selected from the group consisting of a message content condition, a message envelope condition, an environmental and temporal condition, and a combination thereof, and at least one action selected from the group consisting of a control action, a governance and compliance action, a monitoring action and a combination thereof.

According to yet another aspect of the method of the present invention, the using automatic identification of applications extracted from message content includes classifying messages according to a set of conditions predefined by the PML. According to yet another aspect of the method of the present invention, the step of defining a policy including at least one classifying condition defining at least one primary condition for primary partitioning of message traffic and at least one secondary condition for action selection within the context of the primary partition.

According to yet another aspect of the method of the present invention, the primary partitioning is derived by prioritizing classification results thereby resolving an ambiguous classification.

According to yet another aspect of the method of the present invention, the step of executing the policy includes receiving at least one message, classifying each message according to a set of conditions to provide the at least one action, executing the at least one action, and transmitting the at least one message. According to yet another aspect of the method of the present invention, the classifying each message includes performing an initial message classification to improve execution efficiency, and, based on the initial classification, selecting secondary classification conditions.

According to yet another aspect of the method of the present invention, the step of executing further includes resolving conflicts between actions arising from the classification, before the execution.

According to yet another aspect of the method of the present invention, the step of executing further includes ordering the actions before the execution.

According to yet another aspect of the method of the present invention, the step of executing further comprises recording information selected from the group consisting of messages, message characteristics, message time of arrival, condition evaluation results, selected actions, conflict resolution results, action execution success, action execution failures, action execution results and a combination thereof.

According to yet another aspect of the method of the present invention, the step of executing further comprises recording information regarding each message. According to yet another aspect of the method of the present invention, the step of executing further comprises recording information regarding each message.

According to yet another aspect of the method of the present invention, the step of monitoring further includes providing automatic suggestions and/or requests of new policy definitions. According to yet another aspect of the method of the present invention, the step of monitoring includes providing automatic policy advice and generation based on predefined parameters selected from the group consisting of knowledge, existing policies and information from traffic recording.

According to yet another aspect of the method of the present invention, the information from traffic recording includes at least one of a set of application indicating parameters. According to yet another aspect of the method of the present invention, the providing automatic policy advice includes applying the policy automatically as a new policy.

According to yet another aspect of the method of the present invention, the message content includes content included in a message selected from the group consisting of a XML message, a SOAP message and an EDI message. According to the present invention there is provided in a SOA infrastructure in which messages are created and transmitted through a network fabric, a system for implementation, execution and management of policies, the system comprising a policy management layer operative to define policies using automatic identification of applications extracted from message content, each policy including at least one classifying condition and at least one action, and a policy execution layer operative to perform the at least one action on at least one message following policy directives received from the PML

According to one feature in the system of the present invention, the PEL includes a network of devices selected from the group consisting of a centralized network and a distributed network of devices. According to another feature in the system of the present invention, the at least one action includes an action selected from the group consisting of traffic classification and message handling.

According to yet another feature in the system of the present invention, the system further comprises an application platform layer operative to execute applications involving the messages. According to yet another feature in the system of the present invention, the APL is operative to interact with the PML in order to dynamically control various aspects of message handling through the PML.

According to yet another feature in the system of the present invention, each device is operative to execute policies and includes a two-stage message classification function, a primary classifier function operative to partition messages into message types predefined by the PML, each message belonging to one message type, and a secondary classifier function operative to evaluate only a subset of secondary conditions relevant to a particular message type, the evaluation resulting in actions affecting each message.

According to yet another feature in the system of the present invention, each device further includes an action conflict resolver function operative to resolve actions selected by the secondary classifier function.

According to yet another feature in the system of the present invention, each device further includes an additional element selected from the group consisting of an action order resolver operative to resolve an order in which the actions are performed, an action results recorder used for recording action results and traffic control functions and a policy advice generator for generating information for automatic policy creation by the PML.

According to yet another feature in the system of the present invention, a device includes a device selected from the group consisting of a hardware appliance, a software application and a combination thereof.

According to yet another feature in the system of the present invention, the message content includes content included in a message selected from the group consisting of a XML message, a SOAP message and an EDI message.

According to the present invention there is provided a device for enforcing policies based on a combination of primary and secondary classifications applied to messages, the each policy including at least one classifying condition and at least one action, the device comprising a primary classifier function operative to receive and partition the messages into message types predefined by a policy management layer (PML), each message belonging to one message type, and a secondary classifier function operative to evaluate only a subset of secondary conditions relevant to a particular message type, the evaluation resulting in actions affecting each message.

According to one feature in the device of the present invention, the device further comprises an action conflict resolver function operative to resolve conflicting actions selected by the secondary classifier function.

According to another feature in the device of the present invention, the device further comprises an additional element selected from the group consisting of an action order resolver operative to resolve an order in which the actions are performed, an action results recorder used for recording action results and traffic control functions and a policy advice generator for generating information for automatic policy creation by the PML. According to yet another feature in the device of the present invention, the device is selected from the group consisting of a hardware appliance, a software application and a combination thereof.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS General Architecture

FIG. 1 shows one embodiment of a 3-layer schema-based policy implementation and enforcement architecture 100 of the present invention, implementable in an enterprise environment. Architecture 100 comprises a top Policy Management Layer (PML) 102 responsible for defining the policies to be executed on XML/WS traffic in a SOA environment; a middle Policy Execution Layer (PEL) 104 responsible for performing actions as defined by the policies; and a bottom Application Platform Layer (APL) 106, typically comprising application servers. The APL may include a controlled part 108 which is just the subject of the policies and a controlling part 110 which creates new policies using the PML. Other embodiments of the invention can be based on similar architectures applied to messages in any format, exemplarily formats such as EDI, SMTP, HTTP or binary formats such as CORBA or HOP.

PML 102 may be configured by applications within the enterprise through an interface 112. This interface may exemplarily be an API or Web Service interface, a Graphical User Interface (GUI) or other typical interfaces (e.g. a command line interface or SNMP).. PEL 104 receives policy directives from PML 102 via a form of application interface (e.g. a simple HTTP connection). In addition, PEL 104 also monitors APL 106 as well as the traffic patterns within the SOA and uses this to perform actions on the traffic accordingly. The optional policy control path indicates that the APL may in turn be the consumer of PML policies as well as a generator of new policies, as described above. The PEL defines a functionality that may be performed by dedicated hardware (HW) appliances ("devices"), a software (SW) application or some mix of HW and SW For simplicity, the functionality is referred to hereinafter as implemented in devices. Policy Management Layer

The PML is a single application centrally controlling the PEL devices. The PML provides the means to develop, test, deploy and monitor policies to be applied to XML/Web Services traffic, as well as other traffic formats such as EDI, HTTP, SMTP or other messages, traveling within the SOA. In one embodiment, this layer may be implemented as a central application installed on a dedicated server. It may also be run as an integral part of a device already used in the network such as an existing server or networking device capable of running general purpose applications. Policy Execution Layer

The Policy Execution Layer may be a centralized or distributed network of devices that handle messages as they travel in the network from one application platform to another. The tasks of the Policy Execution Layer may be assigned to existing servers (also responsible for other tasks) which function in this case as virtual Policy Execution Layer devices. These devices may create an overlay network above the standard networking layers (e.g. IP, TCP, HTTP) and below application specific logic. Together these devices create the plumbing of an application fabric, such as one typically found in a Service Oriented Architecture (SOA) based on WS. In most cases, such a fabric will transfer messages in one or a few formats such as XML, EDI, SMTP or other common message formats.

The PEL performs operations on the messages according to the policy directives received from the PML. These operations are defined/based on traffic classification capabilities corresponding to the conditions that may be defined by the policies and on? message handling capabilities corresponding to the actions that may be defined by these policies.

In addition, the PEL is responsible for monitoring the status of the devices within the layer as well as devices forming the APL (e.g. application servers, web servers, blade servers etc.). This information may include livelihood of the monitored devices as well as their current and historic performance and load metrics such as response time, throughput and tasks allocated to them by the Policy Execution Layer in the past. This information is typically used to allow intelligent load balancing of tasks over a set of resources based on predefined conditions and actual traffic flow patterns. Application Platform Layer The APL is comprised of servers executing applications (e.g. web servers, application servers, database servers etc.) and other platforms such as integration platforms (e.g. IBM MQ Series) that are the sources and destinations of the messages sent through the Policy Execution Layer.

Typically, the APL need not play an active role in controlling the PEL since the policies may be defined by human operators based on standard information emanating from the applications such as XML schema referrals. However, in more sophisticated environments, the applications may interact with the PML via a Web Service interface (or other standards based application message interface) in order to dynamically control forwarding, QoS, data processing or other aspects relating to messages they intend to send. In such an environment, the PML enables the PEL to be exposed as a service rather than as part of an underlying infrastructure over which applications have no control. Policy definition

FIG. 2 shows schematically the structure of a policy 200. Policy 200 may comprise at least one classification condition 202 that defines the messages it applies to and actions 204 to be performed once such a message is identified. The at least one classification condition may refer to the content of a message, its lower layer protocol envelopes as well as environmental and temporal information. Actions may include passive monitoring directives, governance directives that may divert or interfere with non-complying messages, traffic control directives affecting traffic flow as well as content-altering directives.

It is possible that multiple policies are applicable to a given message. Policies as well as actions within a policy may be prioritized. This prioritization may be used to resolve conflicts in situations where more than a single policy is applicable or where actions to be performed (within a policy or in separate policies) may have conflicting results. The full procedure of message handling is schematically depicted in FIG. 3.

The conditions may include one or a combination of the following items (but not limited to):

Message content conditions: a. Explicit XML schema (see http://www.w3.org/XML/Schema^"). DTD (see http://www.w3.org/TR/REC-xml/), WSDL (see http://www.w3.org/TR/wsdD, or namespace (see http://www.w3.org/TR/REC-xml-namesΛ references. The reference to a schema, DTD, WSDL or namespace may imply the application(s) the message is associated with. b. Explicit existence or content of SOAP (see http://www.w3.org/TR/soap/) header field. SOAP headers may indicate a reference to an application by their mere existence or explicitly by reference to a specific application related context. c. Explicit EDIF SEF references (see http://www.edidev.com/SEF.htm^'). An EDI message may refer to a known message type that is formally defined by. an EDI SEF file. This notion is similar to that applied above in the context of an XML message and its schema. d. XML schema or DTD implicit conformance. By comparing the structure of a message to a given XML schema or DTD, it may be deduced that a message belongs to a certain class of interest, even if the message itself does not explicitly state this. For example, a message may conform to a standard financial transaction schema it refers to, but by comparing its structure to an external schema identifying important transactions (e.g. high volume transactions) a policy can be defined to handle these transactions with the appropriate care. e. Implicit EDI SEF conformance — similar to the above but in the context of EDI messages. f. XPath or XQuery expressions - an XPath expression (see http://www.w3.org/TR/xpath) or an XQuery expression (see http://www.w3.org/TR/xqueryΛ may define a condition on a sub element of an XML message. By using a XPath or XQuery expression as a condition for policy execution, policies may be defined on various message sets regardless of their application level origin or their entire structure (as typically expressed in a XML schema). g. Other explicit references to message structure definition. These may include standard or non-standard references such as protocol names, version numbers or other identifiers that may identify applications that policies may be applied to. This may apply to XML, EDI, SMTP, HTTP or other message structures. h. Other implicit structural conformance. As mentioned, XML and EDI support several standard and formal mechanisms for defining a message structure (and hence allow the verification of this structure). However, it is possible that non-standard or less well known mechanisms exist to achieve this same goal for XML and EDI as well as SMTP, HTTP or other message types. In this case, it is possible to integrate these mechanisms as a black box comparison capability, allowing the formal identification of a message structure that may imply the need to apply a policy to the message. i. Known application identification indicators. In addition to the conditions based on standard XML and EDI notions as described above, applications may also have different, and possibly more complex, identification characteristics. These may be a combination of several conditions as described above or non-standard criteria that may be applied to the message content, such as the execution of a known algorithm to determine the result of classification (e.g. usage of certain schema combinations and a sum of values of certain elements not exceeding a given number. Message envelope conditions j. MAC source and destination addresses k. VLAN tags

1. IP source and destination addresses m. MPLS tags n. ATM labels o. TCP/UDP port numbers (sockets) p. HTTP header fields, SMTP header fields and other session layer protocol fields.

Environmental and temporal conditions q. Monitored server load (expressed in CPU utilization, number of connections or other parameters). r. Monitored traffic load (expressed in messages per second or bits per second). This may refer to all traffic traversing the Policy Execution Layer or to a subset of the messages identified according to specific content or envelope conditions as mentioned above. s. Policy Execution Layer device status. t. Date and time of day.

Messages are classified based on the above conditions and other optional conditions. This classification may be used for a variety of actions to be performed depending on the standing enterprise policies. The following actions may be supported by the system:

Control actions

^Message forwarding. The forwarding of messages to a given destination. The definition of the destination may be explicit (e.g. by an IP address) or indirectly inferred by application identification, service identification, URL, URN or other means. b.Quaϊiiy of Service (QoS) assignment. This may be performed based on Layer2 (Ethernet) or Layer3 (IP) as well as higher level QoS services (e.g. integration platform, XML and Web

Services standards related to level of service) as well as affect the internal handling by the Policy

Execution Layer itself. c.Load balancing. This may take into account various parameters including relative server strength, measured server load as well as assigned server load as affected by previous Policy

Execution Layer forwarding decisions. Of course, since message content defines the action to be performed, the expected effect a message may have on the target server may also be taken into account in the load balancing decision.

Governance and compliance actions ά.Vaϊidation. Verification of adherence of messages to explicitly or implicitly defined message structures including XML schemas, XML DTD, EDI SEF or other standard or non- standard structural definition formats as well as rules defined by regulatory compliance bodies including but not limited to HIPAA compliance, FinCEN, OPAC₅ or HL7.

^..Encryption enforcement. Enforcement of encryption or non-encryption of certain information within the message. This may be done according to standard mechanisms such as XML Encryption (see http://www.w3.org/TR/xml-encrvption-reql EDI encryption (Xl 2.58) or non-standard mechanisms. f. Signature enforcement. Enforcement of signature existence on sensitive information. This may be done according to standard mechanisms such as XML Signature (see http://www.w3.org/TR/xml dsig-core/) or non standard mechanisms. g-Signature verification. Verification that signatures on a message or message segments are authentic.

^.Credentials verification. Enforcing access to applications of data content is only enabled for users or applications that have the required credentials. This will typically require interaction with a central secure access control application. i. Message dropping. This may be used to discard unwanted or potentially harmful messages.

Monitoring actions ^.Accounting. Counting of messages per policy or per condition. j. Recording. Storing of messages or message extracts per policy or per condition. ^Auditing. Logging of certain traffic patterns in the context of user or application privileges.

1. Alerting. Based on failure of governance checks or any condition specified. Content manipulation actions: m. Transformation. Transformations between XML dialects or between XML and other formats such as EDI or binary formats as well as transformations between these formats. This includes data extraction intended for application acceleration or other purposes. This is typically performed based on XSLT (see http://www.w3.org/TR/xslt) style sheets.

^.Encryption. Encryption of message or message segments according to predefined standard or non-standard algorithms and keys. o. Decryption. Decryption of message or message segments according to predefined standard or non-standard algorithms and keys. ^Signing. Automatic insertion of digital signatures on entire messages or message segments according to predefined standard or non-standard algorithms and keys.

Returning now to FIG. 3, the figure shows a schematic block diagram of a policy execution device 350 according to the present invention. Device 350 comprises a message receiver function

352 for receiving messages from the network; a primary message classifier function 354 for classifying the messages according to a set of conditions predefined by the PML; a secondary message classifier function 356 for evaluating only a sub-set of conditions based on the classification results in function 354 also predefined by the PML; an action conflict resolver function 358 for resolving conflicting actions that may be selected by independent conditions

(rules). This function is needed for example when one rule states: "if CONDI then ENCRYPT MESSAGE" and another rule states: "if COND2 then DECRYPT MESSAGE". The conflict resolution function is required assuming a message cannot be encrypted and decrypted simultaneously (priorities are associated to each rule to do this); an optional order resolver function

360 for resolving the order of operations. For example, some actions depend on possible results of previous actions (e.g. signing and then encrypting of certain content). Changing the order of performing such operations may result in different outcome (messages); an action execution module 362 used to accumulate and execute a list of ordered and non conflicting actions; a condition and action results recorder (storage) 364 used for traffic monitoring, reporting, governance and compliance checks (which are not part of the traffic flow but useful for feedback to the policy creator - human or automatic); a policy advice generator 366 for generating specific information for the automatic creator of policies (also called "policy advisor"); and a message receiver function 352 for transmitting messages to the network. In some embodiments, functions 354 and 356 may be united in one module. In some embodiments, action results recorder 364 and policy advice generator 366 may be removed without significantly affecting the functionality of device 350. In some embodiments, message receiver function 352 and message transmitter function 368 may be optional if the modules were to receive messages from a non-network medium (e.g. shared memory or other storage).

In use, messages are received by message receiver 352, are classified according to a set of conditions predefined by the PML using functions 354 and 356. If existing, conflicts between classification results are resolved by function 354 (e.g. by a priority mechanism defined by PML), and based on this initial classification, secondary classification conditions are selected for classification by function 356. Actions are selected based on the secondary classification results. Conflicts between actions are resolved by function 358 (e.g. by additional priority mechanism defined by PML). Actions are arranged in an order to be executed by function 360 (e.g. based on an order defined by PML), and are executed by module 362. The actions may include message altering actions such as encryption, destination selection actions, as well as passive actions such as logging. If necessary and optionally, messages are modified in module 362, which also decides on a required message destination. Recorder 364 logs information regarding messages handled to be used by users and policy advice mechanisms, policy advice generator 366 derives policy advice based on stored classification results, and function 368 forwards the messages to required destination The message classification steps carried out by functions 354 and 356 can be further divided into initial classification and secondary classification. The initial classification (in 354) includes the substeps of: a. Partitioning messages into message classes based on application indicators (e.g. namespace references, schema references or Xpath queries). b. Resolving conflicts between classification results based on priority mechanism allowing each message to be classified as belonging to one and only one message class (or "type"), and. c. In the event a message is not designated as any explicitly defined message class, implying it belongs to a Default Message Class. The secondary classification (in 356) includes the substeps of: d. Classifying messages within each message class again based on conditions specific to the message class, allowing multiple secondary classification results to co-exist. e. ^! Selecting actions to be performed based on all classification results.

Policy advice generator 366 is operative to perform the following:

1. Consult the knowledge base to define new designated classification conditions on policy execution elements identifying traffic to apply new policies to.

2. Suggest new policies to the user based on feedback from policy execution elements that identified traffic matching designated classification conditions.

3. Update the knowledge base based on user policy updates (adding or removing suggestions) and return to item 1.

In more detail, policy advice generator 366 may:

1. Inspect the following information sources: a. Predefined knowledge base linking a known set of conditions to a potential set of policies to be suggested. b. Network traffic classification results as performed by the policy execution elements, c. Policies defined by the user of the Policy Management Layer.

2. Based on the information above: a. Define new classification conditions to trigger new policy suggestions by the policy execution entity. Two types of conditions may be defined: i. Secondary conditions taken from the knowledge base to be defined as secondary conditions for the Default Message Type (see Message Classification Method). ii. Secondary conditions as defined by the user for user defined message types

(primary classification) to be defined as secondary conditions for the Default Message Type. b. For these conditions, define new entries in the knowledge base suggesting new policies (conditions and actions) triggered by the conditions met including new message type classifiers

(based on primary condition identifiers) and secondary conditions to execute the actions that would have been associated with the secondary conditions had they been met in the context of a user defined message type (or as predefined in the knowledge base). c. Based on policy execution entity classification results, inspect associated knowledge base and suggest new policies to user.

3. In the event of user policy updates, return to item 1. Automatic policy creation

In order to facilitate policy creation, certain default policies may be created automatically as described above with reference to policy advice generator 366. Initially, the PEL devices may be used to monitor the traffic and extract samples of messages flowing through them. These messages may be analyzed for their application identifying content (e.g. the XML schemas they use) and appropriate explicit "no-operation" or "passive monitoring" policies may be created. For instance, for every identified XML schema used, a policy may be set up to count the number of messages running through PEL devices with this schema. This policy may later on be used by the PEL human operator as a basis for the creation of business policies relating to the identified traffic streams. Since XML schemas frequently correlate with specific applications, in many cases meaningful new policies may be created merely by slightly altering the automatic policies to include actions such as attributing a given QoS level to the relevant messages. In addition, relatively small variations on such policies (e.g. by adding an XPath expression to the classification condition) may allow the definition of policies for subsets of traffic related to a given schema, expressing a policy relating to specific messages associated with a specific application (e.g. limiting of the size of a given financial transaction). Policy testing

Once policies have been defined, they may be tested prior to production deployment. This testing phase is intended to minimize failures due to errors in policy configuration as well as enable simulation of potential future policies. Policies may be tested on various levels, including but not limited to:

1. Simulated policy level testing: A message may be submitted to be handled according to a tested policy and the result may then be manually or automatically inspected to verify the correct effect was achieved. This may possibly be achieved by simulating the behavior of a single condition (and the related actions) in addition to the behavior in the context of a complex set of conditions grouped together as a single policy.

2. Simulated device level testing: A message may be submitted to a simulator simulating the behavior of a device loaded with a given set of policies, and the result may be inspected to verify the correct policy was chosen to affect the message. In addition, by storing a historical set of tested policies and the messages they were tested against, it may be possible to verify that older policies continue to have the desired effect they were designed for. 3. Simulated network level testing: A message may be submitted to a simulator simulating a network of devices all configured with appropriate policies closely resembling the intended deployment configuration. Since in a production network, the effect of a policy may have an aggregate effect on the Policy Execution Layer that cannot be modeled by a single device, this type of testing may be extremely useful.

4. Live network testing: Before deployment of a policy, it may be beneficial to deploy it on a device in a mode where it does not yet take effect but only generates a form of log that describes what it would have caused had it been in effect. In this way, policy developers can test in an environment that is identical to their intended deployment environment without taking the risk of deploying a faulty policy.

The extent of policy testing may vary according to the environment where they need to be deployed, the anticipated risk in deploying a faulty policy and the complexity of the newly deployed policy. The testing environment may offer some or all of the above testing tools. Policy deployment Once it has been established that a policy needs to be deployed, deployment may be scheduled and facilitated by the policy management application for delivery to the devices executing the policies. Policy monitoring and alerting

Following deployment, policies may be monitored to ensure their correct behavior by logging their effect on network traffic flow as well as lack of such effect. The monitoring is based on information accumulated by the Policy Execution Layer devices. Monitored information may be stored in various forms of data repositories for archiving, conformance, off-line analysis or any other kind of further processing. This information may be reported directly by the policy management application, exported automatically to a network management system such as IBM- Tivoli (IBM Corporation 1133 Westchester Avenue White Plains, New York 10604, USA) or HP Open View (Hewlett-Packard Company, 3000 Hanover Street Palo Alto, CA 94304-1185 USA) or via a variety of reporting mechanisms such as Syslog, XML formatted information or industry standard reporting mechanisms such as Crystal Reports (http://www.businessobjects.com). In addition, monitored information may be compared with pre-configured thresholds that may define critical events that may cause alerts (sent by e-mail, SMS or other means to relevant operators) or trigger automatic procedures for handling such events (e.g. restrict message flow to or from certain regions in a network, encrypt information that is not normally encrypted, etc.). Examples

The following examples describes a possible SOA topology and the procedures for defining, testing, deploying and monitoring of a set of policies. AU following subsections relate to the same general scenario. Example of network and applicative topology

Figure 4 shows an exemplary schematic physical topology of a network in which the policy execution is implemented according to the present invention. It comprises a PML implemented as a policy management application running on a dedicated policy management station 402, a PEL implemented by three policy execution devices 404A-C (servers or dedicated hardware appliances in charge of executing the policies) comprising a SOA infrastructure and an APL comprised exemplarily of five application servers 406 a-e. Policy management station 402 is connected via a network (not explicitly shown) to all policy execution devices 404, which are in turn connected to each other. The application servers are grouped into server farms and are each connected to one of the policy execution devices. Server 406a is a remote server. Servers 406b and 406c are high performance servers residing in a high performance server farm 408 intended for real time and high priority transactions such as high volume financial transactions. Servers 406d and 406e are lower performance servers residing in a low performance server farm 410 intended for low priority or non real time tasks such as inventory management and low volume financial transactions. Server 406a is running a legacy application that sends and expects to receive messages in EDI format. Servers 406b-d are running Web Services applications and exchange messages in SOAP format over HTTP. Example of policies for implementation

Assume that the following policies are to be implemented in this example:

1. EDI messages from server 406a need to be transformed into a well defined SOAP message structure and sent to the low performance server farm.

2. SOAP messages carrying high volume financial transactions should be sent to the high performance server farm if they come from an IP address within the organization. This rule should only be applied during trading hours (between 10am and 4pm).

3. All SOAP messages carrying personal information must be sent to server 406b. 4. SOAP messages sent to the low performance server farm should in aggregate equally load servers 406d and 406e. 5. SOAP messages carrying credit card numbers sent to the remote server 406a must be encrypted or dropped if not.

6. SOAP messages should be checked to comply with their explicitly referenced schemas. If they don't, an alert should be triggered. Example of policy creation

One approach to creating the policies would be to manually (and tediously) define conditions for identifying the relevant messages and applying the appropriate action to each message type. However, the system as described above may also provide a mechanism that can simplify this process by automatically identifying classes of traffic running in the network as described hereafter.

Initially, the policy execution devices are set up to sniff the messages running through them and report explicit schemas or namespace references mentioned within the messages. The policy management application running on the policy management station receives these reports sent by the policy advice generator and creates default passive policies for each of these traffic classes that merely count the number of messages in each class. An example of a message is presented in FIG.

5. In this example, the XML message explicitly mentions two XML name spaces. The first one,

"http://schemas.xmlsoap.org/soap/envelope/", identifies the message as a SOAP message (typical in Web Services traffic). The second one, "http://example.org/FinancialMessages/", identifies the

SOAP message body is carrying a "financial" message. The policy management application will hence be able to create a message class for SOAP messages carrying "financial" information.

The human operator in charge of defining the policies is presented with the following automatically created passive policies:

1. Policy for EDI messages: just count.

2. Policy for "financial" SOAP messages: just count. 3. Policy for all SOAP messages: just count.

4. Policy for all XML messages: just count.

Based on conditions automatically created for the above traffic classes and the required policies described earlier on, the following conditions for traffic classification are defined:

1. EDI message class - this is exactly the condition automatically created by default. 2. High volume transactions class - based on the "financial" SOAP message condition that was automatically created, an additional condition can be added for identifying high volume transactions by performing an XPath query for the "numberofshares" element. 3. High volume transactions during trading class - based on the previous class, but adding that this condition is met only between 10am and 4pm.

4. High volume transactions during trading from within the organization class - based on the previous class, but adding that the IP address range should be of the format 192.168.0.XXX (assuming this is the range of IP addresses used within the organization).

5. Personal information class - in the context of this example, it is assumed that personal information is all SOAP traffic that includes the element personaldetails. Therefore, the condition set can be a combination of the automatically created policy for SOAP messages and an XPath query identifying this element. 6. Credit card class - in the context of this example, it is assumed that credit card information is all SOAP traffic that includes the element CreditCard. Therefore, the condition set can be a combination of the automatically created policy for SOAP messages and an XPath query identifying this element.

After conditions are defined for identifying the various traffic classes of interest, policies may be created for taking the appropriate actions in the desired context. The following policies are hence defined:

1. EDI traffic policy - for the EDI traffic class, perform a transformation script for transforming the messages into the required SOAP message format. This policy is to be deployed only on policy execution device C since it is only relevant for traffic coming from server 406a (alternatively, the traffic class could be defined to include only traffic coming from the IP address of server 406a).

2. High volume transactions during trading from within the organization policy - for the corresponding traffic class, the action taken at policy execution devices 404b and 404c is to forward the traffic to device 404a. Device 404a is configured to send the traffic to server 406b or 406c. Since no business policy was defined regarding the utilization of these servers, device A may be configured to send the messages to these servers at random.

3. Personal information policy - for the corresponding traffic class, the action taken is to send these messages to server 406b.

4. Low performance farm policy - this, policy is based on the general SOAP message class and only applies to execution device 404b. It is configured to send messages to servers 406d and 406e according to a round-robin algorithm. 5. Credit card policy - for the corresponding traffic class, it is validated that the information carried within the CreditCard element is a single element of the type EncryptedData that conforms to a standard encryption format (XML encryption in the case of the sample message above). In case of a validation failure, these messages are configured to be dropped. This is only applied to execution device 404c facing the remote server.

6. Validation enforcement policy - for the general SOAP message class, a validation enforcement flag is set causing validation to be performed.

Example of policy testing

Based on the organizational procedures, the above defined policies may be tested in various ways as described in the "Policy testing" section above. In this example, it is assumed that it is only required to deploy the policies on the production devices without triggering the actions (i.e. live network testing).As a result of this testing deployment, which doesn't initially alter message handling, it is identified that there exists a conflict between the policy defined to handle high volume financial transactions traffic and the policy defined to handle personal information. The latter policy restricts personal information to server 406b while the financial traffic may be sent to server 406c. Of course, this conflict could have been identified in simulation as well, even at the single device level.

Following this discovery, the action conflict may be resolved by assigning a higher policy priority to the personal information policy. The result of this prioritization is that when a message is classified by policy execution device 404a as both carrying personal information as well as a high volume financial transaction, the forwarding decision made by the device is governed by the personal information policy (i.e. "send to server 406b") and not by the financial policy (i.e. "send to server 406b or 406c at random").

Example of policy deployment Once the policies have been satisfactorily tested, they can be deployed to the network. This action is invoked through the policy management application running on the policy management station, which sends the policy directives to the relevant policy execution devices. Note that some policies as defined above only apply to specific execution devices while others apply to all of them. Example of policy monitoring and alerting

Following deployment, the policy execution devices begin executing the new policies. As a result, the policy management station will receive statistics on the policies executed. It may be found that over time, the traffic identified as high volume financial transactions is growing and as a result performance is degrading gradually. This information may trigger the expansion of the high performance server farm intended to cope with the traffic growth. Example of policy execution The policy execution layer in this example is a set of three devices 404a-c. These devices may be equally equipped or may differ in functional or other capabilities. For example, since device 404c will receive the EDI traffic coming from server 406a, it will be the only device in this example required to perform transformation tasks from EDI to XML and vice versa. As a result, it may be desirable to equip it with acceleration hardware dedicate to dialect transformation. The implementation details of the execution device are beyond the scope of this invention and hence this example. Example of APL control of the SOA infrastructure

At first sight, the application platform layer in this example (comprised of just five application servers 406) seems to have no role in the context of this invention. However, it should be noted that it is most likely that even before the deployment of the SOA infrastructure as described; all applications were already in place. The addition of the policy execution devices contributes to the ability to govern the traffic according to the defined policies as well as accelerate traffic manipulation (e.g. by performing the transformations to and from EDI on execution device 404c and not on server 406a). In addition, the overall performance of the application layer is improved by the addition of the load balancing functionality that may not have existed before the implementation of the PEL.

In this example, it has been assumed that high volume transactions are the only type of "important" information to be explicitly directed to the high performance server farm. However, in the real world it may be desirable to allow the applications themselves to define what messages should be identified as "important". For instance, an application logic may exist to allow low volume transactions to be identified as "important" on a dynamic basis, according to various criteria such as the credentials of the person performing the transaction. This information may not be available to the PEL and hence the need may arise to allow applications to communicate ad-hoc conditions and actions to the policy management application. One such example may be to have the application on one of the application servers configure the policy management application with new conditions such as XPath queries, which identify messages that should receive high priority treatment for a limited duration such as 5 minutes. Clearly such a short notice and ad-hoc policies may not be feasibly configurable by a human operator.

AU publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention.

While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made.

Claims

WHAT IS CLAIMED IS

1. In a Service Oriented Architecture (SOA) infrastructure in which messages are created and transmitted through a network fabric, a method for implementation, execution and management of policies comprising the steps of: a) defining a policy using automatic identification of applications extracted from message content, the policy including at least one classifying condition and at least one action; b) executing the policy; and c) monitoring the execution of the policy; whereby the policy is defined and enforced centrally within the network fabric.

2. The method of claim 1, wherein the step of defining a policy includes providing a policy management layer (PML) operative to perform the defining and wherein the step of executing includes providing a policy execution layer (PEL) having devices and operative to perform the at least one action.

3. The method of claim 1, wherein the step of defining a policy includes creating automatically a default policy.

4. The method of claim 1, wherein the step of defining a policy including at least one classifying condition and at least one action includes defining a policy including at least one condition selected from the group consisting of a message content condition, a message envelope condition, an environmental and temporal condition, and a combination thereof, and at least one action selected from the group consisting of a control action, a governance and compliance action, a monitoring action and a combination thereof.

5. The method of claim 2, wherein the using automatic identification of applications extracted from message content includes classifying messages according to a set of conditions predefined by the PML.

6. The method of claim 1, wherein the step of defining a policy including at least one classifying condition defining at least one primary condition for primary partitioning of message traffic and at least one secondary condition for action selection within the context of the primary partition.

7. The method of claim 6, wherein the primary partitioning is derived by prioritizing classification results thereby resolving an ambiguous classification.

8. The method of claim 1 , wherein the step of executing the policy includes i. receiving at least one message, ii. classifying each message according to a set of conditions to provide the at least one action, iii. executing the at least one action, and iv. transmitting the at least one message.

9. The method of claim 8, wherein the classifying each message includes performing an initial message classification to improve execution efficiency, and, based on the initial classification, selecting secondary classification conditions.

10. The method of claim 9, wherein the step of executing further includes resolving conflicts between actions arising from the classification, before the execution.

11. The method of claim 9, wherein the step of executing further includes ordering the actions before the execution.

12. The method of claim 9, wherein the step of executing further comprises recording information selected from the group consisting of messages, message characteristics, message time of arrival, condition evaluation results, selected actions, conflict resolution results, action execution success, action execution failures, action execution results and a combination thereof.

13. The method of claim 10, wherein the step of executing further comprises recording information regarding each message.

14. The method of claim 11, wherein the step of executing further comprises recording information regarding each message.

15. The method of claim 1, wherein the step of monitoring further includes providing automatic suggestions and/or requests of new policy definitions.

16. The method of claim 1, wherein the step of monitoring includes providing automatic policy advice and generation based on predefined parameters selected from the group consisting of knowledge, existing policies and information from traffic recording.

17. The method of claim 16, wherein the information from traffic recording includes at least one of a set of application indicating parameters.

18. The method of claim 16, wherein the providing automatic policy advice includes applying the policy automatically as a new policy.

19. The method of claim 1, wherein the message content includes content included in a message selected from the group consisting of a XML message, a SOAP message and an EDI message.

20. In a Service Oriented Architecture (SOA) infrastructure in which messages are created and transmitted through a network fabric, a system for implementation, execution and management of policies, the system comprising: a) a policy management layer (PML) operative to define policies using automatic identification of applications extracted from message content, each policy including at least one classifying condition and at least one action; and b) a policy execution layer (PEL) operative to perform the at least one action on at least one message following policy directives received from the PML

21. The system of claim 20, wherein the PEL includes a network of devices selected from the group consisting of a centralized network and a distributed network of devices.

22. The system of claim 21, wherein the at least one action includes an action selected from the group consisting of traffic classification and message handling.

23. The system of claim 22, further comprising an application platform layer (APL) operative to execute applications involving the messages.

24. The system of claim 23, wherein the APL is operative to interact with the PML in order to dynamically control various aspects of message handling through the PML.

25. The system of claim 21, wherein each device is operative to execute policies and includes a two-stage message classification function, a primary classifier function operative to partition messages into message types predefined by the PML, each message belonging to one message type, and a secondary classifier function operative to evaluate only a subset of secondary conditions relevant to a particular message type, the evaluation resulting in actions affecting each message.

26. The system of claim 25, wherein each device further includes an action conflict resolver function operative to resolve actions selected by the secondary classifier function.

27. The system of claim 26, wherein each device further includes an additional element selected from the group consisting of an action order resolver operative to resolve an order in which the actions are performed, an action results recorder used for recording action results and traffic control functions and a policy advice generator for generating information for automatic policy creation by the PML.

28. The system of claim 21, wherein a device includes a device selected from the group consisting of a hardware appliance, a software application and a combination thereof.

29. The system of claim 20, wherein the message content includes content included in a message selected from the group consisting of a XML message, a SOAP message and an EDI message.

30. A device for enforcing policies based on a combination of primary and secondary classifications applied to messages, each policy including at least one classifying condition and at least one action, the device comprising: a. a primary classifier function operative to receive and partition the messages into message types predefined by a policy management layer (PML), each message belonging to one message type; and b. a secondary classifier function operative to evaluate only a subset of secondary conditions relevant to a particular message type, the evaluation resulting in actions affecting each message.

31. The device of claim 30, further comprising an action conflict resolver function operative to resolve conflicting actions selected by the secondary classifier function.

32. The device of claim 31, further comprising an additional element selected from the group consisting of an action order resolver operative to resolve an order in which the actions are performed, an action results recorder used for recording action results and traffic control functions and a policy advice generator for generating information for automatic policy creation by the PML.

33. The device of claim 30, selected from the group consisting of a hardware appliance, a software application and a combination thereof.