Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F15/00—Digital computers in general; Data processing equipment in general
  • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/54—Interprogram communication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network

Definitions

• the present invention relates generally to Web services, and more particularly, to interoperability among Web services.
• Web services are the fundamental building blocks in the movement toward distributed computing on the Internet. Open standards and the focus on communication and collaboration among software applications have created an environment where Web services are becoming the platform of choice for application integration. Applications are constructed using multiple Web services from various sources that work together regardless of where they reside or how they are implemented. Web services represent black-box functionality that can be used or reused without the need to know the inner working of Web services.
• One of the primary advantages of Web services' architecture is that the architecture allows Web services written in different languages ⁇ on different platforms to communicate with each other with ease via messages. Moreover, a significant number of co ⁇ orations and companies already have a Web infrastructure and personnel with deep knowledge and experience in maintaining such an infrastructure, thereby allowing more fluid adoption of Web services as a platform for future applications.
• Web services include information sources that one could easily inco ⁇ orate into applications, such as stock quotes, weather forecasts, sports scores, etc. Beyond information sources, one can imagine a whole class of applications that can be built from Web services to analyze and aggregate information desired by interested persons, and present the information to the interested persons. For example, consider a spreadsheet that summarizes a person's whole financial picture: stocks, 40 IK, bank accounts, loans, etc. If this information were available through Web services, a spreadsheet application could update the information continuously. While most pieces of information may be available now on the Web in a mixture of incongruous, haphazard elements, Web services make programmatic access to all pieces of information easier and more reliable. Web services are diverse, but almost all of them have three things in common:
• Web services expose useful functionality to users via a set of interfaces through a standard protocol, such as Simple Object Access Protocol (SOAP); (2) Web services describe the set of interfaces in a document called a contract using Web Services Description Language (WSDL), which is written in enough detail to allow users to build client applications to talk to Web services; and (3) Web services are registered so that potential users can find Web services easily using Universal Discovery Description and Integration (UDDI).
• WSDL Web Services Description Language
• UDDI Universal Discovery Description and Integration
• a Web service is a piece of software exposed on the Web through a particular protocol, described with a particular WSDL contract, and registered in a parcticular location in the UDDI.
• a WSDL contract describes interfaces of Web services in enough detail to allow a user to build a client application.
• a WSDL contract is a document that describes a set of messages written in a particular protocol and how these messages are to be exchanged.
• a WSDL contract describes a Web service interface in terms of messages the Web service can generate and accept.
• WSDL contracts are readable and editable, but in most cases, WSDL contracts are intended to be produced and consumed by software.
• WSDL contracts specify what a request message must contain and what the response message will look like in an unambiguous notation.
• WSDL contracts use to describe message formats is based on the XML Schema standard, which is not dependent on any particular programming language, and is suitable for describing Web services interfaces that can be accessible from a wide variety of platforms and programming languages.
• WSDL contracts define where the service is available and what communications protocol can be used to talk to the service.
• a WSDL contract should define everything that is required to write an application to work with a Web service.
• WSDL contracts lack the expressive power to define precisely how an application is to interact with a Web service.
• contract means a binding agreement between two software entities, an application that is interacting with a Web service is free to ignore the terms of a WSDL contract.
• a WSDL contract appears as nothing more than a paper tiger.
• a system 100 shown in FIGURE 1 illustrates this problem in greater detail.
• the system 100 includes a client 102, which is a computer that accesses shared network resources being provided by another computer, such as a server 106, on a local area network or wide area network such as the Internet 104.
• a number of Web services 108, 110 are statically stored on the client 102 and the server 106.
• Web services 108, 110 are composed of programs 108A, 110A, and WSDL contracts 108B-110B.
• Each WSDL contract can be divided into two major sections.
• the first section contains abstract definitions and the second section contains concrete descriptions.
• the abstract definitions define contractual elements in a platform-independent and language- independent manner.
• the abstract definitions do not contain machine-specific or language-specific elements. This helps define a set of services that several diverse Web sites can implement. Site-specific elements, such as data serialization, are relegated to the concrete descriptions.
• Abstract definitions include definitions for types, messages, and porttypes.
• the concrete descriptions specify bindings and services.
• the types section declares data types used in a WSDL contract.
• the messages section defines parameters to operations (i.e., methods).
• the porttypes section defines one or more operations that can be invoked by applications (and other Web services) external to a Web service described by a WSDL contract.
• the bindings section can have one or more binding elements whose pu ⁇ ose is to specify how each call and response to an operation is sent or received over the network 104 in accordance with a protocol.
• the services section has one or more service elements, each of which contains port elements, and each of which in turn refers to a binding element in the bindings section.
• Structure 112 illustrates the relationship among contractual elements of the contract 108B and is shown in block diagram form.
• a porttype 112D declares a number of operation elements.
• Operation elements within a porttype define the syntax for calling all methods declared in a porttype, such as a prepare operation 112E, a "do work” operation 112F, and a "clean up” operation 1 12G.
• each operation element in a porttype defines the name of the method, the parameters (using messages), and the type of each parameter.
• a binding element 112C specifies the protocol, serialization, and encoding to be used for each operation 112E- 1 12G of the porttype 112D.
• a port element 112B associates an Internet location with the binding 112C in a one-to-one correspondence via the use of a Uniform Resource Locator (URL).
• a service element 112A contains a set of port elements, such as the port 112B.
• Each service element can be used to group together ports according to a URL destination. For example, a developer can redirect all service requests simply by using another service element, and external Web services can still interact with a Web service.
• Another use of the service element is to classify the ports according to an underlying protocol. For example, a developer can put all HTTP ports in one service element and all SMTP ports in another. An external Web service can then search the WSDL contract 108B for the service that matches the protocol that it can deal with.
• the WSDL contract 108B includes several operations, such as the "prepare” operation 112E, the "do work” operation 112F, and the “clean up” operation 1 12G, which can be invoked to access the services provided by the Web service 108.
• the "prepare” operation 1 12E should be invoked before the "do work” operation 112F
• the "do work” operation 112F should be invoked before the invocation of the "clean up” operation 112G.
• Prior WSDL contracts lack the expressiveness power to communicate this ordering information to other Web services, such as the Web service 110, that may desire the services of the Web service 108.
• the Web service 1 10 may choose to initially call the "clean up" operation 112G instead of first invoking the prepare operation 112E. This could be catastrophic to the working of the Web service 108 in that it may corrupt the internal execution state of the Web service 108.
• the Web service 1 10 is malicious. In this case, the Web service 1 10 can exploit this weakness of the Web service 108 by calling operations 112E-1 12G out of sequence simply to wreak havoc with the proper operation of the Web service 108. If Web services can be inappropriately exploited in this fashion, trustworthiness of Web services will be questioned and their use will be diminished and eventually extinguished from the marketplace.
• a method form of the invention is a computer- implementable method for checking the compatibility of a first porttype of a first Web service and a second porttype of the second Web service.
• the method comprises extracting a first safety from the first porttype of the first Web service and a second safety from the second porttype of the second Web service.
• the method further comprises testing the compatibility of the first safety with the second safety by binding the first safety with the second safety to determine whether the result of the binding produces interoperability between Web services.
• a system, method, and computer-readable medium for improving the safe interoperability of Web services comprises a first Web service for offering computing services and a second Web service that desires the computing services offered by the first Web service.
• the first Web service includes a first port for transmitting and receiving messages and the second Web service includes a second port for transmitting and receiving messages.
• the first port includes a first porttype and the second port includes a second porttype.
• the second port is fusable with the first port for safe access to the services offered by the first Web service if the second porttype is compatible with the first porttype.
• a further system form of the invention comprises a first Web service offering a first set of services and a second Web service offering a second set of services.
• the first Web service includes a first safety (that programmatically expresses safe access to the first set of services) and a second Web service includes a second safety (that programmatically expresses safe access to the second set of services).
• the second Web service accesses the first set of services and the first Web service accesses the second set of services if the second safety is able to programmatically align with the first safety.
• another system form of the invention comprises a first Web service offering services.
• the first Web service includes a safety that programmatically describes an order in which to access the offered services.
• the system further comprises a second Web service that desires to use the services offered by the first Web service.
• the second Web service accepts the safety of the first Web service to form a virtual contract with the first Web service so that the second Web service can access the offered services.
• a computer-readable form of the invention stores a customizable, tag-based data structure suitable for use by a Web service to evaluate safe interoperability with another Web service. More particularly, the data structure comprises a porttype tag that is indicative of operations capable of being invoked by Web services and a safety tag that is indicative of a safety that programmatically specifies an order by which Web services invoke the operations.
• the method form of the invention is implementable in a computer system.
• the method comprises creating a set of operations that are capable of being invoked by Web services and creating a safety that specifies the permissible invocation permutations of the set of operations.
• FIGURE 1 is a block diagram illustrating a conventional Web services system
• FIGURE 2 is a block diagram illustrating an exemplary computing device
• FIGURES 3A-3C are block diagrams illustrating the creation of a specification for a Web service that contains safeties to define the order in which operations of a Web service are to be invoked;
• FIGURE 4 is a textual diagram illustrating syntaxes of an exemplary programming language, which is an artificial language that can be used to define a sequence of instructions that can ultimately be processed and executed for expressing safeties used in interoperability agreements among Web services;
• FIGURES 5A-5C are block diagrams illustrating the safe interoperability of two Web services when their ports have been fused pursuant to the formation of a virtual contract between the two Web services;
• FIGURES 6A-6I are diagrams illustrating the creation of a virtual contract for safe interoperability among three Web services, each Web service providing a service or resource to another Web service in the virtual contract;
• FIGURES 7A-7B are diagrams illustrating syntaxes of another exemplary programming language for forming safeties used in interoperability agreements among Web services
• FIGURES 8A-8O are method diagrams illustrating an exemplary method formed in accordance with this invention for verifying the compatibility of porttypes among Web services so as to form safe interoperability among Web services.
• FIGURE 2 illustrates an example of a computing system environment 200 suitable for practicing certain aspects of the invention, such as executing programs of Web services and verifying the specifications of Web services for safe interoperability.
• the computing system environment 200 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 200 be inte ⁇ reted as having any dependency or requirement relating to any one or combination of the illustrated and described components.
• the invention is operational with numerous other general purpose or special pu ⁇ ose computing system environments or configurations.
• Examples of well-known computing systems, environments and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
• program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
• the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
• program modules may be located in both local and remote computer storage media, including memory storage devices.
• the computing system environment illustrated in FIGURE 2 includes a general pu ⁇ ose computing device in the form of a computer 210.
• Components of computer 210 may include, but are not limited to, a processing unit 220, a system memory 230, and a system bus 221 that couples various system components including the system memory to the processing unit 220.
• the system bus 221 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
• bus architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, also known as Mezzanine bus.
• ISA Industry Standard Architecture
• MCA Micro Channel Architecture
• EISA Enhanced ISA
• VESA Video Electronics Standards Association
• PCI Peripheral Component Interconnect
• Computer 210 typically includes a variety of computer-readable media.
• Computer-readable media can be any available media that can be accessed by computer 210 and includes both volatile and nonvolatile media, removable and nonremovable media.
• Computer-readable media may comprise computer storage media and communication media.
• Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data.
• Computer storage media include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other computer storage media.
• Communication media typically embody computer-readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier wave or other transport mechanism that includes any information delivery media.
• modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
• communication media include wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF infrared, and other wireless media. A combination of any of the above should also be included within the scope of computer-readable media.
• the system memory 230 includes computer storage media in the form of volatile and/or nonvolatile memory, such as read only memory (ROM) 231 and random access memory (RAM) 232.
• ROM read only memory
• RAM random access memory
• BIOS basic input/output system 233
• RAM 232 typically contains data and/or program modules that are immediately accessible and/or presently being operated on by processing unit 220.
• FIGURE 2 illustrates operating system 234, application programs 235, other program modules 236, and program data 237.
• the computer 210 may also include other removable/non-removable, volatile/nonvolatile computer storage media.
• FIGURE 2 illustrates the hard disk drive 241 that reads from or writes to non-removable, nonvolatile magnetic media, the magnetic disk drive 251 that reads from or writes to a removable, nonvolatile magnetic disk 252, and an optical disk drive 255 that reads from or writes to a removable, nonvolatile optical disk 256, such as a CD-ROM or other optical media.
• Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital videotapes, solid state RAM, solid state ROM, and the like.
• the hard disk drive 241 is typically connected to the system bus 221 through a non-removable memory interface, such as interface 240, and the magnetic disk drive 251 and optical disk drive 255 are typically connected to the system bus 221 by a removable memory interface, such as interface 250.
• hard disk drive 241 is illustrated as storing operating system 244, application programs 245, other program modules 246, and program data 247. Note that these components can either be the same as or different from operating system 234, application programs 235, other program modules 236, and program data 237. Operating system 244, application programs 245, other program modules 246, and program data 247 are given different numbers here to illustrate that, at a minimum, they are different copies.
• a user may enter commands and information into the computer 210 through input devices, such as a keyboard 262 and pointing device 261, the latter of which is commonly referred to as a mouse, trackball, or touch pad.
• Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
• a user input interface 260 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port, or universal serial bus (USB).
• a monitor 291 or other type of display device is also connected to the system bus 221 via an interface, such as a video interface 290.
• computers may also include other peripheral output devices, such as speakers 297 and printer 296, which may be connected through an input/output peripheral interface 295.
• the computer 210 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 280.
• the remote computer 280 may be a personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computer 210, although only a memory storage device 281 has been illustrated in FIGURE 2.
• the logical connections depicted in FIGURE 2 include a local area network (LAN) 271 and a wide area network (WAN) 273, but may also include other networks.
• LAN local area network
• WAN wide area network
• the computer 210 When used in a LAN networking environment, the computer 210 is connected to the LAN 271 through a network interface or adapter 270. When used in a WAN networking environment, the computer 210 typically includes a modem 272 or other means for establishing communications over the WAN 273, such as the Internet.
• the modem 272 which may be internal or external, may be connected to the system bus 221 via the input/output peripheral interface 295, or other appropriate mechanism.
• program modules depicted relative to the computer 210, or portions thereof, may be stored in the remote memory storage device.
• FIGURE 2 illustrates remote application programs 285 as residing on memory device 281. It will be appreciated that the network connections shown are for illustrative pu ⁇ oses only and other means of establishing a communication link between the computers may be used.
• FIGURE 3B illustrates a Web service 300 that includes a program 300A, which is a sequence of instructions of the Web service 300 that can be executed by a computing device, and a specification 300B (shown as “spec” in the drawings), which is a description of the interfaces of the Web service 300.
• the specification 300B unlike a WSDL contract, contains safety rules (hereinafter "safeties") that describe an order in which external Web services can invoke the operations of the Web service 300. In other words, each safety describes the allowable or permissible invocation permutations of the operations of the Web service 300 with which external Web services can call to access the services offered by the Web service 300.
• safety rules hereinafter “safeties”
• FIGURE 3 A A block diagram that illustrates the structure 302 of the Web service 300 is shown in FIGURE 3 A.
• a service element 302A taxonomically differentiates other services described by the specification 300B by grouping together a set of ports (not shown). Each port is associated with a porttype.
• the structure 302 has a porttype 302B.
• the porttype 302B declares a number of operations, such as a prepare operation 302D, a dowork operation 302E, and a cleanup operation 302F.
• the term "operation” is used interchangeably with the term “message” (in contrast, the term “message” in a WSDL contract means only an argument to an operation); the term “parameter” is used to denote an argument to an operation; and the term “binding” is used to mean a programmatic relationship between two safeties, which are explained below (in contrast, the term “binding" in a WSDL contract means an association of a porttype with a particular transfer protocol).
• the safeties 302C are textually expressed by a portion 304 of the specification 300B. See FIGURE 3C.
• Line 304 A contains the keyword porttype, which declares the commencement of a definition for a porttype; a designator "start_work_stop", which is the name of the porttype; and an open curly bracket " ⁇ ”, which has a matching closed curly bracket " ⁇ ” to delimit a block of text that programmatically defines the porttype.
• Line 304B declares the prepare operation 302D, which takes a string as a parameter.
• Line 304C declares a dowork operation 302E as well as its parameter, a string.
• Line 304C declares a cleanup operation 302F that has a string parameter.
• the letter S is the name of the first safety and the letter S W is the name of the second safety.
• Preceding the period ".” of the safety S is the prepare operation 302D indicating that the prepare operation 302D is to be invoked first after which the safety SW is in force.
• the period ".” after the dowork operation 302E but before the safety SW indicates that the dowork operation 302E is invoked after which a recursion of the safety SW can occur.
• the phrase ".SW" following the dowork operation 302E indicates that zero or more invocations of the dowork operation 302E may be possible.
• the plus sign "+” indicates that either the dowork operation 302E or the cleanup operation 302F may be invoked following the invocation of the prepare operation 302D.
• the cleanup operation 302F placed last in the sentence of the safety SW indicates that the cleanup operation 302F should be called last or invoked by an external Web service using the services of the Web service 300.
• Each semicolon ";” following safeties S and SW indicates the termination of the sentence of the safeties on lines 304E, 304F.
• Porttypes and safeties can be expressed using the human-readable syntax 400 illustrated in FIGURE 4 (after which they can be preferably placed in a specification of a Web service, such as the specification 300B).
• Line 400A contains a definition for a port: porttype designator ⁇ signature*; safety; ⁇ , where porttype is a keyword declaring the commencement of the definition of a porttype; designator is an identifier of the porttype; the pair of open and closed curly brackets delimit expressions that define the porttype; and safety indicates rules that define the order in which to invoke the operations described by the signatures.
• Each signature (there can be more than one, which is signified by the asterisk symbol "*") has the syntactical expression "designator ([designator:lineartype,designator:lineartype])" shown on line 400B, where the first designator is the identifier of a particular operation; the second and third designators bound by the pair of parentheses indicate identifiers of parameters of the operation; and the two linear types define the data type of each parameter (for brevity pu ⁇ oses, only two parameter slots are defined for the signature on line 400B, but more than two are possible); the colon ":” indicates that the designator of a parameter on the left-hand side of the colon has the data type declared on the right-hand side of the colon; the comma ",” delimits one parameter from another parameter; and the pair of parentheses "( )” delimit the parameters and their types used by the operation.
• Lines 400C-400I define various types of safeties.
• a stop safety is declared on Hne 400C.
• a stop safety denotes inactivity or termination of a safety.
• a sequence safety declared on line 400D defines an order in which to invoke an operation or a message of a Web service.
• a choice safety declared on lines 400E denotes alternatives that can be chosen in a safety.
• On line 400G a parallel safety is defined to denote concurrent, distributed processing of two safeties.
• a recursion safety which defines a variable whose use is recursive in a safety, is declared on line 400H.
• a reference safety declared on line 4001 denotes that a safety can be given a name to be used in combination with other safeties.
• Line 400J shows that the stop safety is composed of the symbol zero "0".
• the sequence safety is composed of a signature of a function followed by a period ".”, which is then followed by another safety. See line 400K.
• the choice safety is composed of two safeties separated by a plus sign "+” (see line 400L).
• the parallel safety defined on line 400N is composed of two safeties separated by a vertical sign "
• the recursion safety is composed of a keyword "rec” followed by a pair of parentheses, which bound a designator, and is followed by a period and another safety rule. See line 400O.
• the human-readable syntax 400 Using the human-readable syntax 400, expressive nuances of safeties can be specified to enhance safe interoperability among Web services. Each safety is preferably placed in a porttype definition in a Web service's specification.
• the human-readable syntax 400 is illustrated here for ease of discussion in figures following FIGURE 4.
• a more restrained, but equally expressive is the model syntax 702 illustrated in FIGURE 7A (described below).
• Both the human-readable syntax and the model syntax 702 can be formed using a suitable customizable, tag-based language. Any suitable customizable, tag-based language can be used.
• One suitable language includes the XML Schema language.
• a fileserver Web service 502 is shown at FIGURE 5A in block diagram form.
• the fileserver Web service provides file storage services for other Web services on the network. Unlike a disk server, the filerserver Web service 502 not only stores files but manages them and maintains order as other Web services request files and make changes to them. To deal with the tasks of handling multiple (sometimes simultaneous) requests for files, the Web service 502 interacts with processors and controlling software as well as disk drives for storage.
• the fileserver Web service 502 includes a service element 502 A, and a porttype 502B, among other elements (not shown).
• the porttype 502B defines a number of operations, such as an open operation 502D, a read operation 502E, a write operation 502F, and a close operation 502G. These operations 502D-502G are further defined in a portion 504 of a fileserver Web service's specification. See FIGURE 5B.
• the porttype 502B also defines safeties 502C, which specify the order with which external Web services access the services offered by the fileserver Web service 502D via operations 502D-502G.
• the safeties 502C are further defined in the portion 504. See lines 504F, 504G.
• a port 502H of the fileserver Web service 502 allows other Web services to fuse (described in detail below) in order to access the services of the fileserver Web service 502B by invoking operations 502D-502G.
• the portion 504 focuses on one porttype definition among many porttypes of the fileserver Web service's specification.
• Line 504A contains the keyword porttype followed by the designator "fileserver", and a pair of open and closed curly brackets for delimiting the definition of the fileserver porttype 502B.
• Line 504B declares the signature of the open operation 502D that takes a file name as a parameter.
• external services specify the name of the file to be opened via the open operation 502D.
• the open operation 502D should be the first operation that is invoked by external Web services for each particular file server session.
• the read operation 502E is declared on line 504C. The read operation takes a client's port as a parameter.
• the fileserver Web service 502 When the read operation 502E is invoked by external Web services, the fileserver Web service 502 reads a chunk of data from an opened file, and transmits the read data toward the given client's port. External Web services can also write information to opened files via the write operation 502F, which is declared on line 504D. The write operation takes data as a parameter. This data is written by the write operation to the opened file. When all desired operations have been carried out on the opened file, the opened file can be closed via the close operation 502G, which is declared on line 504E. The close operation 502G takes a file name as an argument so that the close operation 502G knows which file to close.
• Lines 504F-504G contain the safeties of the fileserver porttype 502B.
• a system 500 shows the interoperability of Web services 502, 508 after a virtual contract has been created. See FIGURE 5C.
• a virtual contract is created when the porttypes of ports 502H, 508A between the Web services 502, 508 are compatible. More particularly, a virtual contract is created when the safeties of the porttypes of ports 502H, 508A are acceptable to both the Web services 502, 508.
• a virtual contract is not something that physically exists but it is present when the safeties of porttypes align with each other in a way that ensures safe interoperability between Web services 502, 508. For clarity pu ⁇ oses, many elements of the fileserver Web service 502 are not shown in FIGURE 5C.
• the fileserver Web service 502 can be executed on a computing device, such as a cellular phone 506; the client Web service 508 can be executed on a computing device, such as a personal digital assistant 510; and a store Web service 512 can be executed on a computing device, such as a desktop computer 514.
• a computing device such as a cellular phone 506
• the client Web service 508 can be executed on a computing device, such as a personal digital assistant 510
• a store Web service 512 can be executed on a computing device, such as a desktop computer 514.
• the port 508A of the client Web service 508 is shown to be fused to the port 502H of the fileserver Web service 502. This fusing between the client Web service 508 • and the fileserver Web service 502 is possible after the client Web service 508 has shown that it is willing to comply with the safeties of the fileserver porttype 502B. With the fusing of ports 508A-502H, the client Web service 508 can access and invoke operations 502D-502G of the fileserver Web service 502 in accordance with and in the manner specified by the safeties of the fileserver porttype. Suppose that the client Web service 508 has already invoked the open operation 502D to open a file. The client Web service 508 can invoke the read operation 502E to obtain the read data.
• the client Web service 508 provides a port 508B to receive the read data after the invocation of the read operation 502E.
• the fileserver Web service 502 includes a port 5021 for transmitting the read data toward the port 508B.' It is not necessary, however, that the port 508B be an actual port at the client Web service 508.
• the port 508B can be virtually provided by another Web service, such as the store Web service 512. A virtual contract may have been formed between the client Web service 508 and the store Web service 512 to store information in a particular manner desired by the client Web service 508.
• the client Web service can provide the port 512 A of the store Web service 512 so that the data read by the read operation 502E will be automatically forwarded to the store Web service 512. This can occur unbeknownst to the fileserver Web service 502.
• Each port is thus a transferable quantity that can be given to a Web service to expand the communication possibilities of a Web service.
• the prior scope of the fileserver Web service 502 is limited to the interaction with the client Web service 508 but can later be expanded to include the store Web service 512 when the port 512A is transferred to the fileserver Web service 502 via the client Web service 508.
• the joining of Web services is accomplished via a virtual contract through the use of safeties formed in accordance with this invention.
• This joining of Web services heightens the safe interoperability of Web services to create greater functionality than each Web service alone can provide.
• Web services are more trustworthy, dependable, and available if the safeties of Web services are complied with.
• the programmatic joining formed in accordance with this invention reduces or eliminates mistakes, lost requests, faults in the face of invalid requests, or corrupt persisted data in the interoperability of Web services.
• FIGURES 3A-3C introduces the notion of safeties to a specification of a Web service.
• safeties are preferably placed inside a porttype. As also discussed above, safeties describe the order with which external Web services must invoke the operations of a desired Web service to obtain desired services. If an external Web service cannot comply with the safeties of another Web service at the outset, there is no binding agreement (a virtual contract) between the two Web services, and the noncomplying Web service cannot invoke the services of the other Web service.
• a virtual contract One example of a creation of a virtual contract between two Web services is discussed above in connection with FIGURES 5A-5C.
• the port 508A of the client Web service 508 can be fused to the port 502H of the file server Web service 502. Such a fusing allows the client Web service 508 to invoke the services of the file server Web service 502 at the port 502H. More particularly, a virtual contract can be created when the porttype of the port 508A of the client Web service 508 is programmatically compatible (or complies with the safeties of) the porttype of the port 502H of the file server Web service 502.
• the discussion in connection with FIGURES 6A-6I focuses on a binding agreement among three Web services (a purchaser Web service 602, a supplier Web service 606, and a shipper Web service 610) formed in accordance with this invention.
• virtual contracts can be formed without regard to the number of participating Web services as long as each Web service is willing to comply with the safeties of other participating Web services.
• the purchaser Web service 602 includes a service element 602A and a porttype element 602B, among other elements (not shown).
• the porttype 602B includes an initiatepurchase operation 602D, a confirmpurchase operation 602E, and a safety 602C that specifies the invocation of operations 602D-602E.
• the purchaser Web service 602 also includes a port 602F whose data type is the porttype 602B. See FIGURE 6A.
• a portion 604 of the purchaser Web service's specification is illustrated in FIGURE 6B.
• Line 604A contains the keyword porttype; the designator "purchaser” of the porttype; and an open curly bracket “ ⁇ ", which has a companion closed curly bracket to delimit the definition of the purchaser porttype 602B.
• Line 604B contains a signature for the initiatepurchase operation 602D, which has two parameters.
• One parameter is a purchase order parameter designated as "PO”.
• the other parameter is an advanced shipping notice " ⁇ ASN", where the tilde " ⁇ " denotes that the purchaser Web service 602 consumes the data represented by the parameter ASN.
• Line 604C contains a signature of the confirmpurchase operation 602E, which takes an "invoice” parameter and a "goods" parameter.
• the invoice parameter is qualified by a tilde " ⁇ " to denote that the purchaser Web service 602 consumes the data represented by the invoice parameter.
• Both the PO parameter and the goods parameter are not qualified by the tilde, hence indicating that the purchaser Web service 602 is the producer or the source of the data represented by these parameters.
• Line 604D contains a safety for the purchaser porttype 602B. In brief, the invocation ⁇ f the initiatepurchase operation 602D must occur before the invocation of the confirmpurchase operation 602E, which is then followed by a recursion of the invocation of operations 602D, 602E.
• the supplier Web service 606 is illustrated in block diagram form in FIGURE 6C.
• the supplier Web service 606 includes a service element 606A and a porttype element 606B, among other elements (not shown).
• the porttype 606B is a data type for a port 606F of the supplier Web service 606.
• the porttype 606B contains a receivepo operation 606D, a sendinvoice operation 606E, and a safety 606C that specifies the invocation order of operations 606D, 606E.
• the supplier Web service 606 also includes a port 606F whose data type is the porttype 606B.
• a portion 608 of the supplier Web service's specification is shown in FIGURE 6D.
• Line 608 A contains the declaration of a supplier porttype 606B and includes an open curly bracket " ⁇ ", which has a companion closed curly bracket to delimit the definition of the supplier porttype 606B.
• Line 608B contains a signature of the receivepo operation, which takes the purchase order " ⁇ PO" as a parameter. The tilde indicates that the supplier Web service 606 consumes the data represented by the purchase order ⁇ PO parameter.
• Line 608C contains a signature of the sendinvoice operation 606E, which takes the invoice as a parameter.
• Line 608D contains a safety for the supplier porttype 606B.
• the receivepo operation 606D is to be invoked prior to the invocation of the sendinvoice operation 606E, which can then be followed by the recursion of the invocation of operations 606D, 606E.
• the shipper Web service 610 includes a service element 610A and a porttype element 610B, among other elements (not shown).
• the porttype 610B describes the data type of a port 61 OF of the shipper Web service 610.
• the porttype 610B includes a notifyofshipment operation 610D, a confirmreceipt operation 610E, and a safety 610C, which specifies the invocation order of operations 610D, 610E.
• a portion 612 of the shipper Web service's specification is illustrated in textual form in FIGURE 6F.
• Line 612A contains the declaration of the shipper porttype 610B and an open curly bracket " ⁇ ", which has a companion closed curly bracket “ ⁇ ” to delimit the definition of the shipper porttype 610B.
• Line 612B contains a signature of the notifyofshipment operation 610D, which takes the advance shipping notice "ASN" as a parameter. Because the advanced shipping notice ASN is not qualified by a tilde, the shipper Web service 610 is a producer or a source of the data represented by the ASN parameter.
• Line 612C contains a signature of the confirmreceipt operation 610E, which takes "-goods" as an argument.
• the tilde in front of the designator "goods” denotes that the shipper Web service 610 is a consumer of the data represented by the "goods" parameter.
• Line 612D contains a safety for the shipper porttype 610B.
• the invocation of the notifyofshipment operation 610D occurs before the invocation of the confirmereceipt operation 610E, and after which, a recursion of the invocation of the operations 610E, 610E may occur.
• FIGURE 6G A portion 614 of a program for expressing the composition of the purchaser Web service 602, the supplier Web service 606, and the shipper Web services 610 is shown in FIGURE 6G.
• Line 614A contains a signature of a purchaser Web service 602, which has a port designated as "PC" having the purchaser porttype 602B.
• Line 614B contains a signature of the supplier Web service 606, which has a port designated as "PS" having the supplier porttype 606B.
• Line 614C contains a signature for the shipper Web services 610, which has a port designated as "PH" having the shipper porttype 610B.
• Line 6141 contains the keyword service, which heralds the commencement of the definition of a Web service or a composition of Web services; the designator "scm_purchaser_supplier_shipper”, which denotes the name of a composition of Web services 602, 606, and 610; and an open curly bracket " ⁇ ", which has a companion closed curly bracket “ ⁇ ” to delimit the definition of the composition of Web services.
• Line 614J contains the keyword new, which defines unique names for ports and associates these ports with particular porttypes: a new port "PC" of the purchaser porttype 6002b; a new port “PS” of the supplier porttype 606B; a new port “PH” of the shipper porttype 610B; and an open curly bracket " ⁇ ", which has a companion closed curly bracket “ ⁇ ” to delimit the scope of operations for these new ports PC, PS, and PH.
• Line 614K contains the keyword parallel, which denotes that services and processes expressed between an open curly bracket " ⁇ ” and a companion closed curly bracket “ ⁇ ” are to be executed in parallel.
• Line 614L contains an invocation of another Web service composition called
• scm_purchaser_supplier which takes the ports PC, PS as parameters. Digressing, the definition of the Web service composition "scm_purchaser_supplier” begins at line 614D.
• Line 614D contains the keyword service indicating that a definition for Web services or composition of Web services is about to commence; the designator scm_purchaser_supplier denotes the name of the Web service composition; the parameter PC, which is a port 602F of the purchaser porttype 602B; a parameter PS, which is the port 61 OF of the supplier porttype 610B; and an an open curly bracket " ⁇ ", which has a companion closed curly bracket " ⁇ ” to delimit the definition of the Web service composition scm_purchaser_supplier.
• Line 614E contains the keyword parallel denoting that Web services and processes defined between its open curly bracket “ ⁇ ” and closed curly bracket “ ⁇ ” are to be executed in parallel.
• Line 614F invokes the purchaser Web service 602 with a port 602F designated as PC.
• Line 614G invokes the supplier Web service 606 with the port 606F designated as PS.
• Line 614H invokes the fusing mechanism formed in accordance with this invention to fuse ports 602F (designated as PC) with ports 606F (designated as PS). Whether ports 602F, 606F can be fused depends on whether the porttype 602B of the purchaser Web service 602 is compatible with a porttype 606B of the supplier Web service 606.
• ports 602F, 606F are possible if the safety 602C of the purchaser Web service 602 can be aligned with the safety 606C of the supplier Web service 606 so as to produce an input guarded process.
• the safeties 602C, 606C can be aligned, it is programmatically safe to fuse ports 602F, 606F between the purchaser Web service 602 and the supplier Web service 606.
• a virtual contract can be created for the safe interoperability between the purchaser Web service 602 and the supplier Web service 606. This is described in detail below in connection with FIGURES 8A-8O.
• line 614M contains an invocation of the shipper Web service 610, which takes the port 61 OF designated as PH as a parameter.
• Line 614N contains an invocation of the fusing mechanism formed in accordance with this invention between ports 602F (PC) and port 61 OF (PH). If the fusing between ports cannot be accomplished due to incompatibility between safeties or porttypes, the ports will not be fused.
• FIGURE 6H is a dynamic visual presentation of the invocation of operations in a system 600 that includes the purchaser Web service 602, the supplier Web service 606, and the shipper Web service 610.
• the system 600 commences execution with the invocation of the initiatepurchase operation 602D and the production of the purchase order (PO).
• the purchaser Web service 602 then invokes the receivepo operation 606D of the supplier Web service 606, provides the produced purchase order (PO), and the purchase order ( ⁇ PO) is then consumed by the supplier Web service 606.
• the sendinvoice operation 606E is then invoked with the production of the invoice.
• the supplier Web service 606 then invokes the confirmpurchase operation 602E or the purchaser Web service 602, provides the produced invoice (invoice), and the produced invoice (-invoice) is consumed by the purchaser Web service 602.
• the supplier Web service 606 invokes the notifyofshipment operation 610D of the shipper Web service 610 and provides the advanced shipping notice (ASN).
• the shipper Web service 610 then provides the advanced shipping notice (ASN) to the purchaser Web service 602 and the purchaser Web service 602 consumes the advanced shipping notice ( ⁇ ASN).
• the purchaser Web service 602 next invokes the confirmreceipt operation 610E of the shipper Web service 610 and provides the receipt of goods (goods).
• the shipper Web service 610 provides the receipt of goods (goods), and the receipt of goods (-goods) is consumed by the purchaser Web service 602.
• FIGURE 6H illustrates the invocation order specified by the safeties 602C, 606C, 6 IOC.
• the system 600 commences when the purchase order (PO) is produced at the port 602F of the purchaser Web service 602 and sent to the port 606F of the supplier Web service 606, where the purchase order (PO) is consumed.
• the production of the purchase order (PO) is represented by the designator PO without the tilde " ⁇ " in the parameter list of the initiatepurchase operation 602D.
• the consummation of the purchase order (PO) is represented by the receivepo operation 606D with the parameter -PO.
• a first process broadly represented by the initiatepurchase operation 602D becomes inactive (due to the safety 602C) because the port 602F has sent the purchase order (PO) but has not received the advanced shipping notice (-ASN).
• a second process broadly represented by the receivepo operation 606D continues to a third process broadly represented by the sendinvoice operation 606E (due to the safety 606C) because the port 606F has received the purchase order ( ⁇ PO).
• the third process With the third process being active, the invoice is produced at the port 606F and is sent to the port 602F of the purchaser Web service 602 where the invoice is consumed.
• the safety 606C is now satisfied.
• the production of the invoice is represented by the sendinvoice operation 606E and the consummation of the invoice is represented by the confirmpurchase operations 602E.
• a fourth process broadly represented by the confirmpurchase operation 602E becomes inactive (due to the safety 602C) because the port 602F has not received the advanced shipping notice ( ⁇ ASN).
• Mini communication occurs between the supplier Web service 606 and the shipper Web service 602 once the supplier Web service 606 has received the purchase order (PO) at the port 606F.
• the advanced shipping notice (ASN) is produced by the shipper Web services 610 at the port 61 OF and is sent to the port 602F of the purchaser Web service 602 where it is consumed.
• a fifth process broadly represented by the notifyofshipment operation 610D continues on to a sixth process (due to the safety 610C) broadly represented by the confirmreceipt operation 610E because the port 61 OF has sent the advanced shipping notice (ASN), but the sixth process becomes inactive because the port 61 OF has not received the receipt of goods (-goods).
• the first process broadly represented by the initiatepurchase operation 602D becomes active and continues to the the fourth process (due to the safety 602C) broadly represented by the confirmpurchase operation 602E because the port 602F has received the advanced shipping notice (-ASN).
• the production of the advanced shipping notice (ASN) is represented by the notifyofshipment operation 602D and the consummation of the advanced shipping notice (ASN) is represented by the initiatepurchase operation 602D.
• the fourth process broadly represented by the confirmpurchase operation 602E becomes active (due to the safety 602C) because the port 602F has received the advanced shipping notice (-ASN). With the activation of the fourth process, the receipt of goods (goods) is produced at the port 602F of the purchaser Web service 602 and is sent to the port 61 OF of the shipper Web service 610 where it is consumed.
• the production of the receipt of goods (goods) is represented by the confirmpurchase operation 602E and the consummation of the receipt of goods (goods) is represented by the confirmreceipt operation 610E.
• the safety 602C is satisfied with the production of the receipt of goods (goods).
• the sixth process broadly represented by the confirmreceipt operation 610E becomes active because the port 61 OF has received the receipt of goods (-goods) and the safety 610C is then satisfied.
• the hereinabove discussion shows the inherent synchronization (activity and inactivity) of messages and operations when their processing nuances are expressed using safeties formed in accordance with this invention.
• the model syntax 702 for porttypes is illustrated in FIGURE 7A.
• Various elements of the model syntax 702 are similar to elements of the human-readable syntax 400 (the safety syntactical category described on lines 400C-400P).
• the letter PT 702E contains a definition for a porttype: porttype name ⁇ (M;)* S; ⁇ , where porttype is a keyword declaring the commencement of the definition of a porttype; name is an identifier of the porttype; the pair of open and closed curly brackets delimit expressions that define the porttype; the letter M contains a message (described below); and the letter S (described below) indicates one or more safeties.
• the letter S 702A denotes a named collection of safeties to be defined by various elements of the model syntax 702.
• the symbol “0" 702B denotes an inactive or a stop safety.
• the phrase “M.S” 702C denotes a sequence safety, where the letter M denotes a message type 7021, which is followed by another safety 702A.
• the phrase “S Q + S j " 702D denotes a choice to be made between the execution of the safety S 0 or the safety Si .
• Sj" 702F denotes parallel execution of safeties S 0 and Sj.
• the phrase “rec(K).S” 702G denotes a recursion of a name K 702J in the safety S.
• the phrase “K” 702H denotes that the safety 702A can be given a name.
• FIGURE 7B illustrates a system 700 showing the interoperability between a first
• the Web service 706 and a second Web service 710 the first Web service 706 having a safety SI 706A; a messagel operation 706B; a message2 operation 706C; and a port 706D.
• the second Web service 710 includes a safety S2 710A; a message3 operation 71 OB; a message4 operation 7 IOC; and a port 710D.
• the first Web service 706 and the second Web service 710 are shown to be fused by the fuse line 703.
• FIGURES 8A-8O illustrate a method 800 for forming interoperability among Web services, such as the first Web service 706 and the second Web service 710.
• the following description of the method 800 makes references to various elements illustrated in connection with the model syntax 702 and the system 700 shown in FIGURES 7A-7B.
• the method 800 proceeds to a set of method steps 802, defined between a continuation terminal ("terminal A") and an exit terminal ("terminal B").
• the set of method steps 802 describes the creation of Web service specifications that correspond to Web service programs for first and second Web services 706, 710.
• the method 800 proceeds to a block 808 where a developer creates abstract definitions for a specification of the first Web service 706.
• Abstract definitions of a specification include definitions of data types, messages, and porttypes.
• the developer creates concrete descriptions for the specification. See block 810.
• Concrete descriptions include bindings (not to be confused with the binding mechanism formed in accordance with the invention and described below), which are where protocols, serialization, and encoding of data transmission are specified.
• the concrete descriptions include service elements, which specify port addresses of each binding.
• the developer then creates a safety SI 706 A governing the invocation of operations, such as the message 1 operation 706B and the message2 operation 706C, for the specification of the first Web service 706. See block 812.
• the developer then preferably places the safety SI 706A (hereinafter "SI") into the definition of the porttype for the port 606D. See block 814. Steps 808-814 can be repeated to create a specification for the second Web service 710 including a safety S2 710A (hereinafter "S2"). Next, the method 800 proceeds to the exit terminal B.
• SI safety SI 706A
• S2 safety S2 710A
• the method 800 proceeds to a set of method steps 804, defined between a continuation terminal ("terminal C") and an exit terminal ("terminal D").
• the set of method steps 804 describe the discovery of the second Web service 710 by the first Web service 706 and the verification of the ability of the second Web service 710 to safely interact with the first Web service 706.
• the method 800 proceeds to a block 816 where the first Web service 706 discovers a porttype of the port 710D using the specification of the second Web service 710 via a suitable discovery service.
• a suitable discovery service includes a UDDI service, but others are possible.
• the first Web service 706 selects a porttype of the port 706D, which is to be fused with the port 710D, from the specification of the first Web service 706. See block 818.
• the first Web service 706 then extracts the safety S 1 of the porttype of the port 706D and the safety S2 of the porttype of the port 710D. See block 820.
• the process 800 enters another continuation terminal ("terminal Cl8").
• the first Web service 706 checks whether the safety SI is of the form "0", which denotes inactivity or the stop safety. If the answer is YES to the test at decision block 824, the method 800 proceeds to another continuation terminal ("terminal Cl "). Otherwise, if the answer is NO, the method 800 proceeds to another terminal ("terminal C2").
• the method 800 proceeds to another decision block 830 where the first Web service 706 determines whether the safety SI is of the form "M.S" 702C. If the answer is YES, another continuation terminal ("terminal C3") is entered. Otherwise, if the answer is NO, the method 800 proceeds to another continuation terminal ("terminal C4").
• the method 800 proceeds to another decision block 832 where the first Web service 706 determines whether the safety S2 is of the form "So
• M Q .SO which is a sequence safety 702C. If the answer is NO to the test at decision block 826, another continuation terminal ("terminal C8") is entered. If instead, the answer is YES, the method 800 proceeds to another continuation terminal ("terminal C7"). From terminal C7 (FIGURE 8G) the method 800 proceeds to another decision block 898 where the first Web service 706 determines whether the safety S2 is of the form "M j .S ! " 702C. If the answer is NO, the method 800 proceeds to terminal C19.
• block 848 is entered where the the first Web service 706 determines whether a match function, which takes M 0 , M ] as arguments, is defined. See block 848.
• a simple implementation of the match function includes a return of a TRUE Boolean result if M Q is the complement of M . Otherwise, the match function would return a FALSE Boolean result. If the answer to the test at decision block 848 is NO, the safety SI bound with the safety S2 (M Q .S Q ⁇ MJ .S ] ) is undefined. See block 894. The method 800 then proceeds to terminal C20.
• cut is a function that takes Mo, M j as arguments.
• FIGURES 6A-6I shows the interoperability among Purchaser, Supplier, Shipper Web services.
• match function is defined to match types to corresponding types of messages and the cut function is defined to remove these pairs (types and corresponding types)
• the actions of the Purchaser Web service are joins. In other words, the Purchaser Web service waits for both the purchase order (PO) to be consumed and the advanced shipping notice (ASN) to be supplied before advancing in the safety.
• the method 800 proceeds to terminal Cl 8 to loop back to block 822 where the above- described method steps are repeated.
• the method 800 proceeds to another decision block 852 where the first Web service 706 determines whether the safety SI 706A is of the form "SolS j ", which denotes the parallel safety 702F. If the answer is NO, the method 800 proceeds to another continuation terminal ("terminal C 11 "). Otherwise, if the answer is YES, another continuation terminal (“terminal C9") is entered.
• the method 800 proceeds to another decision block 854 where the first Web service 706 determines whether the safety S2 of the second Web service 710 is of the form "S2IS3", which is in the form of the parallel safety 702F. If the answer is NO to the test at decision block 854, the method 800 proceeds to terminal C19. Otherwise, if the answer is YES, block 856 is entered by the method 800.
• the safety SI bound with the safety S2 ((S 0
• S 1 ): :(S 2
• SQ 3 2,3 , 1 a set of four choices
• S 1 , 2 , 3 , o + (S2,0, 1 ,3) + S3 ,o, 1 , 2 ) •
• Each of the four choices can be placed in a form S; m n . See block 858.
• S n )): :S j is defined for a particular choice. See decision block 860.
• S n )): :Sj. See block 862.
• the method 800 proceeds to another continuation terminal ("terminal CIO"). If instead the answer is NO, block 864 is entered where the particular choice is equated to the relationship The method 800 then also proceeds to the terminal CIO.
• the method 800 proceeds to block 866 where one of the four choices (S 0 , 2 ,3, l) + ( s 1 ,2,3, ⁇ ) + ( s 2,0, 1 ,3) + ( s 3,0, l ,2) is selected.
• the process 800 then proceeds to terminal C18 to loop back to block 822 where the above- described method steps are repeated.
• the method 800 proceeds to another decision block 868 where the first Web service 706 determines whether the safety SI is of form rec(K).S 0 , which denotes a recursion safety 702G. If the answer is NO to the test at decision block 868, another continuation terminal ("terminal Cl 2") is entered. Otherwise, if the answer is YES, another decision block 870 is entered where the first Web service 706 checks whether the safety S2 is of the form "S" 702A. If the answer is NO to the test at decision block 870, terminal C19 is entered by the method 800.
• the method 800 proceeds to terminal C19. From terminal C12 (FIGURE 8J), the method 800 proceeds to another decision block 874 where the first Web service 706 checks whether the safety SI is of the form "S" 702A. If the answer is NO, the method 800 proceeds to terminal C 19.
• the method 800 proceeds to another decision block 880 where the first Web service 706 verifies whether the safety S2 is of the form "M Q .S/MI ". If the answer is NO, the method 800 proceeds to another continuation terminal ("terminal C14"). If the answer is YES, the first Web service 706 determines whether a match function, which takes M 0 , Mj as arguments, is defined. See block 882.
• a simple implementation of the match function includes a return of a TRUE Boolean result if M Q is the complement of M . Otherwise, the match function would return a
• FIGURES 6A-6I which shows the interoperability among Purchaser, Supplier, Shipper Web services.
• the match function is defined to match types to corresponding types of messages and the cut function is defined to remove these pairs (types and corresponding types)
• the actions of the Purchaser Web service are joins.
• the Purchaser Web service waits for both the purchase order (PO) to be consumed and the advanced shipping notice (ASN) to be supplied before advancing in the safety.
• the process 800 proceeds to terminal Cl 8 to loop back to block 822 where the above- described method steps are repeated.
• the method 800 proceeds to another decision block 888 where the first Web service 706 determines whether the safety S2 is of the form "(S ⁇ +SjYM". If the answer is YES, the safety S2 is equated to two choices (So/M-H-CSi/M). See block 890. One of these two choices is selected. See block 892. Next, the method 800 proceeds to terminal C 18 to loop back to block 822 where the above-described method steps are repeated. If the answer to the test at decision block 888 is NO, the method 800 proceeds to another continuation terminal ("terminal C16").
• the method 800 proceeds to another decision block 899 where the first Web service 706 checks the safety S2 to determine whether it has the form (S ⁇
• the method 800 proceeds to another decision block 893 where the first Web service 706 determines whether the safety S2 is of the form rec(K).S/M. If the answer is YES, the safety S2 is equated to (S ⁇ rec(K).(S/K) ⁇ /M).
• the first Web service 706 determines that a syntax error has occurred because either the safety S 1 or the safety S2 does not comply with the model syntax 702. See block 889. Fusing between ports 706D, 710D is not possible because safeties SI, S2 are not in a form that can be computed.
• the method 800 proceeds to a set of method steps 806, defined between a continuation terminal ("terminal E") and an exit terminal ("terminal F").
• the set of method steps 806 creates a virtual contract, which is a binding agreement, between the first Web service 706 and the second Web service 710 if the safeties S 1 and the safety S2 can be aligned in a suitable manner that allows for safe interoperability between the first Web service 706 and the second Web service 710.
• the method 800 proceeds to another decision block 885 where the first Web service 706 determines whether the safety S3 (which is the result of the binding relationship between the safety S 1 and the safety S2 ) is equal to zero. If the answer to the test at decision block 885 is YES, the port 706D of the first Web service 706 can be fused with the port 710D of the second Web service 710. See block 881. When two ports can be fused in this way, the interoperability between the first Web service 706 and the second Web service 710 is safe.
• safe means that there exists an input guarded process; that every output has met an input; or that there is no deadlock because the input of either the first Web service 706 or the second Web service 710 is always available to receive messages to process them.
• ports 706D, 710D are fused, the second Web service 710 can commence communicating with the first Web service 706 to provide or to obtain desired services. See block ' 879. The method 800 then proceeds to exit terminal F where it terminates processing.
• a symmetric version of the pi calculus offers the following classes of processes.
• Example 1.1.1 The following example provides a bare bones implementation of a service that expects to be initialized, then is willing to accept repeated work requests or a finalize request.
• Example 2.2.1 The paradigmatic example is the one where a service must be initialized, then is willing to accept repeated work requests or a finalize request.
• Example 2.2.2 This example shows an extremely simplistic three way contract between a purchaser, supplier and shipper.
• the Purchaser will initiate a purchase, offering a purchase order and expecting an advanced shipping notice. It wants to receive an invoice and supply an acknowledgment of receipt of goods.
• the Supplier waits for a purchase order then provides an invoice.
• the Shipper provides an ASN and waits for an acknowledgement of receipt of goods.
• portType Supplier receivePO( ⁇ PO); sendlnvoice(Invoice); rec(k) . (receivePO . sendinvoice . k) ;
• Service SCM_Purchaser (pC Purchaser); Service SCM_Supplier(pS:Supplier); Service SCM_Shipper(pH:Shipper);
• the Type Checking Algorithm There are two forms of type-checking to be done. One checks the compliance of a given service implementation with the collection of port types being advertised (or required). This cannot be specified here in absence of a choice of implementation language. The other checks that given two port types it is safe to 'bind' one port to the other.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Software Systems (AREA)
• Computer Hardware Design (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Information Transfer Between Computers (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (5)

Publications (2)

Family

ID=32072855

Family Applications (1)

Country Status (5)

Families Citing this family (2)

Family Cites Families (3)

• 2003
  • 2003-05-13 KR KR1020057005481A patent/KR101013304B1/ko not_active Expired - Fee Related
  • 2003-05-13 AU AU2003229074A patent/AU2003229074A1/en not_active Abandoned
  • 2003-05-13 WO PCT/US2003/015129 patent/WO2004031970A1/en not_active Ceased
  • 2003-05-13 JP JP2005500109A patent/JP4555221B2/ja not_active Expired - Fee Related
  • 2003-05-13 EP EP03726856A patent/EP1546901A4/de not_active Withdrawn

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events