This invention relates to computer software, and specifically to software applications which may be used to develop other software applications.
Web services are web-based applications which are designed to interact with other applications, such as other web services or client applications. Web services may be deployed in private environments, such as within enterprises to enable divisions and/or subsidiaries to exchange data. Web services may also be deployed publicly. For example, a web service may be registered on the Internet via the Universal Description, Discovery and Integration (UDDI) initiative. Applications may search for a description of a service and, once an appropriate service is found, may interact with it, such as to complete a fee-based transaction.
A web service exposes its functionality via one or more endpoints, which are addressable ports through which an external application may exchange data with the web service. A particular endpoint may expose a plurality of functions or processes to an external application.
Communication with a web service is accomplished via messages. Specifically, in order to invoke a function provided by a web service, an external application typically transmits a “request” message, in a predefined format specified by the web service, to an appropriate endpoint. Upon processing information included in the message, the service may transmit a “response” message to the external application, which also has a predefined format specified by the web service.
A web service “contract” defines various characteristics of a web service, including functions or operations it provides, the format of request and response messages, the communication protocols it employs, and other features, behaviors and rules. As such, the web service contract provides a vehicle for describing a web service to external application. Web service contracts may be developed, for example, in the web service description language (WSDL), the SOAP Service Description Language (SSDL), or any other suitable description language.
A WSDL contract for a web service may define the format of a particular message in the form of an XML Schema. The XML Schema may be incorporated within the WSDL document itself, or may be defined by a separate XML Schema Document (XSD) and be referenced thereby. A WSDL document may also define a binding, or communication protocol, used by an endpoint to receive and transmit messages. For example, a contract may specify that an endpoint employs the Simple Object Access Protocol (SOAP), Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), or any other protocol.
Web services are generally developed according to one of two basic approaches. In private environments where information on functions provided by a web service may be more readily available, a “code-driven” approach is more common. According to this approach, the web service application code is developed first. The WSDL contract describing the web service may be developed later, or may be created automatically, for example, by the application, based on the application code. When a web service is deployed publicly, so that interoperability with external applications is of primary importance, a “contract-driven” approach is more common. According to this approach, the contract is typically developed first, and then an application which conforms to the contract is developed later.
According to one embodiment of the invention, a computer-implemented method is provided for facilitating the definition of a contract for a web service, the contract defining an operation performed by the web service and a format of a message used to communicate with the web service to invoke the operation, the method comprising: (A) implementing at least one rule related to features of the web service, the at least one rule limiting the features of the web service to a subset of features, the subset of features comprising a portion of the features which could characterize the web service; and (B) presenting an interface to a user which enables the user to define the contract for the web service, the contract reflecting the features of the web service, wherein the interface enables the user to select features for inclusion in the contract from among the subset of features.
According to another embodiment, a computer-readable medium is provided having instructions encoded thereon, which instructions, when executed by a computer, perform a method of facilitating a definition of a contract for a web service, the contract defining an operation performed by the web service and a format of a message used to communicate with the web service to invoke the operation, the method comprising: (A) implementing at least one rule related to features of the web service, the at least one rule limiting the features of the web service to a subset of features, the subset of features comprising a portion of the features which could characterize the web service; and (B) presenting an interface to a user which enables the user to define the contract for the web service, the contract reflecting the features of the web service, wherein the interface enables the user to select features for inclusion in the contract from among the subset of features.
The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component illustrated in the figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:
Applicants have appreciated that web services are deployed publicly with increasing frequency, such that interoperability between web services and external applications is becoming increasingly important. As a result, a contract-driven approach to developing web services is becoming increasingly common.
Applicants have also appreciated that conventional tools for developing web service contracts have several key deficiencies. Specifically, while conventional tools may enable a user to develop a sophisticated web contract by providing graphical or forms-based access to the varied functionality provided by web service description languages such as WSDL and SSDL, including parameters for protocols, message format and program calls, most of this functionality is typically not required by a user. Moreover, because conventional tools force the user to select from forms or graphical elements to employ specific functional concepts in a web service contract, the user must understand all of the varied functional concepts to create a valid contract using these tools. Further, because a number of conventional tools display concepts embodied in a web service contract as graphical elements that are connected via links, a crowded and visually confusing interface is frequently presented to the user. Because web service description languages such as WSDL and SSDL may be difficult for users to read and understand, using a basic editing application may not be a viable alternative to conventional tools for many users. Thus, deficiencies with conventional tools form a barrier to more widespread development of web services using a contract-driven approach.
According to one embodiment of the invention, a software application is provided which may address these and other deficiencies by making a number of simplifying assumptions regarding functionality which may be provided by a web service. These assumptions may be based on typical web service implementations, and may reduce the functional options available to a user for inclusion within the corresponding web service contract. For example, according to one embodiment of the invention, the software application may assume that a web service includes one or more endpoints, that each endpoint will employ a SOAP binding, and that specifications defined by the Web Services Interoperability Basic Profile Specification developed by the Web Services Interoperability (WS-I) Organization are followed. As an example, the WS-I 1.0 specification provides that a particular port type may not be used by more than one SOAP binding, that each message includes only a single part, and that SOAP messages follow a literal style.
Because fewer functional concepts are exposed to the user, a more intuitive approach to developing a web service contract may be facilitated.
One embodiment of a process employed by the application to simplify and reduce the functional options presented to a user is shown in
According to one embodiment, the software application provides a graphical user interface (GUI) which enables a user to define a web service contract. The application may enable the user to define messages employed by the endpoint(s) provided by the web service, in an integrated fashion. That is, the GUI may allow the user to view and edit the format of messages and/or other characteristics of a particular function, operation or sequence of operations within the larger context of an endpoint, so that other messages and/or characteristics may be viewed easily and the relationship between those other messages and/or characteristics and the considered message may be easily discerned. Further, in one embodiment, the user may specify the format of one or more messages using a “design by example” approach, wherein the user may provide one or more example messages that conform to a prescribed format, and from which the format of the message may be inferred.
An exemplary interface which may enable the user to design a web service contract and the messages defined thereby is shown in
In
In one embodiment, contract region 205 may enable a user to edit the functions or operations provided by an endpoint (e.g., endpoint 220) or various characteristics thereof. For example, a user may add to, remove or change operations provided by the endpoint, and designate particular operations to support requests (i.e., messages transmitted to the endpoint), responses (i.e., messages transmitted from the endpoint in response to a request), and/or other messages. User editing of operations may be facilitated in any suitable manner, as the invention is not limited in this respect. For example, contract region 205 may enable a user to add a function or operation to endpoint 220 by selecting an “Add” option from selection provided in an edit menu (not shown). In one embodiment, when a user adds to, changes or removes a function or characteristic thereof, commensurate modifications are made to the web service contract which the interface represents.
As can be seen by the highlighted element in contract region 205 in
In the exemplary interface shown, the information related to order message 235 which is shown in message region 210 is controlled in part by the buttons 216-218 which are provided on application bar 215. For example, by pressing button 216 (as shown in
In one embodiment, each of regions 210A-210C may receive input from a user (e.g., via a mouse and/or keyboard), and may be functionally coupled so that each region informs or constrains the other regions. For example, a user may edit an XML schema for order message 235 in message region 210B (as shown in
Alternatively, a user may first edit a sample message in message region 210A, then switch to message region 210B (e.g., by pressing button 217), and an XML schema may be automatically inferred from the sample document. The application may, for example, apply one or more rules which define how a schema may be inferred from a sample. The rule(s) may be defined and/or implemented in any suitable manner. For example, XML schema inference rules defined by the XML Editor product offered by Microsoft Corporation of Redmond, Washington, may be implemented.
Of course, the software application need not be configured to automatically and/or unconditionally infer a schema from a sample message. For example, if the user supplies input to message region 210B which causes the sample message to no longer comply with its XML schema, the software application may prompt the user to confirm that changes to the schema are to be implemented, or request that the user cancel the changes to the sample data so that the data conforms to the prior schema, or to take any other suitable action. The application may also be configured to prompt the user to decouple the message regions 210A-210C, such that the user may proceed by editing the sample and/or schema in its respective region independently of the other “view”. Any suitable manner of message editing may be facilitated, as the invention is not limited in this respect.
It should be appreciated that providing the user with an ability to switch between displays of an XML schema and sample message, where the displays inform and restrain each other, may allow the user to design a message iteratively. In this respect, those skilled in the art will recognize that it is often difficult to conceive of an XML schema without first examining sample data, and that the nature of the XML language is such that it is nearly impossible to infer all aspects of a schema from sample data since specific restrictions can not be expressed in a message sample. Thus, some users may find the ability to design a message iteratively, by switching back and forth between sample data and a schema, to be valuable.
In one embodiment, the software application may be configured to allow a user to define any suitable number of samples for a particular message. For example, the application may provide the user with the capability to copy data from one sample message and paste the data into another sample message. A new sample may be added to a collection of samples for the considered message. Any suitable portion of sample messages in the collection may be functionally coupled to the schema, so that modifications to one sample may be used to update the schema and thus constrain the other samples.
It should be appreciated that although the contract region 205 and message region 210 are illustrated in
Further, it should be appreciated that a region of the interface (e.g., the region of the interface which is occupied by contract region 205 in
In one embodiment, the application may allow the user to view and/or edit the underlying web service contract which is produced via the features of the software application described above.
In the exemplary interface 300, this “WSDL View” may be generated when a user clicks on button 245 (also shown in
While the WSDL view is displayed (as shown in
It should be appreciated that the exemplary features described in the foregoing with reference to
Various aspects of the invention may be implemented on one or more computer systems, such as the exemplary computer system 400 shown in
The processor 403 executes a program called an operating system which controls the execution of other computer programs, and provides scheduling, input/output and other device control, accounting, compilation, storage assignment, data management, memory management, communication and data flow control. The processor and operating system define the computer platform for which application programs in other computer programming languages are written.
The processor 403 may also execute one or more programs to implement various functions, such as those which embody aspects of the invention. These programs may be written in a computer programming language such as a procedural programming language, object-oriented programming language, macro language, or combination thereof.
These programs may be stored in storage system 406. The storage system may hold information on a volatile or nonvolatile medium, and may be fixed or removable. The storage system is shown in greater detail in
Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.