Efforts are being made to more easily conduct business in a web-based environment. “Web Services” is loosely understood to mean the ability to discover and conduct business in a web-based environment. For example, a user (e.g., a web-based application or person with a web browser) may: 1) search through an online registry of businesses and/or services; 2) find a listing in the registry for web based access to a service that that the user desires to have performed; and then, 3) engage in a web based business relationship with the service application including the passing of relevant information (e.g., pricing, terms, and conditions) over the network. In other words, web services generally refer to offerings of services by one application to another via the World Wide Web.
Given the nature and use of web services and the rapid increase in their demand, interoperability of web services across clients and servers is becoming increasingly important and cumbersome. Some attempts have been made to achieve interoperability across a wide range of platforms and runtimes. For example, using open standards like eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI), some interoperability has been achieved.
FIG. 1 illustrates a prior art web services platform 100. The platform 100 shows various XML-related standards 102-110 that are used in connection with web services to attempt interoperability. The illustrated standards include XML Namespaces 102, similar to JAVA package names, to provide syntax for data representation in portable format. SOAP 104 refers to a standard packaging format for transmitting XML data between applications over a network. XML schema 106 refers to the World Wide Web Consortium (W3C) schema specification for XML documents. WSDL 108 refers to the standard used for describing the structure of XML data that is exchanged between systems using SOAP 104. Finally, UDDI 110 refers to a standard SOAP-based interface for web services registry and defines a set of web services operations and methods that are used to store and search information regarding web services applications.
However, the open standards are not evolving fast enough to keep up with the increasing demand for web services and needs of additional flexibility and control on the client-side. One of the problems today is the convoluted relationships and mappings between relevant standards. Neither the interoperability nor the client-side flexibility are sufficiently achieved because of the conventional separation of standards, models, and entities for web services (WS) and web services client (WSC). FIG. 2 illustrates a prior art web services model 200. The illustrated web services model 200 includes Web service definition 204, which includes the description of design-time configuration of a web service. Web service configurations 206 refer to the description of the run-time configurations of a web service. The web services model 200 further includes a virtual interface 202. A virtual interface 202 refers to an abstract interface.
Referring now to FIG. 3, it illustrates a prior art web services client model 300. In the illustrated web services client model 300, schema to JAVA (STJ) mappings 302 contain serializer classes and deserializer classes of the XML Schema Definition (XSD) Types. However, the conventional STJ mappings 302 do not contain any field or operation-specific mappings. The conventional model 300 further includes logical ports 304 that are limited to containing merely runtime (RT) relevant configurations and do not contain design-time (DT) configurations. Finally, the illustrated WSDL 306 contains a parsed WSDL structure.
Although the conventional models 200, 300 provide some flexibility, further improvements are needed to achieve interoperability. For example, the conventional model 200 provides provider-oriented inside-out approach for web services, but it does not support consumer-based outside-in approach for web services, which is becoming increasingly important. The conventional models 200, 300 do not provide similar modeling approach for developing web services and web services client which leads to usability deficiencies.
USPTO Backgrounds
USPTO Backgrounds