Patent Application
20070033580
The present invention relates generally to transforming instruction sets in one language to compatible instruction sets in another language, and more specifically relates to mapping simple object access protocol (SOAP) messages with the business process language XLANG/s.
A challenge faced by many Web sites is the provision of dynamic content, i.e., content that changes in real-time. This requires applications to be run from Web servers and transported via an appropriate protocol. A dynamic web content model allows World Wide Web (WWW) content providers to provide web services, such as interactive business applications, rather than merely publishing pages of static information.
Web services are used by businesses to interact via distributed environments, such as the Internet or WWW. To ensure that these interactions are accomplished successfully, transport mechanisms must be in place for carrying messages to and from participants, and specific business applications must be in place at each participants end. These interactions, by their very nature are message driven. For example, a buyer sends a purchase order to a seller. The seller then checks its inventory to determine if it can provide the ordered items. The seller then sends an acknowledgement back to the buyer with a price. Finally, the buyer accepts or rejects the sellers offer (and possibly places another order). As evident in this example, each participant's business application reacts to the receipt of messages, which may be received at any time. Thus, a participant's business application should be able to receive, and send, messages to conduct business transactions in an asynchronous manner. To successfully conduct a business transaction, a participant's asynchronous transactional messaging business application should be able to communicate with another participant's asynchronous transactional messaging business application via the transport mechanism. Also, each asynchronous transactional messaging business application should be able to communicate with the transport mechanism, while complying with the transport mechanism's protocol.
However, all transport mechanisms are not compatible with all business applications. A possible solution to force compatibility is to require each participant to write its asynchronous transactional messaging business application using instructions that are specifically tailored to comply with every protocol requirement of the transport mechanism. This is difficult, if not impossible for every situation. A participant would have to know the exact requirements of the protocol of the mechanism to be used. This is not always known in advance. Also, it would be extremely difficult and time consuming to program an asynchronous transactional messaging business application to address every protocol requirement. This level of difficulty would deter potential participants from using that business application. In order for businesses to use web services, the web services should be user friendly. That is, complex, intricate programming steps should be transparent to the participant. The participant should be able to generate high level business applications utilizing nomenclature and concepts familiar to the participant and normally used in the specific business.
Therefore, techniques for providing compatibility between asynchronous transactional messaging applications and web services that are transparent to the participant are desired.
The present invention provides compatibility between web services and asynchronous transactional messaging languages. Instructions in an asynchronous transactional messaging language, are mapped, or transformed, into instructions that are compatible with the web services. In one embodiment, the asynchronous transactional messaging language is XLANG/s, and the web service languages are the web services description language (WSDL) and the simple object access protocol (SOAP). A designer, or programmer simply writes high level declarative statements, in XLANG/s for example, that pertain to the specific type of business transaction. During compilation, selected instructions are transformed into instructions that are compatible with web services, such as SOAP or WSDL for example. This transformation is transparent to the designer of the business application. The transformation process transforms the type of instruction and the syntax of the instruction. Proxy classes, which refer to the class or interface name of the message, are transformed into port types. A port is a construct from which messages can be received or sent, and a port type defines a collection of operations that can be used on a port type. Methods of a proxy class are transformed into operations. An operation defines a single valid exchange that can occur on a port type. The input and output parameters of the operations (viz., methods) are transformed into request message types and response message types, respectively. The XLANG/s source files are compiled in an iterative compilation process. During each pass of this compilation process, different XLANG/s types and variables are parsed. These parsed results are logically organized in a tree structure. The tree structure is traversed in depth first traversal order. During this traversal, the XLANG/s constructs are transformed into instructions compatible with web services, such as WSDL/SOAP.
The features and advantages of the present invention will be best understood when considering the following description in conjunction with the accompanying drawings, of which:
A technique in accordance with the present invention makes web services compatible with asynchronous transactional messaging languages. In one embodiment, instructions in the asynchronous transactional messaging language, XLANG/s are mapped, or transformed, into instructions that are compatible with the web services description language (WSDL) and simple object access protocol (SOAP) messages. As described in more detail below, proxy classes are transformed into port types, methods of the proxy classes are transformed into operations, and the input and output parameters of the operations are transformed into request message types and response message types, respectively. This is accomplished by compiling the XLANG/s source files in an iterative compilation process. During each pass of this compilation process, different XLANG/s variables are parsed. The compilation results in compilation units. These units are logically organized in a tree structure. The tree structure is traversed in depth first traversal order. As units are encountered during this traversal, the XLANG/s compilation units are replaced with compatible WSDL/SOAP compilation units. Throughout this document, the terms transform, translate, and map are used interchangeably. To facilitate an understanding of this translation process, a brief introduction to web services, SOAP, and the XLANG/s language are provided below.
Introduction to Web Services
Businesses, today more then ever, are interacting via distributed environments, such as the Internet or World Wide Web. For example, a user may want to know the prices of rental cars for an upcoming trip. The user may request these prices through an intermediate business on the Internet. The intermediate business, upon receiving the user's request, will send requests to a variety of rental car businesses. After responses are received, the intermediate business will then send the results to the user. The user will then reserve a car and pay for the reservation via the intermediate business. Web services are utilized to facilitate these types of interactions. Web services include, among other things, communication protocols to facilitate communication between different businesses on the network. One such protocol is the simple object access protocol (SOAP), which is described in more detail below. Also, businesses do not always use the same application software to conduct their activities. A language designed to automate business processes based on web services is XLANG/s, which is also described in more detail below. However, in order for a web service to be effective, protocols, such as SOAP, and business process languages, such as XLANG/s, must be able to communicate with each other. Establishing this compatibility is an application of an embodiment of the present invention.
Introduction to Soap
SOAP is a protocol for exchange of information in a distributed environment (e.g., the Internet). Information is exchanged via SOAP “messages”. SOAP may be envisioned as a Remote Procedure Call (RPC) protocol that uses HTTP as its transport and XML as its data format, or packaging. It is to be understood, however, that neither SOAP, nor the syntax for specifying SOAP-based Web Services described herein are limited to HTTP as a transport. SOAP is described in U.S. Pat. No. 6,457,066, issued to Mein et al., and in a document entitled “Simple Object Access Protocol (SOAP) 1.1”, a W3C note of May 8, 2000, authored by DevelopMentor, IBM, Lotus Development Corporation, Microsoft, and User Land Software, both of which are hereby incorporated by reference in their entirety as if presented herein.
SOAP is a protocol capable of accessing and invoking methods in Automation objects across the Internet and through firewalls. The protocol includes a data structure which encodes, as a SOAP request, the name of the Automation object of interest, a method to invoke that object, any valid Automation (in)(out) parameters to be exchanged with the object, and creates a client-side SOAP proxy for the Automation object.
A SOAP message is an XML document with predefined elements that may have user-defined data as sub-elements. The predefined elements include a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. The envelope is the top element of the XML document representing the message. The header is a generic mechanism for adding features to a SOAP message. The body contains mandatory information intended for the ultimate recipient of the message. An example format of a SOAP message is shown below in Table 1.
An example of a typical “Hello World”-style HTTP SOAP request is described below. In this example, an input string is provided as an input and the output is in the form of “Hello ‘input string’”. Consider the function: string HelloWorld (string inputstring). This is a function named “HelloWorld” that takes a string parameter as input and returns a string. This example shows a typical scenario for which this function can be invoked remotely via SOAP and HTTP. The format of this exemplary “Hello World” SOAP HTTP request is shown in Table 2 below:
The first part of the request contains common HTTP headers, with the addition of the HTTP SOAP request-specific SOAPAction header. The SOAP message portion follows the format described above (note the absence of the “Header” element). The user data under the “Body” attribute is one possible encoding of a “Hello World” RPC request. The element “inputString” is a parameter to the function “HelloWorld” and has the value “StringValue”.
When a server receives this message, it:
The format of an exemplary “Hello World” SOAP HTTP response is shown below in Table 3.
Introduction to XLANG/s
XLANG/s is a language that describes the logical sequencing of business processes, as well as the implementation of the business process by using various technology components or services. The XLANG/s language is expressed in Extensible Markup Language (XML). The XLANG/s Language is a modern, special purpose language used to describe business process and business protocol. It is a declarative language, and as such it defines an explicit instruction set describing and implementing steps in a business process, the relationship between those steps, their semantics, and interactions. XLANG/s code is designed to be executable, not just descriptive. Because of its declarative nature and specific semantics, the resulting executable code is deterministic; that is, the behavior of the running business process is well defined by the semantics of the collection of XLANG/s instructions. The definitions of these business processes in executable form are called orchestrations.
XLANG/s is compatible with many internet standards. XLANG/s is designed to use XML (Extensible Markup Language), XSD (XML Schema Definition), XSLT (XSL Transformations), XPATH (XML Path Language), and WSDL (Web Services Description Language) as supported standards and has embedded support for working with .NET based objects and messages. The XLANG/s language is syntactically similar to C# to facilitate learning and understanding XLANG/s. The use of XLANG/s is most advantageous when applied to a business process. Lower level implementation of that process, such as database access, may be more appropriately performed through .NET based objects. Because XLANG/s assignment and expression syntax is modeled after C#, a C# specification may be referenced as an aid to understanding the exact syntax.
The XLANG/s language defines a rich set of high-level constructs used to define business process. While providing support for low-level data types like string and int, high-level data-types are also defined. These high-level data types include messages, ports (locations to which messages are sent and received), correlations, and service links. These data-types are used to rigorously define the semantics associated with the business process. These data-types are complemented by process control statements such as ‘if/else if/else’, ‘while’, and ‘scope’ (including transactional scopes, for both long-running and atomic transactions).
XLANG/s statements generally fall into one of two categories: simple statements that act on their own, such as receive or send; and complex statements which contain or group either simple statements or other complex statements. Complex statements include service, scope, parallel, and listen.
The semantics embodied in XLANG/s are a reflection of those defined in a document titled “Business Process Execution Language for Web Services”, Version 1.1, dated Mar. 31, 2003, published by Microsoft, IBM, and BEA for the definition of Business Process semantics, which is hereby incorporated by reference in its entirety as if presented herein. The Business Process Execution Language for Web Services specification is commonly referred to as the BPEL4WS specification.
A relatively simple XLANG/s program requires a port type and a message type to be defined (this gives the orchestration some data to work with), receives the message over a port and then terminates. Table 4 below contains an example of XLANG/s source code for a simple “Hello World” program.
The above HelloWorld application will compile, thus resulting an orchestration. However, any underlying runtime that executes this orchestration will have difficultly processing it because there is no indication how to activate the orchestration. In XLANG/s, an activation receive invokes a new instances of an orchestration. In a typical real world business application, several messages are sent to and from the XLANG/s application. In addition, many running instances of the application may exist. For example, in the above HelloWorld application, a PurchaseOrder message is processed. This single application can process several (e.g., hundreds or thousands) of purchase orders concurrently. Preferably, a runtime implementation of XLANG/s is informed when a message should create a new instance of the process. The XLANG/s implementation is informed via an activation receive. Activation receives invoke new instances of an orchestration. However, if the message is to be routed to an existing instance, preferably the runtime implementation of XLANG/s is informed via a correlation set. Correlation sets define how a message is routed to an existing instance.
Shown below in Table 5 is example XLANG/s source code of the HelloWorld application, in which the receive statement is now an activation receive. Also, a send port is added, and the message is sent to that port.
This version of the HelloWorld application creates a new running instance of the orchestration and sends the received message over a send port. This version of HelloWorld has the following new elements: (1) A new send port type and port: ptPOSend and poPOSend, respectively; (2) The receive statement is now an activate receive, which creates a new instance of the orchestration; and (3) A send statement which directs the message to a send port. In the two port declarations shown in the above source code, the poPOReceive uses the implements modifier, and the poPOSend uses the uses modifier. The implements modifier tells the runtime it will be receiving a message over that port. The uses modifier tells the runtime that it will be sending a message over that port.
XLANG/s understands C# (or .NET) types. However, XLANG/s categorizes .NET types into distinguished (or simple) and complex types. The distinguished types are the following classes in the System namespace (and the complex types are all other types).
XLANG/s reason for being (raison d'etre) is message handling. Messages can be based on schemas, .NET classes, Web Message types (WSDL), and/or complex message types. For example in the above HelloWorldApp application, the message msgPO was defined as an instance of a schema based message.
XLANG/s supports the following complex data types:
Shown below in Table 6, is source code of the HelloWorld application using XLANG/s complex data types. The initial version of the HelloWorld application contained porttypes, this revised version also contains a complex messagetype, a correlationtype for the re-transmission and receipt of a business message, and a servicelink type used to distribute the message to one of several potential partners.
This version of the HelloWorld application has the following new artifacts:
The following statements are utilized in the XLANG/s language.
An XLANG/s service communicates with the outside world by sending and/or receiving messages. The message type is the structural definition of such a communication entity. Conceptually a message can be thought of as a collection of multiple strongly-typed parts. Within an XLANG/s module, the message-type can be declared as either a multipart-type declaration or a method-type declaration. An exemplary format of a multi-part message-type definition is shown below.
If the message-type declaration includes more than one part declaration, exactly one of the parts is annotated as a body (or identifying) part. If the message-type declaration has only one part, the body annotation is optional. In one embodiment, this is used for on-the-wire type determination, in which the type of the body part is an alias for the type of the aggregate message. An empty message-type declaration (i.e., with no parts) is allowed. Such messages are used to convey a data-free notification.
XLANG/s supports two type systems: Net and XSD. This support for dual type systems is visible in the way XLANG/s treats part declarations. A message part of type .Net type, is declared as:
To natively use a .NET type as a message part, XLANG/s imposes no further restriction on it other than the fact that the type must be XML serializable using the declared type.
Additionally, XLANG/s provides an extensibility mechanism whereby non XML serializable classes can be used as a message part by providing a custom formatter for the type. The runtime implementation, in such cases, uses the formatter for serialization of the object to create the wire format.
XSD-based types can be used as message parts by special casing into prescribed .NET type, which envelopes the XSD schema associated with the type. In the grammar XSD type's usage looks exactly as above, however, the underlying implementation relies on the complete definition for the XSD based type to be made available in a prescribed fashion. The part declaration itself looks like:
The first production is used when the XSD schema to which the part is pointing to is a single-rooted schema. The type of the envelope class is, then, sufficient to determine the XSD type. In case the schema being pointed to is a multi-rooted schema, the second production is necessary to point to the specific root element that is used to define the type.
Method-message-types are used to define a message-type based on a signature of a method call. This style is useful when targeting Web Services calls where the resulting message-types (which essentially mirror the Web Service call's parameters) can be created by the user by pointing to a web-services method. Generally, when a message-type is declared using the method as the base, one can declare two message-types from it: a request type, aggregating all the in and ref parameters; and a response type, aggregating all the out, ref parameters and (when non-void) the return value (identified by having the part-name equal to the method name concatenated with Result). It is ill-conditioned to have a parameter with the same name.
An example message type declaration is shown below.
Fundamentally XLANG/s understands multi-part messages. Therefore, method type declarations are transformed into a multi-part declaration. For the request type, each in & ref parameter becomes a part. For the response type, each out & ref parameter is a part. In addition the response type has another part relating to the return value when non-void.
An example of an interface definition and corresponding XLANG/s code is shown below. Assuming an interface definition as following:
its usage in XLANG/s will appear as follows:
Port Types
A port is an end point at which an XLANG/s service can send and/or receive messages. Each port is of a particular type. The porttype is a full structural definition of the shape of interactions that occur on any instance of that type. Aporttype is a collection of operations.
An operation is the definition of any single valid exchange that can occur on the porttype. Direction is not specified in the porttype definition. The specific usage of the porttype (i.e., a port declaration) details the direction and consequently the usage with-in a service. Exemplary port-type and operations declarations are shown below.
Each operation, on the porttype, can be oneway or requestresponse in nature. An example of this is shown below.
The operation name is unique across all operations for a specific port type. A oneway operation is associated with a single message-type, which travels as input into this operation. A on-way operation does not have an associated response. A requestresponse operation is associated with a request message type, a response message type, and (optionally) multiple faults (all individually named). Fault names are unique across a particular operation. Fault types are unique across all the fault(s) and the response type for the operation. Exemplary statements are shown below.
Class and interface names can be used for defining the shape/type of a port.
When using this syntax:
At step 106, the compilation units are logically formed into a parse tree. This tree is traversed in depth first parse tree traversal order at step 108. At step 110, during the traversal, selected XLANG/s compilations units (i.e., those types, ports, and messages corresponding to Web Services) are replaced with (transformed to) WSDL/SOAP compatible compilation units. For each compilation unit, method messagetypes and class-based porttypes appearing in servicelinktypes, are transformed upon parsing the first service in the units. Then the method-based messages and class-based ports are transformed. When subsequent services are parsed, only the method-based messages and class-based ports need to be transformed.
Returning to step 302, if the instruction is a message type, then the fully qualified method name is extracted from the name space at step 314. The prefix comprising double underscores followed by the term “messagetype”, followed by a single underscore is appended to the fully qualified method name at step 316. At step 318 it is determined if the instruction includes an input parameter or an output parameter. If the instruction comprises an input parameter, then at step 310, a suffix comprising a single underscore followed by the term “request” is appended to the fully qualified method name. At step 312, all periods are replaced with underscores in the fully qualified method name. For example, if the fully qualified name for a SOAP method having a request operation is: “N1.N2.N3.ProxyClass.XBar”, the transformed instruction is: “——messagetype_N1_N2_N3_ProxyClass_XBar_request”.
Returning to step 318, if it is determined that the instruction comprises an output parameter, a suffix comprising a single underscore followed by the term “response” is appended to the fully qualified method name, at step 320,. At step 322, all periods are replaced with underscores in the fully qualified method name. For example, if the fully qualified name for a SOAP method having a response operation is: “N1.N2.N3.ProxyClass.XBar”, the transformed instruction is: “——messagetype_N1_N2_N3_ProxyClass_XBar_response”.
A more comprehensive example illustrating syntax transformations to both port types and message types is shown in Table 7 below. Assume the following example proxy class.
Utilizing the above described transformation syntax, yields the transformed names, shown in Table 8.
The following two examples illustrate the above described transformation processes. A programmer and/or designer writes XLANG/s code to be associated with web services. The code that is written by the programmer/designer is transformed by the processes described above to be compatible with the web services. The following examples show code that could be used on both sides of a message transaction. One side is referred to as the web services side and the other side is referred to as the client side. Also, at the beginning of each example the web services code is shown. This web services code is in the form of SOAP code.
Table 9 below contains the Hello World SOAP example described earlier.
The Web Services side XLANG/s code that implements a corresponding Web Service is shown in Table 10 below:
A client side Web Service implemented in XLANG/s takes the form shown in Table 11 below.
To be compatible with the SOAP code of Table 9, the XLANG/s code of Table 10 is transformed in accordance with the processes described above. The transformed XLANG/s code, transformed from the code shown in Table 10 is shown below in Table 12 below.
To be compatible with the SOAP code of Table 9, the XLANG/s code of Table 11 is transformed in accordance with the processes described above. The results are shown below in Table 13.
The second example is slightly more sophisticated than the first example. Web Services in the form of two SOAP methods are shown below in Table 14.
The XLANG/s code that would be written by a designer/programming to be associated with the code of Table 14 is shown below in Table 15.
In order for the XLANG/s code of Table 15 to be compatible with the SOAP code of Table 14, it is transformed in accordance with the processes described above. The resultant code is shown in Table 16 below.
More specifically, the code generator 406 analyzes the transformed parse tree from the transformer 404 and then produces an intermediate language that can be compiled into machine instructions to execute the program, or the code generator 406 can produce machine instructions directly. The parse tree is traverses in depth first traversal order. During this traversal, the transformer 404 transforms selected compilation units into corresponding instructions compatible with web services (e.g., WSDL, SOAP). These transformations are performed in accordance with the processes described above with reference to
Overview of a Suitable Computing System Environment
The method and system for transforming SOAP messages to XLANG/s are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the method and system for transforming SOAP messages to XLANG/s include, but are not limited to, personal computers, server computers, hand-held 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.
The method and system for transforming SOAP messages to XLANG/s may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The method and system for transforming SOAP messages to XLANG/s may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media including memory storage devices.
With reference to
The computer 510 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 510 and includes both volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, 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 includes, 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 tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 510. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “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. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. It is to be understood that combinations of any of the media are also included within the scope of computer readable media.
The system memory 530 includes computer storage media in the form of volatile and/or non-volatile memory such as ROM 531 and RAM 532. A basic input/output system 533 (BIOS), containing the basic routines that help to transfer information between elements within computer 510, such as during start-up, are typically stored in ROM 531. RAM 532 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 520. By way of example, and not limitation,
The computer 510 may also include other removable/non-removable, volatile/non-volatile computer storage media. By way of example only,
The drives and their associated computer storage media, discussed above and illustrated in
The computer 510 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 580. The remote computer 580 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 510, although only a memory storage device 581 has been illustrated in
Then used in a LAN networking environment, the computer 510 is connected to the LAN 571 through a network interface or adapter 570. When used in a WAN networking environment, the computer 510 typically includes a modem 572 or other means for establishing communications over the WAN 573, such as the Internet. The modem 572, which may be internal or external, may be connected to the system bus 521 via the user input interface 560, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 510, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
Various distributed computing frameworks have been and are being developed in light of the convergence of personal computing and the Internet. Individuals and business users alike are provided with a seamlessly interoperable and web-enabled interface for applications and computing devices, making computing activities increasingly web browser or network-oriented.
For example, MICROSOFT®'s .NET platform includes servers, building-block services, such as web-based data storage, and downloadable device software. Generally speaking, the .NET platform provides (1) the ability to make the entire range of computing devices work together and to have user information automatically updated and synchronized on all of them, (2) increased interactive capability for web sites, enabled by greater use of XML rather than HTML, (3) online services that feature customized access and delivery of products and services to the user from a central starting point for the management of various applications, such as e-mail, for example, or software, such as Office .NET, (4) centralized data storage, which will increase efficiency and ease of access to information, as well as synchronization of information among users and devices, (5) the ability to integrate various communications media, such as e-mail, faxes, and telephones, (6) for developers, the ability to create reusable modules, thereby increasing productivity and reducing the number of programming errors, and (7) many other cross-platform integration features as well.
While exemplary embodiments herein are described in connection with software residing on a computing device, one or more portions of the method and system for transforming SOAP messages to XLANG/s may also be implemented via an operating system, application program interface (API), or a “middle man” object between a coprocessor and requesting object, such that services may be performed by, supported in, or accessed via all of .NET's languages and services, and in other distributed computing frameworks as well.
A method for transforming SOAP to XLANG/s as described herein may be embodied in the form of computer-implemented processes and system for practicing those processes. A method for transforming SOAP to XLANG/s as described herein may also be embodied in the form of computer program code embodied in tangible media, such as floppy diskettes, read only memories (ROMs), CD-ROMs, hard drives, high density disk, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes a system for practicing the invention. The method for transforming SOAP to XLANG/s as described herein may also be embodied in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over the electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes a system for practicing the invention. When implemented on a general-purpose processor, the computer program code segments configure the processor to create specific logic circuits.
The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may utilize the signal processing services of the present invention, e.g., through the use of a data processing API or the like, are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.
The methods and apparatus of the present invention may also be practiced via communications embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a client computer, a video recorder or the like, or a receiving machine having the signal processing capabilities as described in exemplary embodiments above becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates to invoke the functionality of the present invention. Additionally, any storage techniques used in connection with the present invention may invariably be a combination of hardware and software.
While embodiments of the present invention has been described in connection with the exemplary embodiments of the various figures, it is to be understood that other similar embodiments may be used or modifications and additions may be made to the described embodiment for performing the same function of the present invention without deviating therefrom. Furthermore, it should be emphasized that a variety of computer platforms, including handheld device operating systems and other application specific operating systems are contemplated, especially as the number of wireless networked devices continues to proliferate. Therefore, the present invention should not be limited to any single embodiment, but rather should be construed in breadth and scope in accordance with the appended claims.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10459021 | Jun 2003 | US |
| Child | 11546034 | Oct 2006 | US |
