Patent Application
20120166550
“Business to Business” (B2B) describes commerce transactions between businesses, such as between a manufacturer and a wholesaler and retailer.
“Service oriented architecture” (SOA) refers to an architecture for building and providing a business solution, which divides the business solution into units of services. These service based architectures typically allow for high-reliability at reduced cost due to extensive re-use and modification of existing services. A service oriented architecture provides a method by which modern B2B commerce can be implemented in a flexible and economical manner.
A B2B messaging protocol is a formal description of the B2B message formats and the rules for exchanging those messages between the various collaborating B2B parties. Typically, in B2B message based communications, complex and proprietary messaging protocols must be developed that support the B2B message based communications. Setting up B2B message based communication is often a lengthy process requiring agreement on the B2B messaging protocol and the implementation of specifically tailored software to implement the protocol.
Standardization efforts aim to standardize the messaging protocols and therefore, make implementation of the software the idle the B2B messaging easier. Standards however are more rigid and specialization of the developed standard to individual needs of the collaborating partners is generally not possible.
Disclosed, in one example, is a method of business-to-business messaging using a computer processor programmed to perform the operations including receiving a human-cognizable business-to-business message; parsing the human-cognizable business-to-business message; validating the human-cognizable business-to-business message using a message protocol ontology; and selecting and executing a service call corresponding to the particular human-cognizable business-to-business message based upon a message-to-service ontology.
Disclosed, in another example, is a business-to-business messaging system with a user terminal configured to send a human-cognizable business-to-business message through a communications network to a central terminal based upon a message protocol ontology; the central terminal comprising a computer processor which is configured to validate the human-cognizable business-to-business message based upon the message protocol ontology and using a message-to-service ontology, execute a service call corresponding to the human-cognizable business-to-business message.
Also disclosed in yet another example, is a machine readable medium that stores instructions which when performed by a machine, causes the machine to perform the operations of: receiving a human-cognizable business-to-business message; obtaining a current state of a domain object stored in non-transitory storage, wherein the business domain object is identified in the human-cognizable business-to-business message; validating the received human-cognizable business-to-business message based upon a new desired state provided in the human-cognizable business-to-business message, a current state, and a message protocol ontology; updating the current state of the domain object to the new desired state if the human-cognizable business-to-business message is successfully validated by executing a service call which is selected based upon a message-to-service call ontology.
In the following, a detailed description of examples will be given with references to the drawings. It should be understood that various modifications to the examples may be made. In particular, elements of one example may be combined and used in other examples to form new examples.
The present disclosure describes in one example, an extensible method, system and product for realizing a B2B message based protocol for communication about business objects and an SOA integration engine for calling services in response to receipt of a B2B message. In one example, the B2B messaging protocol is built using lightweight protocol ontology models that facilitate easy changes to the messaging protocol by non-technical individuals and without modifications to the underlying system itself. In other examples, a SOA integration engine can also be implemented in a similarly flexible manner to bind particular messages to a service call of a SOA based upon message-to-service ontologies. In yet additional examples, the B2B messages can be human cognizable and use structures that are based upon principles of the Language Action Perspective.
While B2B messages sent between various communicating entities can be used to achieve many purposes, in one example, the subject of a B2B message can concern the status or some property of a real world object or process. The real world objects, resources or tasks that are the subject of the communications can be represented digitally by the parties through the use of data structures. These data structures are referred to herein as “domain objects.” These domain objects can store any desired properties about the attributes of the real world objects. In one example of the present disclosure, these properties can then be updated by the parties through the B2B messaging protocol described herein. Thus, in one example, through the use of the B2B messaging, the domain objects can be updated to reflect the true, real world status of the real objects they represent
While B2B messages get their name from business to business transactions, the applicability of B2B messaging and SOAs are not limited to business situations. Indeed, one alternative example situation is illustrated in
While
The coordinating organization 320, stores an electronic representation of the real world object as a domain object and updates the status of the domain objects based upon messages received from the executing organization 310.
The coordinating organization 320 can issue commands to the executing organization 310 to take action on the real world objects. Once the action has been executed, the executing organization 310 can send a B2B message back to the coordinating organization 320 that the action has been executed. The coordinating organization 320 then updates the status of the domain object to reflect the completed activity.
One example of a method utilized by a coordinating organization system 320 to process the various B2B messages of the present techniques is shown in
In block 420, the various parts of the message can be parsed in one example, all, or part of, the B2B message can be both computer readable and human cognizable. Having the messages human cognizable allows for human creation of the B2B messages in some implementations. Human cognizable messages also allows for human understanding of the B2B messages quickly and easily, which may be of benefit in some implementations where humans will ultimately be responsible for executing at least some of the commands sent from the coordinating organization 320. One example of such an implementation where human cognizable messages would he helpful would he the emergency responder situation as shown in
In one example, the message types passed between the coordinating organization and the executing organization can identify the type of action taken or requested. The mess types can be based upon principals of the Language Action Perspective (LAP). The LAP states that language consists of speech acts as basic units of an utterance. With each utterance the speaker performs an action (speech act). For example, with the expression “i beg your pardon,” the speaker requests his conversational partner to repeat the last sentence. Each speech act consists of two components: the propositional content and the illocutionary force. The propositional content describes the actual content of an utterance, i.e. what the utterance is about. The illocutionary farce describes the way it is uttered or the speaker's intention, B2B message types can be constructed based upon the illocutionary force concept of the LAP. This allows the message to express, in a human cognizable way, the intention behind the message concerning a domain object's state change. By selecting a specific portion of human language that is natural to human speakers, and yet compact enough to program into a computer, both human and computer cognition can be achieved.
Some example message types based on LAP can include:
In some examples, the message can also contain an object type field that specifies the type of real world object that is the subject of the B2B message. One example object type would be an “activity.” This specifies that the real world object referenced is categorized as an activity. Other example object types can be “resource,” “incident,” or any other category of real world object that is desired.
In some examples, the message can also contain an object reference field that specifies the actual real world object. For example, if the object type field is “activity,” the reference may be any specific type of activity, such as: “put out fire,” or “ship packages.” If the object type is “resource,” the object reference could be, for example, “package” or “fire truck.” The object reference field specifies the exact object that is the subject of the message. In the case where multiple resources are in the system (say two fire trucks), the fire trucks can be differentiated through an additional field in the message, or given a unique object reference field. Thus for example, “fire truck,” would be “fire truck 1,” and “fire truck 2,” in the case of two fire tracks.
In still other examples, the message can also contain a property field that signifies the information field in the domain object that the user wishes to update. One example might be “status,” which is indicating that the user wishes to update the status of the domain object to some value. Another example might be “fuel level” to update the status of how much fuel a resource has. This field can be any property that the user wishes to track. Other examples might include the status of an article of manufacture, such as “assembly stage,” to denote where the item is in the manufacturing process.
In some examples, the message includes an old value field that signifies the old value (i.e., a previous value) of the domain object property specified in the property field. In the above example where the property signifies “status”, the old value may indicate “ready,” “not-ready “suspended”, or the like.
In some examples, the message can include a new value field that is the desired new value for the domain object property specified in the property field. One example new value here the property is “status” would be “failed,” or “busy.” Other examples could include specific property levels. For example, if the property field is “fuel level,” the new value could be a reading of the amount of fuel currently available, such as “50 lbs,” or “½ full.” If the property field is “assembly stage,” a new value field could be “painted,” to indicate that the item was recently painted.
It will be recognized by those skilled in the art that the property of the domain object can be any type of property desired. Thus the actual values of the property can be Boolean, string, integer, floating point, or any other data type.
In some examples, the message can also contain a time slot field which indicates the time at which to process the state change. One example time slot would be “immediate,” Other time slot values could be specific times, say “7:00 p.m. CST” or in offsets, for example “30 minutes from now.” In other embodiments the time can include a reference date, such as May 5, 2011 7:00 p.m. CST.”
In yet other examples, the message can also contain a reason field that can be a free text section for notes and other miscellaneous communications.
Putting this all together, one example message could be: request state change, activity, put out fire, not started, started, immediately, prevent destruction of house.” This message conveys, in a human cognizable way, the request to an emergency responder to begin firefighting efforts to prevent destruction of a house. Because the message is structured with a limited vocabulary of language, this message is computer cognizable, and since the limited vocabulary is specifically structured to be natural to humans, it is also human cognizable.
Continuing with
By use of the message-to-service ontologies, the message-to-service mappings can be made flexible enough to easily update, adapt, and create new B2B messages, protocols, and services with little to no modification to the underlying code. All that is necessary is to update the message-to-service ontology.
The message-to-service ontologies, which define the various service callers to execute given the various properties of the domain objects and the received message, is defined in one example, using domain ontologies. Domain ontologies define a vocabulary of concepts from a part of the world (a domain) and specify relationships between those concepts. Common components of domain ontologies are concepts that describe information about classes of things, and specific instances of concepts and the relationships between different concepts and different instances.
For example, the concept WINES might have general descriptive information for the alcoholic beverage such as: that it is made from grapes, it contains alcohol, and the like. A specific instance of WINES might be a cabernet sauvignon. The cabernet sauvignon might include specific properties to that particular instance of WINE concept, such as that the cabernet sauvignon is made from red grapes. Thus through the use of ontologies, a discrete part of the world can be modeled and represented. These domain ontologies can be modeled and stored in a database or other data storage using a specific machine-readable syntax. Common Ontology languages can include, in some examples, languages of the Web Ontology Language (OWL) knowledge representation languages and F-LOGIC™. Logical reasoning software such as PELLET™, RACERPRO™, FACT++™. ONTOBROKER™ from Ontoprise GmbH, Germany, and HERMIT™ can then be used to analyze the modeled ontology and make inferences based upon those ontologies.
Referring now to
In some examples, the message type, object type, and property as specified in the received B2B message can be used to determine the proper position in the message-to-service ontology, and thus the proper service call. In some examples, the system searches through the message-to-service ontologies for a service call that involves those object and property types and is triggered by that message type. If a service call is found, the service can be invoked. In one example, Java reflection techniques are used to invoke a service operation that has the same name as the associated service action found in the message-to-service ontology. In the Example of
One way service calls can be executed is by using the reflection techniques in the Java programming language. These reflection techniques support dynamic retrieval of information about classes, data structures, and methods by name, and allow for their manipulation within an executing Java program. Other example mechanisms to call the actual services include RPC (remote procedure call), shared library calls such as .DLL calls, inter-process communications, messaging (including inter and intra system messaging), or the like.
The result is that the message-to-service ontology used to call services is flexible enough to handle many different types of domains and services. All that is needed to add a new type of domain object or new service is to create or update a simple-to-construct message-to-service ontology model, or re-use another, existing model with either no modifications, or slight modifications.
While the format of the message-to-service ontology shown in
Continuing with
Once the current property value is extracted in block 440, the message handler in one example, validates the messaging protocol in block 450 to ensure that the particular property can be set based upon the established message protocol, the current value, and the intended values from the received message. The messaging protocol, which defines the various message sequences allowed given the various properties of the domain objects, is defined in one example, using domain ontologies. By using a protocol ontology, this validation is agnostic about the particular domain object or its properties. By use of the ontologies, the messaging protocol can be made flexible enough to easily update, adapt, and create new B2B messages and protocols with little to no modification to the underlying code. All that is necessary is to update the messaging ontology.
In one example, a message protocol ontology is referenced to determine whether the message is correct given the current properties of the domain object. In
In one example, shown in
When the various B2B messages are validated using the protocol ontologies, the system can search for the correct protocol ontology by using the domain object and property type that can be included in the B2B message. Once the correct protocol ontology is located, the system can use the current state of the domain object (gathered by the prior service call), and the new, desired state, to determine the position in the protocol ontology. For example, if the StatusActivity in
In this way, the protocol ontology can define the allowed state transitions for the various domain objects, and can also define the allowed message protocol for the various B2B messages in an easily extensible manner. While the example of
The result is that the message protocol to update various properties of the domains is flexible enough to handle many different types of domains. All that is needed to add a new type of domain object is to create or update a simple-to-construct ontology model, or re-use another, existing model with either no modifications, or slight modifications. The protocol ontology and thus the message protocol can be re-used across different activities in some examples. Thus the protocol ontology and thus the message protocol for “fighting a fire,” and “building a sand-bag wall” can be the same.
For example, the domain ontology exemplified in
Continuing with
If the message is consistent with the protocol, the system executes the service call to change the desired property as specified in the B2B message in block 460. The service call to execute, in one example, was determined in block 430. As with block 440, one way service calls can be executed is by using the reflection techniques in the Java programming language. Other example mechanisms to call the actual services include RPC (remote procedure call), shared library calls such as .DLL calls, inter-process communications, messaging (including inter and intra system messaging), or the like.
Service caller 820 encapsulates code that is required to execute a call to a service 830. In one example, there is a specific service caller 820 for each service 830. This can serve to decouple the message information handler 810 from the specifics of each service 830, thereby promoting flexibility. Service callers 820 in one example provide a standardized interface for invoking service operations. In one example, the parameters passed by the message information handler to the service caller can include the domain object reference and the property value. The appropriate service caller 820 to use is determined by a semantic processor 840, which utilizes a reasoner 85( )to parse the service ontologies 860 to determine the appropriate service caller 820.
Validator 870 validates a received message 800 against the message protocol domain ontology 880 using the reasoner 850. With the information of the current state of the domain object, which is gathered by a service call 820, and the type of the lastly handled message, which is stored by the State Manager component 890, the actual position in the protocol is determined, and the validator 870 can check whether the current message type and the new state of the domain object are permitted.
Semantic Processor 840 is responsible for finding the appropriate service caller 820 using the received message 800 as input. In one example, the parameters “message type,” “object type,” and “property” are used by the semantic processor 840 to create a query to the reasoner 850 to search through the service ontologies 860 for an operation that involves those object and property types and is triggered by that message type. If such an operation is found, the Semantic Processor 840 returns the names of the service and the operation to the message information handler 810 so that the message information handler 810 can call the service caller 820. In one example, the message information handier 810 can call the service caller 820 using the name of the service using Java reflection techniques.
Reasoner 850 is a semantic reasoner able to infer logical consequences from a set of inference rules specified by means of an ontology language. Some example reasoners include PELLET™, RACERPRO™, FACT++™, and HERMIT™.
Any of the above described components of the system illustrated in
Message information handler 810 then executes the service call 979, to read the old property value of the property specified in the property field of the incoming message. At 980, service caller 820 executes service 830 and receives the value of the property 981. Service caller then passes the current property value back to the message information handler 810 at 982.
Message information handler 810 then sends the message and the old property value to the validator 870 for validation of the message protocol. Using calls 984 and 985, validator 870 retrieves the previously sent message (if any) from the state manager 890. Once that is complete, the validator 870 generates a query to the reasoner 850 to retrieve the state transitions for this property in block 986. The results, returned in block 987, are then used by the validator 870 to validate the state transition. If the message is successfully validated, the validator 870 uses call 988 to store the current message to the state manager 890.
The validator 870 sends a validation result 989 to the message information handler 810. If the result indicates that the message was successfully validated, the message information handler 810 calls the service caller 820 at block 990 to update the property of the business domain object to the new requested property. Service caller 820 then executes the service call 991 with service 830.
While the sequence diagram of
Either or both of the executing or coordinating organization can be implemented using a machine.
The example computer system 1000 includes a processor 1002 (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU) or both), a main memory 1001 and a static memory 1006, which communicate with each other via a bus 1008. The computer system 1000 may further include a video display unit 1010 (e.g., a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT)). The computer system 1000 also includes an alphanumeric input device 1012 (e.g., a keyboard), a User Interface (UI) cursor controller 1014 (e.g., a mouse), a disk drive unit 1016, a signal generation device 1018 (e.g., a speaker) and a net network interface device 1020 (e.g., a transmitter).
The disk drive unit 1016 includes a machine-readable medium 1022 on which is stored one or more sets of instructions 1024 and data structures (e.g., software) embodying or used by any one or more of the methodologies or functions illustrated herein. The software may also reside, completely or at least partially, within the main memory 1001 and/or within the processor 1002 during execution thereof by the computer system 1000, the main memory 1001 and the processor 1002 also constituting machine-readable media.
The instructions 1024 may further be transmitted or received over a network 1026 via the network interface device 1020 using any one of a number of well-known transfer protocols (e.g., HTTP, Session Initiation Protocol (SIP)).
The term “machine readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the machine and that cause the machine to perform any of the one or more of the methodologies illustrated herein. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic medium. In one example, machine-readable medium can include a non-transitory machine readable medium.
Method examples illustrated herein may be computer-implemented. Some examples may include computer-readable media encoded with a computer program (e.g., software), which includes instructions operable to cause an electronic device to perform methods of various examples. A software implementation for computer-implemented method) may include microcode, assembly language code, or a higher-level language code, which further may include computer readable instructions for performing various methods. The code may form portions of computer program products. Further, the code may be tangibly stored on one or more volatile or non-volatile computer-readable media during execution or at other times. These computer-readable media may include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, Random Access Memories (RAMs) Read Only Memories (ROMs), and the like.
