Embodiments of the invention generally relate to the field of web services. More particularly, the embodiments of the invention relate to generating and providing a web services client extensions model.
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.
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. With conventional web services modeling applications and tools, neither the interoperability nor the client-side flexibility are sufficiently achieved because of the limitation in use of web services metadata and conventional separation of standards, models, and entities for web services (WS) and web services client (WSC). For example, Java application programming interface (API) for Extensible Markup Language (XML)-based Remote Procedure Call (RPC) (JAX-RPC), such as JAX-RPC 1.1, does not provide for loading and describing of dynamic web services interfaces, data access, and object manipulation. Furthermore, its metadata hides important web service details and is not suitable for building specialised web service applications.
A system and method are provided to generate an enhanced configuration model. In one embodiment, application programming interfaces (APIs) are identified. The APIs relate to web services and/or web services clients. Access to the APIs is provides via a configuration model.
The above attributes may be implemented using a computer program, a method, a system or apparatus, or any combination of computer programs, methods, or systems. These and other details of one or more embodiments of the invention are set forth in the accompanying drawings and in the description below.
The invention is 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.
As used herein, references to one or more “embodiments” are understood as describing a particular feature, structure, or characteristic included in at least one implementation of the invention. Thus, phrases such as “in one embodiment” or “in an alternate embodiment” appearing herein describe various embodiments and implementations of the invention, and do not necessarily all refer to the same embodiment. However, they are also not necessarily mutually exclusive. Descriptions of certain details and implementations follow, including a description of the figures, which may depict some or all of the embodiments described below, as well as discussing other potential embodiments or implementations of the inventive concepts presented herein.
In one embodiment, extension model 300 includes extension interfaces 308 that serve as a convenient API for setting additional client settings and for providing additional client APIs that are in addition to merely the basic client properties. This mechanism allows for setting up of the WS client more convenient and developer-friendly. By providing a homogenous and client-independent and WS-independent extension interface via extension interfaces 308, the need for different client setups is eliminated. For example, an extension API 308 can be used with various types of WS clients (e.g., dynamic client, JAX-RPC client, etc.) as the extension API 308 is WS client-independent and can be used regardless of the type of the WS client. In one embodiment, extension interfaces 308 are generated by defining and providing various APIs needed to configure various WS clients such that there is not longer the need to provide specific settings (e.g., security settings) for each of the WS client. In one embodiment, client proxy 304 may be used in communication with extension interfaces 308, but not necessarily used directly.
In one embodiment, extension interfaces 308 at extension model 300 provide client runtime functionalities, via APIs, that are used by consumer application developers via client 302. The components of these extension APIs are represented by an extension interface name, a factory name, and interface methods. The usage may also be included for clarity. Examples of such extension APIs include an SOAP header interface, a session interface, a HyperText Transfer Protocol (HTTP) control interface, a WS security interface, etc.
For example, the SOAP header API is provided for setting and getting SOAP headers by consumer applications. Methods for getting headers can be invoked after an operation call, while the setting of output headers is done before the operation call. As mentioned previously, the components of this SOAP header API may be represented by an extension interface name (e.g., com.sap.engine.services.webservices.espbase.client.api.SOAPHeaderInterface, etc.), a factory class name (e.g., com.sap.engine.services.webservices.espbase.client.api.SOAPHeaderFactory, etc.), and interface methods (e.g., java.lang.Object getInputHeader(javax.xml.namespace.QName headerName, ClassheaderType) throws UnmarshalException for returning response SOAP Header using deserialization framework, etc.).
The session interfaces is provided to manage HTTP sessions when using web services that support “cookie” sessions. As with SOAP header API, the components of the session API are also represented by an extension interface name (e.g., com.sap.engine.services.webservices.espbase.client.api.SessionInterface, etc.), a factory class name (e.g., com.sap.engine.services.webservices.espbase.client.api.SessionInterfaceFactory, etc), and various interface methods. HTTP control interface provides fine control over some HTTP connection properties that web services clients use to access web services. The components of the HTTP control interface are represented by an extension interface name, a factory class name, and interface methods. The WS security interface is used to provide security settings for WS clients. As with the other interfaces mentioned here as examples, the components of the WS security API are also represented via an extension interface name, a factory class name, and interface methods.
Extension interface 402 further provides a public interface 404 that contains the methods and APIs provided to the consumer developer via the client extension. Furthermore, interface implementation provides implementation class 408 for extension interface 402. The instances of implementation class 408 are associated with specific port instantiated by the consumer application. Once the job with the specific port is completed, the extension instance may not be needed anymore.
The illustrated extension interface structure 402 suggests a tight integration of factory class 406 and implementation class 408 to the WS Client framework and further coupled to interface 404. Factory class 406 is used to create instances of implementation class 408 to provide implementation of interface 404. Interface 404 may include a Java interface to allow the developer to, via a client, access the additional APIs that are provided via extension interface 402. Extension interface 402 represents one or more groups of APIs. In one embodiment, components 404, 406 above the dotted line 410 are made visible to the client, while implementation class 408 may remain internal.
In one embodiment, to perform various embodiments of the present invention, a server or node (e.g., J2EE server) is employed, which supports Enterprise Java Bean (“EJB”) components and EJB containers (at the business layer) and Servlets and Java Server Pages (“JSP”) (at the presentation layer). A virtual machine (VM) may include a Java virtual machine (JVM) to host the server or server node. It is understood that processes taught by the discussion above can be practiced within various software environments such as, for example, object-oriented and non-object-oriented programming environments, Java based environments (such as a J2EE environment or environments defined by other releases of the Java standard), other environments (e.g., a NET environment, a Windows/NT environment each provided by Microsoft Corporation), and the like.
Processes taught by the discussion above may be performed with program code, such as machine-executable instructions, which can cause a machine (such as a “virtual machine”, a general-purpose processor disposed on a semiconductor chip, a special-purpose processor disposed on a semiconductor chip, etc.) to perform certain functions. Alternatively, these functions may be performed by specific hardware components that contain hardwired logic for performing the functions, or by any combination of programmed computer components and custom hardware components.
One or more modules within or associated with an enhanced configuration model (such as the enhanced configuration model 300 of
Client systems 802-806 may execute multiple application or application interfaces. Each instance or application or application interface may constitute a user session. Each user session may generate one or more requests to be processed by server 810. The requests may include instructions or code to be executed on a runtime system, such as VM 816, on server 810 and its components and modules as described throughout this document.
In addition to what is described herein, various modifications may be made to the disclosed embodiments and implementations of the invention without departing from their scope. Therefore, the illustrations and examples herein should be construed in an illustrative, and not a restrictive sense. The scope of the invention should be measured solely by reference to the claims that follow.