International Business Machines Corporation

Gopal Krishnan

Chaitanya Laxminarayan

Matthew Sanchez

Sanjay F Kottaram

Manoj Saxena

Christopher Sanchez

Joel Trunick

Steven Teleki

Russell Scott

Amrish Chaubal

Sanjay Francis

A SOBA lifecycle methodology is provided for assembling and maintaining service-oriented business applications (SOBAs) for effective functionality and interoperability. SOBAs are loosely coupled business processes and applications in which all functions are defined as independent, semantically-aware business services, with distributed assembly from a global chain of providers. One useful prerequisite for the methodology is analyzing the associated SOA (service-oriented architecture) strategy and infrastructure such as the hardware, software, human resources, and deployment strategy. A second prerequisite is analyzing the associated SOA governance process for how all the resources of the SOBA will work together. Governance refers to design, release, run-time, and manage-time functions. The SOBA lifecycle methodology comprises selecting business functions and processes for the SOBA; populating a business services catalog with information about the SOBA and its components; developing and configuring the SOBA; testing and deploying components of the SOBA; setting up and operating the SOBA; and maintaining the SOBA.

Loosely coupled applications lifecycle methodology

Electronic data interchange (EDI) documents are validated by creating an inventory of all rules, dynamically adjusting the inventory based upon entity specific rules derived from a plurality of companion guides, determining a profile containing pointers to select rules in the inventory for each companion guide and storing the profile for each companion guide in a storage. A runtime checker can then be used to check a received EDI document with a corresponding rule set, forward the EDI document if the EDI document matches its current rule set and return the EDI document if the EDI document does not match its current rule set. EDI rules may be enforced, for example, by determining entity-specific rules from corresponding companion guides, by expressing each rule in a neutral and machine readable format, by classifying the rules and/or by creating an inventory of rules and pointers to entity-specific rules.

Cascading definition and support of EDI rules

An autodiscovery feature with an easy-to-use interface is provided to automatically collect metadata about electronic services for use within a business enterprise and to store that metadata in a metadata repository. The autodiscovery feature is used to create autodiscovery queries that are sent to electronic services to collect from the services' digests specified metadata useful for identifying the functionality of those services and integrating the services into business processes. Digests, such as RSS feeds and Atom feeds, are typically created by services to include useful metadata, such as the title of a service, the URL link to a description of the service, a brief description of the service, the publication date of the service, and other data. Autodiscovery queries can thus collect services' relevant metadata and store it in a business enterprise's metadata repository, so that the services' functionality can be quickly identified and used for business processes.

Autodiscovery of business services

An eligibility and benefits (EB) personalization engine, metadata storage and a portal Web page are set up on a server. EB personalization profiles are set up and stored in metadata storage that specify, according to useful descriptors, personalized information that identifies the EB data of insurance companies that is relevant to particular health care providers. An EB filtering rules database is created to store the filtering rules of multiple insurance companies, where the rules are categorized by the same descriptors used in the EB personalization profiles. After receiving a provider's specific request for an insurance company's EB data for a patient's treatment, the EB personalization engine receives the full collection of EB data from the insurance company, uses the provider's EB profile and the EB filtering rules to select the correct EB data for the provider, and sends the provider that selected data.

Personalizing eligibility and benefits responses based on user profiles

A smart node is integrated with each Web service in a Web service application chain to automatically supply compatible features, missing functionality, and orchestration of the processes in the application, without coordination by an orchestration engine, in an embodiment. A smart node is a software program that systematically specifies the communications dimensions, functionality, and orchestration required for interoperability among Web services. The communications parameters, backup functionality, and process orchestration required for the Web services in a Web service application may be predetermined and programmed into smart nodes. The smart nodes are subsequently integrated with the Web services in a Web service application so that communications among the Web services occur first through the smart nodes. The smart nodes can thus supply communications parameters, any missing functionality, and dynamic process orchestration based on the current event context of the Web service application. A smart node further enables a Web service to supply different functionality in different contexts.

Smart nodes for Web services

A method for automatic parallel processing of the steps involved in composing electronic responses to structured electronic requests where the request and the response contain some common fields of information. The process starts subsequent processing steps before the validation of the request is complete. A structurally complete, but partial response to a request is prepared as soon as it is possible to construct that response structure. The response structure is determined from personalization factors for the requestor, and a response template is created. The personalized response document is a skeleton created with known data from the minimum validation of the request, and with placeholders for data that has not yet been determined. The response is selectively populated with data from the request when the format of the response is determined. As additional information becomes available during the processing of the request, that additional data is placed into the response structure.

Parallel composition of electronic responses to electronic requests

Smart nodes for providing interoperability among a plurality of web services in a chain and dynamically orchestrating associated processes

An efficient organizer of companion guide rules is created by a validation application from the common set of rules among an industry's implementation guide and the rulebooks, such as companion guides of one or more entities, such as payers. The organizer of companion guide rules creates an inventory of all rules and a profile for each companion guide and stores each profile in metadata storage. Each profile contains pointers to code in the inventory for all the rules employed by the corresponding companion guide. After an EDI document reaches the validation application, a runtime checker engine checks metadata storage for a current rule set for the payer. A rule set is created the first time a profile is accessed during the validation process and whenever the profile is updated. The runtime checker engine attempts to validate the EDI document by comparing it to the current rule set for a payer's companion guide.

Growing community of inventors

Austin, TX, United States of America

Gopal Krishnan