Service-Oriented Architecture (SOA) is a software system architecture that is realized by connecting independent functional entities capable of completing specific tasks to meet requirements of business integration in an Internet environment. In other words, the SOA is a component model that links different function units (called services) of an application through interfaces and contracts properly defined among these services, wherein the definition of the interfaces is independent from the hardware platform, operating system and programming language for realizing services. The SOA uses the service-oriental modeling technique and WEB service technique to accomplish loose coupling between systems and thus realize integration and cooperation between the systems.
The SOA policy is an important component of the SOA system and is used for declarative description and execution of the SOA system behavior. In the SOA system, the usage of the SOA policy spans different phases across the SOA lifecycle, including design time validation, deployment time policy publication and package and runtime service selection, change management and impact analysis.
Generally, the SOA policy can be classified into the following types in different layers:                Business policy for business decision making and industry guideline compliance, etc.        Application policy for service selection during service invocation, etc.        Governance policy for enforcing rules for standards compliance, and defining system behaviors for governance process, etc.        
A main feature of SOA is that all the data and contexts are described in XML language, and a document containing such data and the contexts is called a SOA metadata document. Generally, the SOA metadata document can include: a service metadata document for describing content relating to a service, a runtime information document for describing content relating to the runtime information, and a document for describing other business content. For example, the service metadata document may use Web Service Description Language (WSDL), XML Schema Definition (XSD), Web Service Policy (WS-Policy), Service Component Definition Language (SCDL), Business Process Execution Language (BPEL), Service Component Architecture (SCA) policy, etc. The runtime information document may use Simple Object Access Protocol (SOAP), Representational State Transfer (REST), etc. The document for describing other business contents may use Service Data Object (SDO), Web Ontology Language (OWL), etc.
Several solutions for generating the SOA policy in the prior art will be briefly introduced as follows:
I. Conventional Business Policy/Rule Definition Tools and Transformation Mechanism
In general, the business rule definition tools use a modeling language or a semi-natural language to express the policies or rules. Additionally, before the policies or rules are enforced, they should be transformed into executable code, such as Java, .NET, etc. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
The business rule definition tools, such as ILOG's JRule™ or Fair Isaac® Blaze Advisor® allow business analysts to author and manage the business rules representing business logic using structured English sentences and phrases compliant with Semantics of Business Vocabulary and Business Rules (SBVR).
The policies or rules defined by the business rule definition tools are layered as different levels, such as a business level, platform independent level, platform specific level, etc., according to a complex model driven architecture.
WebSphere Business Modeler is a business process modeling tool provided by IBM Corporation and has a function of defining the business policies/rules, wherein the business rules can be inserted into the business process. However, the tool is only in conceptual level and only generates an abstract rule framework and textual description.
WebSphere Integration Developer (WID) is an Eclipse based integrated development environment provided by IBM Corporation. It provides a development service for constructing and deploying standard-based business process applications. With the WID tool, a decision table and a rule object can be defined, wherein the decision table is the simplest format for business rule definition and the rule object will be finally implemented in Java. So the flexibility of declarative policy is lost.
The above conventional business policy/rule definition tools have the following limitations:    1. These business policy/rule definition tools generally support complex model driven architecture. Users need to manually author the policy based on rule vocabularies, and then generate the policies/rules of the different levels using the business policy/rule definition tools. As it is difficult to keep a seamless relationship between the policies/rules of the different levels, the business policy/rule definition tool intrinsically cannot perform the transformation between the different levels without losing the semantics and integrity. So the user must manually polish the generated outputs by themselves, which makes the usage of the business policy/rule definition tool complex.    2. Because the finalized policies for enforcement are expressed as executable code, such as Java or .NET program, and the business logic which reflects the business policies or rules are also embedded in the executable codes, the user must reconstruct the updated policies and transform them again when the policies need to be changed with the business requirement. As a result, the flexibility of declarative policy is lost.    3. The policies/rules generated by the above business policy/rule definition tools do not comply with the standards and thus cannot be reused.II. Ontology Based Policy and Corresponding Definition Tools
Web Ontology Language (OWL) is an ontology standard description language recommended by World Wide Web Consortium (W3C). It is a conceptualization specification for one or more domains of knowledge related to specific industry, including OWL Lite sublanguage, OWL DL sublanguage and OWL Full sublanguage.
Semantics Web Rule Language (SWRL) is based on a combination of the OWL DL and OWL Lite sublanguages of the OWL with the Unitary/Binary Datalog RuleML sublanguages of the Rule Markup Language (RuleML). SWRL includes a high-level abstract syntax for Horn-like rules in both the OWL DL and OWL Lite sublanguages of the OWL. It provides model-theoretic semantics to provide the formal meanings for OWL ontology of the policy/rule written in this abstract syntax.
WebSphere Business Services Fabric (WBSF) is a tool provided by the IBM Corporation for supporting business domain service and service policy modeling, development and runtime support. The tool provides a mechanism that provides a dynamic assembler with the acceptable rules for selecting service endpoints. The policy conceptually declares in IF (condition) THEN (assertions) format: if the specified condition (context and content) is met, then the specified contract (in the form of combined assertions) will be produced to match the capabilities defined in the available endpoints, wherein these policies and policy assertions are expressed as the OWL elements.
However, the above ontology based policy definition tool has the following limitations:    1. The policy definition tool heavily relies on the ontology, which depends on a set of complex ontology standards, such as OWL, etc. Thus the policy definition tool is only for description of structure of concepts and objects, and the capability for describing behavior is rather weak.    2. The policy definition is only based on entities described in OWL, and the relations among these entities are not used for policy definition.    3. As all the policies are expressed as the OWL elements, the policy definition and enforcement heavily depend on the OWL engine.III. Service Modeling Language (SML) Rule and Schematron
SML is defined by IBM, Microsoft, BEA, Intel, etc. for XML based IT service management. It provides a rich set of constructs for describing models of complex IT services and systems. The SML model is a set of interrelated XML documents. The XML documents contain information about the parts of an IT service, as well as the constraints which each part must satisfy for the IT service to function properly. The constraints can be described in two ways:    1. Schemas—constraints on the structure and content of a document in the model. SML uses a profile of XML Schema 1.0 as the schema language and also defines a set of extensions to the XML Schema to support inter-document references.    2. Rules—Boolean expressions that constrain the structure and content of a document in a model. SML uses a profile of Schematron and XPath 1.0.
The XML Schema supports a number of built-in grammar-based constraints, but it does not support a language for defining arbitrary rules for constraining the structures and contents of the documents. Schematron is an ISO standard for defining assertions concerning a set of XML documents. The SML uses a profile of the Schematron schema to add support for user-defined constraints. The SML uses XPath 1.0 (which is augmented with smlfn:deref( ) extension function) as its constraint language. The user-defined constraints can be specified using sch:assert and sch:report elements in the Schematron.
The Community Systems Management Open Source (COSMOS) resource modeling sub-project is an open source project for SML modeling and aims to provide support for building a common model to represent the information shared in a system management scenario. The project is proposing to use SML as the XML schema language to define the common model. The Service Modeling Language-Interchange Format (SML-IF) will be used to share the model components between the tools involved in a system management activity.
However, SML is only for validation of a XML document set, and generate text reports. There is no powerful expression mechanism for an action part of the policy to describe and extend the system behavior. It is difficult for users to define the policy/rule manually with SML, especially for non-IT users to define business related policy. In addition, in both the specifications and the existing policy definition tools, there is no linkage between SML and ontology.
Based on the above, all the existing tools for defining the SOA policy have limitations. A new technical solution for generating a SOA policy is needed to solve the problems in the existing tools for defining the SOA policy.
USPTO Backgrounds
USPTO Backgrounds