US20020120685A1 - System for dynamically invoking remote network services using service descriptions stored in a service registry - Google Patents
System for dynamically invoking remote network services using service descriptions stored in a service registry Download PDFInfo
- Publication number
- US20020120685A1 US20020120685A1 US10/120,175 US12017502A US2002120685A1 US 20020120685 A1 US20020120685 A1 US 20020120685A1 US 12017502 A US12017502 A US 12017502A US 2002120685 A1 US2002120685 A1 US 2002120685A1
- Authority
- US
- United States
- Prior art keywords
- service
- request
- services
- description
- output
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5015—Service provider selection
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
Definitions
- This invention relates to electronic information processing systems and more particularly to methods and apparatus for providing information-based services from a plurality of diverse resources to one or more users.
- the Internet has provided access to millions of different information resources.
- human beings typically use browser programs to sift through web pages, web indexing services and available subject matter directories to locate useful information. While powerful tools have been made available to assist human researchers in finding what they need, the vast amount of data which is accessible cannot typically be processed by application programs. Thus, while programmatic access to data on the Internet would be extremely useful, it is not now available.
- Another aspect of the problem is that different resources have different access protocols.
- a developer may need to: (1) access a personnel payroll database for the amount of money to be transferred and the destination account, (2) send a message to a legacy system to initiate the transfer, and (3) access an employee directory service to lookup the employee's email address to send an alert email. All these resources are accessed via different protocols, such as JDBC to access the personnel database, a proprietary protocol to the use the legacy system, and LDAP for directory services. Consequently, each developer must write special code to access each of these different resources, rather than concentrating on the development of application logic.
- the present invention takes the form of methods and apparatus for obtaining information from each of a plurality of diverse data resources having different characteristics.
- a separate service description for each given data resource is stored in a database called the Services Registry.
- Each service description includes: the address to which an information request may be transmitted; a specification of the nature of the input information to be supplied; and a description of the nature of the output information to be supplied in response to request.
- Service requests identifying particular resources may be issued by application programs.
- a service interface program is then executed in response to each such service request to obtain the particular service description corresponding to the identified resource from the Services Registry.
- the interface program then transmits an output information request to the address specified in said particular service description, supplies input information meeting the specification contained in said particular service description to the resource, and routes output information provided by said particular resource to the requesting application program.
- a registration module is preferably used to accept service description information in a predetermined format, preferably in Extensible Markup Language (XML), so that the service description may be validated against a Service Descriptor Schema, which may take the form of an XML schema such as a Document Type Description (DTD), before it is stored in the Services Registry.
- XML Extensible Markup Language
- DTD Document Type Description
- the stored service description may also advantageously include contact information specifying the person or entity supplying the resource described in said service description, as well as test information consisting of fixed input values and fixed output values.
- the stored test values enable the service interface program to perform automatic testing of the described resource by sending the fixed input values to the described resource and comparing the resulting output from the resource with the fixed output values.
- the stored service descriptions may advantageously further include security information for ensuring that requests for output information originate from an authorized source before that request directed to the described resource is satisfied.
- a client When a client sends a request for services to the services interface program, it obtains the service description for the desired resource from the database, transmits an output information request to the address specified in said the service description, supplying input information meeting the specification contained in said particular service description to said particular resource, and receives and routs output information provided by said particular resource in response to said output information request to the executing application program.
- the Dynamic Services Framework contemplated by the present thus wraps disparate resources with a standard programmatic interface which can be accessed in standard ways, primarily using Java.
- a resource owner (service provider) can easily build a dynamic service descriptor specifying the input/output characteristics of accessing their resources. With the descriptor, accessing the resource becomes accessing a service through a standard simple programmatic interface.
- the Dynamic Services Framework provides the infrastructure and logic for abstracting the access of different resources with a single standard interface.
- FIG. 1 is a block diagram which provides an overview of the basic methods performed by and structure of the present invention
- FIG. 2 is a data flow diagram which illustrates an embodiment of the present invention.
- FIG. 3 is a chart depicting the principal class structures used to implement the preferred embodiment of the invention.
- the present invention provides methods and apparatus for effectively converting a variety of diverse information-based resources, such as Internet web sites, databases, and other servers, into information services accessible to programs.
- Each service as presented via an application program interface, conforms to a functional interface standard which provides the application programs with the metadata needed to access and integrate these resources for presentation to an end user.
- Developers refer to developers of Internet applications.
- Dynamic Service a component within the Internet computing model that delivers a specialized value-added functionality.
- a dynamic service typically comprises some content, or some process, or both, with an open programmatic interface.
- Dynamic Service Engine an engine that provides storage, access and management of dynamic services.
- Dynamic Services Framework an open programming framework for enhancing a relational database Internet platform, such as Oracle8i, for service creation, deployment, access and management. It comprises dynamic service engine, a set of dynamic services, as well as users of dynamic services (service consumer).
- Execution Adaptor a routine that executes a service request in a particular flow.
- a flow could be as simple as relaying the request to contacting a service provider, or as complicated as relaying a request to a provider and relaying the response to another provider.
- Input Adaptor a routine that post-processes the service input from consumers to produce the standard service input that is fed to the underlying service.
- An example is converting the unit of length from foot to meter.
- Output Adaptor a routine that transforms the raw output from the underlying service to the standard service response.
- Protocol Adaptor a routine that transforms the standard service request to the inputs needed by underlying service following the underlying protocol.
- Service Consumer the person who makes use of services in his context, typically some web application developer.
- Service Descriptor a descriptor defining the behavior of a service, containing service provider information, description of service functionality, service management information, service input adaptor, service output adaptor, and other provider-specific sections, such as secure access, caching parameters, etc.
- Service Engine same as Dynamic Service Engine
- Service Engine Administrator the person who perform administrative activities for the engine, e.g., enabling/disabling of services, tuning caching parameters of a service, etc.
- Service Handle is a logical representation of a service. In practice it is an in-memory structure that is used to create requests, send requests and fetch responses for the service consumer.
- Service Invocation a programmatic request for a service. After having retrieved a service handle, a service consumer can use that handle to make service requests. This invocation process is analogous to making method calls on an object. The life-cycle of an invocation starts when the request is made and ends when a response is returned to the consumer.
- Service Provider the person/organization that provides a service, typically the owner of some data resource or process, e.g., the owner of a currency exchange rate web site.
- Service Registration is the process of entering the service package into the Services Registry. This action is performed by the Service Administrator upon receiving a service package from the Service Provider and augmenting it by exercising deployment decisions.
- FIG. 1 of the drawings The general makeup of a preferred embodiment of the invention is shown in FIG. 1 of the drawings.
- the system operates under the programmatic control of application programs called Service Consumers (SC) which are executed on behalf of system clients as seen at 117 .
- the application programs utilize access components 130 to send requests to and receive information from a Dynamic Services Engine (DSE) 113 which is connected via the Internet 114 to selected Service Providers (SC) indicated generally at 115 .
- DSE Dynamic Services Engine
- SC Service Providers
- the application program utilizes the information thus obtained to provide value-added information to the end users (clients) 117 .
- DSE Dynamic Services Engine
- Service Definition data called a Service Definition (SD) which describes each Service Provider is first stored in a specification database called the Services Registry (SR) 121 using a registration procedure indicated at 111 .
- the registration procedure 111 supplies a Service Definition for a given service provider in the form of a service Descriptor document expressed in Extensible Markup Language (XML) as indicated at 125 .
- XML Extensible Markup Language
- the individual elements of each XML service Descriptor document 125 are mapped onto a predetermined service description schema in the specification database 121 .
- the database 121 is preferably a relational database which forms part of an integrated database system, such as the Oracle 8i System marketed by Oracle Corporation, Redwood Shores, Calif. 94065, a comprehensive platform for building and deploying Internet and enterprise applications.
- the Oracle 8i platform provides numerous features which can be used to advantage by program developers for developing robust application programs which can also make use of the diverse database resources provided by the present invention. These program development features include:
- iFS the Internet File System, which provides an Internet based file system where the “files” are stored and managed by the database.
- interMedia which facilitates the management of multimedia data, including text, graphics, video and audio files
- WebDB an HTML-based development tool for building web content from the Oracle database using web browsers to develop and build dynamic Web applications which employ data stored completely in the database with no additional Web servers;
- the Java Virtual Machine which forms part of the same machine environment used to execute the Dynamic Services Engine 113 and the functions of the database 121 , is used to execute the translators, seen at 127 in FIG. 1 and discussed in more detail later.
- Each of the translators 127 preferably takes the form of a Java jar file supplied by the implementor to convert data in special formats from particular ones of the service providers 115 into a standard form which may be processed by other components of the system.
- the Service Consumer application program 117 can take the form of a Java program which executes within the Java Virtual Machine, and functions which are performed by the Dynamic Services Engine 113 can be implemented with Java programs executed by the same Java VM.
- Dynamic Service Framework advantageously exploits a number of additional mechanisms which are provided by the Oracle8I RDBMS. Framework leverages those technologies and offers its services on top of them:
- Oracle Jserver The Dynamic Services Engine may be deployed as Java components running on the Oracle JServer JVM.
- Oracle Internet Directory This LDAP directory service may be used by the Registries of the Dynamic Services Framework. This includes the Services Registry, the User Registry and their relationships for handling Access Control.
- Oracle Advanced Queuing Oracle AQ may be used as the underlying system for the communication between the DSE and its clients.
- Oracle Advanced Security Manager is an administration tool that provides a graphical user interface to manage enterprise users, enterprise domains, databases, and enterprise roles that are held in a directory server. Once the consumer has logged in, he/she is free to access any secured service provider which he/she has registered before.
- communications facilities other than the Internet 114 illustrated in FIG. 1 can be used to provide the communications links which couple the service providers 115 to the Dynamic Services Engine 113 and to the Service Consumer application programs 117 .
- data transmission facilities other than the Internet can be used to provide the communication links which couple client machines to the services provided by the system.
- These other communications facilities include leased line connections, mobile phone links, and anything else that can communicate with the host system (e.g. Oracle 8i) via HTTP, IIOP, SQL*NET, Mobile Gateways, and the like.
- Program developers who wish to use a particular resource such as an Internet web site, to provide information to one or more application programs, or a service provider who desires to make a resource generally available to program developers and users, follows a standard registration procedure, indicated at 111 in FIG. 1, to create and store the Service Definition data that the Dynamic Services Engine requires to provide access to that resource.
- the Service Definition is preferably provided to the system as a service definition XML document 125 .
- XML possesses a number of desirable features which make it particularly well suited for the expression of Service Definition data, including the existence of tools for creating and testing the syntax and validity of the specification data to be submitted.
- An XML schema such as an XML DTD, may be used to specify the required and optional elements which should be present in each Service Definition.
- Tools constructed in accordance with the Document Object Module (DOM) standard may be used to provide an application programming interface (API) for the XML Service Descriptor documents.
- API application programming interface
- Standard XML editing tools may be used to prepare the XML data in compliance with a Service Definition schema, allowing the resulting data to be directly mapped into a corresponding schema used by the relational database 121 which is then accessed in the conventional way by the Dynamic Services Engine 113 or by an application program which can make use of the specification data.
- the XML Service Descriptor document 125 and the corresponding data as stored in the specification database 121 , may contains the following kinds of information:
- Company Information this information is use to identify the service provider and includes information to locate and contact the service provider (typically a company or individual) directly by mail, phone, email, company URL or other contact information. If the service provider's logo is to be used in connection with the service, that logo is specified.
- Security Information regarding each service permits the Dynamic Services Engine to perform security functions, either as built-in routines or as provided by others, to authenticate users, validate transactions, encrypt messages, etc.
- each Service Definition includes a list of inputs required to execute the service. At the time the service is executed, a request for each of the specified inputs is automatically presented to the user application program in an appropriate format in each user environment. This mechanism allows the services engine to separate functionality from the presentation, a key to providing the same service on different platforms.
- a user can also provide default values for each or all of the inputs. The default values could be a presented to the user as a list from which users can select a value.
- An input may simply a URI to point the Dynamic Services Engine to a particular service provider together a filename or method name to access the resource.
- an input specification could take the form of a specific URL with a specified GET or PUT method.
- the services engine 113 identifies the jar file from the database 121 and uses the selected Java translator 127 to provide the desired interface to the specific service provider resource 115 .
- the service engine 113 only processes those outputs which are specified in the outputs section of the Service Definition for that resource.
- Contact Information from the service descriptor is used to send a message to the owner or manager of the service provider which does not properly respond to a service request.
- This notification message may take several forms, including email, a prerecorded or synthesized voice message to a designated phone number, a fax transmission, a pager message, etc.
- the services engine will periodically search for updated service information from time to time at a location or locations specified in the Service Definition, which also specifies the frequency with which the update check is to be performed.
- a user or service provider can send a message to the service engine after an update is completed, or can post a new location specification from which further updates will be provided.
- the Service Definition includes fixed input and output values which may be used to test the operation of a specified service. In this way, a malfunctioning service provider can be distinguished from failures caused by communication delays or the like. Automatic tests using this information can be performed periodically to help ensure system integrity, and can also be performed after updates or refresh operations to ensure proper operation of each service.
- Caching Information This section of the service description captures the service driven caching parameters. Items in this section instruct the services engine to use or not use cache memory for a particular operation, and inform the engine how long he cached data should be retained and when it should be considered to be expired. When services are known to present static data which changes only infrequently, requesting retention of fetched data in the cache can both reduce network traffic and provide faster service.
- Additional Information Beside the classes of information noted above, additional information may be stored in the specification database for each service provider resource, including usage log data, information to be presented back to the service provider for its use, or information used to customize or tune a particular service.
- FIG. 2 of the drawings illustrates the operation of the Dynamic Services Engine, shown at 113 in FIG. 1, in more detail.
- each available resource is first described in an XML Service Definition which is translated and stored in the Service Definition database, shown 311 in FIG. 2. All Service Definitions stored in the database 311 are structured in accordance with a predetermined database schema.
- the Dynamic Services Engine includes a generic registration module seen within the dotted rectangle 313 .
- the registration module accepts an XML Service Descriptor document 315 from an available source, such as an XML editor, a web application that processes POST data from an HTML form, or any other suitable source as indicated at 317 .
- the XML Service Descriptor document 315 preferably identifies a standard XML schema which specifies the required and optional elements to be included in the XML Service Definition.
- An example DTD which specifies illustrative XML schema for the Service Definition elements is set forth at the beginning of the accompanying appendix, and is followed by listings for a set of illustrative Service Definition XML documents which comply with the schema.
- XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure.
- XML provides a mechanism to impose constraints on the storage layout and logical structure.
- a software module called an XML processor is used to read XML documents and provide access to their content and structure. It is assumed that an XML processor is doing its work on behalf of another module, called the application.
- the XML specification noted above describes the required behavior of an XML processor in terms of how it must read XML data and the information it must provide to the application.
- a second specification also developed by the World Wide Web Consortium, REC-DOM-Level-1-19981001, Document Object Model (DOM) Level 1 Specification Version 1.0, available on the Web at http://www.w3.org/TR/WD-DOM-19980318, defines the Document Object Model Level 1, a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents.
- the Document Object Model provides a standard set of objects for representing HTML and XML documents, a standard model of how these objects can be combined, and a standard interface for accessing and manipulating them. Vendors can support the DOM as an interface to their proprietary data structures and APIs, and content authors can write to the standard DOM interfaces rather than product-specific APIs, thus increasing interoperability on the Web.
- each XML Service Descriptor document 315 is parsed into its constituent data elements and those data elements are then mapped into and stored in the database 311 in accordance with the standard Service Definition schema.
- Numerous XML parsers including the XML parser which forms part of the Oracle 8i platform, can be employed to process the XML document.
- the Oracle Internet Platform includes built-in XML-support for exchanging XML data over the Internet using the W3C standard, and includes an XML Parser for Java, an XML Class Generator, and an XML Parser for PL/SQL.
- the Oracle XML parser for Java can be executed by Oracle 8i's Java VM, and enables parsing of XML documents through either SAX or DOM interfaces using a validating mode for testing each incoming Service Definition against the Service Definition DTD.
- a revised XML document is supplied via the registration module 313 .
- the services engine can respond to generic requests by displaying a list of available services.
- the inputs specification for a selected service the input data required by that service can be presented to users in a manner which is appropriate to that service in different environments.
- a request for each of the specified inputs is automatically presented to the user application program in an appropriate way in each user environment.
- This mechanism allows the services engine to separate the functionality from the presentation, a key to providing the same service on different platforms.
- a user can also provide default values for each or all of the inputs. The default values could be a presented to the user as a list from which users can select a value.
- An input may simply a URI to point the Dynamic Services Engine to a particular service provider and a filename or method to access the resource.
- an input specification could take the form of a specific URL with a GET or PUT method.
- encryption is specified for incoming messages or input data by the Service Definition
- decryption is performed as indicated at 331 in FIG. 3.
- the content of incoming messages or input data can be validated as specified by the Service Definition as illustrated at 333 .
- accounting functions can be performed in accordance with the business information portion of the Service Definition.
- a service request is transmitted to a service provider 336 , a resource specified in the Service Definition as indicated at 335 .
- this service request can take the form for an HTTP message to a particular URL and method, passing input data to the resource in the manner specified the inputs portion of the Service Definition.
- the service provider (typically a remote web site) returns output data to the Dynamic Services Engine as seen at 340 . If the data returned by the service provider 336 is not already in a standard form, the Service Definition of that resource identifies a Java jar file which is executed as indicated at 343 to translate the data from the provider 336 into the desired standard format.
- the output data from then is then formatted for presentation use by the client application program as indicated at 345 .
- the output data is published for use by the requesting application in an output format specified in the output section of the Service Definition. If so specified in the Service Definition, company information and/or a company logo can be added to the output data from the service provider as seen at 358 , and the data may be encrypted as seen at 361 before being sent to the requesting application program as indicated at 363 .
- the client application program commonly takes the form of a Java program which executes within the same environment as the Dynamic Services Engine and performs specific operations on the data.
- the dynamic services infrastructure may be used to particular advantage to integrate data from several different resources into a single presentation to an ultimate user.
- an application can obtain data from a plurality of different registered online retail sites, perform price comparisons, and present the results to a user.
- a second application could obtain foreign currency exchange rate information from one web site, and obtain price information on stocks or products from other web sites, and present results in a particular currency selected by a user.
- the application program can present data integrated in this fashion in ways that are compatible with any device that can connect to the service, such as Personal Data Assistants (PDA's), web servers, mobile phones, and the like.
- PDA's Personal Data Assistants
- the Service Definition includes contact information which allows the system to periodically issue requests to update the Service Definition data.
- the person or entity to whom the update request is sent, together with the frequency with which the update requests should be issued, are recorded in the specification data for each resource.
- the service provider is contacted as shown at 380 and 382 and, thereafter, the service provider or other person to whom the update request is sent, may respond by submitting new information through the registration mechanism as seen at 484 to modify the Service Definition data in the database 311 .
- test information stored for each service is employed to periodically test the external resource, typically by transmitting standard input data and then comparing the response to standard test output data. If the test reveals a problem, an error report can be sent to a destination address, such as an appropriate person in charge of the service provider, to inform that person of the problem as indicated at 394 .
- caching information may be stored for each service which indicates the extent to which output data from the service should be cached, and how long cached data should be retained.
- means are included for recording the nature of transactions performed by the system in a log file, and to record feedback from both client applications and from end users regarding the system, its use, and its performance.
- Processing means may be incorporated into the system for analyzing both the performance history and the feedback received in order to provide quantitative parameters and descriptive data which describe the performance of the system.
- Service Consumers are clients of the service engine. Through the Dynamic Services client APIs they will acquire handles on the Services, submit service execution requests and collect the responses. SCs are unaware of the communication protocol used by the Dynamic Services client library and the Dynamic Services Engine. Such communication is abstracted by the client library.
- DSE Dynamic Services Engine
- the core of the Dynamic Services Framework The DSE is operates within and uses the services of a relational database system, such as Oracle 8i. Upon Service Consumer request submission, it will execute the service, package the response, and return it to SCs.
- DS Services Registry (SR).
- the Services Registry is the placeholder for the service definitions. Service Consumers can use the client library to query the DSE for lookup operations on the Services Registry.
- DS User Registry (UR). Registry for the Service Consumers of the Dynamic Services Engine. It is used for authenticating Service Consumers during their connection phase. It is used for the storage of user properties and information.
- SP Service Provider
- DS Administrator The administrator is responsible for maintaining the Dynamic Services Registry. His responsibilities include: registration/unregistration/updates of Services, deployment options for services, controlling services access to the Service Consumers, engine performance monitoring, log reviewing, service scheduling, etc.
- the Client Library will be responsible for handling the communication between the Service Consumers and the DSE. The communication will be based on messages.
- a service is defined by all the components that make up the service. They include descriptions of the service in terms of its value-added functionality, declaration of what interfaces it has, information regarding the providing party, and some auxiliary libraries, which may be used during service execution. More concretely, this is referred to as the service package.
- the Service Provider builds this package and hands it off to the Service Administrator, who will augment it before preceding with the registration, with information that is deployment specific. The Service Provider will not need to take these deployment decisions as he builds his initial package; he merely specifies suggestions on these deployment decisions.
- service descriptor provides a centralized source of description for the service.
- An example Service Descriptor for a Currency Exchange Service can be found in part B of the Appendix.
- a service is defined by a multitude of logical components, all of which are specified in the service descriptor, at least in part, if not specified in other documents that the descriptor refers to. There are two sections of the descriptor, one focusing on the higher level descriptions of the service, known as the service header, and another delving on the details of implementations of the service, known as the service body.
- the service header contains high-level descriptions of the service. For the most part, information specified here is descriptive and non-interpretive for browsing and documentation purpose. The exceptions are service interface specification and service identifier.
- Naming information contains a globally unique identifier as well as short and long descriptions of what the service does. Each service will be addressed through an absolute name specified using the URN (Universal Resource Naming) conventions. Universal Resource Naming is described in detail in the Internet Request For Comment document IETF RFC 2141. UUID used by ICE was considered as an alternative.
- the service header includes version information with pointers on how and where the service update is to be performed. Coupled with support contacts from the service provider Information section, this bit of information is critical for service maintenance.
- High-level information about the service provider can be specified, including the provider's company name, copyright information, and company URL. Detailed information drills down further into contacts for support and URLs for logos.
- This information is provided in the form of an X-Link that will point to another XML document.
- the Dynamic Services Engine has to be aware of the semantic mapping between the XML Schema that it follows and the internal storage structure inside the registry. There will be an initial set of schemas that the engine will semantically understand. In the future, plugging in additional parsers for new schemas can augment this set. This allows the Dynamic Services Framework to embrace emerging standards for representing data such as company information/contacts that will have been heavily used in existing applications.
- specified in the descriptor is a set of deployment properties comprised of suggestions from the service provider to aid the service engine administrator during registration time. They include classification guidelines with hierarchical categories as well as flat keywords, and recommendations of caching parameters. This information is also provided in the form of an X-Link that will point to another XML Document specifying the classification schemes. Again, this is to allow for existing or emerging standards on schemas that data used for categorization will adhere to.
- the values specified in this section are only suggestions to a service administrator during service registration.
- the values stored in the Services Registry could be different from the values specified in the descriptor. Note that in other sections, certain parameters can be specified to be deployment options so that the administrator can set them up appropriately at registration time.
- the Service Header allows for the definition of an interface characterized by the schema specifications of its input, output, and exceptions.
- the specifications can be dispersed in external XML-Schema documents or they can be embedded in the Service Descriptor.
- the location of the XML-Schemas is specified by URLs: when a relative URL is used, that is relative to the service package submitted by the service providers.
- Absolute URL can be used to address XMLSchemas stored on external registries or repositories (e.g. integration with the OASIS registry).
- the DSE may also retrieve input/output XML Schemas from external registries such as xml.org.
- the service provider enforces the syntax in which consumers send requests to it, as well as the way in which it provides the responses. The validation will be done in the Service Engine when a consumer sends a request, before the actual service provider is contacted.
- the service provider can also suggest a name for the interface, which is a deployment option and can be overwritten by the service administrator. Any new service that conforms to the same service interface must provide the same input/output/exception definition.
- the engine will also expose to consumers the capability to search for services by interface. Two services that conform to the same interface are considered compatible services, a concept useful for fail over.
- class generators can be used to create Java classes that map to the request/response XML-Schemas.
- a Java class generator may be provided as part of the client toolkit: it will be able to fetch the schema from the service engine and generate appropriate classes for easy manipulation on the client side.
- the Service Body contains more detailed descriptions for each one of the components in the Dynamic Services Engine (DSE) that will be employed at execution time. Specifically, it is sectioned into details on the input, protocol, execution, exception, and output.
- the service provider can specify an adaptor that needs to be used at each level, be it supplied by the engine or the provider. The functionality of each adaptor will be discussed in each of the following sections. In addition to the adaptors, other service specific parameters may also be specified.
- the input section specifies the list of necessary as well as optional processing on the request that comes in from the consumer.
- the request XML that the consumer submits or sends to the service engine will be validated with the Input XML-Schema that is specified previously in the header.
- the DSF allows a service provider to optionally supply some form of Schema Mapping specifications (e.g. through XSL Transformation) that could map this Input XML-Schema to a presentation form such as HTML or WML (Wireless Markup Language).
- Schema Mapping specifications e.g. through XSL Transformation
- HTML or WML Wireless Markup Language
- the engine is not responsible for the rendering: all that the engine is responsible for is the capabilities to store and retrieve the mapping.
- the engine only provides the mapping(s) of the transformation. The actual transformation is done on the consumer side by the client toolkit. If we have a mapping of the schema into an HTML form, the consumer can use the mapping to render the Input schema to an HTML form for his web application. He can then transform the HTTP Requests back to an XML document, which conforms to the XML-Schema specified by the service provider. Finally, the request XML will be sent to the service engine formulating a service request.
- Service providers may specify additional directives for the purposes of:
- Default value Filling in a default value for these parameters into the request XML for which the consumer specified no values.
- Service providers can also specify that the default value for those parameter must be validated at service deployment time. For example, for HTTP, specifying a XPath into the request XML addressing an element that represents one of the HTTP request parameters to be sent to the HTTP server.
- the directive can also provide mapping to the parameters that are not defined by the request XML schema, e.g., some HTML form hidden parameters. In this case, a value has to be specified.
- the value to be filled-in can be a user profile property fetched dynamically at runtime for each user. This information is opaque to the registration parser: The administrator will be prompted to enter a mapping through some API calls to the engine at deployment.
- the input adaptor section is an optional section, identifying an adaptor that further processes the service request before sending to the service provider. Examples of such processing include semantic or higher level validation of the request.
- This input adaptor specification is a fully qualified name of the class that will handle the processing. Such class will be either found in the service package given by the service provider during registration.
- the service provider has the option of specifying some adaptor specific parameters in the PARAMETERS element under the adaptor, which is validated at service registration time and interpreted at runtime by the input adaptor. These parameters are opaque to the Service Descriptor parser and Services Registry.
- the protocol section identifies the way that service engine accesses the underlying service. For example, a service may be accessed via HTTP protocol while another service may be accessed via JDBC protocol.
- This protocol adaptor specification is a fully qualified name of the class that will handle the communication to the underlying service. Such class will be either found in the service package given by the service provider during registration or in the set of libraries that the service engine provides.
- the service provider has the option of specifying some adaptor specific parameters in the PARAMETERS element under the adaptor, which is validated at service registration time and interpreted at runtime by the adaptor. For example, for HTTP, it may specify the HTTP method used and the URL that does the actual servicing. These parameters are opaque to the Service Descriptor parser and Services Registry.
- protocol adaptors that have been prepackaged with the engine, like generic adaptors for HTTP and an Oracle JDBC adaptor.
- the execution section identifies the way in which the service is to be executed. Its responsibility is to take in the request XML and return the response from the underlying service provider.
- Execution adaptors can be standard simple adaptors that follow the simple path described above. They can also be complex adaptors that aggregate several services like in the International Portfolio example. This execution adaptor specification is a fully qualified class name of a class that will perform the execution. Such class will be either found in the service package given by the service provider during registration or in the set of libraries that the service engine provides.
- the service provider has the option of specifying some adaptor specific parameters in the PARAMETERS element under the adaptor, which is validated at service registration time and interpreted at runtime by the execution adaptor. These parameters are opaque to the Service Descriptor parser and Services Registry.
- the result of the execution adaptor is the response given back from the service.
- the response will be in the native format of the service provider.
- the response may be in HTML format, and for database service, the response would be a java.sql.ResultSet object.
- the response will be a structured service response.
- the service provider will use pre-packaged simple adaptor. If the service is a compound service or a simple service that has non-standard execution flow, the service provider will provide a custom execution adaptor.
- the exception section identifies the way in which the exceptions are to be handled for this particular service.
- the output section specifies the list of necessary as well as optional processing to produce the response to the consumer.
- the output section identifies the way in which the output returning from the execution adaptor is to be formatted in the way prescribed by the Output XML-Schema.
- This output adaptor specification is a fully qualified name of the class that will handle the transformation. Such class will be either found in the service package given by the service provider during registration or in the set of libraries that the service engine provides.
- the service provider has the option of specifying some adaptor specific parameters in the PARAMETERS element under the adaptor, which is validated at service registration time and interpreted at runtime by the adaptor. These parameters are opaque to the Service Descriptor parser and Services Registry.
- mappings e.g. in the form of XSL Transforms
- HTML or WML HyperText Markup Language
- Service providers will package their service definitions in to a service package: as said before a service package contains a service descriptor, the XML-Schemas or their locations, and optionally a set of Java class files. It is then responsibility of the Service Administrator to take the service package and register it to the Dynamic Services Engine instance he is managing. During such registration, he will be assisted by the Dynamic Services Administration Tools.
- Deployment parameters are defined as parameters that are specific to the deployment of a service within a Dynamic Services Engine instance. They include:
- b. Deployment input values the values for some of the service request parameters that have been tagged as deployment time inputs by the service provider. Such feature can be used to model a business relationship where the service provider publishes a service that accepts a username/password and license key as inputs. At the deployment time, the Service Administrator establishes a business relationship with the service provider and acquires the username/password and license key to be used within his Dynamic Services Engine.
- Caching policies Strategies employed by the service engine administrator possibly include basic scheduling, pre-fetch, cache on request, and MRU/LRU cache replacement considerations in cases where cache resources allocated are limited.
- d Check for updates and service regression. A frequency to be used for checking if new versions of the service packages have been made available by the service provider or if the service is unavailable.
- Fail Over Create through the Dynamic Services Administrator Tools a Fail Over Service for such service under registration
- the Dynamic Services Engine is the core of the Dynamic Services Framework.
- DSE is deployed as a Java component running on the Oracle JServer.
- the main responsibilities of the DSE are to collect requests for a service execution from the service consumers (DSE-clients) communication sub-system, and relay the requests to the DSE execution sub system, which processes them according to the service specifications and returns the built response to the SCs through the same communication path.
- FIG. 3 of the drawings shows a high-level overview of the internal components of the Dynamic Services Engine execution sub-system—a conceptual class-diagram is used for such representation.
- the engine has been decomposed into several components each of them addressing one of the sub-systems necessary for the service execution.
- Managers as those components whose functionality is service-independent. Managers are responsible for performing tasks that are common across services and which cannot be parameterized by the service provider during their service definition process.
- the Managers shown in FIG. 3 include the Execution Manager 401 , an Input Manager 403 , an Output Manager 405 , a Cache Manager 407 and a Protocol Manager 409 .
- Adaptors are components that are service-specific. For a given service, the Adaptors to be invoked during the service execution are specified by the service provider during the service definition process. Input and Output Adaptors shown at 411 and 413 are responsible for service-specific processing of the service requests and responses. Protocol Adaptors as illustrated at 421 offer an abstraction over the communication protocol between the DSE and the service provider. For each Adaptor, service providers will be able to specify Adaptor-specific parameters in the XML service descriptor. These parameters can be accessed by the Adaptor implementation during service execution. They can be seen as Adaptor configuration parameters. Default adaptors can be provided for standard behaviors and a set of commonly used adaptors are also be provided, such as an XSL Input Adaptor, and HTTP Protocol Adaptor, and an HTML Output Adaptor.
- adaptors are the components that can be implemented by a service provider to extend the engine, they pose security risks to the engine. Hence, all adaptor interfaces should have restricted access of resources to the engine.
- Each of the components shown in the component view should be modeled into Java interfaces.
- Adaptors supplied by service providers should realize the appropriate Adaptor interface (e.g. a YahooStockQuoteOutputAdaptor should implement the OutputAdaptor interface).
- an interface is defined: such interface exposes the Manager functionality, on which other components within the DSE depend.
- a Manager defined by the AbcManager interface is associated to a class called DSEAbcManager which will provide an implementation for those tasks
- the ExecutionManager seen at 401 plays the role of being the coordinator during the service execution. For a given request, it will first ask the InputManager 403 to process it. The latter, after performing an initial processing, will forward the request to the appropriate InputAdaptor 411 for further service-specific processing. The processed request is then handed-off to the ExecutionAdaptor seen at 425 that will perform the service execution. This step includes using the ProtocolManager/ProtocolAdaptor pair 409 / 411 to marshal the request into the form required by the underlying communication protocol between the DSE and the service provider. Additional service-specific logic can be embedded in the ExecutionAdaptor 425 implementation. The raw response returned by the service provider is processed by the OutputManager/OutputAdaptor pair 405 / 413 and then finally returned to the service consumer.
- InputManager 403 is the first step in the service execution flow coordinated by the ExecutionrManager. It is responsible for the processing of a service request. Such processing is available for all services and is meant to be service-independent. Responsibilities of the InputManager 403 include: optional request validation (based on user request), handling default values, hidden values, defining aliases addressing specific part of a service request, and finally invoking the InputAdaptor for service-specific processing.
- Each service specifies the XML-Schema to be used to compile service requests. Every service request is a XML document compliant with such supplied schema.
- InputManager 403 processes request XML documents and, if necessary, make modifications to them.
- the input of InputManager 403 is an XML document representing a service request compliant to the service request XML-Schema. Its output does not necessarily need to be compliant with the input XML schema. It is a choice left to the InputAdaptor to process the input request and to notify the InputManager 403 if such processing altered the structure of the input in a form that makes it not compliant to the schema.
- the InputManager 403 will revalidate the processed request before moving to the next execution steps.
- Service providers can also associate a default value to a given Xpath. For a given request, InputManager will check if the entities addressed by the Xpath have a value specified. For those XPaths that do not have consumer-supplied values, InputManager should use the specified default value and add it to the request. For a given Xpath, it is possible for the service provider to supply a set of default values. For each of these values a new element will be appended to the XML request document if no consumer-supplied value is found. InputManager will not handle default value options that are specified for Xpaths referring to container elements. Such construct can be used for handling parameters that are optional for the service consumer but required by the service provider.
- ProtocolAdaptor will use this facility of InputManager to adapt the service request to the specific needs of the communication protocol used by the service provider.
- InputManager 403 will optionally validate the syntax of the service request to check its compliance to relative input XML-Schema. Such processing will happen after the default value processing described above.
- InputManager 403 is responsible to create an instance of the appropriate InputAdaptor 411 and invoke its process method. Such processing should happen after the default-values processing. InputManager 403 is also responsible for revalidating the request syntax after the InputAdaptor processing. This validation is conditional on the nature of the transformation applied by the InputAdaptor.
- a service descriptor can also specify aliases for given XPaths in the service request.
- the Xpath refers to the processed request XML document and not the original service request.
- the entities addressed by those Xpaths are considered can then be addressed through the aliases.
- Other components, including execution adaptor and protocol adaptors, can then retrieve the values of these entities using the aliases.
- Xpaths referring to elements in the XML tree that are not leaves (e.g. a set of elements of the same type, or container elements) it is up to the users of the aliases to apply the appropriate logic for handling their values.
- a service definition can contain the specification of hidden request parameters. Those are defined as aliases, which are not associated to any Xpath in the request. For each of these hidden parameters a value has to be specified. This construct is used for parameters that should be hidden to the service consumers and which, therefore, cannot be part of the service request.
- Aliases are particularly useful to model the inputs of HTML forms.
- a HTTPProtocolAdaptor will use this facility of InputManager to map and flatten a service request into an query string (of content type application/x-www-form-urlencoded).
- aliases are useful to flatten a hierarchical XML-based service request to a flat list of parameters required by some protocols, such as query string of the type application/x-www-form-urlencoded and JDBC statement binding parameters.
- the InputManager interface defines all the APIs that are exposed to other components within the DSE.
- the DSEInputManager class will implement the interface and provide additional interfaces used only internally by itself.
- the Input Manager's DSEInputManager interface works on the XML-documents representing service requests. DSEInputManager will use the standard Document Object Model (DOM) APIs for its operations.
- DOM Document Object Model
- IA InputAdaptor
- InputAdaptor 411 is responsible for processing of a service request from a servicedependent point of view. Service providers can provide a class implementing the InputAdaptor interface and associate it to their service. During execution InputManager 411 will create an instance for the supplied InputAdaptor and invoke its process method.
- InputAdaptors are optional for a service. If specified, they can process request XML documents and, if necessary, make modifications.
- the input of InputManager is an XML document representing a service request compliant to the service request XML-Schema. Its output does not necessarily need to be compliant with the input XML schema. InputAdaptor should notify the InputManager if their transformation results in a XML document that is not compliant to the service request XML-Schema.
- DSE includes with standard configurable InputAdaptors that can be reused by service providers:
- An XSLTInputAdaptor will transform a service request according to a supplied XSLT transformation.
- This InputAdaptor will be configurable through Adaptor XML-parameter specifying the XSLT transformation to be applied.
- the InputAdaptor interface defines the interfaces that service providers have to implement when defining a custom service request processing logic.
- the ExecutionManager 401 is responsible for the coordinating the service execution flow. It sits in the middle of DSE components and coordinates among them for completing the service execution process. A new instance of the ExecutionManager is created at the beginning of each service execution. ExecutionManager is supposed to be stateless with respect to service executions. A new instance of ExecutionManager will be created by the consumer request handler every time a new request is posted.
- the ExecutionManager orchestrates the service execution among other DSE components.
- the input of the ExecutionManager is a processed service request while its output is a service response.
- the steps taken by the ExecutionManager 401 during the service execution are:
- ExecutionManager 401 will first forward the request to the InputManager 403 for additional processing.
- the processed request is forwarded to the ExecutionAdaptor 425 . Its responsibility is to get the request and optionally interact with the ProtocolManager 409 . Additional service-dependent logic can be implemented in the ExecutionAdaptor 425 .
- ExecutionManager 401 Another responsibility of ExecutionManager 401 is the coordination of service response caching through the Cache Manager 407 . That implies that the ExecutionManager 401 is responsible check for the availability of cached service responses before executing a service. If such response is available, no service will be executed and the cached response will be returned to the client. The caching of the output response will be achieved through the services of the CacheManager 407 . On a principle level, ExecutionManager 401 will asked CacheManager 407 to cache the services response by storing it into a map using the request as a key. The visibility of the cached response and its lifetime will be specified by the Service Administrator on a service base. Additionally the lifetime can be specified by the Service Provider on a request-base through an expiration date model.
- the ExecutionManager interface collects all the APIs that are exposed to other components within the DSE.
- the DSEExecutionManager class will implement such interface and provide additional interfaces used only internally to itself.
- the ExecutionAdaptor 425 is responsible for encapsulating the service-dependent behavior of a service execution. For a given service, its ExecutionAdaptor is specified in the service descriptor. Service providers can provide a class implementing the ExecutionAdaptor interface and associate it to their service. There can be only one ExecutionAdaptor for each service. The ExecutionAdaptor 425 is instantiated by the ExecutionManager 401 , which then delegates to it the responsibility of interacting with the ProtocolManager for reformatting the service request into a form suitable for the remote service provider.
- ExecutionAdaptor 425 is a key component in the DSE framework as it has the ability of associating a complex behavior to a service execution.
- ExecutionAdaptor 425 can be used to build compound services and encapsulate them into a single service.
- ExecutionAdaptor can also be used to define the logic for handling failover behavior where, if a service fails during its execution, a “compatible” back-up service can be invoked.
- ExecutionAdaptor 425 is the layer of the DSE offering service execution flexibility.
- the input of the ExecutionAdaptor is a service request while its output can be some response which will be further processed by OutputManager, or can be a structured service response.
- the service provider can build a specific ExecutionAdaptor. Through a set of APIs, ExecutionAdaptors will be able to access Adaptor parameters specified in the service descriptor. Through this facility, service providers have the option of building general purpose ExecutionAdaptors that are configurable through XML parameters in the service descriptor. In addition, DSE will ship with some pre-built ExecutionAdpators and it will also provide a set of tools to facilitate the creation of new ExecutionAdaptors. Each of the above options is described in details in the next sections.
- a simple ExecutionAdaptor is provided as a component of the DSE engine. It can be considered as a default Adaptor used by the ExecutionManager when no service-dependent Adaptor is specified. Its responsibility is limited to the interaction with the ProtocolManager for the correct service execution.
- Compound services are defined as added-value services built on-top of other services. In general, their execution implies the execution of a set of services—which can happen in parallel mode, serial mode or in a mixture of the two—plus some additional processing/transformation on the requests/responses of the dependent services.
- DSE will support Compound Services through its ExecutionAdaptor layer. Developers of the ExecutionAdaptor will have access to the ServiceRegistry and will therefore be able to create the Service instances that they are dependent on. For each of these services they will be able to pipeline the output of one service into input of another one, maybe after doing some processing on it. They will have full flexibility in defining the logic of their Compound Service given the fact that ExecutionAdaptor are Java-based components.
- Tools have the responsibility of collecting the information above and generate the Java code of an ExecutionAdaptor from there.
- the tools will assist the providers who want to provide compound services such as comparison services and federated search services.
- ExecutionAdaptors are responsible of authenticating to the service providers. The actual authentication procedure is service-specific. ExecutionAdaptors will also rely on ProtocolAdaptors 421 if the authentication is dependent on the protocol, e.g., JDBC.
- One of the functional requirements for the Dynamic Service Framework is the ability for service administrators to specify a list of back-up services to be executed if a service fails.
- the back-up services should be compatible with the original service—meaning that their input/output interfaces should be compliant to the same pair of XML-Schemas.
- the FailOver Adaptor (not shown) will also notify the administrator.
- Tools should also be able to facilitate the processing of creating of such a service. Tools should allow service administrators to create such a failover service through simple graphical interfaces.
- ExecutionAdaptor developers are also given an additional level of flexibility.
- a section in the service descriptor is dedicated to ExecutionAdaptor parameters.
- Those XML-based parameters can be used to build a general-purpose ExecutionAdaptor that can be shared among several services. In fact, by using these parameters the ExecutionAdaptor can be configured according to the needs of each of the services.
- ExecutionAdaptors are just defined by an interface.
- the DSE may be supplied with a simple implementation of the interface while most of the complex ExecutionAdaptors will be generated to meet special needs.
- the ExecutionAdaptor interface defines the interfaces that service providers have to implement when defining a custom service execution flow.
- ProtocolManager 409 is responsible for handling ProtocolAdaptors. Its main function is to act as factory class for ProtocolAdaptors upon requests from the ExecutionAdaptor 425 . ExecutionManager 401 creates the ProtocolManager 409 and then passes it to the ExecutionAdaptor 425 .
- ProtocolManager 409 is organized as the factory class for ProtocolAdaptors. For a given service, it will instantiate the ProtocolAdaptor required by the supplied service.
- the input of the ProtocolManager is a service request while its output is a raw service response.
- the ProtocolManager interface collects all the APIs that are exposed to other components within the DSE.
- the DSEProtocolManager interface class implements such an interface and provides additional interfaces used only internally to this component.
- ProtocolAdaptors seen at 421 are low-level components abstracting the DSE engine from the communication protocol imposed by service providers thus creating an insulation layer between the DSE and the service provider.
- its ProtocolAdaptor is specified in the service descriptor. There can only be one ProtocolAdaptor for each service. Service providers can provide a class implementing the ProtocolAdaptor interface and associate it to their service The ProtocolAdaptor is instantiated by the ProtocolManager.
- ProtocolAdaptor 421 offers an abstraction on the communication protocol imposed by service providers.
- the input of the ProtocolAdaptor is service request. This request is the outcome of the processing performed by the InputManager modules.
- the output of the ProtocolAdaptor is a general Java object encapsulating the raw response returned by the service provider. Such response will be finally processed by the OutputManager so that it will become compliant to the response XML-schema specified in the service descriptor.
- ProtocolAdaptor have the following responsibilities:
- ProtocolAdaptors should be able to bind a service request to the set of parameters expected by the service provider communication protocol. Such binding may require a transformation of the service request structure—which has been designed to be service-independent—into a form that is protocol-specific.
- a service request being represented through a XML document, can have a complex structure. It is the responsibility of the ProtocolAdaptor to “flatten” such request in an HTTP query string representation (of content type application/x-www-form-urlencoded). As described in Section 3.3.2.1 and 0, this can be achieved through the InputManager's aliases.
- ProtocolAdaptor can be used for the bind-parameters in SQL-based services.
- a service request can specify the values of the parameter, while a ProtocolAdaptor parameter in the service descriptor can be used to specify the query to be issued.
- ProtocolAdaptor can then create a SQL statement using the Adaptor parameter, bind the request parameters into the statement and finally execute the query.
- Protocol Adaptors must be able to authenticate to service providers.
- the authentication can be an implicit authentication (automatic authentication upon request from the provider) or explicit authentication (the user of a ProtocolAdaptor issues an explicit authentication request).
- ProtocolAdaptor After the parameters binding, ProtocolAdaptor will open a “connection” to the service provider and simply submit the request in the appropriate form. If the submission is synchronous in nature then the ProtocolAdaptor will wait till the response comes back.
- the ProtocolAdaptor is responsible for “getting” a handle on the raw response returned by the service provider in the native format of the service provider.
- a “raw” response will be modeled as a general java.lang.Object because the format of the response depends on the native format used by the service provider.
- the format of this object is known by the OutputAdaptor, which will be then process it by casting it to the appropriate class (e.g. InputStream for HTTP-based services or ResultSet for Database services).
- DSE is preferably provided with two standard ProtocolAdaptors, HTTPProtocolAdaptor and OraProtocolAdaptor, that can configured and reused by service providers.
- the HTTPProtocolAdaptor will handle the communication between the DSE and service providers using HTTP protocol. Its Adaptor parameters will include the URL to be used, the HTTP method and other HTTP specific parameters.
- HTTPS protocol support may also be provided.
- the OraProtocolAdaptor will handle the communication for those services that publish information stored in Oracle databases. Its Adaptor parameters will include connection parameters such as SID and username/password as well as the SQL statement and its type to be used for accessing the information
- ProtocolAdaptors are defined by an interface.
- the DSE is preferably provided with standard ProtocolAdaptor implementations for the HTTP protocol and the Oracle database access.
- those Adaptors will be configurable through the XML-based Adaptor parameters specified in the service descriptor
- OutputManager 405 is the responsible for handling OutputAdaptors. Its main function is to act as factory class for OutputAdaptor s and to coordinate the communication between the ExecutionManager and the OutputAdaptor. The ExecutionManager creates the OutputManager and then calls it after the ExecutionAdaptor has completed its processing.
- OutputManager 405 may be organized as factory class for OutputAdaptors 413 . For a given service, it will instantiate the OutputAdaptor 413 required by the supplied service. The input for the OutputManager is the raw response returned by the service provider. The OutputManager will forward that raw response to the OutputAdaptor, which will use it to build a ServiceResponse compliant to the response XML-schema specified in the service descriptor. It is the responsibility of the OutputManager to validate the response returned by the OutputAdaptor to check that its syntax is compliant with that XML-schema. Such validation is optional and controlled by the OutputAdaptor.
- the OutputManager interface collects all the APIs that are exposed to other components within the DSE.
- the DSEOutputManager implements such an interface and provides additional interfaces used only internally to this component.
- OutputAdaptor 413 is responsible for transforming the raw response returned by the service provider into the ServiceResponse structure. Such structure is defined in the response XML-schema specified in the service descriptor. OutputAdaptor are service-specific as they carry the knowledge of how the raw service response is structured (both syntactically and semantically). Service providers can provide a class implementing the OutputAdaptor interface and associate it to their services. OutputAdaptors are instantiated by the OutputManager, which will then forward to them the transform call for output transformation.
- OutputAdaptors The responsibility of OutputAdaptors is the transformation from the raw service response in the native format of the service provider to the standard service response defined by the output XML-Schema.
- a web-based service may need an OutputAdaptor to transform the raw service response in HTML to an XML response conformed to the output XML-Schema defined by the service.
- a ServiceProvider has the choice of building a custom OutputAdaptor for their services and specifies it in the service descriptor. For compound services in that the outcome of the ExecutionAdaptor may be already formatted correctly, the default NULL OutputAdaptor can be used.
- the DSE preferably is provided with three configurable OutputAdaptors that can be reused by service providers:
- HTMLOutputAdaptor will handle raw responses that are HTML formatted. It is responsibility of this OutputAdaptor to parse and scrape the HTML page for extracting useful 1 o content from it and package it in an XML response. There are currently two design options for this component. The first option is to build an HTMLOutputAdaptor that is configurable through the Adaptors XML-parameters. The other option is to delegate to the Tools the responsibility of generating the Java code for specialized HTMLOutputAdaptor for each given service.
- XMLOutputAdaptor will handle raw responses that are XML formatted. This OutputAdaptor may be configured through the Adaptor XML-parameter specifying an XSLT transformation. This transformation will be applied to the raw response to adapt it to the response XML-schema.
- SQLOutputAdaptor will handle ResultSet returned from the execution of SQL statements.
- the design of this OutputAdaptor is similar to the XMLOutputAdaptor.
- An Adaptor XML-parameter may be used to specify an XSQL transformation to model the ResultSet into a XML document compliant to the response XML-schema.
- OutputAdaptors are defined by an interface.
- Services Registry which forms part of the specification database shown at 121 in FIG. 1, stores and manages all the services in a service engine. It provides facilities for registering a service, unregistering it, modifying it, and searching the registry for a set of services satisfying a given criteria. From a Service administration point of view, other requirements are:
- Access control is preferably enforced by the registry.
- the Service Administrator should be able to decide whether a service can be accessible by consumers or not. For example, he can choose to expose the generic stock quote service to some consumers, but keeps Yahoo stock quote nor Bloomberg stock quote services inaccessible from any consumer.
- the access control mechanism should provide role-based access control for different service consumers.
- Facilities for bulk loading are also desirable, but only to a limited extent due to the size of the registry which is sized to anticipate at most on the order of thousands of services.
- the Services Registry is an independent component, shared by one or more service execution engines.
- the specification database 121 also manages user profiles, which are described later.
- An execution engine logically accesses the registry whenever service information is needed.
- most of the service access may be provided by the Services Registry cache at the execution engine.
- the architecture provides flexibility in scaling the service engine to a large amount of users (potentially geographically distributed) by simply adding additional service execution engines. The runtime performance of service access, on the other hand, will be satisfied by the cache.
- the Services Registry exposes these features for any components that need to access some information about a service. For example, ExecutionManager will need to obtain the default values to preprocess the input request; client library will need to access the registry to lookup services. Any implementation details should be hidden and completely controlled by the registry module.
- the central registry is preferably implemented using an LDAP directory, such as the Oracle Internet Directory (OID).
- OID Oracle Internet Directory
- An LDAP directory has the following advantages over a conventional database for this -application:
- C. LDAP directory is optimized for read access by various applications in an organization, which fits our usage scenario.
- a service consists of a set of attributes, reflected by a service descriptor; a set of Java classes and dependent resources for various adaptors; reference to input and output schemas; and Service deployment parameters.
- the entire service may be stored in the LDAP directory (directory).
- the service descriptor is modeled by an objectClass (called orclDService for the rest of this document),which consists of a flat list of attributes. A instance of a service descriptor will then be realized as an entry in the directory that inherits from orclDService.
- objectClass called orclDService for the rest of this document
- the structure of the service descriptor is hierarchical while the structure of an objectClass is flat. Hence, the descriptor is flattened in the orclDService.
- Some attributes of the descriptor are composite and multi-valued in nature.
- a descriptor can have multiple Input default value and alias elements. Each entry element consists of path, alias and default value.
- Such an attribute can only modeled by an opaque string. Multiple such opaque strings can be stored in an entry because an LDAP attribute can be multi-valued.
- An alternative can be having multiple sub entries.
- Input and Output schemas can again be modeled by an objectClass.
- Each schema may be realized as an entry in the directory that inherits from the objectClass.
- the objectClass may consist of an attribute that stores the identifier of the schema, an attribute storing the schema (in textual XML or some binary representation of the XML such as serialized Java DOM object), and possibly additional metadata.
- the set of Java classes and resources, represented by a Jar file can be stored modeled by an objectClass.
- the binaries can be stored in a binary opaque attribute.
- the only metadata that needs to be stored is the name of the Jar file.
- Service descriptors are stored hierarchically, according to the categorization of the services defined by service administrators. As a result, each category may be modeled as an entry, consisting of the name of the category, additional descriptions and possibly other metadata. The root of the entire service descriptor tree may be defined by the service administrator.
- Input/output schemas may be stored directly under schema sub-tree of the directory.
- Service registration and unregistration is equivalent to adding and removing an entry to the directory.
- Service update is equivalent to modifying attributes of an entry.
- Transaction control is not specified by LDAP standard although OID guarantees that each modifying operation is atomic. However, registering/unregistering/updating a set of related services in a transaction is not possible with OID. Instead, service access administration logic enforces the transaction.
- Access control is enforced the registry logic by rewriting the access query to a string by adding additional constraints based on access control information.
- the consumer can access some subsets of the services. For example, a policy can be specified such that stockquote service is available to consumers with the role BUSINESS. This can be achieved through maintaining access control list in the user profile registry (Refer to Section 0 for more information) and enforcing the ACL by rewriting the service lookup.
- access control can also be granted/revoked on categories rather than individual services.
- the service administrator should be able to allow only consumers with role A to access to all services under business:finance.
- category-based access control less important because of the limited size of the registry and the limited number of users of the service engine (a service consumer represents an application, rather than end users).
- the service cache is a specific cache provider of the representing the Services Registry.
- the service cache is used by the service access APIs. Service access components will first attempt to read the information from the cache through a query-rewrite layer to rewrite the query in the service cache form. If the information is not in the cache, the service access components will then read the information from the registries. In practice, to improve performance and avoid complication in accessing Java classes, the service cache may cache the entire Services Registry.
- service caches may be implemented as database tables, sitting in the same database as the service execution engine.
- the service descriptor subtree is represented by a descriptor table and a category table.
- the input/output schema subtree may be represented by a schema table.
- the Java classes Jars sub-tree is represented by the class tables of JServer.
- the lifetime of the cache is the lifetime of the service engine.
- a service engine When a service engine starts up, it populates the service cache (a prefetch operation using the terminology of the CacheManager). The service cache stays alive until the engine is shutdown.
- an agent in the registry invalidates the old cache entries and populate the new entries to all affected service caches in all service execution engines.
- the user profile registry is responsible for collecting information that is relative to the Dynamic Service Consumers.
- Service Consumers are defined as applications accessing the Dynamic Service Engine, therefore authenticating themselves to the engine. End users are to be considered as the users of the application built leveraging on Dynamic Services.
- Applications using Dynamic Services authenticate themselves to the Dynamic Services engine. For example. an application may authenticate itself to the Engine using a SC1/SC1 (ServiceConsumer1/ServiceConsumer1) username/password. At the same time, the Application may have its own clients, and it is the application's responsibility to manager those clients.
- SC1/SC1 ServiceConsumer1/ServiceConsumer1
- the user profile registry is used to store information belonging to the SC 1 user.
- Dynamic Services Framework may take advantage of the RDBMS authentication facilities.
- Service Consumers will implicitly open a database connection to the Service Engine.
- the username and password to be supplied at connection opening will be agreed between the Service Administrator and the application developer.
- Service Administrator can also set service access control policies to be associated to each service consumers. Such policies will also be stored in the User Profile Registry.
- Connection-private For example dynamic cookies that are sent to the user during the service execution (e.g. to identify a shopping cart session).
- the User Profile Registry stores and manages user-private information only. Examples of this information include the username and password with respect to a specific service.
- the UserProfile Registry offers to Service Consumers facilities to store properties that are dependent on their clients, thus facilitating the management and mapping of application clients.
- Connection-private information is the HTTP cookies used by web sites for session management.
- the User Profile Registry does not manage dynamic session information such as HTTP cookies. Instead, such information will be returned to Service Consumers in the form of a Service Response header. Note that the User Profile registry and the Service Engine are stateless compared to the service execution.
- the UserProfile Registry may be implemented as an LDAP directory which is the preferred mechanism to archive in a central repository the user information and share it across Dynamic Services Engine instances. Therefore even user credentials will be centrally managed in directory. The access performance may be improved by using caching on the Dynamic Service Engine. Clients will access the cached User Profiles reducing the number of access to the registry.
- the user profile registry provides the following interfaces:
- application code can specify additional optional criteria when storing and retrieving user profile parameters. This facility is particularly useful for managing attributes of application clients within the registry.
- the architecture proposed is particularly well designed for scalability with respect to increasing number of users.
- Service Consumers can authenticate to the Service Engine and then establish a connection pool.
- the scalability of this connection path is directly related to the scalability of Oracle 8 i with respect of the number of client connections.
- applications can use any connection in the pool with any of their client requests.
- the architecture does NOT impose any one-to-one relationship between the application clients and the Service Consumers.
- This chapter details the communication between a service engine and an external entity.
- external entities there are two types of external entities: the application logic of a service consumer, which needs to connect to a service engine, lookup a service, and execute a service; and the application logic of the tools for service administrators, which needs to perform additional administrative tasks such as registration and unregistration of services.
- the communication between a service engine and a client library common foundation is the interface exposed by the service engine to the outside world: External entities like service consumer application logic communicates with service engines using the appropriate client library, which in turn relies on the common foundation. Through the communication interface, service engine accepts requests and invokes appropriate components such as execution manager.
- the communication interface must provide the infrastructure to enable the two different client libraries exposing the operations needed respectively; allow asynchronous communication so that calls to the engine will not block the caller; and maintain the scalability and efficiency of the system.
- the service engine has to be scalable with respect to number of connections. What is more, within a connection, concurrency has to be maximized.
- Service engines communicate with external world through message queues in the engine.
- an external entity needs to perform a certain action, for example, executing a service
- the client library common foundation will send a correspond message to the request queue.
- a request handler in the service engine will listen to the queue, fetch the request message, and invoke appropriate engine components, for example, execution manager.
- service engine will post the response in the response queue.
- a listener in the client library common foundation will listen to the response queue, and invoke appropriate callback method.
- the client library common foundation opens a connection to the database instance where the service engine resides.
- the common foundation also performs other initialization: creating a connection to the Oracle Advanced Queuing service, creating the request and responses queues for the connection, setting up the request handler in the engine, and setting up the response listener for the external entity.
- the external entity can then perform various operations such as looking up and executing services.
- the client library common foundation will send a request message to its request queue in the engine.
- an object identifying the request message will be associated to the message to serve as the request identifier.
- the external entity receives the response by registering a callback method.
- client's calls to the engine do not block the client code.
- the request handler in the engine will process the request message, and enqueue the response message in the response queue.
- the request handler is not committed to handle requests concurrently.
- the response listener at the external entity side (created at connection initialization time) will receive the responses sent by the engine. Based on the request identifier, the listener will invoke the appropriate callback method. Exceptions are treated as a special type of response: the response listener will be able to throw and create the appropriate exception correspondingly.
- the client library common foundation closes the database connection
- the common foundation will also free up other connection-private resources, e.g., queues created and pending request/response messages.
- the message-based communication is built on top of the relational database queuing mechanism which, in the preferred embodiment, is Oracle Advanced Queuing (AQ) in the Oracle database.
- the mechanism uses the Java Messaging Service (JMS) interface exposed by AQ wherever applicable, to maximize interoperability.
- JMS Java Messaging Service
- the JMS enqueue interface may be used to enqueue a message for both the clients and the request handlers.
- the JMS MessageListener may be used to receive messages asynchronously.
- AQ-based JMS MessageListener of the connection (managed by the client library common foundation) is responsible for listening for the response, which does not actively poll the network .
- the connection-private JMS MessageListener will dispatch the response to the appropriate callback method based on the request identifier.
- the request handler in the engine is created as a JMS MessageListener, a static Java object in the connection's private Java Virtual Machine. It has to be static in order to receive any request in the lifetime of the connection.
- a database connection will be obtained.
- a JMSConnection and a JMSSession will then be created based on the database connection at the client side.
- Connection-private (conceptually) queues will be created in JMSSession.
- the request handler in the engine will also be created, based on a JMSConnection/JMSSession created at the server side. All the logic will be captured in a Java Stored Procedure to minimize the complexity of the client library.
- Oracle AQ JMS based messaging architecture allows external entities to make calls to the engine without blocking.
- connection private request handlers on top of Oracle JServer allows the service engine to leverage Oracle database's scalability with respect to the number of connections.
- connection-private queues rather than sharing some global queues for a few reasons.
- connection private queues can avoid additional unnecessary complexity on selector to pick appropriate messages for a connection in a global queue.
- the overhead of creating queues is a one-time overhead during initialization for each connection. Typically, a connection is expected to exist for a long time so that the overhead in initialization will be relatively insignificant. See 6.3.2 for alternatives that have been discarded.
- Non pre-emptive threads used in handling the requests in a connection maximizes the concurrency within the connection. It is anticipated that the common scenario when a thread will be idle is making socket calls. Non pre-emptive threads provided by JServer provides the appropriate lightweight infrastructure to maximize the concurrency while minimizing the overhead introduced.
- the communication interfaces between an engine and an external entity is defined by the client library. Since there are two types of external entities (consumers and administrators), there are two client libraries correspondingly. The interfaces are defined by the interactions listed out in the previous two sections. All complexities of messaging and connection initialization will be hidden from the users of the libraries.
- JDBC-based communication and AQ/JMS-based communication may be used between a client and an engine.
- An HTTP-based communication can optionally be implemented to facilitate communications through firewalls.
- the messaging interfaces are AQ/JMS-based, but the AQ/JMS interfaces may be implemented on top of HTTP.
- the communication that uses JDBC directly may be implemented using HTTP-POST request to Oracle Web Server.
- Connection-private request and response queues are again queues in AQ. There are various possible alternatives in realizing them. Broadly speaking, there are two dimensions of parameters:
- a request queue and a response queue implemented as one physical queue with two selectors: one for the requests and one for the responses, versus each of them implemented as a physical queue.
- connection-private queue implemented as a physical queue created for the connection, versus the queue implemented as a global queue (across connections) with a specific selector for the connection.
- connection-private queue is implemented as a physical queue, created for the connection.
- Connection-private request and response queues are implemented as one physical queue created for the connection, with two selectors.
- connection-private request queue is implemented as a global request queue shared among all connections, with a selector to select messages specifically for the request of the connection.
- the connection-private response queue may then be implemented similarly.
- connection-private queues are implemented by one global queue. Each connection then has two selectors: one selector for selecting request messages of the connection, and one selector for selecting the response messages of the connection.
- the request and response queues are preferably implemented using two physical queues private to the connection.
- EJB-based architecture In addition to the messaging-based architecture presented, an EJB-based architecture could be used. All interactions defined by messages can be represented by methods of a set of generic Dynamic Services EJBs. This architecture is less desirable because EJB specification does not provide asynchronous interface infrastructure and does not allow creation of threads either (so asynchronous behavior cannot be achieved by spawning threads in EJB server and returning the result through a callback function). Moreover, a messaging-based architecture permits the definition of a core subset of interfaces as messages. If there is a need to support other protocols between a client and an engine, the message definition provides the common foundation for implementing additional protocols.
- the ExcutionAdaptor When executing a service, the ExcutionAdaptor is responsible for establishing the right execution flow for the service. Let's assume for example that a particular service requires to make a first round-trip to the service provider for authentication purposes and then to perform a second one to actually execute the service. If the communication protocol is HTTP based, the session between the two round-trips will be maintained through the usage of HTTP cookies. The ExecutionAdaptor will collect the cookie returned after the first round trip and then re-use it for the second request.
- ExecutionAdaptors will have access to facilities provided by the Dynamic Service engine to temporarily store session identifiers such as HTTP cookies. The lifetime of this storage will only be within one service execution and therefore will not span across multiple executions.
- Dynamic Services Engine will not maintain sessions across Service Executions. Following our example of a Service Provider accessed through the HTTP protocol in a single round-trip, if the service provider returns a cookie, the latter will not be stored or managed by the Service Engine. The cookie, or any other protocol-specific session identifier, will be returned to the ServiceConsumers in the form of a response header. It this way the Service Engine stays state-less with the respect of Service Executions.
- a Cache Manager is made available within the Dynamic Services Framework. It does not need to have a semantic understanding of what is being cached but must be extensible in order to serve components including the Services Registry, service execution (responses), and even protocol adaptors. The caching for each one of the components is done in a relatively independent manner so that one component's cache will not interfere with another's. With this independence, different life cycles are achieved across different components. Two dimensions determine the life cycles of the caches; application (or module) specific expiration policies and general flushing policies.
- connection level caching where everything cached during a connection is flushed when the connection closes
- engine level caching where everything cached during an uptime of the engine is flushed when the engine is shut down
- persistent caching where the cache is never flushed. If desired, caches can be purged manually via API calls.
- the Cache Manager should have a plug-in architecture that allows different plug-ins to augment it and allow it to cache for new components. These plug-ins contain the logic for semantically understanding what is being cached as well as the component specific expiration policy that will be enforced.
- the CacheManager is a component that will be shared across components that needs any caching functionalities. It is an extensible component, which can extend its provisions to new components through a plug-in architecture.
- the plug-ins are in the form of configuration files that contain specifications on information such as expiration policies and general cache flushing policies.
- CacheManager operates with caching models and supports the models specified in the HTTP/1.1 protocol: Expiration Model and Validation Model—for more details on those policies please refer to the HTTP/1.1 specifications.
- the validation model corresponds to the general cache flushing policies described above. Service providers will be able to suggest caching policies to be used for their services. This implies that a section in the service descriptor will be dedicated to caching parameters. For example, those parameters can include the specification of an Xpath in the service response addressing the server-specified expiration time for that response.
- the visibility of the cache will be determined by the Service Administrator initially during registration time. Later he may alter this visibility by modifying the access control for users/consumers on the underlying storage solutions of the cache depending on the service.
- Pre-fetching is a feature controlled by the service administrator rather than service providers. For each service, service administrators can specify a request and an execution time schedule. DSE will follow the supplied schedule to execute the service with the supplied request and then cache its response. Such feature will also have to behave consistently with the caching policy supplied by the service provider. Administrator Tools can help to suggest an optimal pre- fetching policy.
- a hash table like structure which may be implemented a database table may be maintained, where the cached results are hashed with keys that are component specific.
- a context bundle can be used as a key to hash the service response for a certain service execution.
- the Event Manager is a component that tracks actions taken in the flow of an execution. In essence the engine should be able to make use of all this information for purposes of logging, billing, etc.
- the model followed should be one where it is possible for components interested in auditing, to add themselves as listeners to the EventManager. Components internal to the DSE will generate the events and post to the EventManager which will dispatch them to the appropriate listeners. Appropriate event classes should be used for each one of these actions. Events generated by the DSE will also contain information about the user that triggered the operation that generated them so that logging and billing logic can be applied on such information.
- the Event Manager interface exposed would give access to all of the events tracked/saved in a systematic manner.
- Other modules can be attached to the EventManager to make use of the information tracked by the EventManager.
- a set of modules providing some system services may be provided:
- Logging services can re-organize these events in some systematic way for use with other modules or even applications, e.g., third-party log analysis applications, system debugging and profiling report tools, etc.
- Billing services can use this information to track how much a consumer is using the services and therefore how he is to be billed accordingly.
- the billing module may provide an API to attach billing applications, e.g., Oracle iPayment, to the service engine.
- Notification services can notify administrators (or any other relevant personnel) certain system-generated events, e.g., service execution failure. It can provide an API to attach different notification methods, e.g., email, pager, short messaging, Oracle Enterprise Manager, etc.
- Trigger services allow administrators to execute administrator-defined services upon the occurrence of some events. For example, a user-quota service trigger can be activated before a service is invoked to audit resource allocation. An execution of a trigger is guaranteed to start at the same state as the event that triggers it.
- triggers There are two types of triggers: passive triggers do not affect the execution flow of the logic that generates the event. Active triggers, on the other hand, can affect the execution flow of the logic that generates the event, e.g., a user resource auditing trigger can stop the execution of a service if the user has exhausted his quota.
- logging, billing and notification services are simply specific triggers. However, they are defined and provided by the engine while trigger services are services defined by individual administrator for their specific tasks.
- Different event-consuming modules are interested in different types of events. For example, logging services are generally interested in the all events while billing services are only interested in the service-execution-completion events. Hence, an events will be classified to one or more class(es) by different classification schemes.
- the classification schemes include:
- ALL events all events belong to the ALL event class. Logging services are interested in all events.
- System-generated vs. user-generated events The service engine will define and generate a fixed set of events while administrators and service providers can also define and generate other events in their plug-ins to the engine, e.g., a service-specific execution adaptor. Notification services only notify system-generated events.
- Triggerable events Some events represents a state that additional triggers can be attached in the execution flow, e.g., user-resource auditing trigger can be attached before the execution of a service. Some other events are purely informational and are not designed to invoke any triggers. Trigger services will only be interested in triggerable events.
- Profile events are events generated for service execution performance profiling.
- Debug events are events generated to produce some system traces for debugging purposes.
- components of the Dynamic Services Engine may post events about their operations to the EventManager. In practice, this can be done by having the Event Manager component receiving messages from these internal DSE components through queues.
- EventManager Components interested in certain events may register themselves to the EventManager and indicate the class of events they are interested in.
- the communication between the EventManager and the Listeners e.g. LoggingListener
- LoggingListener will be based on a publish-subscribe model based on AQ facility.
- Each component will run in its own dedicated connection to the engine. In this case, these components will be executed asynchronously.
- error Handling may be performed by queuing and dequeuing error messages using AQ.
- the conceptual response queue is used for posting the error messages.
- Each error message is therefore be modeled as a special response message.
- Error messages materialize in the form of short XML documents whose type is deduced from a set of headers.
- the client library constructs a Java exception out of the message and return it to the clients.
- Error messages reflect the source of the problem. That is, they also return the client-context supplied at request time in a fashion similar to the one discussed in Section 6.1.3.1.
- Error messages indicate severity; the following are the prescribed levels of severity.
- the client library will interact with the response queues and upon receiving error messages, package them into Java exceptions are returned them to the clients.
- Warning These error messages serve to warn the consumer that the execution of services following may behave abnormally after the occurrence of the warning.
- Error messages set provisions for service providers to embed service specific error details in these error messages. This is a way for service providers to “extend” our error handling mechanism. Such service specific error messages can be raised by the Adaptor's code, where service provider can add additional error condition check. These details can be simple or complex structured XML snippets that will be understandable by both the providers and the consumers.
- Application-to-Application This type of error messages is thrown when a service specific error happens. This can take on several forms including but not limited to semantic errors in the request happening on the service provider side or any errors resulting from applying service provider-supplied adaptors.
- Application-to-Server This type of error messages is thrown usually by the DSE. It entails errors that occurred before going to the service provider. As far as the consumer is concerned, either something went wrong on his side, or on the engine side. This type of errors include syntax errors where the request XML does not conform to the provided Input XML-Schema, as well as the engine's notification of updates letting consumers know that some specific service will be down. Specific cases of Application-to-Server errors are the Administrator related ones. They involve registration errors that could result only from calling the APIs that are accessible to the administrator.
- Server-to-DataSource This type of error messages is the lowest level of errors. It occurs at the “transport” level when connection problems between the Engine and the service provider are encountered. This entails not only errors like having a proxy that is down, but also “File Not Found Exceptions” on the service provider side.
- DS Exception Queue In addition to the Request and Response queues that each consumer owns, an exception queue will be set up called DS Exception Queue, which will be a destination for error messages when they are thrown by the service engine, awaiting pickup by the consumers. Error messages materialize in the form of short XML documents whose type is deduced from a set of headers. If we have a separate queue just for the exception, then error message can be modeled as a unique type of messages. The solution is not desirable because for a submitted request, the client library will have to “monitor” two queues for a possible response. In fact, the response queue will be used if a correct response is returned and the error queue if the request fails. Hence, it is preferable to monitor only ONE queue and have the error message as a special response type.
- a logical service engine can be implemented by a central registry (of users and services) and a set of service execution engines. The system can then be scaled by adding additional service execution engines.
- the central registry will not become a bottleneck because of the heavy use of caches at the service execution engine. What is more, if the users are geographically distributed, service execution engines can also be added to reduce the network traffic.
- the central Services Registry of a service engine can contain reference to services in the central Services Registry of another service engine. To improve performance, a central Services Registry will also cache these external references. This is useful for sharing service definitions among multiple engines. In a large organization, there can be multiple service engines serving different sub-organizations. A service that is primarily owned and managed by a sub-organization (represented by a service engine) can then be re-used by other sub-organizations without requiring the other suborganizations to duplicate the service (and hence the management of the service).
- Service Engine to Service Engine communication In some B 2 B exchange or content syndication scenarios, a service engine can be also be a service provider to another service engine (when both parties are using providing their solutions based on Dynamic Services Framework).
- An optimized ProtocolAdaptor may be implemented to provide a fastpath communication between the two engines, improving the runtime performance of such systems.
- Security consists of following components:
- Authentication For services customer and services provider, authentication insures the Dynamic Services Engine is the entity the customer or provider wants to contact. For the Dynamic Services Engine, authentication means that it is connected to the expected service customer and/or service provider.
- Integrity To secure that the data cannot be modified while transmitted via public network.
- Access control is closely related to security, which concerns two aspects: the privilege to access a certain database table, or the authority to access, manage or execute the local files in the OS of the Dynamic Services Engine's host. After authentication, the DBMS or the OS knows who is the user. By granting the database privileges or file system authority to this user, the access control can be applied. In other words, for Dynamic Service Engine, access control can be implemented by Oracle DBMS functions, or the host's OS commands. There is no need for Dynamic Service Framework to provide additional access control.
- a fully-fledged security system consists of three components: authentication, encryption and integrity, for some connections only one or two security features are necessary. For example, if a certain service provider only requires authentication, then the dynamic engine will only have to authenticate itself to the service provider, but it may not encrypt its data to the service provider and it may not ensure the integrity of the transmitted data.
- Dynamic Service Framework preferably offers two security features, (1) conventional login name/password method for authentication, (2) Secure Socket Layer (SSL) for authentication, encryption and integrity.
- SSL Secure Socket Layer
- connection between a service consumer and the dynamic service engine There are two kinds of connections in the Dynamic Services Framework, the connection between a service consumer and the dynamic service engine, as well as the connection between the engine and a certain service provider.
- the system handle two types of connections, one is based on HTTP protocol and the other is JDBC connection, and implements the following four security options:
- SSL Secure Sockets Layer
Abstract
A dynamic services infrastructure accepts data describing data resources and stores that data in a relational database from which it may be retrieved to handle service requests issued by application programs. The database stores Service Definition data which is initially supplied in the form of XML Service Descriptor documents which are then mapped into the database from which they may be accessed. Each Service Definition includes an input specification which identifies the address of a resource as well as the nature of the input data to be supplied to the resource with the request, and further includes an output specification which describes the nature of the output information which is supplied by the resource in response to the request. The Service Definition further includes information describing the service provider which supplies the resource, test information including fixed input and output values which permit the operability of the resource to be verified, update information which permits the infrastructure to insure that the Service Definition information is kept current, and security information which permits the system to validate users and provide secure encrypted information exchanges. When a client sends a request for services to the infrastructure, obtains the service description for the desired resource from the database, transmits an output information request to the address specified in said the service description, supplying input information meeting the specification contained in said particular service description to said particular resource, and receives and routs output information provided by said particular resource in response to said output information request to the executing application program.
Description
- This application is a division of U.S. patent application Ser. No. 09/584,318 filed on May 31, 2000 which claimed the benefit of the filing date of U.S. Provisional Patent Application Serial No. 60/137,006 filed on Jun. 1, 1999.
- A portion of the disclosure of this patent document contains material subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
- This invention relates to electronic information processing systems and more particularly to methods and apparatus for providing information-based services from a plurality of diverse resources to one or more users.
- The Internet has provided access to millions of different information resources. To obtain desired information, human beings typically use browser programs to sift through web pages, web indexing services and available subject matter directories to locate useful information. While powerful tools have been made available to assist human researchers in finding what they need, the vast amount of data which is accessible cannot typically be processed by application programs. Thus, while programmatic access to data on the Internet would be extremely useful, it is not now available.
- There are many resources with different characteristics to which developers have no easy programmatic access. While most provide interfaces for end-users, they provide none for applications. If developers want to make use of these resources, they have no simple programmatic interface to use. For example, many web sites provide services for stock prices; some web sites provide services giving current rates of currency exchange. Yet developers have no easy way of building an application that delivers stock prices in the currency of the user's choice, albeit all the information they need can be found on the web.
- Another aspect of the problem is that different resources have different access protocols. For example, to build a payroll application, a developer may need to: (1) access a personnel payroll database for the amount of money to be transferred and the destination account, (2) send a message to a legacy system to initiate the transfer, and (3) access an employee directory service to lookup the employee's email address to send an alert email. All these resources are accessed via different protocols, such as JDBC to access the personnel database, a proprietary protocol to the use the legacy system, and LDAP for directory services. Consequently, each developer must write special code to access each of these different resources, rather than concentrating on the development of application logic.
- It is accordingly an object of the present invention to provide methods and apparatus for delivering data from different resources in ways that permit programs to process and integrate that data for the benefit of end users.
- In a principle aspect, the present invention takes the form of methods and apparatus for obtaining information from each of a plurality of diverse data resources having different characteristics. A separate service description for each given data resource is stored in a database called the Services Registry. Each service description includes: the address to which an information request may be transmitted; a specification of the nature of the input information to be supplied; and a description of the nature of the output information to be supplied in response to request.
- Service requests identifying particular resources may be issued by application programs. A service interface program is then executed in response to each such service request to obtain the particular service description corresponding to the identified resource from the Services Registry. The interface program then transmits an output information request to the address specified in said particular service description, supplies input information meeting the specification contained in said particular service description to the resource, and routes output information provided by said particular resource to the requesting application program.
- In accordance with the invention, a registration module is preferably used to accept service description information in a predetermined format, preferably in Extensible Markup Language (XML), so that the service description may be validated against a Service Descriptor Schema, which may take the form of an XML schema such as a Document Type Description (DTD), before it is stored in the Services Registry.
- The stored service description may also advantageously include contact information specifying the person or entity supplying the resource described in said service description, as well as test information consisting of fixed input values and fixed output values. The stored test values enable the service interface program to perform automatic testing of the described resource by sending the fixed input values to the described resource and comparing the resulting output from the resource with the fixed output values. Further, the stored service descriptions may advantageously further include security information for ensuring that requests for output information originate from an authorized source before that request directed to the described resource is satisfied.
- When a client sends a request for services to the services interface program, it obtains the service description for the desired resource from the database, transmits an output information request to the address specified in said the service description, supplying input information meeting the specification contained in said particular service description to said particular resource, and receives and routs output information provided by said particular resource in response to said output information request to the executing application program.
- The Dynamic Services Framework contemplated by the present thus wraps disparate resources with a standard programmatic interface which can be accessed in standard ways, primarily using Java. A resource owner (service provider) can easily build a dynamic service descriptor specifying the input/output characteristics of accessing their resources. With the descriptor, accessing the resource becomes accessing a service through a standard simple programmatic interface. The Dynamic Services Framework provides the infrastructure and logic for abstracting the access of different resources with a single standard interface.
- These and other objects, features and advantages of the present invention will become more apparent through a consideration of the following detailed description of a specific embodiment of the invention. In the course of that description, frequent reference will be made to the attached drawings.
- FIG. 1 is a block diagram which provides an overview of the basic methods performed by and structure of the present invention,
- FIG. 2 is a data flow diagram which illustrates an embodiment of the present invention, and
- FIG. 3 is a chart depicting the principal class structures used to implement the preferred embodiment of the invention.
- The present invention provides methods and apparatus for effectively converting a variety of diverse information-based resources, such as Internet web sites, databases, and other servers, into information services accessible to programs. Each service, as presented via an application program interface, conforms to a functional interface standard which provides the application programs with the metadata needed to access and integrate these resources for presentation to an end user.
- 1. System Overview
- 1.1 Glossary
- The glossary of terms below introduces terms which are frequently used in the following description.
- Developers: developers refer to developers of Internet applications.
- Dynamic Service (Service): a component within the Internet computing model that delivers a specialized value-added functionality. A dynamic service typically comprises some content, or some process, or both, with an open programmatic interface.
- Dynamic Service Engine: an engine that provides storage, access and management of dynamic services.
- Dynamic Services Framework: an open programming framework for enhancing a relational database Internet platform, such as Oracle8i, for service creation, deployment, access and management. It comprises dynamic service engine, a set of dynamic services, as well as users of dynamic services (service consumer).
- Execution Adaptor: a routine that executes a service request in a particular flow. A flow could be as simple as relaying the request to contacting a service provider, or as complicated as relaying a request to a provider and relaying the response to another provider.
- Framework: same as Dynamic Services Framework
- Input Adaptor: a routine that post-processes the service input from consumers to produce the standard service input that is fed to the underlying service. An example is converting the unit of length from foot to meter.
- Output Adaptor: a routine that transforms the raw output from the underlying service to the standard service response.
- Protocol Adaptor: a routine that transforms the standard service request to the inputs needed by underlying service following the underlying protocol.
- Service: same as Dynamic Service.
- Service Consumer: the person who makes use of services in his context, typically some web application developer.
- Service Descriptor: a descriptor defining the behavior of a service, containing service provider information, description of service functionality, service management information, service input adaptor, service output adaptor, and other provider-specific sections, such as secure access, caching parameters, etc.
- Service Engine: same as Dynamic Service Engine
- Service Engine Administrator: the person who perform administrative activities for the engine, e.g., enabling/disabling of services, tuning caching parameters of a service, etc.
- Service Handle: a service handle is a logical representation of a service. In practice it is an in-memory structure that is used to create requests, send requests and fetch responses for the service consumer.
- Service Invocation: a programmatic request for a service. After having retrieved a service handle, a service consumer can use that handle to make service requests. This invocation process is analogous to making method calls on an object. The life-cycle of an invocation starts when the request is made and ends when a response is returned to the consumer.
- Service Provider: the person/organization that provides a service, typically the owner of some data resource or process, e.g., the owner of a currency exchange rate web site.
- Service Registration: registration is the process of entering the service package into the Services Registry. This action is performed by the Service Administrator upon receiving a service package from the Service Provider and augmenting it by exercising deployment decisions.
- 1.2 System Overview
- The general makeup of a preferred embodiment of the invention is shown in FIG. 1 of the drawings. As shown, the system operates under the programmatic control of application programs called Service Consumers (SC) which are executed on behalf of system clients as seen at117. The application programs utilize
access components 130 to send requests to and receive information from a Dynamic Services Engine (DSE) 113 which is connected via theInternet 114 to selected Service Providers (SC) indicated generally at 115. The application program utilizes the information thus obtained to provide value-added information to the end users (clients) 117. - In accordance with an important feature of the invention, before any of the
Service Providers 115 are accessed by theDSE 113, Service Definition data called a Service Definition (SD) which describes each Service Provider is first stored in a specification database called the Services Registry (SR) 121 using a registration procedure indicated at 111. Theregistration procedure 111 supplies a Service Definition for a given service provider in the form of a service Descriptor document expressed in Extensible Markup Language (XML) as indicated at 125. The individual elements of each XMLservice Descriptor document 125 are mapped onto a predetermined service description schema in thespecification database 121. - The
database 121 is preferably a relational database which forms part of an integrated database system, such as the Oracle 8i System marketed by Oracle Corporation, Redwood Shores, Calif. 94065, a comprehensive platform for building and deploying Internet and enterprise applications. The Oracle 8i platform provides numerous features which can be used to advantage by program developers for developing robust application programs which can also make use of the diverse database resources provided by the present invention. These program development features include: - a. iFS, the Internet File System, which provides an Internet based file system where the “files” are stored and managed by the database.
- b. interMedia, which facilitates the management of multimedia data, including text, graphics, video and audio files;
- c. Oracle Enterprise Manager, which provides database and environment management user interfaces;
- d. Oracle Web Application Server, which facilitates the development of web-based applications,
- e. WebDB, an HTML-based development tool for building web content from the Oracle database using web browsers to develop and build dynamic Web applications which employ data stored completely in the database with no additional Web servers; and
- f. a Java Virtual Machine integrated directly into the database engine.
- The Java Virtual Machine, which forms part of the same machine environment used to execute the
Dynamic Services Engine 113 and the functions of thedatabase 121, is used to execute the translators, seen at 127 in FIG. 1 and discussed in more detail later. Each of thetranslators 127 preferably takes the form of a Java jar file supplied by the implementor to convert data in special formats from particular ones of theservice providers 115 into a standard form which may be processed by other components of the system. Similarly, the ServiceConsumer application program 117 can take the form of a Java program which executes within the Java Virtual Machine, and functions which are performed by theDynamic Services Engine 113 can be implemented with Java programs executed by the same Java VM. - Dynamic Service Framework advantageously exploits a number of additional mechanisms which are provided by the Oracle8I RDBMS. Framework leverages those technologies and offers its services on top of them:
- Oracle Jserver: The Dynamic Services Engine may be deployed as Java components running on the Oracle JServer JVM.
- Oracle Internet Directory (OID): This LDAP directory service may be used by the Registries of the Dynamic Services Framework. This includes the Services Registry, the User Registry and their relationships for handling Access Control.
- Oracle Advanced Queuing (AQ): Oracle AQ may be used as the underlying system for the communication between the DSE and its clients.
- Oracle Advanced Security: Oracle Enterprise Security Manager is an administration tool that provides a graphical user interface to manage enterprise users, enterprise domains, databases, and enterprise roles that are held in a directory server. Once the consumer has logged in, he/she is free to access any secured service provider which he/she has registered before.
- It should be noted that communications facilities other than the
Internet 114 illustrated in FIG. 1 can be used to provide the communications links which couple theservice providers 115 to theDynamic Services Engine 113 and to the ServiceConsumer application programs 117. is Similarly, data transmission facilities other than the Internet can be used to provide the communication links which couple client machines to the services provided by the system. These other communications facilities include leased line connections, mobile phone links, and anything else that can communicate with the host system (e.g. Oracle 8i) via HTTP, IIOP, SQL*NET, Mobile Gateways, and the like. - 1.2 Service Definition Database
- As contemplated by the invention, diverse external resources are made accessible to application programs by access mechanisms which utilize Service Definition data stored in the
database 121. The Service Definition which describes each of the resources provided by theservice providers 115 is used to expose that resource to application programs as a standardized service. - Program developers who wish to use a particular resource, such as an Internet web site, to provide information to one or more application programs, or a service provider who desires to make a resource generally available to program developers and users, follows a standard registration procedure, indicated at111 in FIG. 1, to create and store the Service Definition data that the Dynamic Services Engine requires to provide access to that resource.
- As contemplated by the invention, the Service Definition is preferably provided to the system as a service
definition XML document 125. XML possesses a number of desirable features which make it particularly well suited for the expression of Service Definition data, including the existence of tools for creating and testing the syntax and validity of the specification data to be submitted. An XML schema, such as an XML DTD, may be used to specify the required and optional elements which should be present in each Service Definition. Tools constructed in accordance with the Document Object Module (DOM) standard may be used to provide an application programming interface (API) for the XML Service Descriptor documents. Standard XML editing tools may be used to prepare the XML data in compliance with a Service Definition schema, allowing the resulting data to be directly mapped into a corresponding schema used by therelational database 121 which is then accessed in the conventional way by theDynamic Services Engine 113 or by an application program which can make use of the specification data. - The XML
Service Descriptor document 125, and the corresponding data as stored in thespecification database 121, may contains the following kinds of information: - 1. Company Information: this information is use to identify the service provider and includes information to locate and contact the service provider (typically a company or individual) directly by mail, phone, email, company URL or other contact information. If the service provider's logo is to be used in connection with the service, that logo is specified.
- 2. Business Information: This section contains information regarding fees to use the services, license keys, etc, allowing the automation of business transactions for each service provider. The information available can be used to build different pricing models, e.g. pay-per-use, block license fees, free use with associated advertising, etc.
- 3. Security Information: Security information regarding each service permits the Dynamic Services Engine to perform security functions, either as built-in routines or as provided by others, to authenticate users, validate transactions, encrypt messages, etc.
- 4. Inputs: each Service Definition includes a list of inputs required to execute the service. At the time the service is executed, a request for each of the specified inputs is automatically presented to the user application program in an appropriate format in each user environment. This mechanism allows the services engine to separate functionality from the presentation, a key to providing the same service on different platforms. As part of the input, a user can also provide default values for each or all of the inputs. The default values could be a presented to the user as a list from which users can select a value. An input may simply a URI to point the Dynamic Services Engine to a particular service provider together a filename or method name to access the resource. In the common Internet scenario, an input specification could take the form of a specific URL with a specified GET or PUT method.
- 5. Outputs: Because the Dynamic Services Engine attempts to present heterogeneous services in a homogeneous environment, the list of outputs to be presented to the users as a result of service execution must be provide as part of the service description. If the service does not return data in a well-understood common format, or if the service provider does not wish to expose its standard output to the system, a Java jar file may be specified as part of the output description, with the Java file acting as one of the
translators 127 seen in FIG. 1 to implement a standard interface specified for use by the dynamic services system. When such a resource is accessed, theservices engine 113 identifies the jar file from thedatabase 121 and uses the selectedJava translator 127 to provide the desired interface to the specificservice provider resource 115. When the particular resource at 115 is accessed, theservice engine 113 only processes those outputs which are specified in the outputs section of the Service Definition for that resource. - 6. Contact Information. Contact information from the service descriptor is used to send a message to the owner or manager of the service provider which does not properly respond to a service request. This notification message may take several forms, including email, a prerecorded or synthesized voice message to a designated phone number, a fax transmission, a pager message, etc.
- 7. Update Information. The services engine will periodically search for updated service information from time to time at a location or locations specified in the Service Definition, which also specifies the frequency with which the update check is to be performed. Optionally, a user or service provider can send a message to the service engine after an update is completed, or can post a new location specification from which further updates will be provided.
- 8. Automatic Test Information: the Service Definition includes fixed input and output values which may be used to test the operation of a specified service. In this way, a malfunctioning service provider can be distinguished from failures caused by communication delays or the like. Automatic tests using this information can be performed periodically to help ensure system integrity, and can also be performed after updates or refresh operations to ensure proper operation of each service.
- 9. Caching Information. This section of the service description captures the service driven caching parameters. Items in this section instruct the services engine to use or not use cache memory for a particular operation, and inform the engine how long he cached data should be retained and when it should be considered to be expired. When services are known to present static data which changes only infrequently, requesting retention of fetched data in the cache can both reduce network traffic and provide faster service.
- 10. Additional Information. Beside the classes of information noted above, additional information may be stored in the specification database for each service provider resource, including usage log data, information to be presented back to the service provider for its use, or information used to customize or tune a particular service.
- 1.3 The Dynamic Services Engine
- FIG. 2 of the drawings illustrates the operation of the Dynamic Services Engine, shown at113 in FIG. 1, in more detail.
- As noted above, before the services engine can process requests for services, each available resource is first described in an XML Service Definition which is translated and stored in the Service Definition database, shown311 in FIG. 2. All Service Definitions stored in the
database 311 are structured in accordance with a predetermined database schema. - The Dynamic Services Engine includes a generic registration module seen within the dotted
rectangle 313. The registration module accepts an XMLService Descriptor document 315 from an available source, such as an XML editor, a web application that processes POST data from an HTML form, or any other suitable source as indicated at 317. - The XML
Service Descriptor document 315 preferably identifies a standard XML schema which specifies the required and optional elements to be included in the XML Service Definition. An example DTD which specifies illustrative XML schema for the Service Definition elements is set forth at the beginning of the accompanying appendix, and is followed by listings for a set of illustrative Service Definition XML documents which comply with the schema. - The form and function of XML an XML schema data is defined in a formal specification, REC-xml-19980210, Extensible Markup Language (XML) 1.0, issued by the Word Wide Web Consortium, the current version of which (issued on Feb. 10, 1998) is available on the Web at http://www.w3.org/TR/REC-xml. As stated in that document, the Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [ISO8879]. By construction, XML documents are conforming SGML documents.
- XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure. A software module called an XML processor is used to read XML documents and provide access to their content and structure. It is assumed that an XML processor is doing its work on behalf of another module, called the application. The XML specification noted above describes the required behavior of an XML processor in terms of how it must read XML data and the information it must provide to the application.
- A second specification, also developed by the World Wide Web Consortium, REC-DOM-Level-1-19981001, Document Object Model (DOM) Level 1 Specification Version 1.0, available on the Web at http://www.w3.org/TR/WD-DOM-19980318, defines the Document Object Model Level 1, a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents. As stated in the DOM recommendation, the Document Object Model provides a standard set of objects for representing HTML and XML documents, a standard model of how these objects can be combined, and a standard interface for accessing and manipulating them. Vendors can support the DOM as an interface to their proprietary data structures and APIs, and content authors can write to the standard DOM interfaces rather than product-specific APIs, thus increasing interoperability on the Web.
- As seen in FIG. 2 at319, each XML
Service Descriptor document 315 is parsed into its constituent data elements and those data elements are then mapped into and stored in thedatabase 311 in accordance with the standard Service Definition schema. Numerous XML parsers, including the XML parser which forms part of the Oracle 8i platform, can be employed to process the XML document. The Oracle Internet Platform includes built-in XML-support for exchanging XML data over the Internet using the W3C standard, and includes an XML Parser for Java, an XML Class Generator, and an XML Parser for PL/SQL. The Oracle XML parser for Java can be executed by Oracle 8i's Java VM, and enables parsing of XML documents through either SAX or DOM interfaces using a validating mode for testing each incoming Service Definition against the Service Definition DTD. When it is necessary of desirable to alter or update an existing Service Definition, a revised XML document is supplied via theregistration module 313. - When an available resource has been registered with the dynamic services system, all or part of the information or processing services which are available from that resource can be programatically accessed by an application program which issues a service request. When a service request is received, the Dynamic Services Engine processes the request against security information stored in the
database 311 to authenticate the user and validate the request as indicated at 324. - By accessing service description data in the
database 311, the services engine can respond to generic requests by displaying a list of available services. In addition, by accessing the inputs specification for a selected service, the input data required by that service can be presented to users in a manner which is appropriate to that service in different environments. At the time the service is executed, a request for each of the specified inputs is automatically presented to the user application program in an appropriate way in each user environment. This mechanism allows the services engine to separate the functionality from the presentation, a key to providing the same service on different platforms. As part of the input, a user can also provide default values for each or all of the inputs. The default values could be a presented to the user as a list from which users can select a value. An input may simply a URI to point the Dynamic Services Engine to a particular service provider and a filename or method to access the resource. In the common Internet scenario, an input specification could take the form of a specific URL with a GET or PUT method. - If encryption is specified for incoming messages or input data by the Service Definition, decryption is performed as indicated at331 in FIG. 3. Likewise, the content of incoming messages or input data can be validated as specified by the Service Definition as illustrated at 333. Next, as seen at 337, before the service request is executed accounting functions can be performed in accordance with the business information portion of the Service Definition. Finally, when these steps are completed, a service request is transmitted to a
service provider 336, a resource specified in the Service Definition as indicated at 335. As noted earlier, this service request can take the form for an HTTP message to a particular URL and method, passing input data to the resource in the manner specified the inputs portion of the Service Definition. - The service provider (typically a remote web site) returns output data to the Dynamic Services Engine as seen at340. If the data returned by the
service provider 336 is not already in a standard form, the Service Definition of that resource identifies a Java jar file which is executed as indicated at 343 to translate the data from theprovider 336 into the desired standard format. - The output data from then is then formatted for presentation use by the client application program as indicated at345. The output data is published for use by the requesting application in an output format specified in the output section of the Service Definition. If so specified in the Service Definition, company information and/or a company logo can be added to the output data from the service provider as seen at 358, and the data may be encrypted as seen at 361 before being sent to the requesting application program as indicated at 363.
- The client application program commonly takes the form of a Java program which executes within the same environment as the Dynamic Services Engine and performs specific operations on the data. The dynamic services infrastructure may be used to particular advantage to integrate data from several different resources into a single presentation to an ultimate user. By way of example, an application can obtain data from a plurality of different registered online retail sites, perform price comparisons, and present the results to a user. A second application could obtain foreign currency exchange rate information from one web site, and obtain price information on stocks or products from other web sites, and present results in a particular currency selected by a user. In each case, the application program can present data integrated in this fashion in ways that are compatible with any device that can connect to the service, such as Personal Data Assistants (PDA's), web servers, mobile phones, and the like.
- As indicated earlier, the Service Definition includes contact information which allows the system to periodically issue requests to update the Service Definition data. The person or entity to whom the update request is sent, together with the frequency with which the update requests should be issued, are recorded in the specification data for each resource. Typically, the service provider is contacted as shown at380 and 382 and, thereafter, the service provider or other person to whom the update request is sent, may respond by submitting new information through the registration mechanism as seen at 484 to modify the Service Definition data in the
database 311. - As indicated at390, test information stored for each service is employed to periodically test the external resource, typically by transmitting standard input data and then comparing the response to standard test output data. If the test reveals a problem, an error report can be sent to a destination address, such as an appropriate person in charge of the service provider, to inform that person of the problem as indicated at 394.
- To improve system performance and reduce network traffic, caching information may be stored for each service which indicates the extent to which output data from the service should be cached, and how long cached data should be retained.
- Preferably, means are included for recording the nature of transactions performed by the system in a log file, and to record feedback from both client applications and from end users regarding the system, its use, and its performance. Processing means may be incorporated into the system for analyzing both the performance history and the feedback received in order to provide quantitative parameters and descriptive data which describe the performance of the system.
- 1. Design Features
- The principal architectural features of the specific dynamic services framework contemplated by the invention may be individually summarized as follows:
- Service Consumer (SC). Service Consumers are clients of the service engine. Through the Dynamic Services client APIs they will acquire handles on the Services, submit service execution requests and collect the responses. SCs are unaware of the communication protocol used by the Dynamic Services client library and the Dynamic Services Engine. Such communication is abstracted by the client library.
- Dynamic Services Engine (DSE). The core of the Dynamic Services Framework. The DSE is operates within and uses the services of a relational database system, such as Oracle 8i. Upon Service Consumer request submission, it will execute the service, package the response, and return it to SCs.
- DS Services Registry (SR). The Services Registry is the placeholder for the service definitions. Service Consumers can use the client library to query the DSE for lookup operations on the Services Registry.
- DS User Registry (UR). Registry for the Service Consumers of the Dynamic Services Engine. It is used for authenticating Service Consumers during their connection phase. It is used for the storage of user properties and information.
- Service Provider (SP). They are responsible for defining and providing a service. DSE will contact them during service execution accordingly to the specification provided in their service definition.
- DS Administrator (DSA). The administrator is responsible for maintaining the Dynamic Services Registry. His responsibilities include: registration/unregistration/updates of Services, deployment options for services, controlling services access to the Service Consumers, engine performance monitoring, log reviewing, service scheduling, etc.
- Communication between DSE and SCs. The Client Library will be responsible for handling the communication between the Service Consumers and the DSE. The communication will be based on messages.
- Communication between DSE and DSAs. Service Administrator will be interfacing to the engines through the Administrator Tools. The Tools will be using an extended version of the client library to communicate with the Dynamic Services Engine.
- 2. Service Definition
- A service is defined by all the components that make up the service. They include descriptions of the service in terms of its value-added functionality, declaration of what interfaces it has, information regarding the providing party, and some auxiliary libraries, which may be used during service execution. More concretely, this is referred to as the service package. The Service Provider builds this package and hands it off to the Service Administrator, who will augment it before preceding with the registration, with information that is deployment specific. The Service Provider will not need to take these deployment decisions as he builds his initial package; he merely specifies suggestions on these deployment decisions.
- 2.1. Service Definition: From the Service Provider
- From a service provider's point of view, a service is modeled through an XML document called service descriptor, which provides a centralized source of description for the service. An example Service Descriptor for a Currency Exchange Service can be found in part B of the Appendix.
- A service is defined by a multitude of logical components, all of which are specified in the service descriptor, at least in part, if not specified in other documents that the descriptor refers to. There are two sections of the descriptor, one focusing on the higher level descriptions of the service, known as the service header, and another delving on the details of implementations of the service, known as the service body.
- 2.1.1. Service Header
- The service header contains high-level descriptions of the service. For the most part, information specified here is descriptive and non-interpretive for browsing and documentation purpose. The exceptions are service interface specification and service identifier.
- 2.1.1.1. Naming Specification
- Naming information contains a globally unique identifier as well as short and long descriptions of what the service does. Each service will be addressed through an absolute name specified using the URN (Universal Resource Naming) conventions. Universal Resource Naming is described in detail in the Internet Request For Comment document IETF RFC 2141. UUID used by ICE was considered as an alternative.
- 2.1.1.2. Version Specification
- The service header includes version information with pointers on how and where the service update is to be performed. Coupled with support contacts from the service provider Information section, this bit of information is critical for service maintenance.
- 2.1.1.3. Service Provider Information
- High-level information about the service provider can be specified, including the provider's company name, copyright information, and company URL. Detailed information drills down further into contacts for support and URLs for logos. This information is provided in the form of an X-Link that will point to another XML document. In order to make use of this XML Document, the Dynamic Services Engine has to be aware of the semantic mapping between the XML Schema that it follows and the internal storage structure inside the registry. There will be an initial set of schemas that the engine will semantically understand. In the future, plugging in additional parsers for new schemas can augment this set. This allows the Dynamic Services Framework to embrace emerging standards for representing data such as company information/contacts that will have been heavily used in existing applications.
- 2.1.1.4. Deployment Specification
- Optionally, specified in the descriptor is a set of deployment properties comprised of suggestions from the service provider to aid the service engine administrator during registration time. They include classification guidelines with hierarchical categories as well as flat keywords, and recommendations of caching parameters. This information is also provided in the form of an X-Link that will point to another XML Document specifying the classification schemes. Again, this is to allow for existing or emerging standards on schemas that data used for categorization will adhere to. The values specified in this section are only suggestions to a service administrator during service registration. The values stored in the Services Registry could be different from the values specified in the descriptor. Note that in other sections, certain parameters can be specified to be deployment options so that the administrator can set them up appropriately at registration time.
- 2.1.1.5. Service Interface Specification
- The Service Header allows for the definition of an interface characterized by the schema specifications of its input, output, and exceptions. The specifications can be dispersed in external XML-Schema documents or they can be embedded in the Service Descriptor. The location of the XML-Schemas is specified by URLs: when a relative URL is used, that is relative to the service package submitted by the service providers. Absolute URL can be used to address XMLSchemas stored on external registries or repositories (e.g. integration with the OASIS registry). The DSE may also retrieve input/output XML Schemas from external registries such as xml.org. It should be also be able to insert/update/delete XML Schemas at external registries on behalf of the user. By specifying these schemas, the service provider enforces the syntax in which consumers send requests to it, as well as the way in which it provides the responses. The validation will be done in the Service Engine when a consumer sends a request, before the actual service provider is contacted.
- The service provider can also suggest a name for the interface, which is a deployment option and can be overwritten by the service administrator. Any new service that conforms to the same service interface must provide the same input/output/exception definition. The engine will also expose to consumers the capability to search for services by interface. Two services that conform to the same interface are considered compatible services, a concept useful for fail over.
- To facilitate the development of code that will work with the Dynamic Services Framework, class generators can be used to create Java classes that map to the request/response XML-Schemas. A Java class generator may be provided as part of the client toolkit: it will be able to fetch the schema from the service engine and generate appropriate classes for easy manipulation on the client side.
- 2.1.2. Service Body
- The Service Body contains more detailed descriptions for each one of the components in the Dynamic Services Engine (DSE) that will be employed at execution time. Specifically, it is sectioned into details on the input, protocol, execution, exception, and output. The service provider can specify an adaptor that needs to be used at each level, be it supplied by the engine or the provider. The functionality of each adaptor will be discussed in each of the following sections. In addition to the adaptors, other service specific parameters may also be specified.
- 2.1.2.1. Input Specifications
- The input section specifies the list of necessary as well as optional processing on the request that comes in from the consumer.
- 2.1.2.2. Input: Rendering Directives
- Under normal execution flow, the request XML that the consumer submits or sends to the service engine will be validated with the Input XML-Schema that is specified previously in the header. However, the DSF allows a service provider to optionally supply some form of Schema Mapping specifications (e.g. through XSL Transformation) that could map this Input XML-Schema to a presentation form such as HTML or WML (Wireless Markup Language). As a result, the consumer can easily provide to its clients (remember that our consumers are application developers) a way to input service requests, for applications that have an HTML or WML interface.
- Notice that the engine is not responsible for the rendering: all that the engine is responsible for is the capabilities to store and retrieve the mapping. The engine only provides the mapping(s) of the transformation. The actual transformation is done on the consumer side by the client toolkit. If we have a mapping of the schema into an HTML form, the consumer can use the mapping to render the Input schema to an HTML form for his web application. He can then transform the HTTP Requests back to an XML document, which conforms to the XML-Schema specified by the service provider. Finally, the request XML will be sent to the service engine formulating a service request.
- 2.1.2.3. Input: Default value and aliases directives
- Service providers may specify additional directives for the purposes of:
- 1) Default value: Filling in a default value for these parameters into the request XML for which the consumer specified no values. Service providers can also specify that the default value for those parameter must be validated at service deployment time. For example, for HTTP, specifying a XPath into the request XML addressing an element that represents one of the HTTP request parameters to be sent to the HTTP server. The directive can also provide mapping to the parameters that are not defined by the request XML schema, e.g., some HTML form hidden parameters. In this case, a value has to be specified.
- In both cases, the value to be filled-in can be a user profile property fetched dynamically at runtime for each user. This information is opaque to the registration parser: The administrator will be prompted to enter a mapping through some API calls to the engine at deployment.
- 2.1.2.4. Input: Input Adaptor
- The input adaptor section is an optional section, identifying an adaptor that further processes the service request before sending to the service provider. Examples of such processing include semantic or higher level validation of the request. This input adaptor specification is a fully qualified name of the class that will handle the processing. Such class will be either found in the service package given by the service provider during registration.
- The service provider has the option of specifying some adaptor specific parameters in the PARAMETERS element under the adaptor, which is validated at service registration time and interpreted at runtime by the input adaptor. These parameters are opaque to the Service Descriptor parser and Services Registry.
- 2.1.2.5. Protocol Specifications
- The protocol section identifies the way that service engine accesses the underlying service. For example, a service may be accessed via HTTP protocol while another service may be accessed via JDBC protocol. This protocol adaptor specification is a fully qualified name of the class that will handle the communication to the underlying service. Such class will be either found in the service package given by the service provider during registration or in the set of libraries that the service engine provides.
- The service provider has the option of specifying some adaptor specific parameters in the PARAMETERS element under the adaptor, which is validated at service registration time and interpreted at runtime by the adaptor. For example, for HTTP, it may specify the HTTP method used and the URL that does the actual servicing. These parameters are opaque to the Service Descriptor parser and Services Registry.
- Usually, service providers will choose to use protocol adaptors that have been prepackaged with the engine, like generic adaptors for HTTP and an Oracle JDBC adaptor.
- 2.1.2.6. Execution Specifications
- The execution section identifies the way in which the service is to be executed. Its responsibility is to take in the request XML and return the response from the underlying service provider. Execution adaptors can be standard simple adaptors that follow the simple path described above. They can also be complex adaptors that aggregate several services like in the International Portfolio example. This execution adaptor specification is a fully qualified class name of a class that will perform the execution. Such class will be either found in the service package given by the service provider during registration or in the set of libraries that the service engine provides.
- The service provider has the option of specifying some adaptor specific parameters in the PARAMETERS element under the adaptor, which is validated at service registration time and interpreted at runtime by the execution adaptor. These parameters are opaque to the Service Descriptor parser and Services Registry.
- The result of the execution adaptor is the response given back from the service. If the service is a simple service, the response will be in the native format of the service provider. For example, for a web-based service, the response may be in HTML format, and for database service, the response would be a java.sql.ResultSet object. If the service is a compound service, the response will be a structured service response.
- Usually, if the service is a simple service, a service provider will use pre-packaged simple adaptor. If the service is a compound service or a simple service that has non-standard execution flow, the service provider will provide a custom execution adaptor.
- 2.1.2.7. Exception Specifications
- The exception section identifies the way in which the exceptions are to be handled for this particular service. Output Specifications
- The output section specifies the list of necessary as well as optional processing to produce the response to the consumer.
- 2.1.2.8. Output: Output Adaptor
- The output section identifies the way in which the output returning from the execution adaptor is to be formatted in the way prescribed by the Output XML-Schema. This output adaptor specification is a fully qualified name of the class that will handle the transformation. Such class will be either found in the service package given by the service provider during registration or in the set of libraries that the service engine provides.
- The service provider has the option of specifying some adaptor specific parameters in the PARAMETERS element under the adaptor, which is validated at service registration time and interpreted at runtime by the adaptor. These parameters are opaque to the Service Descriptor parser and Services Registry.
- Usually, for simple services, service providers will either use the pre-packaged adaptors such as XML Adaptor and JDBC ResultSet Adaptor, or they will provide custom adaptors. For compound services, service providers will use a NULL Adaptor since the response from the execution adaptor will often be in the proper format prescribed by the Output XML-Schema.
- 2.1.2.9. Output: Rendering Directives
- As far as the service execution flow is concerned, output section is the final stop. However, additional mechanisms are provided for the service provider to optionally specify mappings (e.g. in the form of XSL Transforms) that will map this response XML to other forms such as HTML or WML. Consumers, rather than service engines, are responsible to make use of the transformation to render the desirable output.
- Service providers will package their service definitions in to a service package: as said before a service package contains a service descriptor, the XML-Schemas or their locations, and optionally a set of Java class files. It is then responsibility of the Service Administrator to take the service package and register it to the Dynamic Services Engine instance he is managing. During such registration, he will be assisted by the Dynamic Services Administration Tools.
- During registration, information found in the descriptor and all other sources that it refers to will be used to create a logical representation of the service in the Services Registry. Such a process will involve an interaction with the Service Administration who will be asked to specify the value for the service deployment parameters. Deployment parameters are defined as parameters that are specific to the deployment of a service within a Dynamic Services Engine instance. They include:
- a. Naming and classification of a service. The category under which the service should be registered as well.
- b. Deployment input values: the values for some of the service request parameters that have been tagged as deployment time inputs by the service provider. Such feature can be used to model a business relationship where the service provider publishes a service that accepts a username/password and license key as inputs. At the deployment time, the Service Administrator establishes a business relationship with the service provider and acquires the username/password and license key to be used within his Dynamic Services Engine.
- c. Caching policies: Strategies employed by the service engine administrator possibly include basic scheduling, pre-fetch, cache on request, and MRU/LRU cache replacement considerations in cases where cache resources allocated are limited.
- d. Check for updates and service regression. A frequency to be used for checking if new versions of the service packages have been made available by the service provider or if the service is unavailable.
- e. Fail Over: Create through the Dynamic Services Administrator Tools a Fail Over Service for such service under registration
- f. Others: other parameters include logging. After registration/deployment, these decisions taken by the Service Administrator will be materialized and stored in the Services Registry. As a result, when the service is exported from one service engine to another, the information contained in the exported service descriptor will include the deployment choices made by the original administrator; hence the properties found will be a superset of those found in the original service descriptor. A Service Administrator XML schema can be used to validate an exported service descriptor XML document.
- 3. DSE Execution
- 3.1.1. Introduction—Component layout
- The Dynamic Services Engine (DSE) is the core of the Dynamic Services Framework. In the preferred embodiment, DSE is deployed as a Java component running on the Oracle JServer. The main responsibilities of the DSE are to collect requests for a service execution from the service consumers (DSE-clients) communication sub-system, and relay the requests to the DSE execution sub system, which processes them according to the service specifications and returns the built response to the SCs through the same communication path.
- The discussion to follow will focus on the DSE execution sub-system, detailing the internals of the DSE Execution sub-system from the service execution prospective. This section will first present a decomposition of the DSE execution into smaller components and it will then continue showing how they interact during a service execution. The specific details of each component will be finally presented.
- 3.1.2. Component Overview
- FIG. 3 of the drawings shows a high-level overview of the internal components of the Dynamic Services Engine execution sub-system—a conceptual class-diagram is used for such representation. The engine has been decomposed into several components each of them addressing one of the sub-systems necessary for the service execution.
- In general, Managers as those components whose functionality is service-independent. Managers are responsible for performing tasks that are common across services and which cannot be parameterized by the service provider during their service definition process. The Managers shown in FIG. 3 include the
Execution Manager 401, anInput Manager 403, anOutput Manager 405, aCache Manager 407 and aProtocol Manager 409. - Unlike Managers, Adaptors are components that are service-specific. For a given service, the Adaptors to be invoked during the service execution are specified by the service provider during the service definition process. Input and Output Adaptors shown at411 and 413 are responsible for service-specific processing of the service requests and responses. Protocol Adaptors as illustrated at 421 offer an abstraction over the communication protocol between the DSE and the service provider. For each Adaptor, service providers will be able to specify Adaptor-specific parameters in the XML service descriptor. These parameters can be accessed by the Adaptor implementation during service execution. They can be seen as Adaptor configuration parameters. Default adaptors can be provided for standard behaviors and a set of commonly used adaptors are also be provided, such as an XSL Input Adaptor, and HTTP Protocol Adaptor, and an HTML Output Adaptor.
- Since adaptors are the components that can be implemented by a service provider to extend the engine, they pose security risks to the engine. Hence, all adaptor interfaces should have restricted access of resources to the engine.
- 3.1.3. Implementation Approach
- Each of the components shown in the component view should be modeled into Java interfaces. Adaptors supplied by service providers should realize the appropriate Adaptor interface (e.g. a YahooStockQuoteOutputAdaptor should implement the OutputAdaptor interface). For each of the Managers, an interface is defined: such interface exposes the Manager functionality, on which other components within the DSE depend. For example, a Manager defined by the AbcManager interface, is associated to a class called DSEAbcManager which will provide an implementation for those tasks
- 3.2. Simple service execution illustrations
- The ExecutionManager seen at401 plays the role of being the coordinator during the service execution. For a given request, it will first ask the
InputManager 403 to process it. The latter, after performing an initial processing, will forward the request to theappropriate InputAdaptor 411 for further service-specific processing. The processed request is then handed-off to the ExecutionAdaptor seen at 425 that will perform the service execution. This step includes using the ProtocolManager/ProtocolAdaptor pair 409/411 to marshal the request into the form required by the underlying communication protocol between the DSE and the service provider. Additional service-specific logic can be embedded in theExecutionAdaptor 425 implementation. The raw response returned by the service provider is processed by the OutputManager/OutputAdaptor pair 405/413 and then finally returned to the service consumer. - 3.3. InputManager/DSEInputManager (IM)
- 3.3.1. Code layering/system services
-
InputManager 403 is the first step in the service execution flow coordinated by the ExecutionrManager. It is responsible for the processing of a service request. Such processing is available for all services and is meant to be service-independent. Responsibilities of theInputManager 403 include: optional request validation (based on user request), handling default values, hidden values, defining aliases addressing specific part of a service request, and finally invoking the InputAdaptor for service-specific processing. - 3.3.2. Concepts
- Each service specifies the XML-Schema to be used to compile service requests. Every service request is a XML document compliant with such supplied schema.
InputManager 403 processes request XML documents and, if necessary, make modifications to them. The input ofInputManager 403 is an XML document representing a service request compliant to the service request XML-Schema. Its output does not necessarily need to be compliant with the input XML schema. It is a choice left to the InputAdaptor to process the input request and to notify theInputManager 403 if such processing altered the structure of the input in a form that makes it not compliant to the schema. In the case of a schema-compliant transformation by theInputAdaptor 411, theInputManager 403 will revalidate the processed request before moving to the next execution steps. - The responsibilities of the
InputManager 403 are: - 3.3.2.1. Handling Default Values
- Service providers can also associate a default value to a given Xpath. For a given request, InputManager will check if the entities addressed by the Xpath have a value specified. For those XPaths that do not have consumer-supplied values, InputManager should use the specified default value and add it to the request. For a given Xpath, it is possible for the service provider to supply a set of default values. For each of these values a new element will be appended to the XML request document if no consumer-supplied value is found. InputManager will not handle default value options that are specified for Xpaths referring to container elements. Such construct can be used for handling parameters that are optional for the service consumer but required by the service provider.
- ProtocolAdaptor will use this facility of InputManager to adapt the service request to the specific needs of the communication protocol used by the service provider.
- 3.3.2.2. Optional Request Validation
- For a supplied request,
InputManager 403 will optionally validate the syntax of the service request to check its compliance to relative input XML-Schema. Such processing will happen after the default value processing described above. - 3.3.2.3. Invoking InputAdaptor
- For service-specific request processing,
InputManager 403 is responsible to create an instance of theappropriate InputAdaptor 411 and invoke its process method. Such processing should happen after the default-values processing.InputManager 403 is also responsible for revalidating the request syntax after the InputAdaptor processing. This validation is conditional on the nature of the transformation applied by the InputAdaptor. - 3.3.2.4. Aliases
- A service descriptor can also specify aliases for given XPaths in the service request. For a request processed by the InputAdaptor41 1, the Xpath refers to the processed request XML document and not the original service request. The entities addressed by those Xpaths are considered can then be addressed through the aliases. Other components, including execution adaptor and protocol adaptors, can then retrieve the values of these entities using the aliases.
- For Xpaths referring to elements in the XML tree that are not leaves (e.g. a set of elements of the same type, or container elements) it is up to the users of the aliases to apply the appropriate logic for handling their values.
- A service definition can contain the specification of hidden request parameters. Those are defined as aliases, which are not associated to any Xpath in the request. For each of these hidden parameters a value has to be specified. This construct is used for parameters that should be hidden to the service consumers and which, therefore, cannot be part of the service request.
- Aliases are particularly useful to model the inputs of HTML forms. For example, a HTTPProtocolAdaptor will use this facility of InputManager to map and flatten a service request into an query string (of content type application/x-www-form-urlencoded).
- In general, aliases are useful to flatten a hierarchical XML-based service request to a flat list of parameters required by some protocols, such as query string of the type application/x-www-form-urlencoded and JDBC statement binding parameters.
- 3.3.3. Architecture
- The InputManager interface defines all the APIs that are exposed to other components within the DSE. The DSEInputManager class will implement the interface and provide additional interfaces used only internally by itself.
- 3.3.4. Data structures
- The Input Manager's DSEInputManager interface works on the XML-documents representing service requests. DSEInputManager will use the standard Document Object Model (DOM) APIs for its operations.
- 3.4. InputAdaptor (IA)
- 3.4.1. Code layering/system services
-
InputAdaptor 411 is responsible for processing of a service request from a servicedependent point of view. Service providers can provide a class implementing the InputAdaptor interface and associate it to their service. Duringexecution InputManager 411 will create an instance for the supplied InputAdaptor and invoke its process method. - 3.4.2. Concepts
- InputAdaptors are optional for a service. If specified, they can process request XML documents and, if necessary, make modifications. The input of InputManager is an XML document representing a service request compliant to the service request XML-Schema. Its output does not necessarily need to be compliant with the input XML schema. InputAdaptor should notify the InputManager if their transformation results in a XML document that is not compliant to the service request XML-Schema.
- In addition, DSE includes with standard configurable InputAdaptors that can be reused by service providers:
- 3.4.2.1. XSLTInputAdaptor
- An XSLTInputAdaptor will transform a service request according to a supplied XSLT transformation. This InputAdaptor will be configurable through Adaptor XML-parameter specifying the XSLT transformation to be applied.
- 3.4.3. Architecture
- The InputAdaptor interface defines the interfaces that service providers have to implement when defining a custom service request processing logic.
- 3.5. ExecutionManager (EM)
- 3.5.1. Code layering/system services
- The
ExecutionManager 401 is responsible for the coordinating the service execution flow. It sits in the middle of DSE components and coordinates among them for completing the service execution process. A new instance of the ExecutionManager is created at the beginning of each service execution. ExecutionManager is supposed to be stateless with respect to service executions. A new instance of ExecutionManager will be created by the consumer request handler every time a new request is posted. - Notice that an ExecutionManager only handles one service request. Concurrent service requests by concurrent users and concurrent service requests by one user is discussed in later in connection with
- Communications of DSE to External Entities.
- 3.5.2. Concepts
- The ExecutionManager orchestrates the service execution among other DSE components. The input of the ExecutionManager is a processed service request while its output is a service response. The steps taken by the
ExecutionManager 401 during the service execution are: - 3.5.2.1. InputManager
- For a supplied request,
ExecutionManager 401 will first forward the request to theInputManager 403 for additional processing. - 3.5.2.2. ExecutionAdaptor
- In the second step, the processed request is forwarded to the
ExecutionAdaptor 425. Its responsibility is to get the request and optionally interact with theProtocolManager 409. Additional service-dependent logic can be implemented in theExecutionAdaptor 425. - 3.5.2.3. OuptutManager
- The raw response returned by the service provider is then fed to the
OutputManager 405 which will structure it accordingly to the response structure defined in the service descriptor. - 3.5.2.4. CacheManager
- Another responsibility of
ExecutionManager 401 is the coordination of service response caching through theCache Manager 407. That implies that theExecutionManager 401 is responsible check for the availability of cached service responses before executing a service. If such response is available, no service will be executed and the cached response will be returned to the client. The caching of the output response will be achieved through the services of theCacheManager 407. On a principle level,ExecutionManager 401 will askedCacheManager 407 to cache the services response by storing it into a map using the request as a key. The visibility of the cached response and its lifetime will be specified by the Service Administrator on a service base. Additionally the lifetime can be specified by the Service Provider on a request-base through an expiration date model. - 3.5.2.5. Architecture
- The ExecutionManager interface collects all the APIs that are exposed to other components within the DSE. The DSEExecutionManager class will implement such interface and provide additional interfaces used only internally to itself.
- 3.6. Execution Adaptor
- 3.6.1. Code layering/system services
- The
ExecutionAdaptor 425 is responsible for encapsulating the service-dependent behavior of a service execution. For a given service, its ExecutionAdaptor is specified in the service descriptor. Service providers can provide a class implementing the ExecutionAdaptor interface and associate it to their service. There can be only one ExecutionAdaptor for each service. TheExecutionAdaptor 425 is instantiated by theExecutionManager 401, which then delegates to it the responsibility of interacting with the ProtocolManager for reformatting the service request into a form suitable for the remote service provider. - 3.6.2. Concepts
-
ExecutionAdaptor 425 is a key component in the DSE framework as it has the ability of associating a complex behavior to a service execution. For example,ExecutionAdaptor 425 can be used to build compound services and encapsulate them into a single service. ExecutionAdaptor can also be used to define the logic for handling failover behavior where, if a service fails during its execution, a “compatible” back-up service can be invoked.ExecutionAdaptor 425 is the layer of the DSE offering service execution flexibility. The input of the ExecutionAdaptor is a service request while its output can be some response which will be further processed by OutputManager, or can be a structured service response. - For a given service, the service provider can build a specific ExecutionAdaptor. Through a set of APIs, ExecutionAdaptors will be able to access Adaptor parameters specified in the service descriptor. Through this facility, service providers have the option of building general purpose ExecutionAdaptors that are configurable through XML parameters in the service descriptor. In addition, DSE will ship with some pre-built ExecutionAdpators and it will also provide a set of tools to facilitate the creation of new ExecutionAdaptors. Each of the above options is described in details in the next sections.
- 3.6.2.1. Simple ExecutionAdaptor
- A simple ExecutionAdaptor is provided as a component of the DSE engine. It can be considered as a default Adaptor used by the ExecutionManager when no service-dependent Adaptor is specified. Its responsibility is limited to the interaction with the ProtocolManager for the correct service execution.
- 3.6.2.2. ExecutionAdaptors for Compound Services
- Compound services are defined as added-value services built on-top of other services. In general, their execution implies the execution of a set of services—which can happen in parallel mode, serial mode or in a mixture of the two—plus some additional processing/transformation on the requests/responses of the dependent services. DSE will support Compound Services through its ExecutionAdaptor layer. Developers of the ExecutionAdaptor will have access to the ServiceRegistry and will therefore be able to create the Service instances that they are dependent on. For each of these services they will be able to pipeline the output of one service into input of another one, maybe after doing some processing on it. They will have full flexibility in defining the logic of their Compound Service given the fact that ExecutionAdaptor are Java-based components.
- Tools Integration. To reduce the ramp-up time for service providers who wants to develop their ExecutionAdaptor, a set of tools may be provided with the DynamicServiceFramework. These tools enable a build process for Compound Service driven from a Graphical User Interface (GUI). From those tools, service providers should be able to specify:
- A. An execution flow for those services that they are building on top of, specifying their order of execution and the degree of parallel execution to be used (within the limitation of JServer); and
- B. Additional logic to connect those service together. This will be achieved through Java code snippets specified in the tools and then used by ExecutionAdaptor . Those snippets will offer full flexibility for the service providers to build any arbitrarily complex connecting logic for their services.
- Tools have the responsibility of collecting the information above and generate the Java code of an ExecutionAdaptor from there. The tools will assist the providers who want to provide compound services such as comparison services and federated search services.
- 3.6.2.3. Authentication to Service Providers
- ExecutionAdaptors are responsible of authenticating to the service providers. The actual authentication procedure is service-specific. ExecutionAdaptors will also rely on
ProtocolAdaptors 421 if the authentication is dependent on the protocol, e.g., JDBC. - 3.6.2.4. FailOver
- One of the functional requirements for the Dynamic Service Framework is the ability for service administrators to specify a list of back-up services to be executed if a service fails. The back-up services should be compatible with the original service—meaning that their input/output interfaces should be compliant to the same pair of XML-Schemas. When the execution of a service fails, the FailOver Adaptor (not shown) will also notify the administrator.
- The flexibility offered by the ExecutionAdaptor layer fits perfectly for modeling such behavior. Service administrator can build a new service out of a set of compatible services and specify the preferred priority order for their execution. An ExecutionAdaptor will then try to execute the first one, if it fails, move to the next one, and so on.
- Tools should also be able to facilitate the processing of creating of such a service. Tools should allow service administrators to create such a failover service through simple graphical interfaces.
- 3.6.2.5. Configurable ExecutionAdaptors
- ExecutionAdaptor developers are also given an additional level of flexibility. A section in the service descriptor is dedicated to ExecutionAdaptor parameters. Those XML-based parameters can be used to build a general-purpose ExecutionAdaptor that can be shared among several services. In fact, by using these parameters the ExecutionAdaptor can be configured according to the needs of each of the services.
- An interesting application of this facility would be to build a generic ExecutionAdaptor whose logic can be supplied through a JavaScript-like language as a one of its XML-based parameters. Through this option, developers would have access to all the syntax exposed through the scripting language used, thus having the possibility of expressing complex logic in a natural way.
- 3.6.3. Architecture
- From architecture prospective, ExecutionAdaptors are just defined by an interface. The DSE may be supplied with a simple implementation of the interface while most of the complex ExecutionAdaptors will be generated to meet special needs. In addition, the ExecutionAdaptor interface defines the interfaces that service providers have to implement when defining a custom service execution flow.
- 3.7. ProtocolManager (PM)
- 3.7.1. Code layering/system services
-
ProtocolManager 409 is responsible for handling ProtocolAdaptors. Its main function is to act as factory class for ProtocolAdaptors upon requests from theExecutionAdaptor 425.ExecutionManager 401 creates theProtocolManager 409 and then passes it to theExecutionAdaptor 425. - 3.7.2. Concepts
-
ProtocolManager 409 is organized as the factory class for ProtocolAdaptors. For a given service, it will instantiate the ProtocolAdaptor required by the supplied service. The input of the ProtocolManager is a service request while its output is a raw service response. - 3.7.3. Architecture
- The ProtocolManager interface collects all the APIs that are exposed to other components within the DSE. The DSEProtocolManager interface class implements such an interface and provides additional interfaces used only internally to this component.
- 3.8. ProtocolAdaptor (PA)
- 3.8.1. Code layering/system services
- ProtocolAdaptors seen at421 are low-level components abstracting the DSE engine from the communication protocol imposed by service providers thus creating an insulation layer between the DSE and the service provider. For a given service, its ProtocolAdaptor is specified in the service descriptor. There can only be one ProtocolAdaptor for each service. Service providers can provide a class implementing the ProtocolAdaptor interface and associate it to their service The ProtocolAdaptor is instantiated by the ProtocolManager.
- 3.8.2. Concepts
-
ProtocolAdaptor 421 offers an abstraction on the communication protocol imposed by service providers. The input of the ProtocolAdaptor is service request. This request is the outcome of the processing performed by the InputManager modules. The output of the ProtocolAdaptor is a general Java object encapsulating the raw response returned by the service provider. Such response will be finally processed by the OutputManager so that it will become compliant to the response XML-schema specified in the service descriptor. - ProtocolAdaptor have the following responsibilities:
- 3.8.2.1. Parameter Bindings
- ProtocolAdaptors should be able to bind a service request to the set of parameters expected by the service provider communication protocol. Such binding may require a transformation of the service request structure—which has been designed to be service-independent—into a form that is protocol-specific.
- For example, a service accepting an HTTP POST request will expect to have its input parameters specified using the conventional HTTP syntax: param1=value1=param2=value2. However, a service request, being represented through a XML document, can have a complex structure. It is the responsibility of the ProtocolAdaptor to “flatten” such request in an HTTP query string representation (of content type application/x-www-form-urlencoded). As described in Section 3.3.2.1 and 0, this can be achieved through the InputManager's aliases.
- A similar example is how ProtocolAdaptor can be used for the bind-parameters in SQL-based services. A service request can specify the values of the parameter, while a ProtocolAdaptor parameter in the service descriptor can be used to specify the query to be issued. ProtocolAdaptor can then create a SQL statement using the Adaptor parameter, bind the request parameters into the statement and finally execute the query.
- 3.8.2.2. Authentication to Service Providers
- Protocol Adaptors must be able to authenticate to service providers. The authentication can be an implicit authentication (automatic authentication upon request from the provider) or explicit authentication (the user of a ProtocolAdaptor issues an explicit authentication request).
- 3.8.2.3. Request Execution
- After the parameters binding, ProtocolAdaptor will open a “connection” to the service provider and simply submit the request in the appropriate form. If the submission is synchronous in nature then the ProtocolAdaptor will wait till the response comes back.
- 3.8.2.4. Raw Response
- The ProtocolAdaptor is responsible for “getting” a handle on the raw response returned by the service provider in the native format of the service provider. Such a “raw” response will be modeled as a general java.lang.Object because the format of the response depends on the native format used by the service provider. The format of this object is known by the OutputAdaptor, which will be then process it by casting it to the appropriate class (e.g. InputStream for HTTP-based services or ResultSet for Database services).
- Compound Services might not have a ProtocolAdaptor specified as they rely on the ProtocolAdaptors of their underlying services. DSE is preferably provided with two standard ProtocolAdaptors, HTTPProtocolAdaptor and OraProtocolAdaptor, that can configured and reused by service providers.
- 3.8.2.5. HTTPProtocolAdaptor
- The HTTPProtocolAdaptor will handle the communication between the DSE and service providers using HTTP protocol. Its Adaptor parameters will include the URL to be used, the HTTP method and other HTTP specific parameters.
- HTTPS protocol support may also be provided.
- 3.8.2.6. OraProtocolAdaptor
- The OraProtocolAdaptor will handle the communication for those services that publish information stored in Oracle databases. Its Adaptor parameters will include connection parameters such as SID and username/password as well as the SQL statement and its type to be used for accessing the information
- 3.8.2.7. Other standard adaptors
- Other adaptors which could be provided as standard components include those supporting LDAP, SMTP/IMAP, SOAP, ICE, BizTalk, etc.
- 3.8.3. Architecture
- From an architectural prospective, ProtocolAdaptors are defined by an interface. The DSE is preferably provided with standard ProtocolAdaptor implementations for the HTTP protocol and the Oracle database access. As mentioned those Adaptors will be configurable through the XML-based Adaptor parameters specified in the service descriptor
- 3.9. OutputManager (OM)
- 3.9.1. Code layering/system services
-
OutputManager 405 is the responsible for handling OutputAdaptors. Its main function is to act as factory class for OutputAdaptor s and to coordinate the communication between the ExecutionManager and the OutputAdaptor. The ExecutionManager creates the OutputManager and then calls it after the ExecutionAdaptor has completed its processing. - 3.9.2. Concepts
-
OutputManager 405 may be organized as factory class forOutputAdaptors 413. For a given service, it will instantiate theOutputAdaptor 413 required by the supplied service. The input for the OutputManager is the raw response returned by the service provider. The OutputManager will forward that raw response to the OutputAdaptor, which will use it to build a ServiceResponse compliant to the response XML-schema specified in the service descriptor. It is the responsibility of the OutputManager to validate the response returned by the OutputAdaptor to check that its syntax is compliant with that XML-schema. Such validation is optional and controlled by the OutputAdaptor. - 3.9.3. Architecture
- The OutputManager interface collects all the APIs that are exposed to other components within the DSE. The DSEOutputManager implements such an interface and provides additional interfaces used only internally to this component.
- 3.10. OutputAdaptor (OA)
- 3.10.1. Code layering system services
-
OutputAdaptor 413 is responsible for transforming the raw response returned by the service provider into the ServiceResponse structure. Such structure is defined in the response XML-schema specified in the service descriptor. OutputAdaptor are service-specific as they carry the knowledge of how the raw service response is structured (both syntactically and semantically). Service providers can provide a class implementing the OutputAdaptor interface and associate it to their services. OutputAdaptors are instantiated by the OutputManager, which will then forward to them the transform call for output transformation. - 3.10.2. Concepts
- The responsibility of OutputAdaptors is the transformation from the raw service response in the native format of the service provider to the standard service response defined by the output XML-Schema. For example, a web-based service may need an OutputAdaptor to transform the raw service response in HTML to an XML response conformed to the output XML-Schema defined by the service. A ServiceProvider has the choice of building a custom OutputAdaptor for their services and specifies it in the service descriptor. For compound services in that the outcome of the ExecutionAdaptor may be already formatted correctly, the default NULL OutputAdaptor can be used.
- The DSE preferably is provided with three configurable OutputAdaptors that can be reused by service providers:
- 3.10.2.1. HTMLOutputAdaptor
- HTMLOutputAdaptor will handle raw responses that are HTML formatted. It is responsibility of this OutputAdaptor to parse and scrape the HTML page for extracting useful1o content from it and package it in an XML response. There are currently two design options for this component. The first option is to build an HTMLOutputAdaptor that is configurable through the Adaptors XML-parameters. The other option is to delegate to the Tools the responsibility of generating the Java code for specialized HTMLOutputAdaptor for each given service.
- 3.10.2.2. XMLOutputAdaptor
- XMLOutputAdaptor will handle raw responses that are XML formatted. This OutputAdaptor may be configured through the Adaptor XML-parameter specifying an XSLT transformation. This transformation will be applied to the raw response to adapt it to the response XML-schema.
- 3.10.2.3. OraOutputAdaptor
- SQLOutputAdaptor will handle ResultSet returned from the execution of SQL statements. The design of this OutputAdaptor is similar to the XMLOutputAdaptor. An Adaptor XML-parameter may be used to specify an XSQL transformation to model the ResultSet into a XML document compliant to the response XML-schema.
- 3.10.2.4. Others
- Other standard OutputAdaptors can be provided, such as an LDAPOutputAdaptor.
- 3.10.3. Architecture
- From an architectural prospective, OutputAdaptors are defined by an interface.
- 4. SR Components
- 4.1. Functional Overview
- Services Registry, which forms part of the specification database shown at121 in FIG. 1, stores and manages all the services in a service engine. It provides facilities for registering a service, unregistering it, modifying it, and searching the registry for a set of services satisfying a given criteria. From a Service administration point of view, other requirements are:
- a. When a service is being updated, any service invocation of the same or dependent services has to be invalidated.
- b. Ability to register/unregister/update a set of services as a single transaction is desirable.
- c. Dependency tracking in service unregistration is desirable for compound services.
- d. Access control is preferably enforced by the registry. The Service Administrator should be able to decide whether a service can be accessible by consumers or not. For example, he can choose to expose the generic stock quote service to some consumers, but keeps Yahoo stock quote nor Bloomberg stock quote services inaccessible from any consumer. In addition, the access control mechanism should provide role-based access control for different service consumers.
- Facilities for bulk loading are also desirable, but only to a limited extent due to the size of the registry which is sized to anticipate at most on the order of thousands of services.
- 4.1.1. Code layering/system services/paths
- From an architecture perspective, the Services Registry is an independent component, shared by one or more service execution engines. In addition to services, the
specification database 121 also manages user profiles, which are described later. An execution engine logically accesses the registry whenever service information is needed. However, in practice most of the service access may be provided by the Services Registry cache at the execution engine. The architecture provides flexibility in scaling the service engine to a large amount of users (potentially geographically distributed) by simply adding additional service execution engines. The runtime performance of service access, on the other hand, will be satisfied by the cache. - The Services Registry exposes these features for any components that need to access some information about a service. For example, ExecutionManager will need to obtain the default values to preprocess the input request; client library will need to access the registry to lookup services. Any implementation details should be hidden and completely controlled by the registry module.
- 4.2. Component Description
- The central registry is preferably implemented using an LDAP directory, such as the Oracle Internet Directory (OID). See generally, LDAP: Programming Directory-Enabled Applications with Lightweight Directory Access Protocol by Tim Howes and Mark Smith, ISBN 1-57870-0000-0 (Macmillan Technical Publishing—1997). An LDAP directory has the following advantages over a conventional database for this -application:
- A. The LDAP directory based approach provides an open-standard based solution, increasing the appeal of the overall system.
- B. Existing users in a corporate LDAP directory can be reused.
- C. LDAP directory is optimized for read access by various applications in an organization, which fits our usage scenario.
- This section starts with discussing individual components, assuming caching does not exist. Finally, it discusses the service cache and its impact to the other components.
- 4.2.1. Service Modeling
- A service consists of a set of attributes, reflected by a service descriptor; a set of Java classes and dependent resources for various adaptors; reference to input and output schemas; and Service deployment parameters. The entire service may be stored in the LDAP directory (directory).
- The service descriptor is modeled by an objectClass (called orclDService for the rest of this document),which consists of a flat list of attributes. A instance of a service descriptor will then be realized as an entry in the directory that inherits from orclDService.
- The structure of the service descriptor is hierarchical while the structure of an objectClass is flat. Hence, the descriptor is flattened in the orclDService.
- Some attributes of the descriptor are composite and multi-valued in nature. For example, a descriptor can have multiple Input default value and alias elements. Each entry element consists of path, alias and default value. Such an attribute can only modeled by an opaque string. Multiple such opaque strings can be stored in an entry because an LDAP attribute can be multi-valued. An alternative can be having multiple sub entries.
- Input and Output schemas can again be modeled by an objectClass. Each schema may be realized as an entry in the directory that inherits from the objectClass. The objectClass may consist of an attribute that stores the identifier of the schema, an attribute storing the schema (in textual XML or some binary representation of the XML such as serialized Java DOM object), and possibly additional metadata.
- Similarly, the set of Java classes and resources, represented by a Jar file, can be stored modeled by an objectClass. The binaries can be stored in a binary opaque attribute. The only metadata that needs to be stored is the name of the Jar file.
- 4.2.2. Services Registry Structure
- Service descriptors are stored hierarchically, according to the categorization of the services defined by service administrators. As a result, each category may be modeled as an entry, consisting of the name of the category, additional descriptions and possibly other metadata. The root of the entire service descriptor tree may be defined by the service administrator.
- Input/output schemas may be stored directly under schema sub-tree of the directory.
- There is no additional hierarchy needed. Java classes Jars may be done in a similar fashion.
- 4.2.3. Service Access: Administration
- Service registration and unregistration is equivalent to adding and removing an entry to the directory. Service update is equivalent to modifying attributes of an entry.
- Transaction control is not specified by LDAP standard although OID guarantees that each modifying operation is atomic. However, registering/unregistering/updating a set of related services in a transaction is not possible with OID. Instead, service access administration logic enforces the transaction.
- 4.2.4. Access Control
- Access control is enforced the registry logic by rewriting the access query to a string by adding additional constraints based on access control information.
- The model is straightforward: A service consumer can either have the rights or not have the rights to access a service: listable in lookups, readable, and executable. Any more granular access is not necessary for the registry. Service Only administrators have the rights to register/unregister/ update services.
- Based on the model, the access control can be subdivided into two sub problems:
- a. Service Administrators should be able to grant accessibility for a particular service to all the consumers. This can be achieved through the addition of an additional boolean attribute toConsumer which is set to true only for a service that can be exposed to the consumers. The access control is then be enforced by the service engine logic with an additional filter of (toConsumer=true).
- b. Role-based access control for different service consumers.
- Based on the roles of a consumer, the consumer can access some subsets of the services. For example, a policy can be specified such that stockquote service is available to consumers with the role BUSINESS. This can be achieved through maintaining access control list in the user profile registry (Refer to Section 0 for more information) and enforcing the ACL by rewriting the service lookup.
- Furthermore, access control can also be granted/revoked on categories rather than individual services. For example, the service administrator should be able to allow only consumers with role A to access to all services under business:finance. However, category-based access control less important because of the limited size of the registry and the limited number of users of the service engine (a service consumer represents an application, rather than end users).
- 4.2.5. Service Cache
- The service cache is a specific cache provider of the representing the Services Registry.
- The service cache is used by the service access APIs. Service access components will first attempt to read the information from the cache through a query-rewrite layer to rewrite the query in the service cache form. If the information is not in the cache, the service access components will then read the information from the registries. In practice, to improve performance and avoid complication in accessing Java classes, the service cache may cache the entire Services Registry.
- Physically, service caches may be implemented as database tables, sitting in the same database as the service execution engine. The service descriptor subtree is represented by a descriptor table and a category table. The input/output schema subtree may be represented by a schema table. The Java classes Jars sub-tree is represented by the class tables of JServer.
- The lifetime of the cache is the lifetime of the service engine. When a service engine starts up, it populates the service cache (a prefetch operation using the terminology of the CacheManager). The service cache stays alive until the engine is shutdown. When there are updates occurred in the registry, an agent in the registry invalidates the old cache entries and populate the new entries to all affected service caches in all service execution engines.
- 5. UPR Components
- 5.1. Introduction
- The user profile registry is responsible for collecting information that is relative to the Dynamic Service Consumers. Service Consumers are defined as applications accessing the Dynamic Service Engine, therefore authenticating themselves to the engine. End users are to be considered as the users of the application built leveraging on Dynamic Services. Applications using Dynamic Services authenticate themselves to the Dynamic Services engine. For example. an application may authenticate itself to the Engine using a SC1/SC1 (ServiceConsumer1/ServiceConsumer1) username/password. At the same time, the Application may have its own clients, and it is the application's responsibility to manager those clients. The user profile registry is used to store information belonging to the SC 1 user.
- 5.2. Service Consumers Authentication
- Applications acting as Service Consumers authenticate to the Dynamic Service Engine to access and execute Services. For such purpose, Dynamic Services Framework may take advantage of the RDBMS authentication facilities. Through the APIs in the client library, Service Consumers will implicitly open a database connection to the Service Engine. The username and password to be supplied at connection opening will be agreed between the Service Administrator and the application developer. Service Administrator can also set service access control policies to be associated to each service consumers. Such policies will also be stored in the User Profile Registry.
- 5.3. User Profile Information
- There are three types of information and attributes that can be associated to the user profile registry:
- 1) DSE-private, meaning information that is shared across users. This is modeled through deployment service input parameters. An example of this would a service, which exposes the same username and password for all the Service Consumers of a Dynamic Services Engine.
- 2) User-private, meaning information that is likely to be valid for the entire life-cycle of the user. For example, let's imagine a service which wants to differentiate the service consumers using different user username/password for each of them.
- 3) Connection-private. For example dynamic cookies that are sent to the user during the service execution (e.g. to identify a shopping cart session).
- The User Profile Registry stores and manages user-private information only. Examples of this information include the username and password with respect to a specific service. The UserProfile Registry offers to Service Consumers facilities to store properties that are dependent on their clients, thus facilitating the management and mapping of application clients.
- 5.3.1. Notes on Connection-private information
- An example of Connection-private information is the HTTP cookies used by web sites for session management. The User Profile Registry does not manage dynamic session information such as HTTP cookies. Instead, such information will be returned to Service Consumers in the form of a Service Response header. Note that the User Profile registry and the Service Engine are stateless compared to the service execution.
- 5.4. Architecture
- The UserProfile Registry may be implemented as an LDAP directory which is the preferred mechanism to archive in a central repository the user information and share it across Dynamic Services Engine instances. Therefore even user credentials will be centrally managed in directory. The access performance may be improved by using caching on the Dynamic Service Engine. Clients will access the cached User Profiles reducing the number of access to the registry. The user profile registry provides the following interfaces:
- a. PropertyValue getPropertyValue(ServiceConsumer username, service name, application criteria, property name)
- b. setPropertyValue(ServiceCosumer username, service name, application criteria, property name, property value)
- We can notice that application code can specify additional optional criteria when storing and retrieving user profile parameters. This facility is particularly useful for managing attributes of application clients within the registry.
- 5.4.1. Notes on scalability
- The architecture proposed is particularly well designed for scalability with respect to increasing number of users. In fact, Service Consumers can authenticate to the Service Engine and then establish a connection pool. The scalability of this connection path is directly related to the scalability of Oracle8i with respect of the number of client connections. In addition, through the facilities provided by the User Profile Registry and exploiting the fact that the Engine is stateless, applications can use any connection in the pool with any of their client requests. In fact, is the architecture does NOT impose any one-to-one relationship between the application clients and the Service Consumers.
- 5.5. Authentication to Service Providers
- Three different scenarios can be used to perform authentication. In the first, the user's credentials are passed as part of the service request. In the second, all consumers for an engine may share the same credentials, which are stored as parameters of the service. In the third case, which is likely to be used the most, each consumer has his own credentials which are accessed through the User Profile Registry.
- 6. Communications of DSE to External Entities
- This chapter details the communication between a service engine and an external entity. In general, there are two types of external entities: the application logic of a service consumer, which needs to connect to a service engine, lookup a service, and execute a service; and the application logic of the tools for service administrators, which needs to perform additional administrative tasks such as registration and unregistration of services.
- All these external entities communicate to service engines using service engine client library. Since there are two types of external entities, there are two client libraries: service consumer client library and service administrator client library. The two client libraries, however, share the same common foundation to communicate with a service engine.
- This chapter starts with a description of the architecture of the communication between a service engine and client library common foundation. It then lists out the operations exposed by service consumer client library, followed by the listing of operations exposed by service administrator client library. After that, client library is discussed. Finally, future extensions and alternatives that have been discarded are present.
- 6.1. Communication between DSE and client library common foundation
- 6.1.1. Code layering/system services/paths
- The communication between a service engine and a client library common foundation is the interface exposed by the service engine to the outside world: External entities like service consumer application logic communicates with service engines using the appropriate client library, which in turn relies on the common foundation. Through the communication interface, service engine accepts requests and invokes appropriate components such as execution manager.
- 6.1.2. Requirements
- The communication interface must provide the infrastructure to enable the two different client libraries exposing the operations needed respectively; allow asynchronous communication so that calls to the engine will not block the caller; and maintain the scalability and efficiency of the system. Specifically, the service engine has to be scalable with respect to number of connections. What is more, within a connection, concurrency has to be maximized.
- 6.1.3. Concepts
- Service engines communicate with external world through message queues in the engine. When an external entity needs to perform a certain action, for example, executing a service, the client library common foundation will send a correspond message to the request queue. A request handler in the service engine will listen to the queue, fetch the request message, and invoke appropriate engine components, for example, execution manager. When the operation is done, service engine will post the response in the response queue. A listener in the client library common foundation will listen to the response queue, and invoke appropriate callback method.
- 6.1.3.1. Service Engine Connection Life Cycle
- When an external entity connects to a service engine, the client library common foundation opens a connection to the database instance where the service engine resides. The common foundation also performs other initialization: creating a connection to the Oracle Advanced Queuing service, creating the request and responses queues for the connection, setting up the request handler in the engine, and setting up the response listener for the external entity.
- With the connection established, the external entity can then perform various operations such as looking up and executing services. The client library common foundation will send a request message to its request queue in the engine. At request submission time, an object identifying the request message will be associated to the message to serve as the request identifier. The external entity receives the response by registering a callback method. In this architecture, client's calls to the engine do not block the client code.
- Listening to the request queue, the request handler in the engine will process the request message, and enqueue the response message in the response queue. The request handler is not committed to handle requests concurrently.
- The response listener at the external entity side (created at connection initialization time) will receive the responses sent by the engine. Based on the request identifier, the listener will invoke the appropriate callback method. Exceptions are treated as a special type of response: the response listener will be able to throw and create the appropriate exception correspondingly.
- When an external entity closes a connection to the engine, the client library common foundation closes the database connection The common foundation will also free up other connection-private resources, e.g., queues created and pending request/response messages.
- 6.1.4. Implementation Approach
- The message-based communication is built on top of the relational database queuing mechanism which, in the preferred embodiment, is Oracle Advanced Queuing (AQ) in the Oracle database. The mechanism uses the Java Messaging Service (JMS) interface exposed by AQ wherever applicable, to maximize interoperability. The JMS enqueue interface may be used to enqueue a message for both the clients and the request handlers. Similarly, the JMS MessageListener may be used to receive messages asynchronously.
- 6.1.4.1. Client-Side
- With the AQ-JMS based asynchronous interface, an external entity can send a request without any blocking. All it needs to supply is a callback method. AQ-based JMS MessageListener of the connection (managed by the client library common foundation) is responsible for listening for the response, which does not actively poll the network . The connection-private JMS MessageListener will dispatch the response to the appropriate callback method based on the request identifier.
- 6.1.4.2. Server-Side
- Similarly, the request handler in the engine is created as a JMS MessageListener, a static Java object in the connection's private Java Virtual Machine. It has to be static in order to receive any request in the lifetime of the connection.
- For each submitted request, a new thread will be created to handle it. In such a thread, a new instance of the ExecutionManager will coordinate the execution. Different requests made in a connection will thus be served by different threads.
- However, since service execution runs in Oracle JServer, which does not provide preemptive threads. The request handler will not be able to handle requests truly concurrently. As a result, while client's call is non-blocking and truly asynchronous, requests in the engine will be handled with only limited concurrency: When a service execution thread is idle in socket calls, another execution thread will be activated. A client can achieve a higher degree of concurrency by using more connections.
- In creating a connection to a service engine, a database connection will be obtained. A JMSConnection and a JMSSession will then be created based on the database connection at the client side. Connection-private (conceptually) queues will be created in JMSSession. The request handler in the engine will also be created, based on a JMSConnection/JMSSession created at the server side. All the logic will be captured in a Java Stored Procedure to minimize the complexity of the client library.
- 6.1.4.3. Scalability and Performance Requirement
- The presented architecture satisfies various requirements:
- a. Oracle AQ JMS based messaging architecture allows external entities to make calls to the engine without blocking.
- b. Connection private request handlers on top of Oracle JServer allows the service engine to leverage Oracle database's scalability with respect to the number of connections.
- c. For each connection, connection-private queues rather than sharing some global queues for a few reasons. First, connection private queues can avoid additional unnecessary complexity on selector to pick appropriate messages for a connection in a global queue. Second, it also gives better isolation of a connection from other connection. Finally, the overhead of creating queues is a one-time overhead during initialization for each connection. Typically, a connection is expected to exist for a long time so that the overhead in initialization will be relatively insignificant. See 6.3.2 for alternatives that have been discarded.
- d. Non pre-emptive threads used in handling the requests in a connection maximizes the concurrency within the connection. It is anticipated that the common scenario when a thread will be idle is making socket calls. Non pre-emptive threads provided by JServer provides the appropriate lightweight infrastructure to maximize the concurrency while minimizing the overhead introduced.
- 6.2. Client Library
- The communication interfaces between an engine and an external entity is defined by the client library. Since there are two types of external entities (consumers and administrators), there are two client libraries correspondingly. The interfaces are defined by the interactions listed out in the previous two sections. All complexities of messaging and connection initialization will be hidden from the users of the libraries.
- 6.3. Miscellaneous
-
- JDBC-based communication and AQ/JMS-based communication (which is also based on JDBC Connection) may be used between a client and an engine. An HTTP-based communication can optionally be implemented to facilitate communications through firewalls. The messaging interfaces are AQ/JMS-based, but the AQ/JMS interfaces may be implemented on top of HTTP. The communication that uses JDBC directly may be implemented using HTTP-POST request to Oracle Web Server.
- 6.3.2. Alternative realization of connection-private queues
- Connection-private request and response queues are again queues in AQ. There are various possible alternatives in realizing them. Broadly speaking, there are two dimensions of parameters:
- 1. A request queue and a response queue implemented as one physical queue with two selectors: one for the requests and one for the responses, versus each of them implemented as a physical queue.
- 2. A connection-private queue implemented as a physical queue created for the connection, versus the queue implemented as a global queue (across connections) with a specific selector for the connection.
- The possible combination then includes:
- a. Each connection-private queue is implemented as a physical queue, created for the connection.
- b. Connection-private request and response queues are implemented as one physical queue created for the connection, with two selectors.
- c. A connection-private request queue is implemented as a global request queue shared among all connections, with a selector to select messages specifically for the request of the connection. The connection-private response queue may then be implemented similarly.
- d. All connection-private queues are implemented by one global queue. Each connection then has two selectors: one selector for selecting request messages of the connection, and one selector for selecting the response messages of the connection.
- The request and response queues are preferably implemented using two physical queues private to the connection.
- 6.3.3. Alternative architectures
- In addition to the messaging-based architecture presented, an EJB-based architecture could be used. All interactions defined by messages can be represented by methods of a set of generic Dynamic Services EJBs. This architecture is less desirable because EJB specification does not provide asynchronous interface infrastructure and does not allow creation of threads either (so asynchronous behavior cannot be achieved by spawning threads in EJB server and returning the result through a callback function). Moreover, a messaging-based architecture permits the definition of a core subset of interfaces as messages. If there is a need to support other protocols between a client and an engine, the message definition provides the common foundation for implementing additional protocols.
- 7. System Services
- This chapter describes a set of high-level services shared and used by various components of the service engine. Some of the services will also be exposed to the users of the engine:
- service providers, service administrators, and service consumers.
- 7.1. Session Context The life-cycle of a Dynamic Service Consumer requires to open a connection to the Dynamic Service Engine at the beginning. Within such connection, Service Consumers can execute multiple services. Each of these services can actually create a session with the remote Service Provider. For example, a service connecting to a web site can receive as part of the response an HTTP cookie that has to be supplied with every following request.
- From the point of view of the Dynamic Service Engine, two types of sessions have to be handled. The first one is across service executions and the second is within a service execution.
- 7.1.1. Session within a Service Execution
- When executing a service, the ExcutionAdaptor is responsible for establishing the right execution flow for the service. Let's assume for example that a particular service requires to make a first round-trip to the service provider for authentication purposes and then to perform a second one to actually execute the service. If the communication protocol is HTTP based, the session between the two round-trips will be maintained through the usage of HTTP cookies. The ExecutionAdaptor will collect the cookie returned after the first round trip and then re-use it for the second request.
- As shown in the diagram below, ExecutionAdaptors will have access to facilities provided by the Dynamic Service engine to temporarily store session identifiers such as HTTP cookies. The lifetime of this storage will only be within one service execution and therefore will not span across multiple executions.
- 7.1.2. Sessions across Service Executions
- Dynamic Services Engine will not maintain sessions across Service Executions. Following our example of a Service Provider accessed through the HTTP protocol in a single round-trip, if the service provider returns a cookie, the latter will not be stored or managed by the Service Engine. The cookie, or any other protocol-specific session identifier, will be returned to the ServiceConsumers in the form of a response header. It this way the Service Engine stays state-less with the respect of Service Executions.
- 7.2. CacheManager (CM)
- A Cache Manager is made available within the Dynamic Services Framework. It does not need to have a semantic understanding of what is being cached but must be extensible in order to serve components including the Services Registry, service execution (responses), and even protocol adaptors. The caching for each one of the components is done in a relatively independent manner so that one component's cache will not interfere with another's. With this independence, different life cycles are achieved across different components. Two dimensions determine the life cycles of the caches; application (or module) specific expiration policies and general flushing policies. Currently there are three policies for general cache flushing; connection level caching where everything cached during a connection is flushed when the connection closes, engine level caching where everything cached during an uptime of the engine is flushed when the engine is shut down, and persistent caching where the cache is never flushed. If desired, caches can be purged manually via API calls.
- To achieve this extensibility, the Cache Manager should have a plug-in architecture that allows different plug-ins to augment it and allow it to cache for new components. These plug-ins contain the logic for semantically understanding what is being cached as well as the component specific expiration policy that will be enforced.
- 7.2.1. Code layering/system services
- The CacheManager is a component that will be shared across components that needs any caching functionalities. It is an extensible component, which can extend its provisions to new components through a plug-in architecture. The plug-ins are in the form of configuration files that contain specifications on information such as expiration policies and general cache flushing policies.
- 7.2.2. Concepts
- CacheManager operates with caching models and supports the models specified in the HTTP/1.1 protocol: Expiration Model and Validation Model—for more details on those policies please refer to the HTTP/1.1 specifications. The validation model corresponds to the general cache flushing policies described above. Service providers will be able to suggest caching policies to be used for their services. This implies that a section in the service descriptor will be dedicated to caching parameters. For example, those parameters can include the specification of an Xpath in the service response addressing the server-specified expiration time for that response.
- The visibility of the cache will be determined by the Service Administrator initially during registration time. Later he may alter this visibility by modifying the access control for users/consumers on the underlying storage solutions of the cache depending on the service.
- A concept related to caching is pre-fetching. Pre-fetching is a feature controlled by the service administrator rather than service providers. For each service, service administrators can specify a request and an execution time schedule. DSE will follow the supplied schedule to execute the service with the supplied request and then cache its response. Such feature will also have to behave consistently with the caching policy supplied by the service provider. Administrator Tools can help to suggest an optimal pre- fetching policy.
- A hash table like structure which may be implemented a database table may be maintained, where the cached results are hashed with keys that are component specific. For example, a context bundle can be used as a key to hash the service response for a certain service execution.
- 7.3. Event Manager and Related Services
- 7.3.1. Concepts
- 7.3.1.1. Event Manager
- The Event Manager is a component that tracks actions taken in the flow of an execution. In essence the engine should be able to make use of all this information for purposes of logging, billing, etc. The model followed should be one where it is possible for components interested in auditing, to add themselves as listeners to the EventManager. Components internal to the DSE will generate the events and post to the EventManager which will dispatch them to the appropriate listeners. Appropriate event classes should be used for each one of these actions. Events generated by the DSE will also contain information about the user that triggered the operation that generated them so that logging and billing logic can be applied on such information.
- 7.3.1.2. System Event-based Services
- The Event Manager interface exposed would give access to all of the events tracked/saved in a systematic manner. Other modules can be attached to the EventManager to make use of the information tracked by the EventManager. A set of modules providing some system services may be provided:
- a. Logging services can re-organize these events in some systematic way for use with other modules or even applications, e.g., third-party log analysis applications, system debugging and profiling report tools, etc.
- b. Billing services can use this information to track how much a consumer is using the services and therefore how he is to be billed accordingly. The billing module may provide an API to attach billing applications, e.g., Oracle iPayment, to the service engine.
- c. Notification services can notify administrators (or any other relevant personnel) certain system-generated events, e.g., service execution failure. It can provide an API to attach different notification methods, e.g., email, pager, short messaging, Oracle Enterprise Manager, etc.
- d. Trigger services allow administrators to execute administrator-defined services upon the occurrence of some events. For example, a user-quota service trigger can be activated before a service is invoked to audit resource allocation. An execution of a trigger is guaranteed to start at the same state as the event that triggers it.
- There are two types of triggers: passive triggers do not affect the execution flow of the logic that generates the event. Active triggers, on the other hand, can affect the execution flow of the logic that generates the event, e.g., a user resource auditing trigger can stop the execution of a service if the user has exhausted his quota.
- Technically, logging, billing and notification services are simply specific triggers. However, they are defined and provided by the engine while trigger services are services defined by individual administrator for their specific tasks.
- 7.3.1.3. Event Classes
- Different event-consuming modules are interested in different types of events. For example, logging services are generally interested in the all events while billing services are only interested in the service-execution-completion events. Hence, an events will be classified to one or more class(es) by different classification schemes. The classification schemes include:
- 1. ALL events: all events belong to the ALL event class. Logging services are interested in all events.
- 2. System-generated vs. user-generated events: The service engine will define and generate a fixed set of events while administrators and service providers can also define and generate other events in their plug-ins to the engine, e.g., a service-specific execution adaptor. Notification services only notify system-generated events.
- 3. Triggerable events: Some events represents a state that additional triggers can be attached in the execution flow, e.g., user-resource auditing trigger can be attached before the execution of a service. Some other events are purely informational and are not designed to invoke any triggers. Trigger services will only be interested in triggerable events.
- 4. Profile events are events generated for service execution performance profiling.
- Debug events are events generated to produce some system traces for debugging purposes.
- 7.3.1.4. Extensibility for the Users of the Engine
- While a set of system services are the clients of the EventManager, administrators may provide additional event-based services indirectly through defmed hooks: Trigger Services and Billing Services. Service Providers, on the other hand, can affect the event system by defining and posting additional events in service-specific adaptors. Service Consumers do not interact with the event system.
- 7.3.1.5. Implementation Approach
- During the regular service execution, components of the Dynamic Services Engine may post events about their operations to the EventManager. In practice, this can be done by having the Event Manager component receiving messages from these internal DSE components through queues.
- Components interested in certain events may register themselves to the EventManager and indicate the class of events they are interested in. The communication between the EventManager and the Listeners (e.g. LoggingListener) will be based on a publish-subscribe model based on AQ facility. Each component will run in its own dedicated connection to the engine. In this case, these components will be executed asynchronously.
- For components whose logic need to be executed immediately and synchronously upon the generation of an event, e.g., active triggers of the trigger service, they may register themselves as synchronous listener to the EventManager via the same publish-subscribe model. However, internally, they may be invoked synchronously (as opposed to asynchronously via messaging) by the EventManager upon the generation of the applicable events.
- 8. Common Infrastructure
- The following list of components may be shared by all the other components in the service engine.
- 8.1 Exception Handling
- Similar to response handling, error Handling may be performed by queuing and dequeuing error messages using AQ. The conceptual response queue is used for posting the error messages. Each error message is therefore be modeled as a special response message. Error messages materialize in the form of short XML documents whose type is deduced from a set of headers. The client library constructs a Java exception out of the message and return it to the clients.
- The error messages meet the following requirements:
- 1) Error messages reflect the source of the problem. That is, they also return the client-context supplied at request time in a fashion similar to the one discussed in Section 6.1.3.1.
- 2) Error messages indicate severity; the following are the prescribed levels of severity. The client library will interact with the response queues and upon receiving error messages, package them into Java exceptions are returned them to the clients.
- a. Warning: These error messages serve to warn the consumer that the execution of services following may behave abnormally after the occurrence of the warning.
- b. Error: These are error messages that stop the execution flow of the service.
- c. Fatal Error: They WILL stop execution flow, invalidating the client connection.
- 3) Error messages set provisions for service providers to embed service specific error details in these error messages. This is a way for service providers to “extend” our error handling mechanism. Such service specific error messages can be raised by the Adaptor's code, where service provider can add additional error condition check. These details can be simple or complex structured XML snippets that will be understandable by both the providers and the consumers.
- The following four types of error messages are supported:
- Application-to-Application (A2A): This type of error messages is thrown when a service specific error happens. This can take on several forms including but not limited to semantic errors in the request happening on the service provider side or any errors resulting from applying service provider-supplied adaptors.
- Application-to-Server (A2S): This type of error messages is thrown usually by the DSE. It entails errors that occurred before going to the service provider. As far as the consumer is concerned, either something went wrong on his side, or on the engine side. This type of errors include syntax errors where the request XML does not conform to the provided Input XML-Schema, as well as the engine's notification of updates letting consumers know that some specific service will be down. Specific cases of Application-to-Server errors are the Administrator related ones. They involve registration errors that could result only from calling the APIs that are accessible to the administrator.
- Server-to-DataSource (S2D): This type of error messages is the lowest level of errors. It occurs at the “transport” level when connection problems between the Engine and the service provider are encountered. This entails not only errors like having a proxy that is down, but also “File Not Found Exceptions” on the service provider side.
- In addition to the Request and Response queues that each consumer owns, an exception queue will be set up called DS Exception Queue, which will be a destination for error messages when they are thrown by the service engine, awaiting pickup by the consumers. Error messages materialize in the form of short XML documents whose type is deduced from a set of headers. If we have a separate queue just for the exception, then error message can be modeled as a unique type of messages. The solution is not desirable because for a submitted request, the client library will have to “monitor” two queues for a possible response. In fact, the response queue will be used if a correct response is returned and the error queue if the request fails. Hence, it is preferable to monitor only ONE queue and have the error message as a special response type.
- 9. Advanced Features
- Multiple Service Execution Engine: To provide additional scalability to a large number of users, a logical service engine can be implemented by a central registry (of users and services) and a set of service execution engines. The system can then be scaled by adding additional service execution engines. The central registry will not become a bottleneck because of the heavy use of caches at the service execution engine. What is more, if the users are geographically distributed, service execution engines can also be added to reduce the network traffic.
- Multiple Service Registries: In a distributed environment, the central Services Registry of a service engine can contain reference to services in the central Services Registry of another service engine. To improve performance, a central Services Registry will also cache these external references. This is useful for sharing service definitions among multiple engines. In a large organization, there can be multiple service engines serving different sub-organizations. A service that is primarily owned and managed by a sub-organization (represented by a service engine) can then be re-used by other sub-organizations without requiring the other suborganizations to duplicate the service (and hence the management of the service).
- Service Engine to Service Engine communication: In some B2B exchange or content syndication scenarios, a service engine can be also be a service provider to another service engine (when both parties are using providing their solutions based on Dynamic Services Framework). An optimized ProtocolAdaptor may be implemented to provide a fastpath communication between the two engines, improving the runtime performance of such systems.
- Integration with external schema registries: Various efforts are ongoing to provide global XML Schema registries, e.g., xml.org by OASIS and biztalk.org by Microsoft. The Service engine may also allow management of XML schemas via these external registries, including retrieval, insertion, deletion, etc. An API to external schema registries may be defined to allow external schema registries to be plugged-in. When there is a demand for integration with certain external schema registries, a plug-in can thus be provided without affecting the rest of the system.
- 10. Security
- Security consists of following components:
- a. Authentication: For services customer and services provider, authentication insures the Dynamic Services Engine is the entity the customer or provider wants to contact. For the Dynamic Services Engine, authentication means that it is connected to the expected service customer and/or service provider.
- b. Encryption: To secure the confidentiality of the data transmitted via public network.
- c. Integrity: To secure that the data cannot be modified while transmitted via public network.
- Access control is closely related to security, which concerns two aspects: the privilege to access a certain database table, or the authority to access, manage or execute the local files in the OS of the Dynamic Services Engine's host. After authentication, the DBMS or the OS knows who is the user. By granting the database privileges or file system authority to this user, the access control can be applied. In other words, for Dynamic Service Engine, access control can be implemented by Oracle DBMS functions, or the host's OS commands. There is no need for Dynamic Service Framework to provide additional access control.
- Although a fully-fledged security system consists of three components: authentication, encryption and integrity, for some connections only one or two security features are necessary. For example, if a certain service provider only requires authentication, then the dynamic engine will only have to authenticate itself to the service provider, but it may not encrypt its data to the service provider and it may not ensure the integrity of the transmitted data.
- There are many ways to implement the authentication, encryption and integrity. Dynamic Service Framework preferably offers two security features, (1) conventional login name/password method for authentication, (2) Secure Socket Layer (SSL) for authentication, encryption and integrity.
- The function libraries of Oracle Net8 and Oracle Advanced Security Option (ASO) offer Java APIs for the variety of encryption algorithms, certificate management, and SSL handshake etc. Other security options, like Kerberos authentication, may be used as well.
- There are two kinds of connections in the Dynamic Services Framework, the connection between a service consumer and the dynamic service engine, as well as the connection between the engine and a certain service provider. The system handle two types of connections, one is based on HTTP protocol and the other is JDBC connection, and implements the following four security options:
- 1. Conventional login/password authentication for HTTP.
- 2. Secure Sockets Layer for HTTP (HTTPS).
- 3. Conventional login/password authentication for JDBC connections.
- Secure Sockets Layer (SSL) for JDBC connections.
- It is to be understood that the specific embodiment of the invention which has been described is merely illustrative of one application of the principles of the invention. Numerous modifications may be made by those skilled in the art without departing from the true spirit and scope of the invention
Claims (28)
1. A method for invoking the performance of a designated service by a service provider in response to a request from a requester sent to said service provider via a network, said method comprising, in combination, the steps of:
storing a description of said designated service at a location accessible to said requester, said description comprising, in combination:
an input description specifying the content of an acceptable input message which may be received by said service provider to initiate the performance of said designated service;
a designation of a unique network address to which said input message is to be sent to invoke the performance of said designated service, and
an output description specifying the content of each output message produced by said service provider during the performance of said designated service,
transmitting a request message that conforms to said input description via said network to said unique network address,
performing said designated service at said service provider in response to the receipt of said request message to generate a response conforming to said output description, and
returning said response via said network to said service consumer.
2. The method set forth in claim 1 wherein said description of said designated service is expressed in Extended Markup Language.
3. The method as set forth in claim 1 wherein said request message is expressed in Extended Markup Language.
4. The method as set forth in claim 3 wherein said request message is expressed in Extended Markup Language and wherein said method further includes the step of validating the content of said request message to verify that it conforms to said description.
5. The method as set forth in claim 1 wherein at least one of said output messages is expressed in Extended Markup Language.
6. The method as set forth in claim 1 wherein at least one of said output messages is expressed in Extended Markup Language and wherein said method further includes the step of validating said at least one output message to verify that it conforms to said description.
7. The method as set forth in claim 4 wherein at least one of said output messages is expressed in Extended Markup Language and wherein said method further includes the step of validating said at least one output message to verify that it conforms to said description.
8. The method as set forth in claim 1 wherein said output description specifying the content of each output message produced by said service provider during the performance of said designated service includes the specification of the content of at least one error message that is produced when an error condition is experienced during the performance of said designated service.
9. The method as set forth in claim 8 wherein said error message is expressed in Extended Markup Language.
10. The method as set forth in claim 9 wherein said output description specifying the content of each output message produced by said service provider during the performance of said designated service includes the specification of the content of at least one error message expressed in Extended Markup Language that is produced when an error condition is experienced during the performance of said designated service.
11. The method as set forth in claim 1 wherein said step of storing a description of said designated service comprises the steps of
establishing a registration database for storing a plurality of service descriptions each of which describes an available service and each of which conforms to a predetermined service description format specification, and
storing said designated service description in said database.
12. The method set forth in claim 11 further including the step of generating a listing of available services specified by said plurality of service descriptions in response to a listing request.
13. A system for invoking the performance of a selected one of a plurality of diverse services via the Internet, said system comprising, in combination:
a database coupled to the Internet for storing a description of each of said services, each of said descriptions describing a designated service and comprising:
an input description specifying the content of an input message that may be received and used by said designated service to perform said designated service;
a designation of the unique Internet address to which said input message is to be directed to invoke the performance of said designated service, and
an output description specifying the content of each output message produced by the performance of said designated service,
first processing means at a client location for executing an application program that includes means for transmitting a request message that conforms to said input description to said Internet address, and
second processing at said Internet address for performing said designated service in response to the receipt of said request message to generate a response conforming to said output description and to return said response via the Internet to said first processing means.
14. The system set forth in claim 13 wherein each of said descriptions is expressed in Extended Markup Language in a predetermined format.
15. The system as set forth in claim 14 wherein said request message is expressed in Extended Markup Language.
16. The system as set forth in claim 15 wherein at least one of said output messages is expressed in Extended Markup Language.
17. The system set forth in claim 16 further including registration means coupled to said database for accepting new descriptions of additional services and for storing said new descriptions in said database.
18. The system as set forth in claim 17 wherein said output description includes the specification of the content of at least one error message that is produced when an error condition is experienced during the performance of said designated service.
19. The system as set forth in claim 18 further including means for verifying that said request message conforms to said input description for said designated service.
20. The system as set forth in claim 19 further including means for verifying that said response conforms to said output description for said designated service.
21. The system as set forth in claim 20 further including means coupled to said database and responsive to listing request for generating a listing of said plurality of diverse services.
22. A system for performing a programmatic data exchange via the Internet between a consumer application executing on a client computer and a selected one of a plurality of different service applications, at least some of which are performed by computers located remotely from said client computer and connected to said client computer via the Internet, said system comprising, in combination,
a registry database coupled to the Internet, said registry database comprising, in combination:
registration means for storing in said registry database a service description which specifies, for each given one of said service applications:
the content and format of an input message which may be received and processed by said given one of said service applications;
the Internet address to which said input message is to be sent in order to invoke the operation of said given one of said service applications; and
the content and format of any output messages which are produced by the operation of said given one of said service applications;
means responsive to a listing request received from a list requester for returning a listing of said plurality of different service applications to said list requester; and
means responsive to a service description request received from a service description requester for returning a designated one of said service descriptions to said service requester; and
interface means for integrating the operation of said consumer application with said selected one of said service applications, said interface means comprising:
means for transmitting a listing request to said registry database and for receiving in response thereto a listing of said plurality of different service applications;
means for transmitting a description request to said registry database and for receiving in response thereto a description of said selected one of said service applications;
means for forming an input message that conforms to said selected service description,
means for transmitting said input message via the Internet to the Internet address specified in said selected service description; and
means for receiving a responsive output message via the Internet from said selected one of said service applications and for supplying data contained therein to said consumer application.
23. The system set forth in claim 22 wherein said each of said service descriptions is expressed in Extended Markup Language in a predetermined format.
24. The system as set forth in claim 23 wherein said input message is expressed in Extended Markup Language.
25. The system as set forth in claim 24 said output messages are expressed in Extended Markup Language.
26. The system as set forth in claim 25 wherein at least one of said output messages is an error message produced when an error condition is experienced during the performance of said given service.
27. The system as set forth in claim 25 further including means for verifying that said request message conforms to the content and format specified for an input message in the description for said given service.
28. The system as set forth in claim 26 further including means for verifying that said responsive output message conforms to the content and format specified for an output message in the description for said given service.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/120,175 US20020120685A1 (en) | 1999-06-01 | 2002-04-10 | System for dynamically invoking remote network services using service descriptions stored in a service registry |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13700699P | 1999-06-01 | 1999-06-01 | |
US09/584,318 US7472349B1 (en) | 1999-06-01 | 2000-05-31 | Dynamic services infrastructure for allowing programmatic access to internet and other resources |
US10/120,175 US20020120685A1 (en) | 1999-06-01 | 2002-04-10 | System for dynamically invoking remote network services using service descriptions stored in a service registry |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/584,318 Division US7472349B1 (en) | 1999-06-01 | 2000-05-31 | Dynamic services infrastructure for allowing programmatic access to internet and other resources |
Publications (1)
Publication Number | Publication Date |
---|---|
US20020120685A1 true US20020120685A1 (en) | 2002-08-29 |
Family
ID=40138596
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/584,318 Expired - Lifetime US7472349B1 (en) | 1999-06-01 | 2000-05-31 | Dynamic services infrastructure for allowing programmatic access to internet and other resources |
US10/120,175 Abandoned US20020120685A1 (en) | 1999-06-01 | 2002-04-10 | System for dynamically invoking remote network services using service descriptions stored in a service registry |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/584,318 Expired - Lifetime US7472349B1 (en) | 1999-06-01 | 2000-05-31 | Dynamic services infrastructure for allowing programmatic access to internet and other resources |
Country Status (1)
Country | Link |
---|---|
US (2) | US7472349B1 (en) |
Cited By (325)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020019824A1 (en) * | 2000-04-12 | 2002-02-14 | International Business Machines Corporation | Method to generically describe and manipulate arbitrary data structures |
US20020062448A1 (en) * | 2000-10-26 | 2002-05-23 | Seiko Epson Corporation | Service providing system, service providing terminal, client terminal, and storage medium |
US20020078094A1 (en) * | 2000-09-07 | 2002-06-20 | Muralidhar Krishnaprasad | Method and apparatus for XML visualization of a relational database and universal resource identifiers to database data and metadata |
US20020078068A1 (en) * | 2000-09-07 | 2002-06-20 | Muralidhar Krishnaprasad | Method and apparatus for flexible storage and uniform manipulation of XML data in a relational database system |
US20020120750A1 (en) * | 2001-02-16 | 2002-08-29 | Michael Nidd | Method, network device and computer program product for performing service discovery in a pervasive network |
US20020120704A1 (en) * | 2000-11-28 | 2002-08-29 | Karp Alan H. | Computer language for defining business conversations |
US20020133808A1 (en) * | 2000-11-10 | 2002-09-19 | Adam Bosworth | Cell based data processing |
US20020143820A1 (en) * | 2000-10-04 | 2002-10-03 | Van Eaton James R. | Methods and systems for generating a viewable document using view descriptors and generic view stylesheets |
US20020161688A1 (en) * | 2000-02-16 | 2002-10-31 | Rocky Stewart | Open market collaboration system for enterprise wide electronic commerce |
US20020188869A1 (en) * | 2001-06-11 | 2002-12-12 | Paul Patrick | System and method for server security and entitlement processing |
US20030004771A1 (en) * | 2001-06-28 | 2003-01-02 | International Business Machines Corporation | Method, system, and program for executing a workflow |
US20030005406A1 (en) * | 2001-06-28 | 2003-01-02 | International Business Machines Corporation | Method, system, and program for using objects in data stores during execution of a workflow |
US20030004770A1 (en) * | 2001-06-28 | 2003-01-02 | International Business Machines Corporation | Method, system, and program for generating a workflow |
US20030023662A1 (en) * | 2001-07-30 | 2003-01-30 | International Business Machines Corporation | Method, system, and program for enabling access to a plurality of services |
US20030023476A1 (en) * | 2001-06-29 | 2003-01-30 | Incidentreports, Inc. | System and method for recording and using incident report data |
US20030023615A1 (en) * | 2001-07-25 | 2003-01-30 | Gabriel Beged-Dov | Hybrid parsing system and method |
US20030023773A1 (en) * | 2001-07-30 | 2003-01-30 | International Business Machines Corporation | Method, system, and program for performing workflow related operations |
US20030028669A1 (en) * | 2001-07-06 | 2003-02-06 | Alcatel | Method and system for routing logging a request |
US20030093403A1 (en) * | 2001-10-18 | 2003-05-15 | Mitch Upton | System and method for implementing an event adapter |
US20030093436A1 (en) * | 2001-09-28 | 2003-05-15 | International Business Machines Corporation | Invocation of web services from a database |
US20030101190A1 (en) * | 2001-03-14 | 2003-05-29 | Microsoft Corporation | Schema-based notification service |
US20030120665A1 (en) * | 2001-05-25 | 2003-06-26 | Joshua Fox | Run-time architecture for enterprise integration with transformation generation |
US20030126558A1 (en) * | 2001-10-24 | 2003-07-03 | Griffin Philip B. | System and method for XML data representation of portlets |
US20030131073A1 (en) * | 2001-03-14 | 2003-07-10 | Lucovsky Mark H. | Schema-based services for identity-based data access |
US20030154356A1 (en) * | 2002-02-13 | 2003-08-14 | Ibrahim Kamel | Efficient service management in home gateways |
US20030191769A1 (en) * | 2001-09-28 | 2003-10-09 | International Business Machines Corporation | Method, system, and program for generating a program capable of invoking a flow of operations |
US20030191824A1 (en) * | 2002-04-03 | 2003-10-09 | Raghav Rao | Installation of network services in an embedded network server |
US20030200319A1 (en) * | 2002-04-19 | 2003-10-23 | Bodine Gregory L. | System and method for interfacing with existing system management products or software solutions |
US20030204756A1 (en) * | 1997-02-12 | 2003-10-30 | Ransom Douglas S. | Push communications architecture for intelligent electronic devices |
US20030212673A1 (en) * | 2002-03-01 | 2003-11-13 | Sundar Kadayam | System and method for retrieving and organizing information from disparate computer network information sources |
US20030225729A1 (en) * | 2002-05-31 | 2003-12-04 | American Express Travel Related Services Company, Inc. | System and method for facilitating information collection, storage, and distribution |
US20030233397A1 (en) * | 2002-06-12 | 2003-12-18 | Seapass Solutions Inc. | Interface development environment and interface for connecting systems having different data structures |
US20040006550A1 (en) * | 2002-05-02 | 2004-01-08 | Mitch Upton | System and method for enterprise application interactions |
US20040006663A1 (en) * | 2002-05-01 | 2004-01-08 | David Wiser | System and method for storing large messages |
US20040015859A1 (en) * | 2002-05-02 | 2004-01-22 | Timothy Potter | Systems and methods for modular component deployment |
US20040034859A1 (en) * | 2002-05-02 | 2004-02-19 | Timothy Potter | Shared common connection factory |
US20040049481A1 (en) * | 2002-05-01 | 2004-03-11 | Mike Blevins | Systems and methods for business process plug-in development |
US20040059966A1 (en) * | 2002-09-20 | 2004-03-25 | International Business Machines Corporation | Adaptive problem determination and recovery in a computer system |
US20040060044A1 (en) * | 2002-09-20 | 2004-03-25 | International Business Machines Corporation | Method and apparatus for automatic updating and testing of software |
US20040060002A1 (en) * | 2002-09-12 | 2004-03-25 | Microsoft Corporation | Schema-based service for identity-based access to lists |
US20040059704A1 (en) * | 2002-09-20 | 2004-03-25 | International Business Machines Corporation | Self-managing computing system |
US20040059810A1 (en) * | 2002-09-20 | 2004-03-25 | International Business Machines Corporation | Method and apparatus for publishing and monitoring entities providing services in a distributed data processing system |
US20040068728A1 (en) * | 2002-05-02 | 2004-04-08 | Mike Blevins | Systems and methods for collaborative business plug-ins |
US20040078440A1 (en) * | 2002-05-01 | 2004-04-22 | Tim Potter | High availability event topic |
US20040107183A1 (en) * | 2002-12-03 | 2004-06-03 | Jp Morgan Chase Bank | Method for simplifying databinding in application programs |
US6766313B1 (en) * | 2000-07-12 | 2004-07-20 | Microsoft Corporation | System and method for caching and retrieving information |
US20040162642A1 (en) * | 2000-11-28 | 2004-08-19 | Marcus Gasper | Thin client power management system and method |
US20040162906A1 (en) * | 2003-02-14 | 2004-08-19 | Griffin Philip B. | System and method for hierarchical role-based entitlements |
US20040167899A1 (en) * | 2003-02-20 | 2004-08-26 | Bea Systems, Inc. | Virtual content repository browser |
US20040168153A1 (en) * | 2003-02-26 | 2004-08-26 | Bea Systems, Inc. | Systems and methods for dynamic component versioning |
US6789077B1 (en) * | 2000-05-09 | 2004-09-07 | Sun Microsystems, Inc. | Mechanism and apparatus for web-based searching of URI-addressable repositories in a distributed computing environment |
US20040187127A1 (en) * | 2003-02-25 | 2004-09-23 | Albert Gondi | Systems and methods for transaction chaining |
US20040193329A1 (en) * | 1994-12-30 | 2004-09-30 | Ransom Douglas S. | System and method for securing energy management systems |
US20040199636A1 (en) * | 2001-09-28 | 2004-10-07 | International Business Machines Corporation | Automatic generation of database invocation mechanism for external web services |
US20040210836A1 (en) * | 2003-03-03 | 2004-10-21 | Canon Kabushiki Kaisha | Method of offering a service provided by a server computer in a communication network |
US20040215725A1 (en) * | 2003-03-31 | 2004-10-28 | Lorraine Love | System and method for multi-platform queue queries |
US20040215700A1 (en) * | 2002-12-26 | 2004-10-28 | Michael Shenfield | System and method for building and execution of platform-neutral generic services' client applications |
US20040220952A1 (en) * | 2002-08-29 | 2004-11-04 | Bea Systems, Inc. | Web service gateway generation |
US20040230955A1 (en) * | 2003-02-26 | 2004-11-18 | Bea Systems, Inc. | System for multi-language debugging |
US20040236780A1 (en) * | 2003-02-25 | 2004-11-25 | Michael Blevins | Systems and methods for client-side filtering of subscribed messages |
US20040250241A1 (en) * | 2003-02-26 | 2004-12-09 | O'neil Edward K. | System and method for dynamic data binding in distributed applications |
US20040254824A1 (en) * | 2003-01-07 | 2004-12-16 | Alex Loucaides | System and method for process scheduling |
US20050010902A1 (en) * | 2003-02-25 | 2005-01-13 | Bea Systems, Inc. | Systems and methods extending an existing programming language with constructs |
US20050022164A1 (en) * | 2003-02-25 | 2005-01-27 | Bea Systems, Inc. | Systems and methods utilizing a workflow definition language |
US20050034104A1 (en) * | 2003-02-26 | 2005-02-10 | Bea Systems, Inc. | Method for multi-language debugging |
US20050030555A1 (en) * | 2003-05-16 | 2005-02-10 | Phenix John Kevin | Job processing framework |
US20050044173A1 (en) * | 2003-02-28 | 2005-02-24 | Olander Daryl B. | System and method for implementing business processes in a portal |
US6862594B1 (en) * | 2000-05-09 | 2005-03-01 | Sun Microsystems, Inc. | Method and apparatus to discover services using flexible search criteria |
US20050055358A1 (en) * | 2000-09-07 | 2005-03-10 | Oracle International Corporation | Apparatus and method for mapping relational data and metadata to XML |
US20050065743A1 (en) * | 2003-03-31 | 2005-03-24 | Cumming Daniel A. | Methods and apparatus for retrieving energy readings from an energy monitoring device |
US20050071344A1 (en) * | 2003-09-30 | 2005-03-31 | International Business Machines Corporation | Dynamic generation of XML schema for backend driven data validation |
US20050086330A1 (en) * | 2003-08-29 | 2005-04-21 | Michael Perham | Method and apparatus for dynamic, non-intrusive personalization of web services |
US20050108682A1 (en) * | 2003-02-26 | 2005-05-19 | Bea Systems, Inc. | Systems for type-independent source code editing |
US20050114771A1 (en) * | 2003-02-26 | 2005-05-26 | Bea Systems, Inc. | Methods for type-independent source code editing |
US20050119990A1 (en) * | 2003-07-10 | 2005-06-02 | Lee Patrick R. | System and method for customizing a data display using a presentation profile |
US20050138208A1 (en) * | 2003-12-17 | 2005-06-23 | International Business Machines Corporation | Service oriented integration server architecture |
US20050144437A1 (en) * | 1994-12-30 | 2005-06-30 | Ransom Douglas S. | System and method for assigning an identity to an intelligent electronic device |
US20050144174A1 (en) * | 2003-12-31 | 2005-06-30 | Leonid Pesenson | Framework for providing remote processing of a graphical user interface |
US20050165815A1 (en) * | 2000-06-06 | 2005-07-28 | Groove Networks, Inc. | Method and apparatus for efficient management of XML documents |
US20050165776A1 (en) * | 2004-01-14 | 2005-07-28 | International Business Machines Corporation | Method and apparatus for validating and configuring database transaction requests from multiple clients |
US20050210004A1 (en) * | 2004-03-18 | 2005-09-22 | International Business Machines Corporation | Method and apparatus for generating query and response statements at runtime from generic requests |
US20050210053A1 (en) * | 2004-03-18 | 2005-09-22 | International Business Machines Corporation | Method and apparatus for splitting and merging request and response data at runtime |
US20050228827A1 (en) * | 2004-04-13 | 2005-10-13 | Bea Systems, Inc. | System and method for viewing a virtual content repository |
US20050234889A1 (en) * | 2001-05-25 | 2005-10-20 | Joshua Fox | Method and system for federated querying of data sources |
US20050234849A1 (en) * | 2004-04-13 | 2005-10-20 | Bea Systems, Inc. | System and method for content lifecycles |
US20050234942A1 (en) * | 2004-04-13 | 2005-10-20 | Bea Systems, Inc. | System and method for content and schema lifecycles |
US20050240863A1 (en) * | 2003-02-25 | 2005-10-27 | Olander Daryl B | System and method for structuring distributed applications |
US20050251504A1 (en) * | 2004-04-13 | 2005-11-10 | Bea Systems, Inc. | System and method for custom content lifecycles |
US20050251512A1 (en) * | 2004-04-13 | 2005-11-10 | Bea Systems, Inc. | System and method for searching a virtual content repository |
US20050262362A1 (en) * | 2003-10-10 | 2005-11-24 | Bea Systems, Inc. | Distributed security system policies |
US20050262522A1 (en) * | 2004-05-21 | 2005-11-24 | Paul Gassoway | Method and apparatus for reusing a computer software library |
US6988025B2 (en) | 2000-11-28 | 2006-01-17 | Power Measurement Ltd. | System and method for implementing XML on an energy management device |
US20060028252A1 (en) * | 2004-04-13 | 2006-02-09 | Bea Systems, Inc. | System and method for content type management |
US20060031763A1 (en) * | 2003-03-22 | 2006-02-09 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method relating to access of information |
US20060031586A1 (en) * | 2004-04-26 | 2006-02-09 | Jp Morgan Chase Bank | System and method for routing messages |
US20060052921A1 (en) * | 2002-11-07 | 2006-03-09 | Bodin William K | On-demand system for supplemental diagnostic and service resource planning for mobile systems |
US20060059003A1 (en) * | 2004-08-20 | 2006-03-16 | Nokia Corporation | Context data in UPNP service information |
US20060059252A1 (en) * | 2002-12-18 | 2006-03-16 | Michiaki Tatsubori | Web service providing system, server device for the same, control method for controlling computer system as server device for web service providing system, program for executing the control method, and recording medium |
US7028028B1 (en) * | 2001-05-17 | 2006-04-11 | Enosys Markets,Inc. | System for querying markup language data stored in a relational database according to markup language schema |
US7028223B1 (en) * | 2001-08-13 | 2006-04-11 | Parasoft Corporation | System and method for testing of web services |
US20060123101A1 (en) * | 2004-11-22 | 2006-06-08 | Veradasys, Inc. | Application instrumentation and monitoring |
US20060136473A1 (en) * | 2004-12-20 | 2006-06-22 | Lamb James A | Service data organization |
US20060136436A1 (en) * | 2004-12-22 | 2006-06-22 | At&T Corp. | Arrangement enabling thin client to access and present data in custom defined reports |
US20060143267A1 (en) * | 2000-09-28 | 2006-06-29 | Bea Systems, Inc. | System for managing logical process flow in an online environment |
US20060156387A1 (en) * | 2005-01-10 | 2006-07-13 | Google Inc. | Methods and systems for opportunistic cookie caching |
US20060174132A1 (en) * | 2003-02-20 | 2006-08-03 | Bea Systems, Inc. | Federated management of content repositories |
US7089330B1 (en) * | 2000-09-28 | 2006-08-08 | I2 Technologies Us, Inc. | System and method for transforming custom content generation tags associated with web pages |
EP1691303A1 (en) * | 2005-02-09 | 2006-08-16 | Deutsche Post AG | Method and system for controlling the access to multiple data systems |
EP1691302A1 (en) * | 2005-02-09 | 2006-08-16 | Deutsche Post AG | Method and system for controlling the access to data systems |
US20060184826A1 (en) * | 2005-02-11 | 2006-08-17 | Microsoft Corporation | Using a description language to build a management system |
US20060184878A1 (en) * | 2005-02-11 | 2006-08-17 | Microsoft Corporation | Using a description language to provide a user interface presentation |
US20060195453A1 (en) * | 2003-03-12 | 2006-08-31 | Microsoft Corporation | Customization of process logic in a software system |
US20060235840A1 (en) * | 2005-04-19 | 2006-10-19 | Anand Manikutty | Optimization of queries over XML views that are based on union all operators |
US7127328B2 (en) | 1994-12-30 | 2006-10-24 | Power Measurement Ltd. | System and method for federated security in an energy management system |
US20060248467A1 (en) * | 2005-04-29 | 2006-11-02 | Microsoft Corporation | Framework for declarative expression of data processing |
US7134072B1 (en) * | 1999-10-13 | 2006-11-07 | Microsoft Corporation | Methods and systems for processing XML documents |
US20060277189A1 (en) * | 2005-06-02 | 2006-12-07 | Microsoft Corporation | Translation of search result display elements |
US7158981B2 (en) | 2001-09-28 | 2007-01-02 | Oracle International Corporation | Providing a consistent hierarchical abstraction of relational data |
US20070011167A1 (en) * | 2005-07-08 | 2007-01-11 | Muralidhar Krishnaprasad | Optimization of queries on a repository based on constraints on how the data is stored in the repository |
US20070033571A1 (en) * | 2005-08-02 | 2007-02-08 | Sap Ag | Dynamic work center |
US20070033196A1 (en) * | 2005-08-02 | 2007-02-08 | Sap Ag | Service directory |
US20070038649A1 (en) * | 2005-08-11 | 2007-02-15 | Abhyudaya Agrawal | Flexible handling of datetime XML datatype in a database system |
US7185342B1 (en) * | 2001-07-24 | 2007-02-27 | Oracle International Corporation | Distributed service aggregation and composition |
US20070074066A1 (en) * | 2002-05-01 | 2007-03-29 | Bea Systems, Inc. | High availability for event forwarding |
US20070083538A1 (en) * | 2005-10-07 | 2007-04-12 | Roy Indroniel D | Generating XML instances from flat files |
US20070083529A1 (en) * | 2005-10-07 | 2007-04-12 | Oracle International Corporation | Managing cyclic constructs of XML schema in a rdbms |
US20070106815A1 (en) * | 2005-11-09 | 2007-05-10 | Computer Associates Think, Inc. | System and method for routing directory service operations in a directory service network |
WO2007056766A2 (en) * | 2005-11-09 | 2007-05-18 | Computer Associates Think, Inc. | System and method for efficient directory performance using non-persistent storage |
US20070118632A1 (en) * | 2005-11-09 | 2007-05-24 | Computer Associates Think, Inc. | System and method for providing a directory service network |
US20070150598A1 (en) * | 2002-05-02 | 2007-06-28 | Bea Systems, Inc. | System and method for providing highly available processing of asynchronous service requests |
US20070162439A1 (en) * | 2001-03-27 | 2007-07-12 | Bea Systems, Inc. | Reconfigurable query generation system for web browsers |
US20070162466A1 (en) * | 2005-05-20 | 2007-07-12 | International Business Machines Corporation | Algorithm to marshal/unmarshal XML schema annotations to SDO dataobjects |
US7281245B2 (en) * | 2002-06-05 | 2007-10-09 | Microsoft Corporation | Mechanism for downloading software components from a remote source for use by a local software application |
US7296056B2 (en) | 2001-07-30 | 2007-11-13 | International Business Machines Corporation | Method, system, and program for selecting one user to assign a work item in a workflow |
US20070288138A1 (en) * | 2002-08-29 | 2007-12-13 | Bodin William K | Anticipatory Mobile System Service Brokering and Resource Planning from Multiple Providers |
US20070294056A1 (en) * | 2006-06-16 | 2007-12-20 | Jpmorgan Chase Bank, N.A. | Method and system for monitoring non-occurring events |
US20070294386A1 (en) * | 2002-09-20 | 2007-12-20 | Rajarshi Das | Composition Service for Autonomic Computing |
US20080005093A1 (en) * | 2006-07-03 | 2008-01-03 | Zhen Hua Liu | Techniques of using a relational caching framework for efficiently handling XML queries in the mid-tier data caching |
US20080046328A1 (en) * | 2006-08-15 | 2008-02-21 | Microsoft Corporation | Automated acquisition and configuration of goods and services via a network |
US20080046569A1 (en) * | 2006-08-15 | 2008-02-21 | Microsoft Corporation | System and method to identify, rank, and audit network provided configurables |
US20080046550A1 (en) * | 2006-08-15 | 2008-02-21 | Microsoft Corporation | Message based network transmission for selection and auditing of internet services |
US20080071726A1 (en) * | 2006-09-18 | 2008-03-20 | Emc Corporation | Cascaded discovery of information environment |
US20080091711A1 (en) * | 2003-07-02 | 2008-04-17 | Snodgrass Ryan J | Predictive prefetching to improve parallelization of document generation subtasks |
US7366712B2 (en) * | 2001-05-31 | 2008-04-29 | Intel Corporation | Information retrieval center gateway |
US20080109292A1 (en) * | 2006-11-03 | 2008-05-08 | Sap Ag | Voice-enabled workflow item interface |
US7376746B2 (en) | 2003-04-10 | 2008-05-20 | Hitachi, Ltd. | Method and program for disclosing and providing services on network |
US20080177785A1 (en) * | 2003-08-07 | 2008-07-24 | Prager Scott H | System, and program product for rebasing an application |
US20080201776A1 (en) * | 2007-02-21 | 2008-08-21 | Hewlett Packard Company | Method And Computing System For Avoiding Denial Of Service Attacks |
US20080215710A1 (en) * | 2002-03-20 | 2008-09-04 | Tadashi Takeuchi | Contents distributing method and distributing system |
WO2008112103A1 (en) * | 2007-03-07 | 2008-09-18 | Ianywhere Solutions, Inc. | Selectively updating web pages on a mobile client |
US20080235710A1 (en) * | 2007-03-21 | 2008-09-25 | International Business Machines Corporation | Distributed Pluggable Middleware Services |
US20080288315A1 (en) * | 2002-11-07 | 2008-11-20 | William Kress Bodin | Location Based Services Revenue Sharing and Cost Offsetting |
US7516121B2 (en) | 2004-06-23 | 2009-04-07 | Oracle International Corporation | Efficient evaluation of queries using translation |
US7523131B2 (en) | 2005-02-10 | 2009-04-21 | Oracle International Corporation | Techniques for efficiently storing and querying in a relational database, XML documents conforming to schemas that contain cyclic constructs |
US7546370B1 (en) | 2004-08-18 | 2009-06-09 | Google Inc. | Search engine with multiple crawlers sharing cookies |
US20090157628A1 (en) * | 2007-09-28 | 2009-06-18 | Xcerion Ab | Network operating system |
US20090164500A1 (en) * | 2007-12-20 | 2009-06-25 | Ankur Mathur | System for providing a configurable adaptor for mediating systems |
US20090198765A1 (en) * | 2003-01-23 | 2009-08-06 | Verdasys, Inc. | Digital asset usage accountability via event journaling |
US20090300063A1 (en) * | 2001-01-09 | 2009-12-03 | Tim Neil | Software, devices and methods facilitating execution of server-side applications at mobile devices |
US7650592B2 (en) | 2003-03-01 | 2010-01-19 | Bea Systems, Inc. | Systems and methods for multi-view debugging environment |
US7653930B2 (en) | 2003-02-14 | 2010-01-26 | Bea Systems, Inc. | Method for role and resource policy management optimization |
US7664742B2 (en) | 2005-11-14 | 2010-02-16 | Pettovello Primo M | Index data structure for a peer-to-peer network |
US7668806B2 (en) | 2004-08-05 | 2010-02-23 | Oracle International Corporation | Processing queries against one or more markup language sources |
US20100056043A1 (en) * | 2007-12-21 | 2010-03-04 | Ibiquity Digital Corporation | Radio Service Registry |
US7676538B2 (en) | 2002-05-02 | 2010-03-09 | Bea Systems, Inc. | Systems and methods for application view transactions |
US7698427B2 (en) | 2001-07-30 | 2010-04-13 | International Business Machines Corporation | Method, system, and program for transferring data from an application engine |
US7707496B1 (en) | 2002-05-09 | 2010-04-27 | Microsoft Corporation | Method, system, and apparatus for converting dates between calendars and languages based upon semantically labeled strings |
US7707564B2 (en) | 2003-02-26 | 2010-04-27 | Bea Systems, Inc. | Systems and methods for creating network-based software services using source code annotations |
US7707024B2 (en) | 2002-05-23 | 2010-04-27 | Microsoft Corporation | Method, system, and apparatus for converting currency values based upon semantically labeled strings |
US7712024B2 (en) | 2000-06-06 | 2010-05-04 | Microsoft Corporation | Application program interfaces for semantically labeling strings and providing actions based on semantically labeled strings |
US7711550B1 (en) | 2003-04-29 | 2010-05-04 | Microsoft Corporation | Methods and system for recognizing names in a computer-generated document and for providing helpful actions associated with recognized names |
US7716492B1 (en) | 2000-05-09 | 2010-05-11 | Oracle America, Inc. | Method and apparatus to obtain service capability credentials |
US7716163B2 (en) | 2000-06-06 | 2010-05-11 | Microsoft Corporation | Method and system for defining semantic categories and actions |
US7716676B2 (en) | 2002-06-25 | 2010-05-11 | Microsoft Corporation | System and method for issuing a message to a program |
US20100125666A1 (en) * | 2008-11-14 | 2010-05-20 | Microsoft Corporation | Service facade design and implementation |
US7725560B2 (en) | 2002-05-01 | 2010-05-25 | Bea Systems Inc. | Web service-enabled portlet wizard |
US7730123B1 (en) | 2005-12-20 | 2010-06-01 | At&T Intellectual Property Ii, Lp | Software application implemented using services from a services repository generated using a target services roadmap |
US7739228B1 (en) | 2005-12-20 | 2010-06-15 | At&T Intellectual Property Ii, L.P. | Method of generating a services repository using a target services roadmap |
US7739588B2 (en) | 2003-06-27 | 2010-06-15 | Microsoft Corporation | Leveraging markup language data for semantically labeling text strings and data and for providing actions based on semantically labeled text strings and data |
US20100153604A1 (en) * | 2000-06-20 | 2010-06-17 | Palmsource, Inc. | Data exchange between a handheld device and another computer system using an exchange manager via synchronization |
US7742048B1 (en) | 2002-05-23 | 2010-06-22 | Microsoft Corporation | Method, system, and apparatus for converting numbers based upon semantically labeled strings |
US7743060B2 (en) | 2004-01-26 | 2010-06-22 | International Business Machines Corporation | Architecture for an indexer |
US20100161778A1 (en) * | 2008-12-22 | 2010-06-24 | Sap Ag | On-demand provisioning of services running on embedded devices |
US20100169488A1 (en) * | 2008-12-31 | 2010-07-01 | Sap Ag | System and method of consolidated central user administrative provisioning |
US7752634B1 (en) * | 2003-08-29 | 2010-07-06 | International Business Machines Corporation | Non-intrusive personalization of web services |
US7752205B2 (en) | 2005-09-26 | 2010-07-06 | Bea Systems, Inc. | Method and system for interacting with a virtual content repository |
US7757168B1 (en) * | 2000-04-07 | 2010-07-13 | Xerox Corporation | Meta-document and method of managing |
US7770102B1 (en) | 2000-06-06 | 2010-08-03 | Microsoft Corporation | Method and system for semantically labeling strings and providing actions based on semantically labeled strings |
US7774601B2 (en) | 2004-04-06 | 2010-08-10 | Bea Systems, Inc. | Method for delegated administration |
US7778816B2 (en) | 2001-04-24 | 2010-08-17 | Microsoft Corporation | Method and system for applying input mode bias |
US7783614B2 (en) | 2003-02-13 | 2010-08-24 | Microsoft Corporation | Linking elements of a document to corresponding fields, queries and/or procedures in a database |
US7783626B2 (en) | 2004-01-26 | 2010-08-24 | International Business Machines Corporation | Pipelined architecture for global analysis and index building |
US7788590B2 (en) | 2005-09-26 | 2010-08-31 | Microsoft Corporation | Lightweight reference user interface |
US7788602B2 (en) | 2000-06-06 | 2010-08-31 | Microsoft Corporation | Method and system for providing restricted actions for recognized semantic categories |
US7797310B2 (en) | 2006-10-16 | 2010-09-14 | Oracle International Corporation | Technique to estimate the cost of streaming evaluation of XPaths |
US7802180B2 (en) | 2004-06-23 | 2010-09-21 | Oracle International Corporation | Techniques for serialization of instances of the XQuery data model |
US7810036B2 (en) | 2003-02-28 | 2010-10-05 | Bea Systems, Inc. | Systems and methods for personalizing a portal |
US7818344B2 (en) | 2005-09-26 | 2010-10-19 | Bea Systems, Inc. | System and method for providing nested types for content management |
US7827546B1 (en) * | 2002-06-05 | 2010-11-02 | Microsoft Corporation | Mechanism for downloading software components from a remote source for use by a local software application |
US7840614B2 (en) | 2003-02-20 | 2010-11-23 | Bea Systems, Inc. | Virtual content repository application program interface |
US7890484B1 (en) * | 2004-11-10 | 2011-02-15 | At&T Intellectual Property Ii, L.P. | Method and apparatus for selecting services based on behavior models |
US7917537B2 (en) | 2005-09-26 | 2011-03-29 | Oracle International Corporation | System and method for providing link property types for content management |
US7930277B2 (en) | 2004-04-21 | 2011-04-19 | Oracle International Corporation | Cost-based optimizer for an XML data repository within a database |
US7949941B2 (en) | 2005-04-22 | 2011-05-24 | Oracle International Corporation | Optimizing XSLT based on input XML document structure description and translating XSLT into equivalent XQuery expressions |
US7953734B2 (en) | 2005-09-26 | 2011-05-31 | Oracle International Corporation | System and method for providing SPI extensions for content management system |
US7958112B2 (en) | 2008-08-08 | 2011-06-07 | Oracle International Corporation | Interleaving query transformations for XML indexes |
US7966665B1 (en) | 2007-11-16 | 2011-06-21 | Open Invention Network, Llc | Compliance validator for restricted network access control |
US7992085B2 (en) | 2005-09-26 | 2011-08-02 | Microsoft Corporation | Lightweight reference user interface |
US8015572B2 (en) | 2002-02-22 | 2011-09-06 | Oracle International Corporation | Systems and methods for an extensible software proxy |
US8024397B1 (en) * | 2005-12-20 | 2011-09-20 | At&T Intellectual Property Ii, L.P. | System for generating a services repository using a target services roadmap |
US20110238837A1 (en) * | 2010-03-26 | 2011-09-29 | Fujitsu Limited | Method and System for Providing Services |
US20110238935A1 (en) * | 2010-03-29 | 2011-09-29 | Software Ag | Systems and/or methods for distributed data archiving |
US8051188B2 (en) | 2002-09-05 | 2011-11-01 | Canon Kabushiki Kaisha | Method of proposing a service via a description document of such a service |
US8073841B2 (en) | 2005-10-07 | 2011-12-06 | Oracle International Corporation | Optimizing correlated XML extracts |
US8117264B1 (en) * | 2002-10-07 | 2012-02-14 | Yahoo! Inc. | Email system |
US8135796B1 (en) | 2000-05-09 | 2012-03-13 | Oracle America, Inc. | Mechanism and apparatus for accessing and addressing services in a distributed computing environment |
US8135772B2 (en) | 2002-05-01 | 2012-03-13 | Oracle International Corporation | Single servlets for B2B message routing |
US8136025B1 (en) | 2003-07-03 | 2012-03-13 | Google Inc. | Assigning document identification tags |
US8229932B2 (en) | 2003-09-04 | 2012-07-24 | Oracle International Corporation | Storing XML documents efficiently in an RDBMS |
US8271498B2 (en) | 2004-09-24 | 2012-09-18 | International Business Machines Corporation | Searching documents for ranges of numeric values |
US8285724B2 (en) | 2004-01-26 | 2012-10-09 | International Business Machines Corporation | System and program for handling anchor text |
US8296304B2 (en) | 2004-01-26 | 2012-10-23 | International Business Machines Corporation | Method, system, and program for handling redirects in a search engine |
US20130013804A1 (en) * | 2011-07-07 | 2013-01-10 | Ipc Systems, Inc. | Protocol agnostic notification system |
US8391884B2 (en) * | 2009-03-26 | 2013-03-05 | Andrew Llc | System and method for managing created location contexts in a location server |
US20130060797A1 (en) * | 2011-09-07 | 2013-03-07 | Paul Saunier | Data transformation method and system |
US8417693B2 (en) | 2005-07-14 | 2013-04-09 | International Business Machines Corporation | Enforcing native access control to indexed documents |
US8463852B2 (en) | 2006-10-06 | 2013-06-11 | Oracle International Corporation | Groupware portlets for integrating a portal with groupware systems |
US20130198828A1 (en) * | 2012-01-31 | 2013-08-01 | Eric Addkison Pendergrass | Application-access authentication agent |
US8548938B2 (en) | 2001-05-25 | 2013-10-01 | International Business Machines Corporation | Business rules for configurable metamodels and enterprise impact analysis |
US8572576B2 (en) | 2001-03-14 | 2013-10-29 | Microsoft Corporation | Executing dynamically assigned functions while providing services |
US8620938B2 (en) | 2002-06-28 | 2013-12-31 | Microsoft Corporation | Method, system, and apparatus for routing a query to one or more providers |
US8621639B1 (en) * | 2006-09-28 | 2013-12-31 | Whitehat Security, Inc. | Using fuzzy classification models to perform matching operations in a web application security scanner |
US8631028B1 (en) | 2009-10-29 | 2014-01-14 | Primo M. Pettovello | XPath query processing improvements |
US8694510B2 (en) | 2003-09-04 | 2014-04-08 | Oracle International Corporation | Indexing XML documents efficiently |
US8706708B2 (en) | 2002-06-06 | 2014-04-22 | Microsoft Corporation | Providing contextually sensitive tools and help content in computer-generated documents |
US8819212B1 (en) * | 2007-09-28 | 2014-08-26 | Emc Corporation | Delegation of data classification using common language |
US8831966B2 (en) | 2003-02-14 | 2014-09-09 | Oracle International Corporation | Method for delegated administration |
US8868720B1 (en) | 2007-09-28 | 2014-10-21 | Emc Corporation | Delegation of discovery functions in information management system |
US8959058B1 (en) * | 2004-09-02 | 2015-02-17 | Symantec Corporation | Linking dynamic computer data protection to an external state |
US9031908B1 (en) * | 2009-03-31 | 2015-05-12 | Symantec Corporation | Method and apparatus for simultaneous comparison of multiple backup sets maintained in a computer system |
US9141658B1 (en) | 2007-09-28 | 2015-09-22 | Emc Corporation | Data classification and management for risk mitigation |
US9171100B2 (en) | 2004-09-22 | 2015-10-27 | Primo M. Pettovello | MTree an XPath multi-axis structure threaded index |
US20160098491A1 (en) * | 2014-10-02 | 2016-04-07 | Institute For Information Industry | Service provider system and service provider method |
US9323901B1 (en) | 2007-09-28 | 2016-04-26 | Emc Corporation | Data classification for digital rights management |
US9367642B2 (en) | 2005-10-07 | 2016-06-14 | Oracle International Corporation | Flexible storage of XML collections within an object-relational database |
US9374437B2 (en) * | 2010-12-30 | 2016-06-21 | Sap Se | Schema validation proxy |
US9461890B1 (en) | 2007-09-28 | 2016-10-04 | Emc Corporation | Delegation of data management policy in an information management system |
TWI577155B (en) * | 2015-08-28 | 2017-04-01 | Chunghwa Telecom Co Ltd | Network service management system and method |
US20170124632A1 (en) * | 2012-02-17 | 2017-05-04 | Ebay Inc. | Electronic commerce file system |
US9734222B1 (en) | 2004-04-06 | 2017-08-15 | Jpmorgan Chase Bank, N.A. | Methods and systems for using script files to obtain, format and transport data |
US9886309B2 (en) | 2002-06-28 | 2018-02-06 | Microsoft Technology Licensing, Llc | Identity-based distributed computing for device resources |
US20180046630A1 (en) * | 2016-08-12 | 2018-02-15 | Invensys Systems, Inc. | Storing and identifying content through content descriptors in a historian system |
US9922031B2 (en) | 2005-11-09 | 2018-03-20 | Ca, Inc. | System and method for efficient directory performance using non-persistent storage |
US10191982B1 (en) | 2009-01-23 | 2019-01-29 | Zakata, LLC | Topical search portal |
US20190155629A1 (en) * | 2014-09-30 | 2019-05-23 | Amazon Technologies, Inc. | Low latency computational capacity provisioning |
US10482513B1 (en) | 2003-09-02 | 2019-11-19 | Vinimaya, Llc | Methods and systems for integrating procurement systems with electronic catalogs |
US10528574B2 (en) | 2009-01-23 | 2020-01-07 | Zakta, LLC | Topical trust network |
US10599500B2 (en) | 2017-09-30 | 2020-03-24 | Oracle International Corporation | API registry in a container platform for automatically generating client code libraries |
US10643178B1 (en) | 2017-06-16 | 2020-05-05 | Coupa Software Incorporated | Asynchronous real-time procurement system |
US10652201B1 (en) * | 2015-05-04 | 2020-05-12 | EMC IP Holding Company LLC | Cloud service registry |
US10725752B1 (en) | 2018-02-13 | 2020-07-28 | Amazon Technologies, Inc. | Dependency handling in an on-demand network code execution system |
US10733085B1 (en) | 2018-02-05 | 2020-08-04 | Amazon Technologies, Inc. | Detecting impedance mismatches due to cross-service calls |
US10776091B1 (en) | 2018-02-26 | 2020-09-15 | Amazon Technologies, Inc. | Logging endpoint in an on-demand code execution system |
US10776171B2 (en) | 2015-04-08 | 2020-09-15 | Amazon Technologies, Inc. | Endpoint management system and virtual compute system |
CN111797340A (en) * | 2020-06-10 | 2020-10-20 | 浙江大学 | Service packaging system for user-defined extraction flow |
US10824484B2 (en) | 2014-09-30 | 2020-11-03 | Amazon Technologies, Inc. | Event-driven computing |
US10831898B1 (en) | 2018-02-05 | 2020-11-10 | Amazon Technologies, Inc. | Detecting privilege escalations in code including cross-service calls |
CN111930474A (en) * | 2020-07-30 | 2020-11-13 | 杭州当虹科技股份有限公司 | Concurrency limiting method of single service interface based on java atomic operation |
US10853112B2 (en) | 2015-02-04 | 2020-12-01 | Amazon Technologies, Inc. | Stateful virtual compute system |
US10861069B2 (en) | 2010-12-02 | 2020-12-08 | Coupa Software Incorporated | Methods and systems to maintain, check, report, and audit contract and historical pricing in electronic procurement |
US10884812B2 (en) | 2018-12-13 | 2021-01-05 | Amazon Technologies, Inc. | Performance-based hardware emulation in an on-demand network code execution system |
US10884802B2 (en) | 2014-09-30 | 2021-01-05 | Amazon Technologies, Inc. | Message-based computation request scheduling |
US10884722B2 (en) | 2018-06-26 | 2021-01-05 | Amazon Technologies, Inc. | Cross-environment application of tracing information for improved code execution |
US10884787B1 (en) | 2016-09-23 | 2021-01-05 | Amazon Technologies, Inc. | Execution guarantees in an on-demand network code execution system |
US10891145B2 (en) | 2016-03-30 | 2021-01-12 | Amazon Technologies, Inc. | Processing pre-existing data sets at an on demand code execution environment |
US10908927B1 (en) | 2019-09-27 | 2021-02-02 | Amazon Technologies, Inc. | On-demand execution of object filter code in output path of object storage service |
US10915371B2 (en) | 2014-09-30 | 2021-02-09 | Amazon Technologies, Inc. | Automatic management of low latency computational capacity |
US10942795B1 (en) | 2019-11-27 | 2021-03-09 | Amazon Technologies, Inc. | Serverless call distribution to utilize reserved capacity without inhibiting scaling |
US10949237B2 (en) | 2018-06-29 | 2021-03-16 | Amazon Technologies, Inc. | Operating system customization in an on-demand network code execution system |
US10956185B2 (en) | 2014-09-30 | 2021-03-23 | Amazon Technologies, Inc. | Threading as a service |
US10996961B2 (en) | 2019-09-27 | 2021-05-04 | Amazon Technologies, Inc. | On-demand indexing of data in input path of object storage service |
US11010188B1 (en) | 2019-02-05 | 2021-05-18 | Amazon Technologies, Inc. | Simulated data object storage using on-demand computation of data objects |
US11016815B2 (en) | 2015-12-21 | 2021-05-25 | Amazon Technologies, Inc. | Code execution request routing |
US11023416B2 (en) | 2019-09-27 | 2021-06-01 | Amazon Technologies, Inc. | Data access control system for object storage service based on owner-defined code |
US11023311B2 (en) | 2019-09-27 | 2021-06-01 | Amazon Technologies, Inc. | On-demand code execution in input path of data uploaded to storage service in multiple data portions |
US11030332B1 (en) * | 2015-04-13 | 2021-06-08 | Wells Fargo Bank, N.A. | Database controlled web service type architecture |
US11055112B2 (en) | 2019-09-27 | 2021-07-06 | Amazon Technologies, Inc. | Inserting executions of owner-specified code into input/output path of object storage service |
US11099917B2 (en) | 2018-09-27 | 2021-08-24 | Amazon Technologies, Inc. | Efficient state maintenance for execution environments in an on-demand code execution system |
US11099870B1 (en) | 2018-07-25 | 2021-08-24 | Amazon Technologies, Inc. | Reducing execution times in an on-demand network code execution system using saved machine states |
US11106477B2 (en) | 2019-09-27 | 2021-08-31 | Amazon Technologies, Inc. | Execution of owner-specified code during input/output path to object storage service |
US11115404B2 (en) | 2019-06-28 | 2021-09-07 | Amazon Technologies, Inc. | Facilitating service connections in serverless code executions |
US11119809B1 (en) | 2019-06-20 | 2021-09-14 | Amazon Technologies, Inc. | Virtualization-based transaction handling in an on-demand network code execution system |
US11119826B2 (en) | 2019-11-27 | 2021-09-14 | Amazon Technologies, Inc. | Serverless call distribution to implement spillover while avoiding cold starts |
US11126469B2 (en) | 2014-12-05 | 2021-09-21 | Amazon Technologies, Inc. | Automatic determination of resource sizing |
US11132213B1 (en) | 2016-03-30 | 2021-09-28 | Amazon Technologies, Inc. | Dependency-based process of pre-existing data sets at an on demand code execution environment |
US11146569B1 (en) | 2018-06-28 | 2021-10-12 | Amazon Technologies, Inc. | Escalation-resistant secure network services using request-scoped authentication information |
US11159528B2 (en) | 2019-06-28 | 2021-10-26 | Amazon Technologies, Inc. | Authentication to network-services using hosted authentication information |
US11182505B2 (en) | 2017-05-31 | 2021-11-23 | Intuit Inc. | System for managing transactional data |
US11190609B2 (en) | 2019-06-28 | 2021-11-30 | Amazon Technologies, Inc. | Connection pooling for scalable network services |
US11188391B1 (en) | 2020-03-11 | 2021-11-30 | Amazon Technologies, Inc. | Allocating resources to on-demand code executions under scarcity conditions |
US11243953B2 (en) | 2018-09-27 | 2022-02-08 | Amazon Technologies, Inc. | Mapreduce implementation in an on-demand network code execution system and stream data processing system |
US11243819B1 (en) | 2015-12-21 | 2022-02-08 | Amazon Technologies, Inc. | Acquisition and maintenance of compute capacity |
US11250007B1 (en) | 2019-09-27 | 2022-02-15 | Amazon Technologies, Inc. | On-demand execution of object combination code in output path of object storage service |
US11263220B2 (en) | 2019-09-27 | 2022-03-01 | Amazon Technologies, Inc. | On-demand execution of object transformation code in output path of object storage service |
US11354169B2 (en) | 2016-06-29 | 2022-06-07 | Amazon Technologies, Inc. | Adjusting variable limit on concurrent code executions |
US11360948B2 (en) | 2019-09-27 | 2022-06-14 | Amazon Technologies, Inc. | Inserting owner-specified data processing pipelines into input/output path of object storage service |
US11386230B2 (en) | 2019-09-27 | 2022-07-12 | Amazon Technologies, Inc. | On-demand code obfuscation of data in input path of object storage service |
US11388210B1 (en) | 2021-06-30 | 2022-07-12 | Amazon Technologies, Inc. | Streaming analytics using a serverless compute system |
US11394761B1 (en) | 2019-09-27 | 2022-07-19 | Amazon Technologies, Inc. | Execution of user-submitted code on a stream of data |
US11416628B2 (en) | 2019-09-27 | 2022-08-16 | Amazon Technologies, Inc. | User-specific data manipulation system for object storage service based on user-submitted code |
US11461124B2 (en) | 2015-02-04 | 2022-10-04 | Amazon Technologies, Inc. | Security protocols for low latency execution of program code |
US11467890B2 (en) | 2014-09-30 | 2022-10-11 | Amazon Technologies, Inc. | Processing event messages for user requests to execute program code |
US11526505B2 (en) * | 2018-12-10 | 2022-12-13 | Teradata Us, Inc. | Enabling cross-platform query optimization via expressive markup language |
US11550944B2 (en) | 2019-09-27 | 2023-01-10 | Amazon Technologies, Inc. | Code execution environment customization system for object storage service |
US11550713B1 (en) | 2020-11-25 | 2023-01-10 | Amazon Technologies, Inc. | Garbage collection in distributed systems using life cycled storage roots |
US11586459B2 (en) * | 2020-04-01 | 2023-02-21 | Vmware, Inc. | Generating and preserving default configurations of a system |
US11593270B1 (en) | 2020-11-25 | 2023-02-28 | Amazon Technologies, Inc. | Fast distributed caching using erasure coded object parts |
US11656892B1 (en) | 2019-09-27 | 2023-05-23 | Amazon Technologies, Inc. | Sequential execution of user-submitted code and native functions |
US11714682B1 (en) | 2020-03-03 | 2023-08-01 | Amazon Technologies, Inc. | Reclaiming computing resources in an on-demand code execution system |
US11775640B1 (en) | 2020-03-30 | 2023-10-03 | Amazon Technologies, Inc. | Resource utilization-based malicious task detection in an on-demand code execution system |
US11861386B1 (en) | 2019-03-22 | 2024-01-02 | Amazon Technologies, Inc. | Application gateways in an on-demand network code execution system |
US11860954B1 (en) | 2009-01-23 | 2024-01-02 | Zakta, LLC | Collaboratively finding, organizing and/or accessing information |
US11875173B2 (en) | 2018-06-25 | 2024-01-16 | Amazon Technologies, Inc. | Execution of auxiliary functions in an on-demand network code execution system |
US11943093B1 (en) | 2018-11-20 | 2024-03-26 | Amazon Technologies, Inc. | Network connection recovery after virtual machine transition in an on-demand network code execution system |
US11968280B1 (en) | 2021-11-24 | 2024-04-23 | Amazon Technologies, Inc. | Controlling ingestion of streaming data to serverless function executions |
Families Citing this family (62)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3617406B2 (en) * | 2000-03-30 | 2005-02-02 | 日本電気株式会社 | Quality assurance type communication service providing method and service providing method corresponding to multi-domain and service mediating apparatus |
US6999989B2 (en) * | 2001-03-29 | 2006-02-14 | At&T Corp. | Methods for providing video enhanced electronic mail return receipts |
US7284191B2 (en) * | 2001-08-13 | 2007-10-16 | Xerox Corporation | Meta-document management system with document identifiers |
US7133862B2 (en) | 2001-08-13 | 2006-11-07 | Xerox Corporation | System with user directed enrichment and import/export control |
DE60129701T2 (en) * | 2001-09-21 | 2008-04-30 | Koninklijke Kpn N.V. | Computer system, data transmission network, computer program and data carriers, all messages for filtering content according to a tagging language |
US8356067B2 (en) * | 2002-10-24 | 2013-01-15 | Intel Corporation | Servicing device aggregates |
US7246356B1 (en) * | 2003-01-29 | 2007-07-17 | Adobe Systems Incorporated | Method and system for facilitating comunications between an interactive multimedia client and an interactive multimedia communication server |
US7287256B1 (en) | 2003-03-28 | 2007-10-23 | Adobe Systems Incorporated | Shared persistent objects |
US7873716B2 (en) * | 2003-06-27 | 2011-01-18 | Oracle International Corporation | Method and apparatus for supporting service enablers via service request composition |
US8200775B2 (en) | 2005-02-01 | 2012-06-12 | Newsilike Media Group, Inc | Enhanced syndication |
US7644170B2 (en) * | 2003-08-11 | 2010-01-05 | Teamon Systems, Inc. | Communications system providing extensible protocol translation features and related methods |
US20050193370A1 (en) * | 2004-02-27 | 2005-09-01 | Goring Brian R. | System and method for interactive wireless applications with conditional UI controls and screen navigation |
US20050229099A1 (en) * | 2004-04-07 | 2005-10-13 | Rogerson Dale E | Presentation-independent semantic authoring of content |
US7890744B2 (en) * | 2004-04-07 | 2011-02-15 | Microsoft Corporation | Activating content based on state |
US7822992B2 (en) * | 2004-04-07 | 2010-10-26 | Microsoft Corporation | In-place content substitution via code-invoking link |
US9565297B2 (en) | 2004-05-28 | 2017-02-07 | Oracle International Corporation | True convergence with end to end identity management |
US8073810B2 (en) | 2007-10-29 | 2011-12-06 | Oracle International Corporation | Shared view of customers across business support systems (BSS) and a service delivery platform (SDP) |
US9245236B2 (en) | 2006-02-16 | 2016-01-26 | Oracle International Corporation | Factorization of concerns to build a SDP (service delivery platform) |
US8321498B2 (en) | 2005-03-01 | 2012-11-27 | Oracle International Corporation | Policy interface description framework |
US9038082B2 (en) | 2004-05-28 | 2015-05-19 | Oracle International Corporation | Resource abstraction via enabler and metadata |
US8966498B2 (en) | 2008-01-24 | 2015-02-24 | Oracle International Corporation | Integrating operational and business support systems with a service delivery platform |
US8458703B2 (en) | 2008-06-26 | 2013-06-04 | Oracle International Corporation | Application requesting management function based on metadata for managing enabler or dependency |
US8032920B2 (en) | 2004-12-27 | 2011-10-04 | Oracle International Corporation | Policies as workflows |
US8200700B2 (en) * | 2005-02-01 | 2012-06-12 | Newsilike Media Group, Inc | Systems and methods for use of structured and unstructured distributed data |
US8347088B2 (en) | 2005-02-01 | 2013-01-01 | Newsilike Media Group, Inc | Security systems and methods for use with structured and unstructured data |
US9202084B2 (en) | 2006-02-01 | 2015-12-01 | Newsilike Media Group, Inc. | Security facility for maintaining health care data pools |
US8700738B2 (en) | 2005-02-01 | 2014-04-15 | Newsilike Media Group, Inc. | Dynamic feed generation |
US8140482B2 (en) | 2007-09-19 | 2012-03-20 | Moore James F | Using RSS archives |
US20070050446A1 (en) | 2005-02-01 | 2007-03-01 | Moore James F | Managing network-accessible resources |
US7756932B2 (en) * | 2005-07-29 | 2010-07-13 | Research In Motion Limited | System and method for processing messages being composed by a user |
JP2007279838A (en) * | 2006-04-03 | 2007-10-25 | Ibm Japan Ltd | Information processor, method, and program |
US8914493B2 (en) | 2008-03-10 | 2014-12-16 | Oracle International Corporation | Presence-based event driven architecture |
US8214503B2 (en) | 2007-03-23 | 2012-07-03 | Oracle International Corporation | Factoring out dialog control and call control |
US20090012987A1 (en) * | 2007-07-05 | 2009-01-08 | Kaminsky David L | Method and system for delivering role-appropriate policies |
US8539097B2 (en) | 2007-11-14 | 2013-09-17 | Oracle International Corporation | Intelligent message processing |
US8161171B2 (en) | 2007-11-20 | 2012-04-17 | Oracle International Corporation | Session initiation protocol-based internet protocol television |
US9654515B2 (en) | 2008-01-23 | 2017-05-16 | Oracle International Corporation | Service oriented architecture-based SCIM platform |
US8589338B2 (en) | 2008-01-24 | 2013-11-19 | Oracle International Corporation | Service-oriented architecture (SOA) management of data repository |
US8510796B2 (en) * | 2008-01-25 | 2013-08-13 | Oracle International Corporation | Method for application-to-application authentication via delegation |
US8401022B2 (en) | 2008-02-08 | 2013-03-19 | Oracle International Corporation | Pragmatic approaches to IMS |
US10819530B2 (en) | 2008-08-21 | 2020-10-27 | Oracle International Corporation | Charging enabler |
US20100094716A1 (en) * | 2008-10-15 | 2010-04-15 | Ganesan Chandramouli | Method and computer-readable storage media to determine and access provisioning services |
US8255490B1 (en) | 2008-10-22 | 2012-08-28 | Amazon Technologies, Inc. | Dynamic service-oriented architecture using customization code |
US20100217867A1 (en) * | 2009-02-25 | 2010-08-26 | International Business Machines Corporation | System and method for creating and using service dependency graphs to automate the development and deployment of service oriented applications |
US8879547B2 (en) | 2009-06-02 | 2014-11-04 | Oracle International Corporation | Telephony application services |
MY164485A (en) * | 2009-07-20 | 2017-12-29 | Mimos Berhad | A method and system for an intelligent framework of a service orientated architecture |
US8583830B2 (en) | 2009-11-19 | 2013-11-12 | Oracle International Corporation | Inter-working with a walled garden floor-controlled system |
US8533773B2 (en) | 2009-11-20 | 2013-09-10 | Oracle International Corporation | Methods and systems for implementing service level consolidated user information management |
US9269060B2 (en) | 2009-11-20 | 2016-02-23 | Oracle International Corporation | Methods and systems for generating metadata describing dependencies for composable elements |
US8943508B2 (en) * | 2009-12-09 | 2015-01-27 | International Business Machines Corporation | Service oriented collaboration |
US9509790B2 (en) | 2009-12-16 | 2016-11-29 | Oracle International Corporation | Global presence |
US9503407B2 (en) | 2009-12-16 | 2016-11-22 | Oracle International Corporation | Message forwarding |
US8244754B2 (en) | 2010-02-01 | 2012-08-14 | International Business Machines Corporation | System and method for object searching in virtual worlds |
US9244956B2 (en) | 2011-06-14 | 2016-01-26 | Microsoft Technology Licensing, Llc | Recommending data enrichments |
US9147195B2 (en) | 2011-06-14 | 2015-09-29 | Microsoft Technology Licensing, Llc | Data custodian and curation system |
US9122720B2 (en) * | 2011-06-14 | 2015-09-01 | Microsoft Technology Licensing, Llc | Enriching database query responses using data from external data sources |
US9990232B2 (en) * | 2015-10-06 | 2018-06-05 | Red Hat, Inc. | Quality of service tagging for computing jobs |
US11467868B1 (en) * | 2017-05-03 | 2022-10-11 | Amazon Technologies, Inc. | Service relationship orchestration service |
CN109408575B (en) * | 2018-10-19 | 2020-11-10 | 广东省气象探测数据中心 | Data access service system |
US11196837B2 (en) | 2019-03-29 | 2021-12-07 | Intel Corporation | Technologies for multi-tier prefetching in a context-aware edge gateway |
US11388054B2 (en) | 2019-04-30 | 2022-07-12 | Intel Corporation | Modular I/O configurations for edge computing using disaggregated chiplets |
US20200136921A1 (en) | 2019-09-28 | 2020-04-30 | Intel Corporation | Methods, system, articles of manufacture, and apparatus to manage telemetry data in an edge environment |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6041308A (en) * | 1996-09-04 | 2000-03-21 | Priceline.Com Incorporated | System and method for motivating submission of conditional purchase offers |
US6064979A (en) * | 1996-10-25 | 2000-05-16 | Ipf, Inc. | Method of and system for finding and serving consumer product related information over the internet using manufacturer identification numbers |
US6226675B1 (en) * | 1998-10-16 | 2001-05-01 | Commerce One, Inc. | Participant server which process documents for commerce in trading partner networks |
US6356949B1 (en) * | 1999-01-29 | 2002-03-12 | Intermec Ip Corp. | Automatic data collection device that receives data output instruction from data consumer |
US6407753B1 (en) * | 1999-05-04 | 2002-06-18 | International Business Machines Corporation | System and method for integrating entities via user-interactive rule-based matching and difference reconciliation |
US6542912B2 (en) * | 1998-10-16 | 2003-04-01 | Commerce One Operations, Inc. | Tool for building documents for commerce in trading partner networks and interface definitions based on the documents |
US6826597B1 (en) * | 1999-03-17 | 2004-11-30 | Oracle International Corporation | Providing clients with services that retrieve data from data sources that do not necessarily support the format required by the clients |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6154738A (en) * | 1998-03-27 | 2000-11-28 | Call; Charles Gainor | Methods and apparatus for disseminating product information via the internet using universal product codes |
US6990514B1 (en) * | 1999-09-03 | 2006-01-24 | Cisco Technology, Inc. | Unified messaging system using web based application server for management of messages using standardized servers |
-
2000
- 2000-05-31 US US09/584,318 patent/US7472349B1/en not_active Expired - Lifetime
-
2002
- 2002-04-10 US US10/120,175 patent/US20020120685A1/en not_active Abandoned
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6041308A (en) * | 1996-09-04 | 2000-03-21 | Priceline.Com Incorporated | System and method for motivating submission of conditional purchase offers |
US6064979A (en) * | 1996-10-25 | 2000-05-16 | Ipf, Inc. | Method of and system for finding and serving consumer product related information over the internet using manufacturer identification numbers |
US6226675B1 (en) * | 1998-10-16 | 2001-05-01 | Commerce One, Inc. | Participant server which process documents for commerce in trading partner networks |
US6542912B2 (en) * | 1998-10-16 | 2003-04-01 | Commerce One Operations, Inc. | Tool for building documents for commerce in trading partner networks and interface definitions based on the documents |
US6356949B1 (en) * | 1999-01-29 | 2002-03-12 | Intermec Ip Corp. | Automatic data collection device that receives data output instruction from data consumer |
US6826597B1 (en) * | 1999-03-17 | 2004-11-30 | Oracle International Corporation | Providing clients with services that retrieve data from data sources that do not necessarily support the format required by the clients |
US6407753B1 (en) * | 1999-05-04 | 2002-06-18 | International Business Machines Corporation | System and method for integrating entities via user-interactive rule-based matching and difference reconciliation |
Cited By (546)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6990395B2 (en) | 1994-12-30 | 2006-01-24 | Power Measurement Ltd. | Energy management device and architecture with multiple security levels |
US7188003B2 (en) | 1994-12-30 | 2007-03-06 | Power Measurement Ltd. | System and method for securing energy management systems |
US20040193329A1 (en) * | 1994-12-30 | 2004-09-30 | Ransom Douglas S. | System and method for securing energy management systems |
US7127328B2 (en) | 1994-12-30 | 2006-10-24 | Power Measurement Ltd. | System and method for federated security in an energy management system |
US7761910B2 (en) | 1994-12-30 | 2010-07-20 | Power Measurement Ltd. | System and method for assigning an identity to an intelligent electronic device |
US20050144437A1 (en) * | 1994-12-30 | 2005-06-30 | Ransom Douglas S. | System and method for assigning an identity to an intelligent electronic device |
US20030204756A1 (en) * | 1997-02-12 | 2003-10-30 | Ransom Douglas S. | Push communications architecture for intelligent electronic devices |
US20040138835A1 (en) * | 1997-02-12 | 2004-07-15 | Power Measurement Ltd. | Push communications architecture for intelligent electronic devices |
US20050138432A1 (en) * | 1997-02-12 | 2005-06-23 | Ransom Douglas S. | System and method for routing power management via XML firewall |
US7216043B2 (en) | 1997-02-12 | 2007-05-08 | Power Measurement Ltd. | Push communications architecture for intelligent electronic devices |
US7734380B2 (en) | 1997-02-12 | 2010-06-08 | Power Measurement Ltd. | Push communications architecture for intelligent electronic devices |
US7248978B2 (en) | 1997-02-12 | 2007-07-24 | Power Measurement Ltd. | System and method for routing power management data via XML firewall |
US7134072B1 (en) * | 1999-10-13 | 2006-11-07 | Microsoft Corporation | Methods and systems for processing XML documents |
US20020161688A1 (en) * | 2000-02-16 | 2002-10-31 | Rocky Stewart | Open market collaboration system for enterprise wide electronic commerce |
US7249157B2 (en) | 2000-02-16 | 2007-07-24 | Bea Systems, Inc. | Collaboration system for exchanging of data between electronic participants via collaboration space by using a URL to identify a combination of both collaboration space and business protocol |
US8219904B2 (en) | 2000-04-07 | 2012-07-10 | Xerox Corporation | Meta-document and method of managing |
US20100235337A1 (en) * | 2000-04-07 | 2010-09-16 | Xerox Corporation | Meta-Document and Method Of Managing |
US7757168B1 (en) * | 2000-04-07 | 2010-07-13 | Xerox Corporation | Meta-document and method of managing |
US20020019824A1 (en) * | 2000-04-12 | 2002-02-14 | International Business Machines Corporation | Method to generically describe and manipulate arbitrary data structures |
US6862594B1 (en) * | 2000-05-09 | 2005-03-01 | Sun Microsystems, Inc. | Method and apparatus to discover services using flexible search criteria |
US8135796B1 (en) | 2000-05-09 | 2012-03-13 | Oracle America, Inc. | Mechanism and apparatus for accessing and addressing services in a distributed computing environment |
US7716492B1 (en) | 2000-05-09 | 2010-05-11 | Oracle America, Inc. | Method and apparatus to obtain service capability credentials |
US6789077B1 (en) * | 2000-05-09 | 2004-09-07 | Sun Microsystems, Inc. | Mechanism and apparatus for web-based searching of URI-addressable repositories in a distributed computing environment |
US7770102B1 (en) | 2000-06-06 | 2010-08-03 | Microsoft Corporation | Method and system for semantically labeling strings and providing actions based on semantically labeled strings |
US20050165815A1 (en) * | 2000-06-06 | 2005-07-28 | Groove Networks, Inc. | Method and apparatus for efficient management of XML documents |
US7721194B2 (en) * | 2000-06-06 | 2010-05-18 | Groove Networks, Inc. | Method and apparatus for efficient management of XML documents |
US7788602B2 (en) | 2000-06-06 | 2010-08-31 | Microsoft Corporation | Method and system for providing restricted actions for recognized semantic categories |
US7716163B2 (en) | 2000-06-06 | 2010-05-11 | Microsoft Corporation | Method and system for defining semantic categories and actions |
US7712024B2 (en) | 2000-06-06 | 2010-05-04 | Microsoft Corporation | Application program interfaces for semantically labeling strings and providing actions based on semantically labeled strings |
US20100153604A1 (en) * | 2000-06-20 | 2010-06-17 | Palmsource, Inc. | Data exchange between a handheld device and another computer system using an exchange manager via synchronization |
US8452836B2 (en) * | 2000-06-20 | 2013-05-28 | Access Co., Ltd. | Data exchange between a handheld device and another computer system using an exchange manager via synchronization |
US6766313B1 (en) * | 2000-07-12 | 2004-07-20 | Microsoft Corporation | System and method for caching and retrieving information |
US20050055358A1 (en) * | 2000-09-07 | 2005-03-10 | Oracle International Corporation | Apparatus and method for mapping relational data and metadata to XML |
US7260585B2 (en) | 2000-09-07 | 2007-08-21 | Oracle International Corporation | Apparatus and method for mapping relational data and metadata to XML |
US7873649B2 (en) * | 2000-09-07 | 2011-01-18 | Oracle International Corporation | Method and mechanism for identifying transaction on a row of data |
US20020078094A1 (en) * | 2000-09-07 | 2002-06-20 | Muralidhar Krishnaprasad | Method and apparatus for XML visualization of a relational database and universal resource identifiers to database data and metadata |
US6871204B2 (en) | 2000-09-07 | 2005-03-22 | Oracle International Corporation | Apparatus and method for mapping relational data and metadata to XML |
US20020078068A1 (en) * | 2000-09-07 | 2002-06-20 | Muralidhar Krishnaprasad | Method and apparatus for flexible storage and uniform manipulation of XML data in a relational database system |
US7024425B2 (en) | 2000-09-07 | 2006-04-04 | Oracle International Corporation | Method and apparatus for flexible storage and uniform manipulation of XML data in a relational database system |
US20060143267A1 (en) * | 2000-09-28 | 2006-06-29 | Bea Systems, Inc. | System for managing logical process flow in an online environment |
US7089330B1 (en) * | 2000-09-28 | 2006-08-08 | I2 Technologies Us, Inc. | System and method for transforming custom content generation tags associated with web pages |
US20020143820A1 (en) * | 2000-10-04 | 2002-10-03 | Van Eaton James R. | Methods and systems for generating a viewable document using view descriptors and generic view stylesheets |
US6948117B2 (en) * | 2000-10-04 | 2005-09-20 | Microsoft Corporation | Methods and systems for generating a viewable document using view descriptors and generic view stylesheets |
US7328253B2 (en) * | 2000-10-26 | 2008-02-05 | Seiko Epson Corporation | Service providing system, service providing terminal, client terminal, and storage medium |
US20020062448A1 (en) * | 2000-10-26 | 2002-05-23 | Seiko Epson Corporation | Service providing system, service providing terminal, client terminal, and storage medium |
US20020133808A1 (en) * | 2000-11-10 | 2002-09-19 | Adam Bosworth | Cell based data processing |
US8312429B2 (en) * | 2000-11-10 | 2012-11-13 | Oracle International Corporation | Cell based data processing |
US20020120704A1 (en) * | 2000-11-28 | 2002-08-29 | Karp Alan H. | Computer language for defining business conversations |
US6988025B2 (en) | 2000-11-28 | 2006-01-17 | Power Measurement Ltd. | System and method for implementing XML on an energy management device |
US7165113B2 (en) * | 2000-11-28 | 2007-01-16 | Hewlett-Packard Development Company, L.P. | Computer language for defining business conversations |
US20040162642A1 (en) * | 2000-11-28 | 2004-08-19 | Marcus Gasper | Thin client power management system and method |
US20110087710A1 (en) * | 2001-01-09 | 2011-04-14 | Tim Neil | Software, devices and methods facilitating execution of server-side applications at mobile devices |
US20090300063A1 (en) * | 2001-01-09 | 2009-12-03 | Tim Neil | Software, devices and methods facilitating execution of server-side applications at mobile devices |
US7865528B2 (en) * | 2001-01-09 | 2011-01-04 | Nextair Corporation | Software, devices and methods facilitating execution of server-side applications at mobile devices |
US8204911B2 (en) * | 2001-01-09 | 2012-06-19 | Nextair Corporation | Software, devices and methods facilitating execution of server-side applications at mobile devices |
US8126982B2 (en) * | 2001-02-16 | 2012-02-28 | International Business Machines Corporation | Method, network device and computer program product for performing service discovery in a pervasive network |
US20020120750A1 (en) * | 2001-02-16 | 2002-08-29 | Michael Nidd | Method, network device and computer program product for performing service discovery in a pervasive network |
US7302634B2 (en) * | 2001-03-14 | 2007-11-27 | Microsoft Corporation | Schema-based services for identity-based data access |
US9413817B2 (en) | 2001-03-14 | 2016-08-09 | Microsoft Technology Licensing, Llc | Executing dynamically assigned functions while providing services |
US20060161554A1 (en) * | 2001-03-14 | 2006-07-20 | Microsoft Corporation | Schema-Based Services For Identity-Based Data Access |
US20030101190A1 (en) * | 2001-03-14 | 2003-05-29 | Microsoft Corporation | Schema-based notification service |
US9460421B2 (en) | 2001-03-14 | 2016-10-04 | Microsoft Technology Licensing, Llc | Distributing notifications to multiple recipients via a broadcast list |
US7664724B2 (en) * | 2001-03-14 | 2010-02-16 | Microsoft Corporation | Schema-based services for identity-based data access |
US20030131073A1 (en) * | 2001-03-14 | 2003-07-10 | Lucovsky Mark H. | Schema-based services for identity-based data access |
US8572576B2 (en) | 2001-03-14 | 2013-10-29 | Microsoft Corporation | Executing dynamically assigned functions while providing services |
US7860877B2 (en) * | 2001-03-27 | 2010-12-28 | Oracle International Corporation | Reconfigurable query generation system for web browsers |
US20070162439A1 (en) * | 2001-03-27 | 2007-07-12 | Bea Systems, Inc. | Reconfigurable query generation system for web browsers |
US7778816B2 (en) | 2001-04-24 | 2010-08-17 | Microsoft Corporation | Method and system for applying input mode bias |
US20060179049A1 (en) * | 2001-05-17 | 2006-08-10 | Andrey Balmin | System for querying markup language data stored in a relational database according to markup language schema |
US7028028B1 (en) * | 2001-05-17 | 2006-04-11 | Enosys Markets,Inc. | System for querying markup language data stored in a relational database according to markup language schema |
US20050234889A1 (en) * | 2001-05-25 | 2005-10-20 | Joshua Fox | Method and system for federated querying of data sources |
US8548938B2 (en) | 2001-05-25 | 2013-10-01 | International Business Machines Corporation | Business rules for configurable metamodels and enterprise impact analysis |
US8412746B2 (en) | 2001-05-25 | 2013-04-02 | International Business Machines Corporation | Method and system for federated querying of data sources |
US20030120665A1 (en) * | 2001-05-25 | 2003-06-26 | Joshua Fox | Run-time architecture for enterprise integration with transformation generation |
US7146399B2 (en) * | 2001-05-25 | 2006-12-05 | 2006 Trident Company | Run-time architecture for enterprise integration with transformation generation |
US7366712B2 (en) * | 2001-05-31 | 2008-04-29 | Intel Corporation | Information retrieval center gateway |
US20020188869A1 (en) * | 2001-06-11 | 2002-12-12 | Paul Patrick | System and method for server security and entitlement processing |
US7069536B2 (en) | 2001-06-28 | 2006-06-27 | International Business Machines Corporation | Method, system, and program for executing a workflow |
US20030005406A1 (en) * | 2001-06-28 | 2003-01-02 | International Business Machines Corporation | Method, system, and program for using objects in data stores during execution of a workflow |
US7100147B2 (en) | 2001-06-28 | 2006-08-29 | International Business Machines Corporation | Method, system, and program for generating a workflow |
US20030004770A1 (en) * | 2001-06-28 | 2003-01-02 | International Business Machines Corporation | Method, system, and program for generating a workflow |
US7043714B2 (en) | 2001-06-28 | 2006-05-09 | International Business Machines Corporation | Method, system, and program for using objects in data stores during execution of a workflow |
US20030004771A1 (en) * | 2001-06-28 | 2003-01-02 | International Business Machines Corporation | Method, system, and program for executing a workflow |
US20030023476A1 (en) * | 2001-06-29 | 2003-01-30 | Incidentreports, Inc. | System and method for recording and using incident report data |
US20030028669A1 (en) * | 2001-07-06 | 2003-02-06 | Alcatel | Method and system for routing logging a request |
US7185342B1 (en) * | 2001-07-24 | 2007-02-27 | Oracle International Corporation | Distributed service aggregation and composition |
US6862588B2 (en) * | 2001-07-25 | 2005-03-01 | Hewlett-Packard Development Company, L.P. | Hybrid parsing system and method |
US20030023615A1 (en) * | 2001-07-25 | 2003-01-30 | Gabriel Beged-Dov | Hybrid parsing system and method |
US7698427B2 (en) | 2001-07-30 | 2010-04-13 | International Business Machines Corporation | Method, system, and program for transferring data from an application engine |
US7047535B2 (en) | 2001-07-30 | 2006-05-16 | International Business Machines Corporation | Method, system, and program for performing workflow related operations using an application programming interface |
US20030023773A1 (en) * | 2001-07-30 | 2003-01-30 | International Business Machines Corporation | Method, system, and program for performing workflow related operations |
US20030023662A1 (en) * | 2001-07-30 | 2003-01-30 | International Business Machines Corporation | Method, system, and program for enabling access to a plurality of services |
US7228547B2 (en) * | 2001-07-30 | 2007-06-05 | International Business Machines Corporation | Method, system, and program for enabling access to a plurality of services |
US7296056B2 (en) | 2001-07-30 | 2007-11-13 | International Business Machines Corporation | Method, system, and program for selecting one user to assign a work item in a workflow |
US20060150026A1 (en) * | 2001-08-13 | 2006-07-06 | Parasoft Corporation | System and method for testing of web services |
US7028223B1 (en) * | 2001-08-13 | 2006-04-11 | Parasoft Corporation | System and method for testing of web services |
US8924408B2 (en) | 2001-09-28 | 2014-12-30 | International Business Machines Corporation | Automatic generation of database invocation mechanism for external web services |
US8166006B2 (en) * | 2001-09-28 | 2012-04-24 | International Business Machines Corporation | Invocation of web services from a database |
US7158981B2 (en) | 2001-09-28 | 2007-01-02 | Oracle International Corporation | Providing a consistent hierarchical abstraction of relational data |
US8914807B2 (en) | 2001-09-28 | 2014-12-16 | International Business Machines Corporation | Method, system, and program for generating a program capable of invoking a flow of operations |
US20030191769A1 (en) * | 2001-09-28 | 2003-10-09 | International Business Machines Corporation | Method, system, and program for generating a program capable of invoking a flow of operations |
US20030093436A1 (en) * | 2001-09-28 | 2003-05-15 | International Business Machines Corporation | Invocation of web services from a database |
US20040199636A1 (en) * | 2001-09-28 | 2004-10-07 | International Business Machines Corporation | Automatic generation of database invocation mechanism for external web services |
US7340714B2 (en) * | 2001-10-18 | 2008-03-04 | Bea Systems, Inc. | System and method for using web services with an enterprise system |
US20030182452A1 (en) * | 2001-10-18 | 2003-09-25 | Mitch Upton | System and method for implementing a schema object model in application integration |
US7831655B2 (en) | 2001-10-18 | 2010-11-09 | Bea Systems, Inc. | System and method for implementing a service adapter |
US20030093403A1 (en) * | 2001-10-18 | 2003-05-15 | Mitch Upton | System and method for implementing an event adapter |
US7721193B2 (en) | 2001-10-18 | 2010-05-18 | Bea Systems, Inc. | System and method for implementing a schema object model in application integration |
US20030105884A1 (en) * | 2001-10-18 | 2003-06-05 | Mitch Upton | System and method for using Web services with an enterprise system |
US20030126558A1 (en) * | 2001-10-24 | 2003-07-03 | Griffin Philip B. | System and method for XML data representation of portlets |
US20050187986A1 (en) * | 2001-10-24 | 2005-08-25 | Bea Systems, Inc. | Data synchronization |
US20030154356A1 (en) * | 2002-02-13 | 2003-08-14 | Ibrahim Kamel | Efficient service management in home gateways |
US7010661B2 (en) * | 2002-02-13 | 2006-03-07 | Matsushita Electric Industrial Co., Ltd. | Efficient service management in home gateways |
US8484664B2 (en) | 2002-02-22 | 2013-07-09 | Oracle International Corporation | Systems and methods for an extensible software proxy |
US8015572B2 (en) | 2002-02-22 | 2011-09-06 | Oracle International Corporation | Systems and methods for an extensible software proxy |
US20090265346A1 (en) * | 2002-03-01 | 2009-10-22 | Business Objects Americas | System and Method for Retrieving and Organizing Information from Disparate Computer Network Information Sources |
US20030212673A1 (en) * | 2002-03-01 | 2003-11-13 | Sundar Kadayam | System and method for retrieving and organizing information from disparate computer network information sources |
US8131755B2 (en) | 2002-03-01 | 2012-03-06 | SAP America, Inc. | System and method for retrieving and organizing information from disparate computer network information sources |
US20060259476A1 (en) * | 2002-03-01 | 2006-11-16 | Inxight Software, Inc. | System and Method for Retrieving and Organizing Information From Disparate Computer Network Information Services |
US20060200462A1 (en) * | 2002-03-01 | 2006-09-07 | Inxight Software, Inc. | System and Method for Retrieving and Organizing Information From Disparate Computer Network Information Services |
US7567953B2 (en) | 2002-03-01 | 2009-07-28 | Business Objects Americas | System and method for retrieving and organizing information from disparate computer network information sources |
US20080215710A1 (en) * | 2002-03-20 | 2008-09-04 | Tadashi Takeuchi | Contents distributing method and distributing system |
US20030191824A1 (en) * | 2002-04-03 | 2003-10-09 | Raghav Rao | Installation of network services in an embedded network server |
US7571221B2 (en) * | 2002-04-03 | 2009-08-04 | Hewlett-Packard Development Company, L.P. | Installation of network services in an embedded network server |
US20030200319A1 (en) * | 2002-04-19 | 2003-10-23 | Bodine Gregory L. | System and method for interfacing with existing system management products or software solutions |
US7346647B2 (en) * | 2002-04-19 | 2008-03-18 | Computer Associates Think, Inc. | System and method for interfacing with existing system management products or software solutions |
US20070074066A1 (en) * | 2002-05-01 | 2007-03-29 | Bea Systems, Inc. | High availability for event forwarding |
US7257645B2 (en) | 2002-05-01 | 2007-08-14 | Bea Systems, Inc. | System and method for storing large messages |
US7725560B2 (en) | 2002-05-01 | 2010-05-25 | Bea Systems Inc. | Web service-enabled portlet wizard |
US7840532B2 (en) | 2002-05-01 | 2010-11-23 | Oracle International Corporation | System and method for storing large messages |
US7840611B2 (en) | 2002-05-01 | 2010-11-23 | Oracle International Corporation | High availability for event forwarding |
US8135772B2 (en) | 2002-05-01 | 2012-03-13 | Oracle International Corporation | Single servlets for B2B message routing |
US20070198467A1 (en) * | 2002-05-01 | 2007-08-23 | Bea Systems, Inc. | System and method for storing large messages |
US20040006663A1 (en) * | 2002-05-01 | 2004-01-08 | David Wiser | System and method for storing large messages |
US20070156884A1 (en) * | 2002-05-01 | 2007-07-05 | Bea Systems, Inc. | High availability for event forwarding |
US20070156922A1 (en) * | 2002-05-01 | 2007-07-05 | Bea Systems, Inc. | High availability for event forwarding |
US20040078440A1 (en) * | 2002-05-01 | 2004-04-22 | Tim Potter | High availability event topic |
US20040049481A1 (en) * | 2002-05-01 | 2004-03-11 | Mike Blevins | Systems and methods for business process plug-in development |
US20040221261A1 (en) * | 2002-05-01 | 2004-11-04 | Mike Blevins | Collaborative business plug-in framework |
US20070150598A1 (en) * | 2002-05-02 | 2007-06-28 | Bea Systems, Inc. | System and method for providing highly available processing of asynchronous service requests |
US8046772B2 (en) | 2002-05-02 | 2011-10-25 | Oracle International Corporation | System and method for enterprise application interactions |
US20040034859A1 (en) * | 2002-05-02 | 2004-02-19 | Timothy Potter | Shared common connection factory |
US20040015859A1 (en) * | 2002-05-02 | 2004-01-22 | Timothy Potter | Systems and methods for modular component deployment |
US20040006550A1 (en) * | 2002-05-02 | 2004-01-08 | Mitch Upton | System and method for enterprise application interactions |
US20040068728A1 (en) * | 2002-05-02 | 2004-04-08 | Mike Blevins | Systems and methods for collaborative business plug-ins |
US7676538B2 (en) | 2002-05-02 | 2010-03-09 | Bea Systems, Inc. | Systems and methods for application view transactions |
US7953787B2 (en) | 2002-05-02 | 2011-05-31 | Oracle International Corporation | System and method for providing highly available processing of asynchronous requests using distributed request and response queues and a service processor |
US7350184B2 (en) | 2002-05-02 | 2008-03-25 | Bea Systems, Inc. | System and method for enterprise application interactions |
US7707496B1 (en) | 2002-05-09 | 2010-04-27 | Microsoft Corporation | Method, system, and apparatus for converting dates between calendars and languages based upon semantically labeled strings |
US7707024B2 (en) | 2002-05-23 | 2010-04-27 | Microsoft Corporation | Method, system, and apparatus for converting currency values based upon semantically labeled strings |
US7742048B1 (en) | 2002-05-23 | 2010-06-22 | Microsoft Corporation | Method, system, and apparatus for converting numbers based upon semantically labeled strings |
US20080065651A1 (en) * | 2002-05-31 | 2008-03-13 | American Express Travel Related Services Company, Inc. | System and method for acquisition, assimilation and storage of information |
US7610261B2 (en) | 2002-05-31 | 2009-10-27 | American Express Travel Related Services Company, Inc. | System and method for acquisition, assimilation and storage of information |
US20030225729A1 (en) * | 2002-05-31 | 2003-12-04 | American Express Travel Related Services Company, Inc. | System and method for facilitating information collection, storage, and distribution |
US8090734B2 (en) | 2002-05-31 | 2012-01-03 | American Express Travel Related Services Company, Inc. | System and method for assessing risk |
US20100005027A1 (en) * | 2002-05-31 | 2010-01-07 | American Express Travel Related Services Company, Inc. | System and method for assessing risk |
US7386528B2 (en) * | 2002-05-31 | 2008-06-10 | American Express Travel Related Services Company, Inc. | System and method for acquisition, assimilation and storage of information |
US7281245B2 (en) * | 2002-06-05 | 2007-10-09 | Microsoft Corporation | Mechanism for downloading software components from a remote source for use by a local software application |
US7827546B1 (en) * | 2002-06-05 | 2010-11-02 | Microsoft Corporation | Mechanism for downloading software components from a remote source for use by a local software application |
US8706708B2 (en) | 2002-06-06 | 2014-04-22 | Microsoft Corporation | Providing contextually sensitive tools and help content in computer-generated documents |
US20030233397A1 (en) * | 2002-06-12 | 2003-12-18 | Seapass Solutions Inc. | Interface development environment and interface for connecting systems having different data structures |
US7257647B2 (en) * | 2002-06-12 | 2007-08-14 | Seapass Solutions Inc. | Development environment platform using message type mapping for converting message and providing information between systems having different data structures |
US7716676B2 (en) | 2002-06-25 | 2010-05-11 | Microsoft Corporation | System and method for issuing a message to a program |
US9886309B2 (en) | 2002-06-28 | 2018-02-06 | Microsoft Technology Licensing, Llc | Identity-based distributed computing for device resources |
US8620938B2 (en) | 2002-06-28 | 2013-12-31 | Microsoft Corporation | Method, system, and apparatus for routing a query to one or more providers |
US20040220952A1 (en) * | 2002-08-29 | 2004-11-04 | Bea Systems, Inc. | Web service gateway generation |
US20070288138A1 (en) * | 2002-08-29 | 2007-12-13 | Bodin William K | Anticipatory Mobile System Service Brokering and Resource Planning from Multiple Providers |
US8051188B2 (en) | 2002-09-05 | 2011-11-01 | Canon Kabushiki Kaisha | Method of proposing a service via a description document of such a service |
US20040060002A1 (en) * | 2002-09-12 | 2004-03-25 | Microsoft Corporation | Schema-based service for identity-based access to lists |
US7950015B2 (en) | 2002-09-20 | 2011-05-24 | International Business Machines Corporation | System and method for combining services to satisfy request requirement |
US7216343B2 (en) | 2002-09-20 | 2007-05-08 | International Business Machines Corporation | Method and apparatus for automatic updating and testing of software |
US20040059704A1 (en) * | 2002-09-20 | 2004-03-25 | International Business Machines Corporation | Self-managing computing system |
US7194445B2 (en) | 2002-09-20 | 2007-03-20 | Lenovo (Singapore) Pte. Ltd. | Adaptive problem determination and recovery in a computer system |
US20040059966A1 (en) * | 2002-09-20 | 2004-03-25 | International Business Machines Corporation | Adaptive problem determination and recovery in a computer system |
US20070294386A1 (en) * | 2002-09-20 | 2007-12-20 | Rajarshi Das | Composition Service for Autonomic Computing |
US20040060044A1 (en) * | 2002-09-20 | 2004-03-25 | International Business Machines Corporation | Method and apparatus for automatic updating and testing of software |
US20040059810A1 (en) * | 2002-09-20 | 2004-03-25 | International Business Machines Corporation | Method and apparatus for publishing and monitoring entities providing services in a distributed data processing system |
US8117264B1 (en) * | 2002-10-07 | 2012-02-14 | Yahoo! Inc. | Email system |
US8291032B2 (en) | 2002-10-07 | 2012-10-16 | Yahoo! Inc. | Email system |
US7797170B2 (en) | 2002-11-07 | 2010-09-14 | International Business Machines Corporation | Location based services revenue sharing and cost offsetting |
US20060052921A1 (en) * | 2002-11-07 | 2006-03-09 | Bodin William K | On-demand system for supplemental diagnostic and service resource planning for mobile systems |
US8027843B2 (en) | 2002-11-07 | 2011-09-27 | International Business Machines Corporation | On-demand supplemental diagnostic and service resource planning for mobile systems |
US20080288315A1 (en) * | 2002-11-07 | 2008-11-20 | William Kress Bodin | Location Based Services Revenue Sharing and Cost Offsetting |
US8321467B2 (en) | 2002-12-03 | 2012-11-27 | Jp Morgan Chase Bank | System and method for communicating between an application and a database |
US20070143337A1 (en) * | 2002-12-03 | 2007-06-21 | Mangan John P | Method For Simplifying Databinding In Application Programs |
US20040107183A1 (en) * | 2002-12-03 | 2004-06-03 | Jp Morgan Chase Bank | Method for simplifying databinding in application programs |
US20060059252A1 (en) * | 2002-12-18 | 2006-03-16 | Michiaki Tatsubori | Web service providing system, server device for the same, control method for controlling computer system as server device for web service providing system, program for executing the control method, and recording medium |
US7865595B2 (en) * | 2002-12-18 | 2011-01-04 | International Business Machines Corporation | Processing call requests with respect to objects |
US7555538B2 (en) * | 2002-12-26 | 2009-06-30 | Research In Motion Limited | System and method for building and execution of platform-neutral generic services' client applications |
US20040215700A1 (en) * | 2002-12-26 | 2004-10-28 | Michael Shenfield | System and method for building and execution of platform-neutral generic services' client applications |
US20040254824A1 (en) * | 2003-01-07 | 2004-12-16 | Alex Loucaides | System and method for process scheduling |
US8032439B2 (en) | 2003-01-07 | 2011-10-04 | Jpmorgan Chase Bank, N.A. | System and method for process scheduling |
US10692135B2 (en) | 2003-01-07 | 2020-06-23 | Jpmorgan Chase Bank, N.A. | System and method for process scheduling |
US20090198765A1 (en) * | 2003-01-23 | 2009-08-06 | Verdasys, Inc. | Digital asset usage accountability via event journaling |
US7934091B2 (en) | 2003-01-23 | 2011-04-26 | Verdasys, Inc. | Digital asset usage accountability via event journaling |
US7783614B2 (en) | 2003-02-13 | 2010-08-24 | Microsoft Corporation | Linking elements of a document to corresponding fields, queries and/or procedures in a database |
US7653930B2 (en) | 2003-02-14 | 2010-01-26 | Bea Systems, Inc. | Method for role and resource policy management optimization |
US7992189B2 (en) | 2003-02-14 | 2011-08-02 | Oracle International Corporation | System and method for hierarchical role-based entitlements |
US20040162906A1 (en) * | 2003-02-14 | 2004-08-19 | Griffin Philip B. | System and method for hierarchical role-based entitlements |
US8831966B2 (en) | 2003-02-14 | 2014-09-09 | Oracle International Corporation | Method for delegated administration |
US20060174132A1 (en) * | 2003-02-20 | 2006-08-03 | Bea Systems, Inc. | Federated management of content repositories |
US7562298B2 (en) * | 2003-02-20 | 2009-07-14 | Bea Systems, Inc. | Virtual content repository browser |
US20040167899A1 (en) * | 2003-02-20 | 2004-08-26 | Bea Systems, Inc. | Virtual content repository browser |
US8099779B2 (en) | 2003-02-20 | 2012-01-17 | Oracle International Corporation | Federated management of content repositories |
US7840614B2 (en) | 2003-02-20 | 2010-11-23 | Bea Systems, Inc. | Virtual content repository application program interface |
US7293038B2 (en) | 2003-02-25 | 2007-11-06 | Bea Systems, Inc. | Systems and methods for client-side filtering of subscribed messages |
US20040236780A1 (en) * | 2003-02-25 | 2004-11-25 | Michael Blevins | Systems and methods for client-side filtering of subscribed messages |
US7844636B2 (en) | 2003-02-25 | 2010-11-30 | Oracle International Corporation | Systems and methods for client-side filtering of subscribed messages |
US7752599B2 (en) | 2003-02-25 | 2010-07-06 | Bea Systems Inc. | Systems and methods extending an existing programming language with constructs |
US20040187127A1 (en) * | 2003-02-25 | 2004-09-23 | Albert Gondi | Systems and methods for transaction chaining |
US7584474B2 (en) | 2003-02-25 | 2009-09-01 | Bea Systems, Inc. | Systems and methods for transaction chaining |
US20050022164A1 (en) * | 2003-02-25 | 2005-01-27 | Bea Systems, Inc. | Systems and methods utilizing a workflow definition language |
US20050010902A1 (en) * | 2003-02-25 | 2005-01-13 | Bea Systems, Inc. | Systems and methods extending an existing programming language with constructs |
US7774697B2 (en) | 2003-02-25 | 2010-08-10 | Bea Systems, Inc. | System and method for structuring distributed applications |
US20050240863A1 (en) * | 2003-02-25 | 2005-10-27 | Olander Daryl B | System and method for structuring distributed applications |
US20040230955A1 (en) * | 2003-02-26 | 2004-11-18 | Bea Systems, Inc. | System for multi-language debugging |
US20050114771A1 (en) * | 2003-02-26 | 2005-05-26 | Bea Systems, Inc. | Methods for type-independent source code editing |
US20040250241A1 (en) * | 2003-02-26 | 2004-12-09 | O'neil Edward K. | System and method for dynamic data binding in distributed applications |
US20050034104A1 (en) * | 2003-02-26 | 2005-02-10 | Bea Systems, Inc. | Method for multi-language debugging |
US8032860B2 (en) | 2003-02-26 | 2011-10-04 | Oracle International Corporation | Methods for type-independent source code editing |
US7650276B2 (en) | 2003-02-26 | 2010-01-19 | Bea Systems, Inc. | System and method for dynamic data binding in distributed applications |
US7299454B2 (en) | 2003-02-26 | 2007-11-20 | Bea Systems, Inc. | Method for multi-language debugging |
US7707564B2 (en) | 2003-02-26 | 2010-04-27 | Bea Systems, Inc. | Systems and methods for creating network-based software services using source code annotations |
US20040168153A1 (en) * | 2003-02-26 | 2004-08-26 | Bea Systems, Inc. | Systems and methods for dynamic component versioning |
US20050108682A1 (en) * | 2003-02-26 | 2005-05-19 | Bea Systems, Inc. | Systems for type-independent source code editing |
US20050044173A1 (en) * | 2003-02-28 | 2005-02-24 | Olander Daryl B. | System and method for implementing business processes in a portal |
US7810036B2 (en) | 2003-02-28 | 2010-10-05 | Bea Systems, Inc. | Systems and methods for personalizing a portal |
US7650592B2 (en) | 2003-03-01 | 2010-01-19 | Bea Systems, Inc. | Systems and methods for multi-view debugging environment |
US20040210836A1 (en) * | 2003-03-03 | 2004-10-21 | Canon Kabushiki Kaisha | Method of offering a service provided by a server computer in a communication network |
US7870495B2 (en) * | 2003-03-03 | 2011-01-11 | Canon Kabushiki Kaisha | Method of offering a service provided by a server computer in a communication network |
US7711688B2 (en) * | 2003-03-12 | 2010-05-04 | Microsoft Corporation | Customization of process logic in a software system |
US20060195453A1 (en) * | 2003-03-12 | 2006-08-31 | Microsoft Corporation | Customization of process logic in a software system |
US20060031763A1 (en) * | 2003-03-22 | 2006-02-09 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method relating to access of information |
US20040215725A1 (en) * | 2003-03-31 | 2004-10-28 | Lorraine Love | System and method for multi-platform queue queries |
US20050065743A1 (en) * | 2003-03-31 | 2005-03-24 | Cumming Daniel A. | Methods and apparatus for retrieving energy readings from an energy monitoring device |
US7089089B2 (en) | 2003-03-31 | 2006-08-08 | Power Measurement Ltd. | Methods and apparatus for retrieving energy readings from an energy monitoring device |
US7376746B2 (en) | 2003-04-10 | 2008-05-20 | Hitachi, Ltd. | Method and program for disclosing and providing services on network |
US7711550B1 (en) | 2003-04-29 | 2010-05-04 | Microsoft Corporation | Methods and system for recognizing names in a computer-generated document and for providing helpful actions associated with recognized names |
US20050030555A1 (en) * | 2003-05-16 | 2005-02-10 | Phenix John Kevin | Job processing framework |
US8095659B2 (en) | 2003-05-16 | 2012-01-10 | Jp Morgan Chase Bank | Service interface |
US7739588B2 (en) | 2003-06-27 | 2010-06-15 | Microsoft Corporation | Leveraging markup language data for semantically labeling text strings and data and for providing actions based on semantically labeled text strings and data |
US20080091711A1 (en) * | 2003-07-02 | 2008-04-17 | Snodgrass Ryan J | Predictive prefetching to improve parallelization of document generation subtasks |
US9948531B2 (en) | 2003-07-02 | 2018-04-17 | Amazon Technologies, Inc. | Predictive prefetching to reduce document generation times |
US8566788B2 (en) | 2003-07-02 | 2013-10-22 | Amazon.Com, Inc. | Predictive prefetching to improve parallelization of data retrieval subtasks |
US8136089B2 (en) * | 2003-07-02 | 2012-03-13 | Amazon.Com, Inc. | Predictive prefetching to improve parallelization of document generation subtasks |
US8136025B1 (en) | 2003-07-03 | 2012-03-13 | Google Inc. | Assigning document identification tags |
US9411889B2 (en) | 2003-07-03 | 2016-08-09 | Google Inc. | Assigning document identification tags |
US7331018B2 (en) * | 2003-07-10 | 2008-02-12 | Computer Associates Think, Inc. | System and method for customizing a data display using a presentation profile |
US20050119990A1 (en) * | 2003-07-10 | 2005-06-02 | Lee Patrick R. | System and method for customizing a data display using a presentation profile |
US7945532B2 (en) * | 2003-08-07 | 2011-05-17 | International Business Machines Corporation | System, and program product for rebasing an application |
US20080177785A1 (en) * | 2003-08-07 | 2008-07-24 | Prager Scott H | System, and program product for rebasing an application |
US20050086330A1 (en) * | 2003-08-29 | 2005-04-21 | Michael Perham | Method and apparatus for dynamic, non-intrusive personalization of web services |
US8949311B2 (en) * | 2003-08-29 | 2015-02-03 | International Business Machines Corporation | Dynamic, non-intrusive personalization of web services |
US7752634B1 (en) * | 2003-08-29 | 2010-07-06 | International Business Machines Corporation | Non-intrusive personalization of web services |
US10482513B1 (en) | 2003-09-02 | 2019-11-19 | Vinimaya, Llc | Methods and systems for integrating procurement systems with electronic catalogs |
US8229932B2 (en) | 2003-09-04 | 2012-07-24 | Oracle International Corporation | Storing XML documents efficiently in an RDBMS |
US8694510B2 (en) | 2003-09-04 | 2014-04-08 | Oracle International Corporation | Indexing XML documents efficiently |
US8041687B2 (en) * | 2003-09-30 | 2011-10-18 | International Business Machines Corporation | Dynamic generation of XML Schema for backend driven data validation |
US20050071344A1 (en) * | 2003-09-30 | 2005-03-31 | International Business Machines Corporation | Dynamic generation of XML schema for backend driven data validation |
US20050262362A1 (en) * | 2003-10-10 | 2005-11-24 | Bea Systems, Inc. | Distributed security system policies |
US20050138208A1 (en) * | 2003-12-17 | 2005-06-23 | International Business Machines Corporation | Service oriented integration server architecture |
US7917652B2 (en) | 2003-12-17 | 2011-03-29 | International Business Machines Corporation | Service oriented integration server architecture |
US20090144449A1 (en) * | 2003-12-17 | 2009-06-04 | International Business Machines Corporation | Service Oriented Integration Server Architecture |
US7490168B2 (en) * | 2003-12-17 | 2009-02-10 | International Business Machines Corporation | Service oriented integration server architecture |
US20050144174A1 (en) * | 2003-12-31 | 2005-06-30 | Leonid Pesenson | Framework for providing remote processing of a graphical user interface |
US20050165776A1 (en) * | 2004-01-14 | 2005-07-28 | International Business Machines Corporation | Method and apparatus for validating and configuring database transaction requests from multiple clients |
US7299234B2 (en) * | 2004-01-14 | 2007-11-20 | International Business Machines Corporation | Method and apparatus for validating and configuring database transaction requests from multiple clients |
US7743060B2 (en) | 2004-01-26 | 2010-06-22 | International Business Machines Corporation | Architecture for an indexer |
US7783626B2 (en) | 2004-01-26 | 2010-08-24 | International Business Machines Corporation | Pipelined architecture for global analysis and index building |
US8296304B2 (en) | 2004-01-26 | 2012-10-23 | International Business Machines Corporation | Method, system, and program for handling redirects in a search engine |
US8285724B2 (en) | 2004-01-26 | 2012-10-09 | International Business Machines Corporation | System and program for handling anchor text |
US7266561B2 (en) | 2004-03-18 | 2007-09-04 | International Business Machines Corporation | Method and apparatus for splitting and merging request and response data at runtime |
US20050210053A1 (en) * | 2004-03-18 | 2005-09-22 | International Business Machines Corporation | Method and apparatus for splitting and merging request and response data at runtime |
US20050210004A1 (en) * | 2004-03-18 | 2005-09-22 | International Business Machines Corporation | Method and apparatus for generating query and response statements at runtime from generic requests |
US7225202B2 (en) | 2004-03-18 | 2007-05-29 | International Business Machines Corporation | Method and apparatus for generating query and response statements at runtime from generic requests |
US7774601B2 (en) | 2004-04-06 | 2010-08-10 | Bea Systems, Inc. | Method for delegated administration |
US9734222B1 (en) | 2004-04-06 | 2017-08-15 | Jpmorgan Chase Bank, N.A. | Methods and systems for using script files to obtain, format and transport data |
US10223434B2 (en) | 2004-04-06 | 2019-03-05 | Jpmorgan Chase Bank, N.A. | Methods and systems for using script files to obtain, format and transport data |
US20050251512A1 (en) * | 2004-04-13 | 2005-11-10 | Bea Systems, Inc. | System and method for searching a virtual content repository |
US20050234849A1 (en) * | 2004-04-13 | 2005-10-20 | Bea Systems, Inc. | System and method for content lifecycles |
US20060028252A1 (en) * | 2004-04-13 | 2006-02-09 | Bea Systems, Inc. | System and method for content type management |
US20050228827A1 (en) * | 2004-04-13 | 2005-10-13 | Bea Systems, Inc. | System and method for viewing a virtual content repository |
US20050234942A1 (en) * | 2004-04-13 | 2005-10-20 | Bea Systems, Inc. | System and method for content and schema lifecycles |
US20050251504A1 (en) * | 2004-04-13 | 2005-11-10 | Bea Systems, Inc. | System and method for custom content lifecycles |
US7930277B2 (en) | 2004-04-21 | 2011-04-19 | Oracle International Corporation | Cost-based optimizer for an XML data repository within a database |
US20060031586A1 (en) * | 2004-04-26 | 2006-02-09 | Jp Morgan Chase Bank | System and method for routing messages |
US20050262522A1 (en) * | 2004-05-21 | 2005-11-24 | Paul Gassoway | Method and apparatus for reusing a computer software library |
US7900199B2 (en) * | 2004-05-21 | 2011-03-01 | Computer Associates Think, Inc. | Method and apparatus for reusing a computer software library |
US7516121B2 (en) | 2004-06-23 | 2009-04-07 | Oracle International Corporation | Efficient evaluation of queries using translation |
US7802180B2 (en) | 2004-06-23 | 2010-09-21 | Oracle International Corporation | Techniques for serialization of instances of the XQuery data model |
US7668806B2 (en) | 2004-08-05 | 2010-02-23 | Oracle International Corporation | Processing queries against one or more markup language sources |
US7546370B1 (en) | 2004-08-18 | 2009-06-09 | Google Inc. | Search engine with multiple crawlers sharing cookies |
US8312132B2 (en) * | 2004-08-20 | 2012-11-13 | Core Wireless Licensing S.A.R.L. | Context data in UPNP service information |
US20130173674A1 (en) * | 2004-08-20 | 2013-07-04 | Core Wireless Licensing, S.a.r.l. | Context data in upnp service information |
US8990302B2 (en) * | 2004-08-20 | 2015-03-24 | Core Wireless Licensing S.A.R.L. | Context data in UPNP service information |
US20130173705A1 (en) * | 2004-08-20 | 2013-07-04 | Core Wireless Licensing, S.a.r.l. | Context data in upnp service information |
US8713176B2 (en) * | 2004-08-20 | 2014-04-29 | Core Wireless Licensing S.A.R.L. | Context data in UPNP service information |
US20060059003A1 (en) * | 2004-08-20 | 2006-03-16 | Nokia Corporation | Context data in UPNP service information |
US10476939B2 (en) | 2004-08-20 | 2019-11-12 | Conversant Wireless Licensing S.A R.L. | Context data in UPnP service information |
US8959058B1 (en) * | 2004-09-02 | 2015-02-17 | Symantec Corporation | Linking dynamic computer data protection to an external state |
US9811425B1 (en) | 2004-09-02 | 2017-11-07 | Veritas Technologies Llc | Linking dynamic computer data protection to an external state |
US9171100B2 (en) | 2004-09-22 | 2015-10-27 | Primo M. Pettovello | MTree an XPath multi-axis structure threaded index |
US8655888B2 (en) | 2004-09-24 | 2014-02-18 | International Business Machines Corporation | Searching documents for ranges of numeric values |
US8346759B2 (en) | 2004-09-24 | 2013-01-01 | International Business Machines Corporation | Searching documents for ranges of numeric values |
US8271498B2 (en) | 2004-09-24 | 2012-09-18 | International Business Machines Corporation | Searching documents for ranges of numeric values |
US7890484B1 (en) * | 2004-11-10 | 2011-02-15 | At&T Intellectual Property Ii, L.P. | Method and apparatus for selecting services based on behavior models |
US7496575B2 (en) * | 2004-11-22 | 2009-02-24 | Verdasys, Inc. | Application instrumentation and monitoring |
US20060123101A1 (en) * | 2004-11-22 | 2006-06-08 | Veradasys, Inc. | Application instrumentation and monitoring |
US20060136473A1 (en) * | 2004-12-20 | 2006-06-22 | Lamb James A | Service data organization |
US20060136436A1 (en) * | 2004-12-22 | 2006-06-22 | At&T Corp. | Arrangement enabling thin client to access and present data in custom defined reports |
US7600028B2 (en) | 2005-01-10 | 2009-10-06 | Google Inc. | Methods and systems for opportunistic cookie caching |
US20060156387A1 (en) * | 2005-01-10 | 2006-07-13 | Google Inc. | Methods and systems for opportunistic cookie caching |
WO2006084616A1 (en) * | 2005-02-09 | 2006-08-17 | Deutsche Post Ag | Process and device for controlling access to data systems |
EP1691303A1 (en) * | 2005-02-09 | 2006-08-16 | Deutsche Post AG | Method and system for controlling the access to multiple data systems |
EP1691302A1 (en) * | 2005-02-09 | 2006-08-16 | Deutsche Post AG | Method and system for controlling the access to data systems |
US7523131B2 (en) | 2005-02-10 | 2009-04-21 | Oracle International Corporation | Techniques for efficiently storing and querying in a relational database, XML documents conforming to schemas that contain cyclic constructs |
US20060184878A1 (en) * | 2005-02-11 | 2006-08-17 | Microsoft Corporation | Using a description language to provide a user interface presentation |
US20060184826A1 (en) * | 2005-02-11 | 2006-08-17 | Microsoft Corporation | Using a description language to build a management system |
US7770124B2 (en) | 2005-02-11 | 2010-08-03 | Microsoft Corporation | Using a description language to build a management system |
US20060235840A1 (en) * | 2005-04-19 | 2006-10-19 | Anand Manikutty | Optimization of queries over XML views that are based on union all operators |
US7685150B2 (en) | 2005-04-19 | 2010-03-23 | Oracle International Corporation | Optimization of queries over XML views that are based on union all operators |
US7949941B2 (en) | 2005-04-22 | 2011-05-24 | Oracle International Corporation | Optimizing XSLT based on input XML document structure description and translating XSLT into equivalent XQuery expressions |
US20060248467A1 (en) * | 2005-04-29 | 2006-11-02 | Microsoft Corporation | Framework for declarative expression of data processing |
US7739691B2 (en) * | 2005-04-29 | 2010-06-15 | Microsoft Corporation | Framework for declarative expression of data processing |
US7680800B2 (en) * | 2005-05-20 | 2010-03-16 | International Business Machines Corporation | Algorithm to marshal/unmarshal XML schema annotations to SDO dataobjects |
US20070162466A1 (en) * | 2005-05-20 | 2007-07-12 | International Business Machines Corporation | Algorithm to marshal/unmarshal XML schema annotations to SDO dataobjects |
US20060277189A1 (en) * | 2005-06-02 | 2006-12-07 | Microsoft Corporation | Translation of search result display elements |
US20070011167A1 (en) * | 2005-07-08 | 2007-01-11 | Muralidhar Krishnaprasad | Optimization of queries on a repository based on constraints on how the data is stored in the repository |
US8166059B2 (en) | 2005-07-08 | 2012-04-24 | Oracle International Corporation | Optimization of queries on a repository based on constraints on how the data is stored in the repository |
US8417693B2 (en) | 2005-07-14 | 2013-04-09 | International Business Machines Corporation | Enforcing native access control to indexed documents |
US20070033571A1 (en) * | 2005-08-02 | 2007-02-08 | Sap Ag | Dynamic work center |
US20070033196A1 (en) * | 2005-08-02 | 2007-02-08 | Sap Ag | Service directory |
US20070038649A1 (en) * | 2005-08-11 | 2007-02-15 | Abhyudaya Agrawal | Flexible handling of datetime XML datatype in a database system |
US7406478B2 (en) | 2005-08-11 | 2008-07-29 | Oracle International Corporation | Flexible handling of datetime XML datatype in a database system |
US7818344B2 (en) | 2005-09-26 | 2010-10-19 | Bea Systems, Inc. | System and method for providing nested types for content management |
US8316025B2 (en) | 2005-09-26 | 2012-11-20 | Oracle International Corporation | System and method for providing SPI extensions for content management system |
US7752205B2 (en) | 2005-09-26 | 2010-07-06 | Bea Systems, Inc. | Method and system for interacting with a virtual content repository |
US7992085B2 (en) | 2005-09-26 | 2011-08-02 | Microsoft Corporation | Lightweight reference user interface |
US7788590B2 (en) | 2005-09-26 | 2010-08-31 | Microsoft Corporation | Lightweight reference user interface |
US7953734B2 (en) | 2005-09-26 | 2011-05-31 | Oracle International Corporation | System and method for providing SPI extensions for content management system |
US7917537B2 (en) | 2005-09-26 | 2011-03-29 | Oracle International Corporation | System and method for providing link property types for content management |
US8554789B2 (en) | 2005-10-07 | 2013-10-08 | Oracle International Corporation | Managing cyclic constructs of XML schema in a rdbms |
US9367642B2 (en) | 2005-10-07 | 2016-06-14 | Oracle International Corporation | Flexible storage of XML collections within an object-relational database |
US8073841B2 (en) | 2005-10-07 | 2011-12-06 | Oracle International Corporation | Optimizing correlated XML extracts |
US20070083529A1 (en) * | 2005-10-07 | 2007-04-12 | Oracle International Corporation | Managing cyclic constructs of XML schema in a rdbms |
US20070083538A1 (en) * | 2005-10-07 | 2007-04-12 | Roy Indroniel D | Generating XML instances from flat files |
US8024368B2 (en) | 2005-10-07 | 2011-09-20 | Oracle International Corporation | Generating XML instances from flat files |
US8572201B2 (en) | 2005-11-09 | 2013-10-29 | Ca, Inc. | System and method for providing a directory service network |
US9922031B2 (en) | 2005-11-09 | 2018-03-20 | Ca, Inc. | System and method for efficient directory performance using non-persistent storage |
US20070118632A1 (en) * | 2005-11-09 | 2007-05-24 | Computer Associates Think, Inc. | System and method for providing a directory service network |
US8478898B2 (en) | 2005-11-09 | 2013-07-02 | Ca, Inc. | System and method for routing directory service operations in a directory service network |
WO2007056766A3 (en) * | 2005-11-09 | 2008-04-10 | Computer Ass Think Inc | System and method for efficient directory performance using non-persistent storage |
WO2007056766A2 (en) * | 2005-11-09 | 2007-05-18 | Computer Associates Think, Inc. | System and method for efficient directory performance using non-persistent storage |
US20070106815A1 (en) * | 2005-11-09 | 2007-05-10 | Computer Associates Think, Inc. | System and method for routing directory service operations in a directory service network |
US7664742B2 (en) | 2005-11-14 | 2010-02-16 | Pettovello Primo M | Index data structure for a peer-to-peer network |
US8166074B2 (en) | 2005-11-14 | 2012-04-24 | Pettovello Primo M | Index data structure for a peer-to-peer network |
US7739228B1 (en) | 2005-12-20 | 2010-06-15 | At&T Intellectual Property Ii, L.P. | Method of generating a services repository using a target services roadmap |
US8024397B1 (en) * | 2005-12-20 | 2011-09-20 | At&T Intellectual Property Ii, L.P. | System for generating a services repository using a target services roadmap |
US7730123B1 (en) | 2005-12-20 | 2010-06-01 | At&T Intellectual Property Ii, Lp | Software application implemented using services from a services repository generated using a target services roadmap |
US20070294056A1 (en) * | 2006-06-16 | 2007-12-20 | Jpmorgan Chase Bank, N.A. | Method and system for monitoring non-occurring events |
US20080005093A1 (en) * | 2006-07-03 | 2008-01-03 | Zhen Hua Liu | Techniques of using a relational caching framework for efficiently handling XML queries in the mid-tier data caching |
US7979320B2 (en) | 2006-08-15 | 2011-07-12 | Microsoft Corporation | Automated acquisition and configuration of goods and services via a network |
US8090766B2 (en) | 2006-08-15 | 2012-01-03 | Microsoft Corporation | System and method to identify, rank, and audit network provided configurables |
US20080046328A1 (en) * | 2006-08-15 | 2008-02-21 | Microsoft Corporation | Automated acquisition and configuration of goods and services via a network |
US20080046550A1 (en) * | 2006-08-15 | 2008-02-21 | Microsoft Corporation | Message based network transmission for selection and auditing of internet services |
US20080046569A1 (en) * | 2006-08-15 | 2008-02-21 | Microsoft Corporation | System and method to identify, rank, and audit network provided configurables |
US8055747B2 (en) * | 2006-08-15 | 2011-11-08 | Microsoft Corporation | Message based network transmission for selection and auditing of internet services |
US20080071727A1 (en) * | 2006-09-18 | 2008-03-20 | Emc Corporation | Environment classification |
US20190377745A1 (en) * | 2006-09-18 | 2019-12-12 | EMC IP Holding Company LLC | Cascaded discovery of information environment |
US8938457B2 (en) | 2006-09-18 | 2015-01-20 | Emc Corporation | Information classification |
US9135322B2 (en) | 2006-09-18 | 2015-09-15 | Emc Corporation | Environment classification |
US11846978B2 (en) * | 2006-09-18 | 2023-12-19 | EMC IP Holding Company LLC | Cascaded discovery of information environment |
US20080071726A1 (en) * | 2006-09-18 | 2008-03-20 | Emc Corporation | Cascaded discovery of information environment |
US8832246B2 (en) | 2006-09-18 | 2014-09-09 | Emc Corporation | Service level mapping method |
US9361354B1 (en) | 2006-09-18 | 2016-06-07 | Emc Corporation | Hierarchy of service areas |
US10394849B2 (en) * | 2006-09-18 | 2019-08-27 | EMC IP Holding Company LLC | Cascaded discovery of information environment |
US8621639B1 (en) * | 2006-09-28 | 2013-12-31 | Whitehat Security, Inc. | Using fuzzy classification models to perform matching operations in a web application security scanner |
US8463852B2 (en) | 2006-10-06 | 2013-06-11 | Oracle International Corporation | Groupware portlets for integrating a portal with groupware systems |
US7797310B2 (en) | 2006-10-16 | 2010-09-14 | Oracle International Corporation | Technique to estimate the cost of streaming evaluation of XPaths |
US20080109292A1 (en) * | 2006-11-03 | 2008-05-08 | Sap Ag | Voice-enabled workflow item interface |
US20080201776A1 (en) * | 2007-02-21 | 2008-08-21 | Hewlett Packard Company | Method And Computing System For Avoiding Denial Of Service Attacks |
WO2008112103A1 (en) * | 2007-03-07 | 2008-09-18 | Ianywhere Solutions, Inc. | Selectively updating web pages on a mobile client |
US8321875B2 (en) | 2007-03-07 | 2012-11-27 | Ianywhere Solutions, Inc. | Selectively updating web pages on a mobile client |
US20100299676A1 (en) * | 2007-03-07 | 2010-11-25 | Ianywhere Solutions, Inc. | Selectively updating web pages on a mobile client |
US7774788B2 (en) | 2007-03-07 | 2010-08-10 | Ianywhere Solutions, Inc. | Selectively updating web pages on a mobile client |
US20080235708A1 (en) * | 2007-03-07 | 2008-09-25 | Ianywhere Solutions, Inc. | Selectively updating web pages on a mobile client |
US8276167B2 (en) * | 2007-03-21 | 2012-09-25 | International Business Machines Corporation | Distributed pluggable middleware services |
US20080235710A1 (en) * | 2007-03-21 | 2008-09-25 | International Business Machines Corporation | Distributed Pluggable Middleware Services |
US20090171974A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US9071623B2 (en) | 2007-09-28 | 2015-06-30 | Xcerion Aktiebolag | Real-time data sharing |
US11838358B2 (en) | 2007-09-28 | 2023-12-05 | Xcerion Aktiebolag | Network operating system |
US20090172078A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US9461890B1 (en) | 2007-09-28 | 2016-10-04 | Emc Corporation | Delegation of data management policy in an information management system |
US8615531B2 (en) | 2007-09-28 | 2013-12-24 | Xcerion Aktiebolag | Programmatic data manipulation |
US20090172086A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US8620863B2 (en) | 2007-09-28 | 2013-12-31 | Xcerion Aktiebolag | Message passing in a collaborative environment |
US20090193440A1 (en) * | 2007-09-28 | 2009-07-30 | Xcerion Aktiebolag | Network operating system |
US20090192992A1 (en) * | 2007-09-28 | 2009-07-30 | Xcerion Aktiebolag | Network operating system |
US20090193410A1 (en) * | 2007-09-28 | 2009-07-30 | Xcerion Aktiebolag | Network operating system |
US8688627B2 (en) | 2007-09-28 | 2014-04-01 | Xcerion Aktiebolag | Transaction propagation in a networking environment |
US20090172715A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US20090157628A1 (en) * | 2007-09-28 | 2009-06-18 | Xcerion Ab | Network operating system |
US20090158142A1 (en) * | 2007-09-28 | 2009-06-18 | Xcerion Ab | Network operating system |
US8738567B2 (en) | 2007-09-28 | 2014-05-27 | Xcerion Aktiebolag | Network file system with enhanced collaboration features |
US8156146B2 (en) | 2007-09-28 | 2012-04-10 | Xcerion Aktiebolag | Network file system |
US8819212B1 (en) * | 2007-09-28 | 2014-08-26 | Emc Corporation | Delegation of data classification using common language |
US20090175198A1 (en) * | 2007-09-28 | 2009-07-09 | Xcerion Ab | Network operating system |
US20090177734A1 (en) * | 2007-09-28 | 2009-07-09 | Xcerion Ab | Network operating system |
US20090157627A1 (en) * | 2007-09-28 | 2009-06-18 | Xcerion Ab | Network operating system |
US8843942B2 (en) | 2007-09-28 | 2014-09-23 | Xcerion Aktiebolag | Interpreting semantic application code |
US8239511B2 (en) | 2007-09-28 | 2012-08-07 | Xcerion Aktiebolag | Network operating system |
US8868720B1 (en) | 2007-09-28 | 2014-10-21 | Emc Corporation | Delegation of discovery functions in information management system |
US9344497B2 (en) | 2007-09-28 | 2016-05-17 | Xcerion Aktiebolag | State management of applications and data |
US9323901B1 (en) | 2007-09-28 | 2016-04-26 | Emc Corporation | Data classification for digital rights management |
US9621649B2 (en) | 2007-09-28 | 2017-04-11 | Xcerion Aktiebolag | Network operating system |
US20090164592A1 (en) * | 2007-09-28 | 2009-06-25 | Xcerion Ab | Network operating system |
US20090172568A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US20090171993A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US8954526B2 (en) | 2007-09-28 | 2015-02-10 | Xcerion Aktiebolag | Network operating system |
US8959123B2 (en) | 2007-09-28 | 2015-02-17 | Xcerion Aktiebolag | User interface framework |
US20090172702A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US20090172087A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US8996459B2 (en) | 2007-09-28 | 2015-03-31 | Xcerion Aktiebolag | Offline and/or client-side execution of a network application |
US8234315B2 (en) | 2007-09-28 | 2012-07-31 | Xcerion Aktiebolag | Data source abstraction system and method |
US9141658B1 (en) | 2007-09-28 | 2015-09-22 | Emc Corporation | Data classification and management for risk mitigation |
US20090172085A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US8280925B2 (en) | 2007-09-28 | 2012-10-02 | Xcerion Aktiebolag | Resolution of multi-instance application execution |
US8302208B1 (en) | 2007-11-16 | 2012-10-30 | Open Invention Network Llc | Compliance validator for restricted network access control |
US7966665B1 (en) | 2007-11-16 | 2011-06-21 | Open Invention Network, Llc | Compliance validator for restricted network access control |
US20090164500A1 (en) * | 2007-12-20 | 2009-06-25 | Ankur Mathur | System for providing a configurable adaptor for mediating systems |
US20100056043A1 (en) * | 2007-12-21 | 2010-03-04 | Ibiquity Digital Corporation | Radio Service Registry |
US8521079B2 (en) | 2007-12-21 | 2013-08-27 | Ibiquity Digital Corporation | Radio service registry |
US7958112B2 (en) | 2008-08-08 | 2011-06-07 | Oracle International Corporation | Interleaving query transformations for XML indexes |
US20100125666A1 (en) * | 2008-11-14 | 2010-05-20 | Microsoft Corporation | Service facade design and implementation |
US8407346B2 (en) * | 2008-11-14 | 2013-03-26 | Microsoft Corporation | Service facade design and implementation |
US8874701B2 (en) * | 2008-12-22 | 2014-10-28 | Sap Se | On-demand provisioning of services running on embedded devices |
US20100161778A1 (en) * | 2008-12-22 | 2010-06-24 | Sap Ag | On-demand provisioning of services running on embedded devices |
US9704134B2 (en) | 2008-12-31 | 2017-07-11 | Sap Se | System and method of consolidated central user administrative provisioning |
US20100169488A1 (en) * | 2008-12-31 | 2010-07-01 | Sap Ag | System and method of consolidated central user administrative provisioning |
US8788666B2 (en) * | 2008-12-31 | 2014-07-22 | Sap Ag | System and method of consolidated central user administrative provisioning |
US10528574B2 (en) | 2009-01-23 | 2020-01-07 | Zakta, LLC | Topical trust network |
US11250076B1 (en) | 2009-01-23 | 2022-02-15 | Zakta Llc | Topical search portal |
US10191982B1 (en) | 2009-01-23 | 2019-01-29 | Zakata, LLC | Topical search portal |
US11860954B1 (en) | 2009-01-23 | 2024-01-02 | Zakta, LLC | Collaboratively finding, organizing and/or accessing information |
US8391884B2 (en) * | 2009-03-26 | 2013-03-05 | Andrew Llc | System and method for managing created location contexts in a location server |
US9031908B1 (en) * | 2009-03-31 | 2015-05-12 | Symantec Corporation | Method and apparatus for simultaneous comparison of multiple backup sets maintained in a computer system |
US8631028B1 (en) | 2009-10-29 | 2014-01-14 | Primo M. Pettovello | XPath query processing improvements |
US8874745B2 (en) * | 2010-03-26 | 2014-10-28 | Fujitsu Limited | Method and system for providing services |
US20110238837A1 (en) * | 2010-03-26 | 2011-09-29 | Fujitsu Limited | Method and System for Providing Services |
US9002801B2 (en) * | 2010-03-29 | 2015-04-07 | Software Ag | Systems and/or methods for distributed data archiving amongst a plurality of networked computing devices |
US20110238935A1 (en) * | 2010-03-29 | 2011-09-29 | Software Ag | Systems and/or methods for distributed data archiving |
US10861069B2 (en) | 2010-12-02 | 2020-12-08 | Coupa Software Incorporated | Methods and systems to maintain, check, report, and audit contract and historical pricing in electronic procurement |
US9374437B2 (en) * | 2010-12-30 | 2016-06-21 | Sap Se | Schema validation proxy |
US8832304B2 (en) * | 2011-07-07 | 2014-09-09 | Ipc Systems, Inc. | Protocol agnostic notification system |
US20130013804A1 (en) * | 2011-07-07 | 2013-01-10 | Ipc Systems, Inc. | Protocol agnostic notification system |
US20130060797A1 (en) * | 2011-09-07 | 2013-03-07 | Paul Saunier | Data transformation method and system |
US8844015B2 (en) * | 2012-01-31 | 2014-09-23 | Hewlett-Packard Development Company, L.P. | Application-access authentication agent |
US20130198828A1 (en) * | 2012-01-31 | 2013-08-01 | Eric Addkison Pendergrass | Application-access authentication agent |
US11562419B2 (en) | 2012-02-17 | 2023-01-24 | Ebay Inc. | Updating of stored item data via a remote computing system |
US20170124632A1 (en) * | 2012-02-17 | 2017-05-04 | Ebay Inc. | Electronic commerce file system |
US10699324B2 (en) * | 2012-02-17 | 2020-06-30 | Ebay Inc. | Updating of stored item data via a remote computing system |
US11755611B2 (en) * | 2014-05-05 | 2023-09-12 | Aveva Software, Llc | Storing and identifying content through content descriptors in a historian system |
US11467890B2 (en) | 2014-09-30 | 2022-10-11 | Amazon Technologies, Inc. | Processing event messages for user requests to execute program code |
US11561811B2 (en) | 2014-09-30 | 2023-01-24 | Amazon Technologies, Inc. | Threading as a service |
US11263034B2 (en) * | 2014-09-30 | 2022-03-01 | Amazon Technologies, Inc. | Low latency computational capacity provisioning |
US10956185B2 (en) | 2014-09-30 | 2021-03-23 | Amazon Technologies, Inc. | Threading as a service |
US20190155629A1 (en) * | 2014-09-30 | 2019-05-23 | Amazon Technologies, Inc. | Low latency computational capacity provisioning |
US10915371B2 (en) | 2014-09-30 | 2021-02-09 | Amazon Technologies, Inc. | Automatic management of low latency computational capacity |
US10884802B2 (en) | 2014-09-30 | 2021-01-05 | Amazon Technologies, Inc. | Message-based computation request scheduling |
US10824484B2 (en) | 2014-09-30 | 2020-11-03 | Amazon Technologies, Inc. | Event-driven computing |
US9904739B2 (en) * | 2014-10-02 | 2018-02-27 | Institute For Information Industry | Service provider system and service provider method |
CN105681378A (en) * | 2014-10-02 | 2016-06-15 | 财团法人资讯工业策进会 | Service providing system and service providing method |
US20160098491A1 (en) * | 2014-10-02 | 2016-04-07 | Institute For Information Industry | Service provider system and service provider method |
US11126469B2 (en) | 2014-12-05 | 2021-09-21 | Amazon Technologies, Inc. | Automatic determination of resource sizing |
US11360793B2 (en) | 2015-02-04 | 2022-06-14 | Amazon Technologies, Inc. | Stateful virtual compute system |
US10853112B2 (en) | 2015-02-04 | 2020-12-01 | Amazon Technologies, Inc. | Stateful virtual compute system |
US11461124B2 (en) | 2015-02-04 | 2022-10-04 | Amazon Technologies, Inc. | Security protocols for low latency execution of program code |
US10776171B2 (en) | 2015-04-08 | 2020-09-15 | Amazon Technologies, Inc. | Endpoint management system and virtual compute system |
US11030332B1 (en) * | 2015-04-13 | 2021-06-08 | Wells Fargo Bank, N.A. | Database controlled web service type architecture |
US10652201B1 (en) * | 2015-05-04 | 2020-05-12 | EMC IP Holding Company LLC | Cloud service registry |
TWI577155B (en) * | 2015-08-28 | 2017-04-01 | Chunghwa Telecom Co Ltd | Network service management system and method |
US11243819B1 (en) | 2015-12-21 | 2022-02-08 | Amazon Technologies, Inc. | Acquisition and maintenance of compute capacity |
US11016815B2 (en) | 2015-12-21 | 2021-05-25 | Amazon Technologies, Inc. | Code execution request routing |
US11132213B1 (en) | 2016-03-30 | 2021-09-28 | Amazon Technologies, Inc. | Dependency-based process of pre-existing data sets at an on demand code execution environment |
US10891145B2 (en) | 2016-03-30 | 2021-01-12 | Amazon Technologies, Inc. | Processing pre-existing data sets at an on demand code execution environment |
US11354169B2 (en) | 2016-06-29 | 2022-06-07 | Amazon Technologies, Inc. | Adjusting variable limit on concurrent code executions |
US20180046630A1 (en) * | 2016-08-12 | 2018-02-15 | Invensys Systems, Inc. | Storing and identifying content through content descriptors in a historian system |
US10884787B1 (en) | 2016-09-23 | 2021-01-05 | Amazon Technologies, Inc. | Execution guarantees in an on-demand network code execution system |
US11182505B2 (en) | 2017-05-31 | 2021-11-23 | Intuit Inc. | System for managing transactional data |
US10643178B1 (en) | 2017-06-16 | 2020-05-05 | Coupa Software Incorporated | Asynchronous real-time procurement system |
US11755393B2 (en) | 2017-09-30 | 2023-09-12 | Oracle International Corporation | API registry in a container platform for automatically generating client code libraries |
US10824489B2 (en) | 2017-09-30 | 2020-11-03 | Oracle International Corporation | Dynamic node rebalancing between container platforms |
US10838788B2 (en) | 2017-09-30 | 2020-11-17 | Oracle International Corporation | Real-time debugging instances in a deployed container platform |
US10599500B2 (en) | 2017-09-30 | 2020-03-24 | Oracle International Corporation | API registry in a container platform for automatically generating client code libraries |
US10599499B2 (en) | 2017-09-30 | 2020-03-24 | Oracle International Corporation | API registry in a container platform providing property-based API functionality |
US11681573B2 (en) | 2017-09-30 | 2023-06-20 | Oracle International Corporation | API registry in a container platform providing property-based API functionality |
US11132241B2 (en) | 2017-09-30 | 2021-09-28 | Oracle International Corporation | API registry in a container platform for automatically generating client code libraries |
US10733085B1 (en) | 2018-02-05 | 2020-08-04 | Amazon Technologies, Inc. | Detecting impedance mismatches due to cross-service calls |
US10831898B1 (en) | 2018-02-05 | 2020-11-10 | Amazon Technologies, Inc. | Detecting privilege escalations in code including cross-service calls |
US10725752B1 (en) | 2018-02-13 | 2020-07-28 | Amazon Technologies, Inc. | Dependency handling in an on-demand network code execution system |
US10776091B1 (en) | 2018-02-26 | 2020-09-15 | Amazon Technologies, Inc. | Logging endpoint in an on-demand code execution system |
US11875173B2 (en) | 2018-06-25 | 2024-01-16 | Amazon Technologies, Inc. | Execution of auxiliary functions in an on-demand network code execution system |
US10884722B2 (en) | 2018-06-26 | 2021-01-05 | Amazon Technologies, Inc. | Cross-environment application of tracing information for improved code execution |
US11146569B1 (en) | 2018-06-28 | 2021-10-12 | Amazon Technologies, Inc. | Escalation-resistant secure network services using request-scoped authentication information |
US10949237B2 (en) | 2018-06-29 | 2021-03-16 | Amazon Technologies, Inc. | Operating system customization in an on-demand network code execution system |
US11099870B1 (en) | 2018-07-25 | 2021-08-24 | Amazon Technologies, Inc. | Reducing execution times in an on-demand network code execution system using saved machine states |
US11836516B2 (en) | 2018-07-25 | 2023-12-05 | Amazon Technologies, Inc. | Reducing execution times in an on-demand network code execution system using saved machine states |
US11099917B2 (en) | 2018-09-27 | 2021-08-24 | Amazon Technologies, Inc. | Efficient state maintenance for execution environments in an on-demand code execution system |
US11243953B2 (en) | 2018-09-27 | 2022-02-08 | Amazon Technologies, Inc. | Mapreduce implementation in an on-demand network code execution system and stream data processing system |
US11943093B1 (en) | 2018-11-20 | 2024-03-26 | Amazon Technologies, Inc. | Network connection recovery after virtual machine transition in an on-demand network code execution system |
US11526505B2 (en) * | 2018-12-10 | 2022-12-13 | Teradata Us, Inc. | Enabling cross-platform query optimization via expressive markup language |
US10884812B2 (en) | 2018-12-13 | 2021-01-05 | Amazon Technologies, Inc. | Performance-based hardware emulation in an on-demand network code execution system |
US11010188B1 (en) | 2019-02-05 | 2021-05-18 | Amazon Technologies, Inc. | Simulated data object storage using on-demand computation of data objects |
US11861386B1 (en) | 2019-03-22 | 2024-01-02 | Amazon Technologies, Inc. | Application gateways in an on-demand network code execution system |
US11714675B2 (en) | 2019-06-20 | 2023-08-01 | Amazon Technologies, Inc. | Virtualization-based transaction handling in an on-demand network code execution system |
US11119809B1 (en) | 2019-06-20 | 2021-09-14 | Amazon Technologies, Inc. | Virtualization-based transaction handling in an on-demand network code execution system |
US11159528B2 (en) | 2019-06-28 | 2021-10-26 | Amazon Technologies, Inc. | Authentication to network-services using hosted authentication information |
US11115404B2 (en) | 2019-06-28 | 2021-09-07 | Amazon Technologies, Inc. | Facilitating service connections in serverless code executions |
US11190609B2 (en) | 2019-06-28 | 2021-11-30 | Amazon Technologies, Inc. | Connection pooling for scalable network services |
US10996961B2 (en) | 2019-09-27 | 2021-05-04 | Amazon Technologies, Inc. | On-demand indexing of data in input path of object storage service |
US11416628B2 (en) | 2019-09-27 | 2022-08-16 | Amazon Technologies, Inc. | User-specific data manipulation system for object storage service based on user-submitted code |
US11394761B1 (en) | 2019-09-27 | 2022-07-19 | Amazon Technologies, Inc. | Execution of user-submitted code on a stream of data |
US11386230B2 (en) | 2019-09-27 | 2022-07-12 | Amazon Technologies, Inc. | On-demand code obfuscation of data in input path of object storage service |
US11360948B2 (en) | 2019-09-27 | 2022-06-14 | Amazon Technologies, Inc. | Inserting owner-specified data processing pipelines into input/output path of object storage service |
US11550944B2 (en) | 2019-09-27 | 2023-01-10 | Amazon Technologies, Inc. | Code execution environment customization system for object storage service |
US11860879B2 (en) | 2019-09-27 | 2024-01-02 | Amazon Technologies, Inc. | On-demand execution of object transformation code in output path of object storage service |
US10908927B1 (en) | 2019-09-27 | 2021-02-02 | Amazon Technologies, Inc. | On-demand execution of object filter code in output path of object storage service |
US11263220B2 (en) | 2019-09-27 | 2022-03-01 | Amazon Technologies, Inc. | On-demand execution of object transformation code in output path of object storage service |
US11023416B2 (en) | 2019-09-27 | 2021-06-01 | Amazon Technologies, Inc. | Data access control system for object storage service based on owner-defined code |
US11250007B1 (en) | 2019-09-27 | 2022-02-15 | Amazon Technologies, Inc. | On-demand execution of object combination code in output path of object storage service |
US11656892B1 (en) | 2019-09-27 | 2023-05-23 | Amazon Technologies, Inc. | Sequential execution of user-submitted code and native functions |
US11023311B2 (en) | 2019-09-27 | 2021-06-01 | Amazon Technologies, Inc. | On-demand code execution in input path of data uploaded to storage service in multiple data portions |
US11055112B2 (en) | 2019-09-27 | 2021-07-06 | Amazon Technologies, Inc. | Inserting executions of owner-specified code into input/output path of object storage service |
US11106477B2 (en) | 2019-09-27 | 2021-08-31 | Amazon Technologies, Inc. | Execution of owner-specified code during input/output path to object storage service |
US10942795B1 (en) | 2019-11-27 | 2021-03-09 | Amazon Technologies, Inc. | Serverless call distribution to utilize reserved capacity without inhibiting scaling |
US11119826B2 (en) | 2019-11-27 | 2021-09-14 | Amazon Technologies, Inc. | Serverless call distribution to implement spillover while avoiding cold starts |
US11714682B1 (en) | 2020-03-03 | 2023-08-01 | Amazon Technologies, Inc. | Reclaiming computing resources in an on-demand code execution system |
US11188391B1 (en) | 2020-03-11 | 2021-11-30 | Amazon Technologies, Inc. | Allocating resources to on-demand code executions under scarcity conditions |
US11775640B1 (en) | 2020-03-30 | 2023-10-03 | Amazon Technologies, Inc. | Resource utilization-based malicious task detection in an on-demand code execution system |
US11586459B2 (en) * | 2020-04-01 | 2023-02-21 | Vmware, Inc. | Generating and preserving default configurations of a system |
CN111797340A (en) * | 2020-06-10 | 2020-10-20 | 浙江大学 | Service packaging system for user-defined extraction flow |
CN111930474A (en) * | 2020-07-30 | 2020-11-13 | 杭州当虹科技股份有限公司 | Concurrency limiting method of single service interface based on java atomic operation |
US11593270B1 (en) | 2020-11-25 | 2023-02-28 | Amazon Technologies, Inc. | Fast distributed caching using erasure coded object parts |
US11550713B1 (en) | 2020-11-25 | 2023-01-10 | Amazon Technologies, Inc. | Garbage collection in distributed systems using life cycled storage roots |
US11388210B1 (en) | 2021-06-30 | 2022-07-12 | Amazon Technologies, Inc. | Streaming analytics using a serverless compute system |
US11968280B1 (en) | 2021-11-24 | 2024-04-23 | Amazon Technologies, Inc. | Controlling ingestion of streaming data to serverless function executions |
Also Published As
Publication number | Publication date |
---|---|
US7472349B1 (en) | 2008-12-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7472349B1 (en) | Dynamic services infrastructure for allowing programmatic access to internet and other resources | |
US7496637B2 (en) | Web service syndication system | |
US7457815B2 (en) | Method and apparatus for automatically providing network services | |
KR100600959B1 (en) | Provisioning aggregated services in a distributed computing environment | |
US6978461B2 (en) | System and method for accessing functionality of a backend system from an application server | |
US7895262B2 (en) | Web service application protocol and SOAP processing model | |
US20080208806A1 (en) | Techniques for a web services data access layer | |
US20030061256A1 (en) | Method and system for generalized and adaptive transaction processing between uniform information services and applications | |
US20070011126A1 (en) | Service-oriented architecture | |
US20030105884A1 (en) | System and method for using Web services with an enterprise system | |
WO2001052056A2 (en) | Method and apparatus for a business applications management system platform | |
US7428756B2 (en) | Access control over dynamic intellectual capital content | |
US20040230982A1 (en) | Assembly of business process using intellectual capital processing | |
US20040230567A1 (en) | Integrating intellectual capital into an intellectual capital management system | |
US20040230691A1 (en) | Evolutionary development of intellectual capital in an intellectual capital management system | |
US20040230618A1 (en) | Business intelligence using intellectual capital | |
Yu et al. | Web Services: XML‐based system integrated techniques | |
Hansen et al. | Web services: an architectural overview | |
US20040230603A1 (en) | Registration and control of intellectual capital | |
US20040230588A1 (en) | Methods and systems for publishing and subscribing to intellectual capital | |
Bih | Deploy XML-based network management approach | |
US20040230590A1 (en) | Asynchronous intellectual capital query system | |
US20040230465A1 (en) | Intellectual capital sharing | |
US20040230591A1 (en) | Enabling active intellectual capital processing to enable data neutrality | |
US20040230589A1 (en) | Integrating intellectual capital through abstraction |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ORACLE CORPORATION;REEL/FRAME:016797/0172 Effective date: 20051115 Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ORACLE CORPORATION;REEL/FRAME:017366/0283 Effective date: 20051115 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |