The present invention relates generally to Web services. More particularly, this invention relates to generating Web services using a Web service tool.
Web services are open interfaces that allow a user of the services to link loosely-coupled systems with a technology that is independent of programming languages and platforms. The World Wide Web Consortium (W3C) defines a Web service as a software system designed to support interoperable machine to machine interaction over a network. In the business context, Web services allow business data to be shared, combined, or modified by heterogeneous computing resources among business partners.
For example, an enterprise may provide a Web service that allows its business partners to enter data (e.g., business leads) into an Adobe® interactive form and upload/email the form to the enterprise's system. This enables the enterprise to collect data offline. The collected data can be modified, combined, and/or synchronized with the system at a later time. As another example, a service provider can use a Web service to send service tickets to service technicians in the field. The service technicians can respond and add field data by filling out a form provided by the Web service.
A Web service is typically implemented as an extensible markup language (XML) object comprised of a combination of contents, application code, functional logic, and application program interfaces (APIs), which can be accessed over any network, e.g., the Internet. The network is typically a TCP/IP based network using the Simple Object Access Protocol or Service Oriented Architecture Protocol (SOAP) standard for message exchanges. A Web service is typically described in a Web Services Description Language (WSDL) file, which is a machine readable description of the operations and message formats supported by the server hosting the Web service. A Web service may be published and discovered, using a Universal Description Discovery and Integration (UDDI) protocol, to enable applications on a remote system to find the Web service.
Conventional Web services are typically designed manually. Function modules and Web service interfaces are conventionally coded by programmers who possess both technical knowledge and business knowledge. Even with highly qualified programmers, the process of creating a Web service may take a long time. As a result, the cost and time for providing a Web service increase greatly.
A system for generating a Web service includes a graphical user interface to guide a designer to create a Web service in pre-defined stages. The graphical user interface receives an input that selects an object and associated attributes from a repository of pre-defined business objects. The system includes a Web service generator that automatically generates code describing and implementing the Web service according to the selected object and attributes. The system also includes a Web service engine to perform runtime operations of the Web service. Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.
Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
A method and system for a Web service tool is described herein. In the following description, numerous details are set forth to provide a more thorough explanation of embodiments of the present invention. It will be apparent, however, to one skilled in the art, that embodiments of the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, to avoid obscuring embodiments of the present invention.
The Web service tool, as described herein, allows a Web service designer to quickly create new services tailored to the specific needs of an organization. With the Web service tool, program code implementing a customized Web service can be generated automatically without manual coding. Instead, a designer merely needs to select pre-defined business objects and their associated attributes to define the Web service. The Web service tool provides a user-friendly creation wizard, which guides a designer stage by stage in the definition process of the Web service. The creation wizard hides technical complexity of building a Web service and allows rapid service deployment. In some embodiments, Web services created by the Web service tool comply with the World Wide Web Consortium (W3C) standard. Therefore, Web services created by the tool can be used by all enterprise service-oriented architecture (SOA) enabled applications
In some embodiments, the Web service tool is able to utilize the application program interface (API) and functionalities provided by NetWeaver® to test a Web service at design time and operate the Web service at runtime. NetWeaver® is a business application that integrates business processes across various sources and is a product of SAP AG located in Germany.
With the Web service tool, an enterprise can build Web services that allow its customers to access product and price information from an external system, e.g., the customers' procurement systems. The Web services can also allow the customers to create sales orders in the enterprise's Customer Relationship Management (CRM) system. For example, the sales order can be created by linking the customer's procurement software to the enterprise's order management application.
The Web service tool allows a designer to create standard Web service operations, such as read, create, query, and change services for business objects in a CRM system. In some embodiments, security and user authorizations of the Web services can be handled by the standard NetWeaver® Web services environment.
In the embodiment of
Referring to
After retrieving the information from CRM application 22 and BOL 23, WST generator 113 displays the retrieved data on a WST user interface 22 for user selection and configuration (block 303). The selection and settings are then stored in a WST database 26 for use during runtime of the Web service (block 304). According to the user selection and settings, WST generator 113 generates data and function modules, e.g., Web service modules 17 and function modules 214, which are utilized during runtime of the Web service (block 305).
As mentioned above with reference to
Referring to
The information retrieved in block 504 is returned to function modules 25 (block 505), which in turn forwards the information to Web service modules 17 (block 506). Web service modules 17 provide the information in the response to requester 13 (block 507). In
The following description provides more details to the generation of a Web service using the components described above. To create a Web service, WST user interface 22 of
Overview list 61 includes a plurality of data fields, e.g., object name field 631, a “used as” (object type) field 632, an object description field 633, an object status field 634, and a query field 635. Object status field 634 indicates the current status of the object (e.g., draft, activated, productive, or non-productive), which will be described in detail below with reference to
Overview screen 600 also allows a designer to copy or delete an existing object. A copy icon 66 and a delete icon 67 are provided in the menu bar of overview list 61. A designer may select an object from overview list 61 (e.g., by clicking on the box 68 next to the selected object name), and click on copy icon 66 or delete icon 67 to copy or delete the selected object. The copy function allows a designer to create a new object by copying an existing object and then modifying or enhancing the copied object. The modification or enhancement can be made by adding or changing attributes associated with the object. The copy function guarantees reusability and extensibility of the Web services. Thus, a worldwide enterprise can define its best practice Web services by adopting a standard set of objects. This standard set of objects may be copied and enhanced by the enterprise's IT departments worldwide to adapt to country-specific needs. For example, Web service security settings of a copied object can be changed according to the planned usage environment of the service.
To create a new object, such as a service object that defines a Web service, a designer can click on a “New” button 65. When the designer clicks on New button 65, a first screen 700 of the creation wizard is displayed.
First screen 700 also includes a query section 79 that displays a list of available query objects. In the example shown in
To navigate to the next wizard screen, the designer can click on a right arrow 77, or directly select the (1-2-3-4) wizard icons 702 on top of first screen 700. At any stage of the creation wizard, a designer can move to a prior or a next screen by clicking on a left arrow 78 or right arrow 77, or may jump to any creation stage by clicking on a number on wizard icon 702 corresponding to the destination stage. It is understood that the location of the icons in any of the screens described herein may vary from the specific embodiments as shown without departing from the broad spirit of the invention. For example, left arrow 78 and right arrow 77, as well as the corresponding arrows in other screens described herein, may be located at the bottom of the corresponding screen.
More specifically, default values can be used to limit a requestor's options. For example, if requestor 13 is to create leads in the Web service provider's CRM system, the Web service provider can set a default value that limits the leads in a certain category. Default values also can hide system-specific data from requestor 13. For example, a designer can set certain data fields as mandatory and use default values for these fields. These mandatory fields can then be excluded from the WSDL file of the Web service to reduce the complexity of the Web service interface.
Third screen 900 also allows a designer to change attribute names for the attributes selected in second screen 800. Attributes can be renamed to customary names or code names that have a specific meaning within an organization. The renaming feature allows Web service provider 12 to create Web services interfaces customized for a common company language, and therefore helps to reduce the complexity of the service interfaces. The renaming feature is also useful if the Web services are to be used in another country where idiomatic usage of language is different. For example, the “House Number” attribute can be renamed to “Street Address.”
Third screen 900 includes a list of the selected attributes and the related information, including a relationship (or node) name 91, attribute description 92, whether the attribute is standard 93 or excluded 94, a reference name 95, a default value 96, and a field name 97. Relationship name 91 is the internal name used by WST 11, a marked excluded 94 field indicates that the attribute is excluded from WSDL file 15, and a marked standard 93 field indicates that the attribute is not excluded. Reference name 95 is the new name given to the renamed attribute and is the name used for the attribute in the WSDL file describing the new Web service. Field name 97 is limited for user interface objects or combinations.
Although not shown in
In fourth screen 1000, a designer can save the new Web service, start the consistency check, activate the Web service, and set the Web service to a “productive” status. The designer can save the new Web service by clicking a save icon 1007 on the menu bar. A corresponding save icon is also provided in each of the screens 700, 800, and 900 for saving the design in progress.
After the Web service is saved and activated, a designer can directly open and export the associated WSDL file 1012 (
During the activation process of the Web service, WST generator 113 generates Web service module 17 and function modules 25 (
A service object, such as the Web service just created, can have one of the four different states: draft, activated, productive, or non-productive. A designer can edit, delete, or change the attributes associated with the object depending on the status. The initial status is draft. In this status, the Web service under creation can be changed, deleted, or copied. After the Web service is created and activated, its status switches from draft to activated and the service becomes available. Deletion and copy of an activated Web service is also possible. Whenever the service definition is to be changed, e.g., by adding more attributes, the status of the service can be set back to draft. After the Web service has been successfully tested, its status can be set to productive to prevent anyone from changing or deleting the service. However, a productive Web service can be copied and the copied version can be modified. If the status of a Web service is non-productive, the Web service can be deleted but not changed.
A method and system for generating a Web service has been described herein. Portions of what was described above may be implemented with logic circuitry such as a dedicated logic circuit or with a microcontroller or other form of processing core that executes program code instructions. Thus, processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine that executes these instructions to perform certain functions. In this context, a “machine” may be a machine that converts intermediate form (or “abstract”) instructions into processor specific instructions (e.g., an abstract execution environment such as a “virtual machine” (e.g., a Java Virtual Machine), an interpreter, a Common Language Runtime, a high-level language virtual machine, etc.), and/or, electronic circuitry disposed on a semiconductor chip (e.g., “logic circuitry” implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative, to a machine, or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code.
It is believed that processes taught by the discussion above may also be described in source level program code in various object-orientated or non-object-orientated computer programming languages supported by various software development frameworks. The source level program code may be converted into an intermediate form of program code (such as Java byte code, Microsoft Intermediate Language, etc.) that is understandable to an abstract execution environment (e.g., a Java Virtual Machine, a Common Language Runtime, a high-level language virtual machine, an interpreter, etc.), or a more specific form of program code that is targeted for a specific processor.
An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a propagation medium (e.g., via a communication link such as a network connection).
In the foregoing specification, embodiments of the invention have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.