US20150261595A1 - System and method for definition, creation, management, transmission, and monitoring of errors in soa environment - Google Patents
System and method for definition, creation, management, transmission, and monitoring of errors in soa environment Download PDFInfo
- Publication number
- US20150261595A1 US20150261595A1 US14/727,574 US201514727574A US2015261595A1 US 20150261595 A1 US20150261595 A1 US 20150261595A1 US 201514727574 A US201514727574 A US 201514727574A US 2015261595 A1 US2015261595 A1 US 2015261595A1
- Authority
- US
- United States
- Prior art keywords
- error
- errors
- domain
- fields
- group
- 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
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0775—Content or structure details of the error report, e.g. specific table structure, specific error fields
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0769—Readable error formats, e.g. cross-platform generic formats, human understandable formats
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0681—Configuration of triggering conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
- H04L43/55—Testing of service level quality, e.g. simulating service usage
Definitions
- This disclosure relates to methods and systems supporting computing and data processing systems. Specifically, the disclosure relates to definition, creation, management, transmission, and monitoring of errors in a Services Oriented Architecture (SOA) environment.
- SOA Services Oriented Architecture
- SOA there are typically many communicating reusable services that are deployed in several machines.
- large-scale enterprises like eBay, eTrade, or Google, for example, there could be thousands of different services deployed in thousands of machines. It is most common and efficient for these automated services to communicate with each other. Further, external access is also typically provided for some of these services.
- various different types of communication protocols may be used for efficiency and optimization reasons. Communication between service providers and service consumers can be accomplished using some pre-defined protocol. In the web services case, this protocol can be the Simple Object Access Protocol (SOAP). SOAP is a protocol for exchanging Extensible Mark-up Language (XML)-based messages over computer networks, normally using Hypertext Transport Protocol (HTTP/HTTPS).
- SOAP Simple Object Access Protocol
- service errors can be defined as any condition indicating complete or partial failure of a service operation, regardless of how this condition is signaled in the whole service processing flow.
- service errors in SOA can come in two forms:
- the structure of the error can be commonly defined for uniformity, consistency and for uniquely identifying errors across an organization. These errors can be originated from:
- a framework is a system, such as an application, within which a error processing mechanism is implemented.
- FIG. 1 illustrates schema of the common error data type—(ErrorData) in an example embodiment
- FIG. 2 illustrates the ErrorData model in an example embodiment
- FIG. 3 illustrates the ErrorLibrary model in an example embodiment
- FIG. 4 illustrates a user interface for creating a new Error Library in an example embodiment
- FIG. 5 illustrates the Error Library creation wizard in an example embodiment
- FIG. 6 illustrates an example embodiment for creating an error domain
- FIG. 7 illustrates an example embodiment for creating an error type
- FIG. 8 illustrates an example of the search wizard in the content plugin in an example embodiment
- FIG. 9 illustrates the error ID space in an example embodiment
- FIG. 10 illustrates the components involved during the pluggable error ID generation process in an example embodiment
- FIG. 11 illustrates an example of the Error Id Generator interface in an example embodiment
- FIG. 12 illustrates a processing flow diagram for an example embodiment
- FIG. 13 illustrates a processing flow diagram for an example embodiment
- FIG. 14 shows a diagrammatic representation of a machine in the form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed, according to an example embodiment.
- Error processing is an important aspect of service invocation in the SOA paradigm.
- SOAP and WSDL standards, and some distributed paradigms before SOAP technology such as CORBA employ an exception pattern around the definition and runtime propagation of error information.
- errors become serializable data types, and are associated to an out-of-band error communication flow—the SOAP Fault flow, in the case of SOAP.
- Possible errors for each service operation are described in wsdl:fault definitions in the WSDL that defines a service. This conventional mechanism has a number of limitations.
- error processing techniques for services are described. These error processing techniques describe how errors are defined, managed, localized and propagated to the callers, what necessary tooling is required to enable this error processing, and finally how an error management sub-system interacts with the rest of the SOA system and tooling.
- the framework can define a standard error message definition that is commonly used across the system.
- Error messages also need to be localizable. How those error messages are localized is specific to a particular embodiment. This can be achieved through Property Resource Bundles in a particular embodiment. These Resource bundles should be included in an Error Library, as described in more detail in later sections.
- SYSTEM errors generated by framework independent of any application logic.
- APPLICATION errors are the errors generated by service implementation.
- CLIENT errors are errors generated due to invalid or insufficient input sent from the client to the service. However, all the errors are handled the same way.
- the framework can define a common base error type definition, hereafter referred to as ErrorData. All errors can use the same ErrorData definition, by default. Services can optionally define a derived type (only extension) to include additional information.
- wire format for these custom errors could be either as exactly defined in the derived type or a custom error handler can be supplied to map the errors as necessary in an example embodiment.
- a top level element to be used to easily identify errors in the response for system error processing. This is useful for example to collect various error metrics by the system while processing the errors.
- This ErrorData data type structure can be defined as a schema type in a common namespace (e.g., http://www.host.com/services) and reused across all services in their own respective namespaces.
- ErrorData ErrorData
- ErrorData ErrorData
- many actual instances of error messages can be created. These error messages can be used by services (or the framework as the case may be), at runtime to indicate what has gone wrong.
- the actual instances of error messages also need to be managed.
- a construct called Error Library is introduced to manage and maintain the error instance definitions. The anatomy of this ErrorLibrary is described in a later section herein.
- the Error ID as defined in the ErrorData structure described above, must be unique across all errors within an organization, so we can distinguish one error from another. Sufficient tooling can support generating these unique Error ID's as part of the overall error processing system. Users or applications (i.e., entities defining the error messages themselves) don't need to be concerned about the actual Error ID numbers or how to generate them.
- system errors could reserve a range of 1-10,000 and application errors could have a range from 10,000-100,000. For example, see the embodiment shown in FIG. 9 .
- the Error Id Generator refers to a component that is responsible for creating unique error IDs.
- An interface called ErrorIDGenerator is defined and different implementations of this interface can be plugged in. For example, one implementation may use a data base sequence generator. The error creating tooling calls this generator to get the next unique error ID while creating an error. For example, see FIGS. 10-11 .
- This capability may not make sense for application errors; because, an automatic retry may not make sense for an application error and often requires a change in the request of some sort.
- metrics can be defined and collected for specific errors. For example, metrics can be collected that define the number of errors that occurred when invoking a specific service, specific operation, categorized by various dimensions like client ID, or application ID. In addition, metrics can be collected that measure counts on error categories: System, Application, and Client. For example, metrics can be collected that can be used to determine that a specific operation invocation has X number of errors, but also to measure that out of these X number of errors, Y are system errors and Z are application errors. Additionally, the metrics provide information that specifies that within the Z application errors how many are “001—Invalid Input” errors, how many are “002—Can't find item” errors, etc. Further, metrics can be collected that are based on error domains.
- metrics can be collected that measure counts of errors by severity. It can be implemented as either one metric for severity or one metric for all severities and use components to indicate counts for individual severities. Thus, errors can be sliced and diced, and reported in many different dimensions. In a particular embodiment, this metrics collection can be done by configuring a handler in SOA runtime.
- a particular embodiment provides a mechanism in “Response Pipeline handler” that checks for whether an error is part of a response and accordingly updates the respective metrics.
- This handler can get the information from the type mappings file. Once error information is collected from the RRE, appropriate error metrics, as defined in the section above, can be updated. Once the error metrics are defined and collected, alert conditions can be defined for those, using a centralized alerting framework. This mechanism can be used to collect error metrics both on the server side and client side.
- a particular embodiment can provide custom error mapping feature to allow such mappings.
- a particular embodiment can provide a centralized alerting function based on error metrics. Errors can be logged as events. Error events can be sampled and logged. It may not be necessary to log every event; because, the volume may be quite high.
- the error sampling frequency can be configurable with a default. For example, the default error sampling frequency can be as follows: once an error of a particular type occurs, log the error and then don't log the error for the next 10 occurrences of the same kind of error.
- Example embodiments provide a mechanism for creating and managing the actual instances of error messages.
- a concept of the Error Library is provided for this purpose. For example, see FIG. 3 .
- An Error Library is a collection of logically related errors that are grouped by domain. It consists of error bundles.
- An error bundle contains multiple error instances, and an associated metadata file that describes static data about the errors such as, the organization, domain, category, severity, etc.
- Tooling is provided to help create or update an error instance in a particular bundle of an ErrorLibrary, as well as creating and managing the bundle and the library itself. Further, tooling can help choose a particular error to be included in a service implementation.
- instances of errors can be managed in the Error library, except for Cause/Detail string and message parameters. Every other aspect of the base error message is statically defined for any given instance of the error message in a particular embodiment. However, not every part of the error needs to be localized. A particular embodiment can localize the error message string and resolution string. The remainder of the data for a particular error doesn't need to be localized. For localization, one option is to use the standard Property Resource Bundle approach, available as part of the standard Java Developer's Kit (JDK). To avoid the overhead and repetition, a particular embodiment can split the error information so that we only keep the localizable information in the properties file of the Resource Bundle and keep the non-localizable static information in a separate metadata file.
- JDK Java Developer's Kit
- the resource properties files and the metadata file forms a bundle for a error domain. This is called an Error Bundle.
- a particular embodiment may support other pluggable localization mechanisms, to store the localizable part of the ErrorData. This pluggability is abstracted through an ErrorProvider interface. The different implementations of this interface are called Error providers.
- the metadata file that contains the static information is what is included in an error library of an example embodiment.
- the metadata file is expressed in XML.
- the build artifact for an error library can be a Standard Java Archive file (jar file), so the file can be loaded using the standard mechanisms.
- a single error library can contain multiple Resource bundles, one per domain. Each Resource Bundle. On the other hand, we can also create a separate error library for each of these. There is no restriction either on the model or on the tooling to do it one way or another.
- a particular embodiment can provide a utility function to service developers to use an error instance (i.e., a new ErrorData) at runtime, when they want to include such error in their response or otherwise.
- This utility function can take the information like error category, optional domain name, and an error id. Based on this information, the utility function can look up the appropriate Resource Bundle and create and populate an ErrorData instance and return. In the case of custom error data type, any additional fields are expected to be filled in by the application code. Custom error fields are not managed inside the error library.
- An example embodiment includes the ability to group certain errors together for management and tracking purposes. For example, all authentication-related errors may be grouped together. Errors like, invalid token, token expired, temporarily blocked, etc. may also be separately grouped A metric may be defined to collect the total number of errors for a given group.
- the framework itself may not come up with the group definition or its constituents; but, we can help service developers to define such groups and we can have a metric automatically registered for that group at initialization time and collect data for that group.
- Error group names are strings and are unique within an error library. So the combination of error library name and the group name can be globally unique.
- the metric that is auto-registered can be this name to avoid collisions.
- An Eclipse plugin can provide functionality to create and manage error libraries and ErrorData instances in them. Several actions can be supported by this plugin.
- This Error Library plugin action can ask for the name of the new error library. For example, see FIGS. 4-6 .
- the new error library structure is then created in the workspace with the given name.
- An Error bundle is a combination of a property resource bundle and the corresponding meta data file.
- This Error Library plugin action can ask for all the fields in ErrorData (except for the ID) or its derived type, in addition to the name of the library, and insert a new record in the corresponding metadata file and the Resource Bundle.
- the Error ID can be generated using the ID generator interface and the mechanism described above. For example, see FIG. 7 .
- a particular embodiment can provide a search menu for error searching.
- An error search can be based on name, category, domain, or description.
- the search feature can refer to tooling support required to find/group errors by various criteria. These criteria can include the following:
- the error library search functionality can be based on a standard content search model. For example, see FIG. 8 .
- Error editing can be done by either directly opening up the error library bundle, if the project is already loaded, or one can start with a search and double click on the search results, which can automatically load the error library and allow editing of the error. Only the error string and the resolution string can be edited. Other fields shouldn't be editable. Errors shouldn't be deletable, once they are created in the error library.
- the pop-up user interface can prompt for domain, sub-domain, etc. For example, see FIG. 7 . If bundles for the specified domain or sub-domain are not currently there (e.g., because of the naming convention of the resource bundle, for example), the tooling can automatically create corresponding bundles. A bundle for a given category and domain can only exist in one error library. This check can be done by the tooling.
- the tooling can support creating and managing custom errors that correspond to this custom type as well. To keep the process consistent, whether the errors exactly follow ErrorData or whether they are derived from ErrorData, the information about what is the error type is kept in the error library itself.
- a particular embodiment provides a menu item to group certain errors together.
- errors defined in the error library must manifest themselves in code some way so that the service implementation can create and send those errors to the callers.
- a particular embodiment may provide an application programming interface (API) that obtains the error in a way that is independent of the Error providers.
- API application programming interface
- ErrorDataKey is the structure that is used as a key to look up in the ErrorDataProvider.
- */ public static class ErrorDataKey ⁇ private String bundleName; /** bundle name */ private String errorName; /** error name */ private long id; /** error id */ private Map additionalKeys; /**
- This map is a placeholder for extensibility purposes */ ⁇ interface ErrorDataProvider ⁇ /** * @param key * @param args * @return an ErrorData based on the key/args values */ public ErrorData getErrorData( ErrorDataKey key, Object[ ] args ); /** *Allows construction of a “custom” ErrorData * @param key * @param args * @param clazz Class type that can be constructed and returned * @return a “custom” ErrorData */ public ⁇ T extends ErrorData>T getCustom
- Each error library can be packaged as a library jar file.
- the application project is required to introduce a dependency on each error library they require.
- a computer-implemented system and method for the definition, creation, management, transmission, and monitoring of errors in a SOA environment provides several features as listed below:
- FIG. 12 is a processing flow chart illustrating an example embodiment of the error library processing system 1500 as described herein.
- the method in an example embodiment includes: defining a common standard error data structure; automatically generating a unique identifier (ID) for each new error data instance; allowing customization of error data structure through extensions; creation and management of error instances that conform to this structure; ability to group errors across various dimensions; introducing the concept of an error library, the error library including a plurality of localizable error bundles, each of the error bundles including a plurality of error data instances for a particular domain, along with the associated metadata; automatically creating runtime artifacts for each error; ability to transmit errors either as faults or as part of the normal response payload; automatic error metric collection based on various error categories, and finally, tooling to help manage error libraries and reporting errors.
- ID unique identifier
- FIG. 13 is a processing flow chart illustrating another example embodiment of the error library processing system 1600 as described herein.
- the method of an example embodiment includes: receiving an error type definition specifying a common error structure (processing block 1610 ); creating, by a data processor, an error library, the error library including a plurality of error bundles, each of the error bundles including a plurality of error data instances, the error data instances conforming to the common error structure (processing block 1620 ); receiving a request to add a new error data instance to the error library (processing block 1630 ); automatically generating a unique identifier (ID) for the new error data instance, the new error data instance ID being unique among all error data instances in the error library (processing block 1640 ); and building the error library to create code which registers all error data instances in the error library (processing block 1650 ).
- ID unique identifier
- FIG. 14 shows a diagrammatic representation of a machine in the example form of a computer system 700 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
- the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
- the machine may operate in the capacity of a server or a client machine in client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
- the machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
- PC personal computer
- PDA Personal Digital Assistant
- STB set-top box
- a cellular telephone a web appliance
- network router switch or bridge
- the example computer system 700 includes a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 704 and a static memory 706 , which communicate with each other via a bus 708 .
- the computer system 700 may further include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
- the computer system 700 also includes an input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse), a disk drive unit 716 , a signal generation device 718 (e.g., a speaker) and a network interface device 720 .
- the disk drive unit 716 includes a machine-readable medium 722 on which is stored one or more sets of instructions (e.g., software 724 ) embodying any one or more of the methodologies or functions described herein.
- the instructions 724 may also reside, completely or at least partially, within the main memory 704 , the static memory 706 , and/or within the processor 702 during execution thereof by the computer system 700 .
- the main memory 704 and the processor 702 also may constitute machine-readable media.
- the instructions 724 may further be transmitted or received over a network 726 via the network interface device 720 .
- a computer system e.g., a standalone, client or server computer system
- an application may constitute a “module” that is configured and operates to perform certain operations as described herein.
- the “module” may be implemented mechanically or electronically.
- a module may comprise dedicated circuitry or logic that is permanently configured (e.g., within a special-purpose processor) to perform certain operations.
- a module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a module mechanically, in the dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g. configured by software) may be driven by cost and time considerations. Accordingly, the term “module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein.
- machine-readable medium 722 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
- the term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present description.
- the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
- the software may be transmitted over a network using a transmission medium.
- the term “transmission medium” shall be taken to include any medium that is capable of storing, encoding or carrying instructions for transmission to and execution by the machine, and includes digital or analog communications signal or other intangible medium to facilitate transmission and communication of such software.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Debugging And Monitoring (AREA)
Abstract
A computer-implemented system and method for the definition, creation, management, transmission, and monitoring of errors in a SOA environment. An example embodiment includes: defining a common standard error data structure; automatically generating a unique identifier (ID) for each new error data instance; allowing customization of error data structure through extensions; creation and management of error instances that conform to this structure; ability to group errors across various dimensions; introducing the concept of an error library, the error library including a plurality of localizable error bundles, each of the error bundles including a plurality of error data instances for a particular domain, along with the associated metadata; automatically creating runtime artifacts for each error; ability to transmit errors either as faults or as part of the normal response payload; automatic error metric collection based on various error categories, and finally, tooling to help manage error libraries and reporting errors.
Description
- This application is a Continuation of U.S. patent application Ser. No. 13/850,021, filed on Mar. 25, 2013, which is a Continuation of U.S. patent application Ser. No. 12/766,712, filed on Apr. 23, 2010, issued on Mar. 26, 2013 as U.S. Pat. No. 8,407,520, the benefit of priority of each of which is claimed hereby, and each are incorporated herein by reference in their entirety.
- A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings that form a part of this document: Copyright 2008-2010, eBay Inc., All Rights Reserved.
- 1. Technical Field
- This disclosure relates to methods and systems supporting computing and data processing systems. Specifically, the disclosure relates to definition, creation, management, transmission, and monitoring of errors in a Services Oriented Architecture (SOA) environment.
- 2. Related Art
- In SOA, there are typically many communicating reusable services that are deployed in several machines. In large-scale enterprises, like eBay, eTrade, or Google, for example, there could be thousands of different services deployed in thousands of machines. It is most common and efficient for these automated services to communicate with each other. Further, external access is also typically provided for some of these services. In communicating with each other, various different types of communication protocols may be used for efficiency and optimization reasons. Communication between service providers and service consumers can be accomplished using some pre-defined protocol. In the web services case, this protocol can be the Simple Object Access Protocol (SOAP). SOAP is a protocol for exchanging Extensible Mark-up Language (XML)-based messages over computer networks, normally using Hypertext Transport Protocol (HTTP/HTTPS).
- No matter how perfectly software is implemented, often times, certain things go wrong and we need a simple and clear mechanism to communicate exactly what went wrong to the callers/users. It is also vital that we need to standardize and follow a common mechanism for describing not only what an error means, but also to propagate such messages consistently and uniformly to the callers. Errors are essentially a result of abnormal processing of the request. This could be due to invalid input/request from the caller, or due to some business error or unexpected system errors. Regardless of what the error is, we need a consistent way to define, create, manage, and transmit the details of the error, to enable service developers and service consumer developers to do error processing efficiently.
- In a SOA environment, service errors can be defined as any condition indicating complete or partial failure of a service operation, regardless of how this condition is signaled in the whole service processing flow. In this sample definition, service errors in SOA can come in two forms:
-
- Faults: Declared in the Web Services Description Language (WSDL) as Fault messages and transmitted from services to consumers in a out of band payload. In the case of SOAP protocol, it is the SOAPFaults, transmitted as exceptions in Java language bindings;
- Response-Resident Errors (RRE): Errors transmitted as part of the normal response payload of operation execution.
- In both of these scenarios, the structure of the error can be commonly defined for uniformity, consistency and for uniquely identifying errors across an organization. These errors can be originated from:
-
- The service implementation when the service application business logic detects application errors, and
- The SOA runtime when it detects system level errors.
- In the absence of special measures (e.g., modeling techniques/implementation enhancements, etc.), there can be a divergent processing flow for service errors. This complicates client processing, especially for non-SOA clients and for 3rd party coders; because, in most cases, processing flows must be anticipated. Additionally, for response-resident errors, in the absence of additional framework or application implementation, most of the SOA value-added processing is missed. A framework is a system, such as an application, within which a error processing mechanism is implemented.
- Thus, a computer-implemented system and method for the definition, creation, management, transmission, and monitoring of errors in a SOA environment is needed.
- Embodiments illustrated by way of example and not limitation in the figures of the accompanying drawings, in which:
-
FIG. 1 illustrates schema of the common error data type—(ErrorData) in an example embodiment; -
FIG. 2 illustrates the ErrorData model in an example embodiment; -
FIG. 3 illustrates the ErrorLibrary model in an example embodiment; -
FIG. 4 illustrates a user interface for creating a new Error Library in an example embodiment; -
FIG. 5 illustrates the Error Library creation wizard in an example embodiment; -
FIG. 6 illustrates an example embodiment for creating an error domain; -
FIG. 7 illustrates an example embodiment for creating an error type; -
FIG. 8 illustrates an example of the search wizard in the content plugin in an example embodiment; -
FIG. 9 illustrates the error ID space in an example embodiment; -
FIG. 10 illustrates the components involved during the pluggable error ID generation process in an example embodiment; -
FIG. 11 illustrates an example of the Error Id Generator interface in an example embodiment; -
FIG. 12 illustrates a processing flow diagram for an example embodiment; -
FIG. 13 illustrates a processing flow diagram for an example embodiment; and -
FIG. 14 shows a diagrammatic representation of a machine in the form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed, according to an example embodiment. - In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some example embodiments. It will be evident, however, to one of ordinary skill in the art that the present invention may be practiced without these specific details.
- As described further below, according to various example embodiments of the disclosed subject matter described and claimed herein, there is provided a computer-implemented system and method for the definition, creation, management, transmission, and monitoring of errors in a SOA environment. Various embodiments are described below in connection with the figures provided herein. The error processing techniques described herein are primarily used in the context of SOA services, although the techniques are not limited to SOA services.
- Error processing is an important aspect of service invocation in the SOA paradigm. The SOAP and WSDL standards, and some distributed paradigms before SOAP technology such as CORBA, employ an exception pattern around the definition and runtime propagation of error information. In the exception pattern, errors become serializable data types, and are associated to an out-of-band error communication flow—the SOAP Fault flow, in the case of SOAP. Possible errors for each service operation are described in wsdl:fault definitions in the WSDL that defines a service. This conventional mechanism has a number of limitations.
- 1. The number of distinct error situations in typical service-enabled business logic can easily get into the hundreds, and this degree of multiplicity is tedious to express in WSDL.
- 2. The very exception-based nature of SOAP faults makes them all-or-nothing in their effect on an operation's control flow: typically they block further activity, making warnings and partial success (partial results) impossible.
- 3. Modeling of “error information within the normal “response-band” service data is expressly excluded by the SOAP fault pattern, and the standard provides no guidance as to how to unify response-band and error-band information.
- 4. Because of the lack of standardization around individual error case definition and around unified response/error flow modeling of errors, there is also no WSDL standards compliant tooling in the industry to provide comprehensive management of the definition, creation, management, and transmission of errors.
- In various example embodiments described herein, error processing techniques for services (and framework) are described. These error processing techniques describe how errors are defined, managed, localized and propagated to the callers, what necessary tooling is required to enable this error processing, and finally how an error management sub-system interacts with the rest of the SOA system and tooling.
- Many conventional systems do not support a formal error identifier (ID) or error messages management mechanism. Clean declaration of errors and their management is important for Services in a SOA environment, because service consumers and service providers are isolated. Therefore, the contract needs to have sufficient information to consumer the service including error information. Lack of a mechanism and tooling to formally define and manage those errors would lead to in-effective and inconsistent use of services, including interoperability issues.
- Before describing how errors are defined, managed and propagated, we will describe the composition of a typical error message in an example embodiment. In a particular embodiment, the framework can define a standard error message definition that is commonly used across the system.
- The following can be the definition of the common base error data type—(ErrorData) in an example embodiment. For example, see also
FIGS. 1 and 2 . -
- Error ID: is a unique number that identifies the error.
- Error Name: A human readable error name in string format.
- Organization: The name of the organization from which the errors come from.
- Category: An error classification with the suggested values of SYSTEM, APPLICATION and CLIENT. Category indicates whether the error occurred in system, application or the client code.
- Domain: This is a field that indicates specific group within the organization. Example values include “TRADING”, “SEARCH”, “SECURITY”, “BILLING”, etc.
- sub-domain: This is a field which further helps to indicate a subsystem within a domain. For example, for System domain, sub-domain can include “Initialization”, “(De)Serialization”, “Authentication”, “Authorization”, etc.
- Severity: This is a field that indicate the severity of an error. Possible values include—INFO, DEBUG, WARNING, CRITICAL.
- Message: This is the language specific error message string that can also be parameterized.
- Resolution: This is a field which can either contain further explanation of the error message or can contain some proposed remedy. The combination of this resolution string and the message string above, can be treated as a “long error message”
- Cause: This is a field that contains the reason for the error, including any stack trace in Java environment, etc. This can be simply a text string. The framework doesn't need to dictate any specific format.
- ExceptionName: A language specific field containing additional information to help reconstructing Fault at the other end.
- All of the above fields are statically defined for any given error message, except for the message parameters, if any, and the Cause field. Cause, Resolution, and sub-domain are optional.
- Error messages also need to be localizable. How those error messages are localized is specific to a particular embodiment. This can be achieved through Property Resource Bundles in a particular embodiment. These Resource bundles should be included in an Error Library, as described in more detail in later sections.
- There are three categories of errors. SYSTEM, APPLICATION and CLIENT. SYSTEM errors are the errors generated by framework independent of any application logic. APPLICATION errors are the errors generated by service implementation. CLIENT errors are errors generated due to invalid or insufficient input sent from the client to the service. However, all the errors are handled the same way.
- Occasionally, there may be a need for service developers to customize the standard error message definition. To accommodate this, the framework and the tooling can allow customization of the error message definition. The framework can define a common base error type definition, hereafter referred to as ErrorData. All errors can use the same ErrorData definition, by default. Services can optionally define a derived type (only extension) to include additional information.
- The wire format for these custom errors could be either as exactly defined in the derived type or a custom error handler can be supplied to map the errors as necessary in an example embodiment.
- When an error is defined as part of a normal payload response, it is suggested a top level element to be used to easily identify errors in the response for system error processing. This is useful for example to collect various error metrics by the system while processing the errors.
- This ErrorData data type structure, as described above, can be defined as a schema type in a common namespace (e.g., http://www.host.com/services) and reused across all services in their own respective namespaces.
- It is also possible to return more than one error (i.e., ErrorData) to the caller, on any given operation invocation. Using the ErrorData structure defined above, many actual instances of error messages can be created. These error messages can be used by services (or the framework as the case may be), at runtime to indicate what has gone wrong. We need to be clear about the distinction between the structure of the error type and the actual instances of error messages. The actual instances of error messages also need to be managed. Here a construct called Error Library is introduced to manage and maintain the error instance definitions. The anatomy of this ErrorLibrary is described in a later section herein.
- The Error ID, as defined in the ErrorData structure described above, must be unique across all errors within an organization, so we can distinguish one error from another. Sufficient tooling can support generating these unique Error ID's as part of the overall error processing system. Users or applications (i.e., entities defining the error messages themselves) don't need to be concerned about the actual Error ID numbers or how to generate them.
- In an example embodiment, one can reserve special ranges for different categories of errors belonging to separate domains, to make the management easier. For example, system errors could reserve a range of 1-10,000 and application errors could have a range from 10,000-100,000. For example, see the embodiment shown in
FIG. 9 . - The Error Id Generator refers to a component that is responsible for creating unique error IDs. An interface called ErrorIDGenerator is defined and different implementations of this interface can be plugged in. For example, one implementation may use a data base sequence generator. The error creating tooling calls this generator to get the next unique error ID while creating an error. For example, see
FIGS. 10-11 . - For system errors, in an example embodiment, there can also be a facility to configure a client to automatically retry the invocation for specific errors. This capability may not make sense for application errors; because, an automatic retry may not make sense for an application error and often requires a change in the request of some sort.
- In an example embodiment, metrics can be defined and collected for specific errors. For example, metrics can be collected that define the number of errors that occurred when invoking a specific service, specific operation, categorized by various dimensions like client ID, or application ID. In addition, metrics can be collected that measure counts on error categories: System, Application, and Client. For example, metrics can be collected that can be used to determine that a specific operation invocation has X number of errors, but also to measure that out of these X number of errors, Y are system errors and Z are application errors. Additionally, the metrics provide information that specifies that within the Z application errors how many are “001—Invalid Input” errors, how many are “002—Can't find item” errors, etc. Further, metrics can be collected that are based on error domains. Also, metrics can be collected that measure counts of errors by severity. It can be implemented as either one metric for severity or one metric for all severities and use components to indicate counts for individual severities. Thus, errors can be sliced and diced, and reported in many different dimensions. In a particular embodiment, this metrics collection can be done by configuring a handler in SOA runtime.
- In order to measure the error metrics in the different dimensions of errors, a particular embodiment provides a mechanism in “Response Pipeline handler” that checks for whether an error is part of a response and accordingly updates the respective metrics. This handler can get the information from the type mappings file. Once error information is collected from the RRE, appropriate error metrics, as defined in the section above, can be updated. Once the error metrics are defined and collected, alert conditions can be defined for those, using a centralized alerting framework. This mechanism can be used to collect error metrics both on the server side and client side.
- Even though the format and structure is pre-defined for errors, sometimes there is a need to map that pre-defined structure to an existing error format, for legacy reasons. A particular embodiment can provide custom error mapping feature to allow such mappings.
- A particular embodiment can provide a centralized alerting function based on error metrics. Errors can be logged as events. Error events can be sampled and logged. It may not be necessary to log every event; because, the volume may be quite high. The error sampling frequency can be configurable with a default. For example, the default error sampling frequency can be as follows: once an error of a particular type occurs, log the error and then don't log the error for the next 10 occurrences of the same kind of error.
- Example embodiments provide a mechanism for creating and managing the actual instances of error messages. A concept of the Error Library is provided for this purpose. For example, see
FIG. 3 . - An Error Library is a collection of logically related errors that are grouped by domain. It consists of error bundles. An error bundle contains multiple error instances, and an associated metadata file that describes static data about the errors such as, the organization, domain, category, severity, etc. Tooling is provided to help create or update an error instance in a particular bundle of an ErrorLibrary, as well as creating and managing the bundle and the library itself. Further, tooling can help choose a particular error to be included in a service implementation.
- As already mentioned, instances of errors can be managed in the Error library, except for Cause/Detail string and message parameters. Every other aspect of the base error message is statically defined for any given instance of the error message in a particular embodiment. However, not every part of the error needs to be localized. A particular embodiment can localize the error message string and resolution string. The remainder of the data for a particular error doesn't need to be localized. For localization, one option is to use the standard Property Resource Bundle approach, available as part of the standard Java Developer's Kit (JDK). To avoid the overhead and repetition, a particular embodiment can split the error information so that we only keep the localizable information in the properties file of the Resource Bundle and keep the non-localizable static information in a separate metadata file. The resource properties files and the metadata file forms a bundle for a error domain. This is called an Error Bundle. In addition to the standard resource bundle mechanism, a particular embodiment may support other pluggable localization mechanisms, to store the localizable part of the ErrorData. This pluggability is abstracted through an ErrorProvider interface. The different implementations of this interface are called Error providers.
- For example, if we have a Properties Resource Bundle for errors from System domain, we can have the following files, with example content in the files as described below.
- SystemErrors_en.properties
errorName1=“Error Message in English forerror 1”, “Error Resolution in English forerror 1”
errorName2=“Error Message in English for error 2”, “Error Resolution in English for error 2”
SystemErrors_de.properties
errorName1=“Error Message in German forerror 1”, “Error Resolution in German forerror 1”
errorName2=“Error Message in German for error 2”, “Error Resolution in German for error 2”
Application_TradingErrors_en.properties
errorName3=“Error Message in English for error 3”, “Error Resolution in English for error 3”
errorName4=“Error Message in English forerror 4”, “Error Resolution in English forerror 4” - These property resource bundles, along with the metadata file that contains the static information (e.g., category, severity, etc., for a given error), is what is included in an error library of an example embodiment. In a particular embodiment, the metadata file is expressed in XML. The build artifact for an error library can be a Standard Java Archive file (jar file), so the file can be loaded using the standard mechanisms.
- A single error library can contain multiple Resource bundles, one per domain. Each Resource Bundle. On the other hand, we can also create a separate error library for each of these. There is no restriction either on the model or on the tooling to do it one way or another.
- In order to efficiently locate the appropriate resource bundle and load it at runtime, certain conventions can be followed for the names of the Resource Bundles. The name can be <CategoryName_DomainName_language.properties> in a particular embodiment. Tooling can add the required error libraries as a dependency for the service implementation and client projects.
- A particular embodiment can provide a utility function to service developers to use an error instance (i.e., a new ErrorData) at runtime, when they want to include such error in their response or otherwise. This utility function can take the information like error category, optional domain name, and an error id. Based on this information, the utility function can look up the appropriate Resource Bundle and create and populate an ErrorData instance and return. In the case of custom error data type, any additional fields are expected to be filled in by the application code. Custom error fields are not managed inside the error library.
- An example embodiment includes the ability to group certain errors together for management and tracking purposes. For example, all authentication-related errors may be grouped together. Errors like, invalid token, token expired, temporarily blocked, etc. may also be separately grouped A metric may be defined to collect the total number of errors for a given group. The framework itself may not come up with the group definition or its constituents; but, we can help service developers to define such groups and we can have a metric automatically registered for that group at initialization time and collect data for that group.
- Error group names are strings and are unique within an error library. So the combination of error library name and the group name can be globally unique. The metric that is auto-registered can be this name to avoid collisions.
- An Eclipse plugin can provide functionality to create and manage error libraries and ErrorData instances in them. Several actions can be supported by this plugin.
- This Error Library plugin action can ask for the name of the new error library. For example, see
FIGS. 4-6 . The new error library structure is then created in the workspace with the given name. - A new error bundle is implicitly created when a new error is created with a new category and domain combination, that doesn't already exist. No explicit menu item is needed for this. An Error bundle is a combination of a property resource bundle and the corresponding meta data file.
- This Error Library plugin action can ask for all the fields in ErrorData (except for the ID) or its derived type, in addition to the name of the library, and insert a new record in the corresponding metadata file and the Resource Bundle. The Error ID can be generated using the ID generator interface and the mechanism described above. For example, see
FIG. 7 . - A particular embodiment can provide a search menu for error searching. An error search can be based on name, category, domain, or description. The search feature can refer to tooling support required to find/group errors by various criteria. These criteria can include the following:
-
- Search by error ID
- Search by error name
- Search by category name
- Search by domain
- Search by description
- The error library search functionality can be based on a standard content search model. For example, see
FIG. 8 . - Error editing can be done by either directly opening up the error library bundle, if the project is already loaded, or one can start with a search and double click on the search results, which can automatically load the error library and allow editing of the error. Only the error string and the resolution string can be edited. Other fields shouldn't be editable. Errors shouldn't be deletable, once they are created in the error library.
- We don't need any special tooling support for adding new domains or sub-domains. As part of adding a new error instance, the pop-up user interface can prompt for domain, sub-domain, etc. For example, see
FIG. 7 . If bundles for the specified domain or sub-domain are not currently there (e.g., because of the naming convention of the resource bundle, for example), the tooling can automatically create corresponding bundles. A bundle for a given category and domain can only exist in one error library. This check can be done by the tooling. - Because service developers can define their custom error types, extending from ErrorData, the tooling can support creating and managing custom errors that correspond to this custom type as well. To keep the process consistent, whether the errors exactly follow ErrorData or whether they are derived from ErrorData, the information about what is the error type is kept in the error library itself.
- Sometimes, one may want to group certain errors together for reporting purpose. Examples include authentication errors within security domain. A particular embodiment provides a menu item to group certain errors together.
- Java Utility to Obtain ErrorData for the Service (getErrorData)
- Ultimately, the errors defined in the error library must manifest themselves in code some way so that the service implementation can create and send those errors to the callers. A particular embodiment may provide an application programming interface (API) that obtains the error in a way that is independent of the Error providers. Below is the interface definition of an example embodiment that illustrates the interaction points between the application developer and SOA error runtime.
-
/** * ErrorDataKey is the structure that is used as a key to look up in the ErrorDataProvider. */ public static class ErrorDataKey { private String bundleName; /** bundle name */ private String errorName; /** error name */ private long id; /** error id */ private Map additionalKeys; /** This map is a placeholder for extensibility purposes */ } interface ErrorDataProvider { /** * @param key * @param args * @return an ErrorData based on the key/args values */ public ErrorData getErrorData( ErrorDataKey key, Object[ ] args ); /** *Allows construction of a “custom” ErrorData * @param key * @param args * @param clazz Class type that can be constructed and returned * @return a “custom” ErrorData */ public <T extends ErrorData>T getCustomErrorData( ErrorDataKey key, Object[ ] args, Class<T> clazz ); } - Here is some sample code illustrating usage of the API's.
-
ErrorDataKey key = new ErrorDataKey ( ) ; key.setLibraryName ( “SearchDomainErrorLibrary” ) ; key.setBundleName ( “SearchDomain” ) ; key.setErrorName ( “insufficient_arguments ” ) ; ErrorDataProvider provider = ErrorDataProviderFactory.getProvider ( ) ; errorData = provider.getErrorData ( key, new Object [ ] { “foo” } } ; - Each error library can be packaged as a library jar file. For an application to access this content, the application project is required to introduce a dependency on each error library they require.
- As described herein, according to various example embodiments, there is provided a computer-implemented system and method for the definition, creation, management, transmission, and monitoring of errors in a SOA environment. The error processing system provides several features as listed below:
-
- The management (creation, modification, unique identification) of individual error instances for specific services.
- The storage and management of content (localizable static content and any associated metadata) associated with these error instances.
- The creation of runtime ErrorData instances that contain dynamic error message parameters and static data.
- Provisions for transmitting the runtime errors as system exceptions, such as SOAP faults, or as application errors, which are contained in normal operation response messages.
- Provisions for automatically identifying and collecting error metrics regardless how there are transmitted.
-
FIG. 12 is a processing flow chart illustrating an example embodiment of the errorlibrary processing system 1500 as described herein. The method in an example embodiment includes: defining a common standard error data structure; automatically generating a unique identifier (ID) for each new error data instance; allowing customization of error data structure through extensions; creation and management of error instances that conform to this structure; ability to group errors across various dimensions; introducing the concept of an error library, the error library including a plurality of localizable error bundles, each of the error bundles including a plurality of error data instances for a particular domain, along with the associated metadata; automatically creating runtime artifacts for each error; ability to transmit errors either as faults or as part of the normal response payload; automatic error metric collection based on various error categories, and finally, tooling to help manage error libraries and reporting errors. -
FIG. 13 is a processing flow chart illustrating another example embodiment of the errorlibrary processing system 1600 as described herein. The method of an example embodiment includes: receiving an error type definition specifying a common error structure (processing block 1610); creating, by a data processor, an error library, the error library including a plurality of error bundles, each of the error bundles including a plurality of error data instances, the error data instances conforming to the common error structure (processing block 1620); receiving a request to add a new error data instance to the error library (processing block 1630); automatically generating a unique identifier (ID) for the new error data instance, the new error data instance ID being unique among all error data instances in the error library (processing block 1640); and building the error library to create code which registers all error data instances in the error library (processing block 1650). -
FIG. 14 shows a diagrammatic representation of a machine in the example form of acomputer system 700 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. - The
example computer system 700 includes a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), amain memory 704 and astatic memory 706, which communicate with each other via abus 708. Thecomputer system 700 may further include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system 700 also includes an input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse), adisk drive unit 716, a signal generation device 718 (e.g., a speaker) and anetwork interface device 720. - The
disk drive unit 716 includes a machine-readable medium 722 on which is stored one or more sets of instructions (e.g., software 724) embodying any one or more of the methodologies or functions described herein. Theinstructions 724 may also reside, completely or at least partially, within themain memory 704, thestatic memory 706, and/or within theprocessor 702 during execution thereof by thecomputer system 700. Themain memory 704 and theprocessor 702 also may constitute machine-readable media. Theinstructions 724 may further be transmitted or received over anetwork 726 via thenetwork interface device 720. - Applications that may include the apparatus and systems of various embodiments broadly include a variety of electronic and computer systems. Some embodiments implement functions in two or more specific interconnected hardware modules or devices with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the example system is applicable to software, firmware, and hardware implementations. In example embodiments, a computer system (e.g., a standalone, client or server computer system) configured by an application may constitute a “module” that is configured and operates to perform certain operations as described herein. In other embodiments, the “module” may be implemented mechanically or electronically. For example, a module may comprise dedicated circuitry or logic that is permanently configured (e.g., within a special-purpose processor) to perform certain operations. A module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a module mechanically, in the dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g. configured by software) may be driven by cost and time considerations. Accordingly, the term “module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. While the machine-
readable medium 722 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present description. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. As noted, the software may be transmitted over a network using a transmission medium. The term “transmission medium” shall be taken to include any medium that is capable of storing, encoding or carrying instructions for transmission to and execution by the machine, and includes digital or analog communications signal or other intangible medium to facilitate transmission and communication of such software. - The illustrations of embodiments described herein are intended to provide a general understanding of the structure of various embodiments, and they are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein. Many other embodiments will be apparent to those of ordinary skill in the art upon reviewing the above description. Other embodiments may be utilized and derived there from, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The figures provided herein are merely representational and may not be drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
- Thus, a computer-implemented system and method for the definition, creation, management, transmission, and monitoring of errors in a SOA environment are disclosed. While the present invention has been described in terms of several example embodiments, those of ordinary skill in the art will recognize that the present invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The description herein is thus to be regarded as illustrative instead of limiting.
Claims (20)
1. A method comprising:
creating a data structure providing a standard error message definition specifying a plurality of fields, the fields comprising fields for at least an error ID, an error domain indicating a group within an organization from which the error comes, and an error category selected from a group comprising system errors, application errors, and client errors; and
within an error library structure, creating a plurality of errors conforming to the standard error message definition and grouping the errors into a plurality of error bundles corresponding to respective combinations of an error domain and an error category.
2. The method of claim 1 , wherein the error bundle for each combination of an error domain and an error category is automatically created upon a first creation of an error having that error domain and that error category associated with it.
3. The method of claim 1 , further comprising creating error groups based on developer input, and automatically registering a metric and collecting data for each error group at a time of initialization of the error group, the metric measuring a total error count for the group.
4. The method of claim 1 , further comprising defining error metrics measuring separate error counts for at least one of separate ones of the error categories, separate ones of the error domains, separate levels of severity, separate clients, or separate applications.
5. The method of claim 1 , further comprising automatically generating a unique error ID for each of the errors.
6. The method of claim 5 , wherein the error IDs are numbers, the method further comprising reserving special ranges of numbers for errors belonging to certain error categories or error domains.
7. The method of claim 1 , wherein the fields specified in the standard error message definition further comprise fields for at least one of a human-readable error name, a name of the organization from which the error comes, a sub-domain, a level of severity, a language-specific error message string, a language-specific resolution string, a cause of the error, and a language-specific exception name.
8. The method of claim 1 , wherein each error bundle comprises a metadata file that stores static data about the errors and a property resource bundle comprising properties files that store localizable data about the errors.
9. The method of claim 8 , wherein the static data comprises at least one of a name of the organization from which the error comes, the error domain, the error category, or a level of severity.
10. The method of claim 8 , wherein the localizable data comprises an error message string and a resolution string.
11. A system comprising:
a non-transitory machine-readable medium for storing an error library structure; and
one or modules implemented by a processor and memory storing instructions executable by the processor, the one or more modules being configured to
create of a data structure providing a standard error message definition specifying a plurality of fields, the fields comprising fields for at least an error ID, an error domain indicating a group within an organization from which the error comes, and an error category selected from a group comprising system errors, application errors, and client errors; and
create, within the error library structure, a plurality of errors conforming to the standard error message definition and grouping the errors into a plurality of error bundles corresponding to respective combinations of an error domain and an error category.
12. The system of claim 11 , wherein the one or modules are configured to automatically create the error bundle for each combination of an error domain and an error category upon a first creation of an error having that error domain and that error category associated with it.
13. The system of claim 11 , wherein the one or more modules are configured to create error groups based on developer input, and automatically register a metric and collect data for each error group at a time of initialization of the error group, the metric measuring a total error count for the group.
14. The system of claim 11 , wherein the one or more modules are configured to define error metrics measuring separate error counts for at least one of separate ones of the error categories, separate ones of the error domains, separate levels of severity, separate clients, or separate applications.
15. The system of claim 11 , wherein the one or more modules are configured to automatically generating a unique error ID for each of the errors.
16. The system of claim 15 , wherein the error IDs are numbers, the one or more modules further being configured to reserve special ranges of numbers for errors belonging to certain error categories or error domains.
17. The system of claim 11 , wherein the fields specified in the standard error message definition further comprise fields for at least one of a human-readable error name, a name of the organization from which the error comes, a sub-domain, a level of severity, a language-specific error message string, a language-specific resolution string, a cause of the error, and a language-specific exception name.
18. The system of claim 11 , wherein each error bundle comprises a metadata file that stores static data about the errors and a property resource bundle comprising properties files that store localizable data about the errors.
19. The system of claim 18 , wherein the static data comprises at least one of a name of the organization from which the error comes, the error domain, the error category, or a level of severity, and wherein the localizable data comprises an error message string and a resolution string.
20. A non-transitory machine-readable medium storing instructions executable by a machine, the instructions, when executed, causing the machine to
create a data structure providing a standard error message definition specifying a plurality of fields, the fields comprising fields for at least an error ID, an error domain indicating a group within an organization from which the error comes, and an error category selected from a group comprising system errors, application errors, and client errors; and
within an error library structure, create a plurality of errors conforming to the standard error message definition and grouping the errors into a plurality of error bundles corresponding to respective combinations of an error domain and an error category.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/727,574 US20150261595A1 (en) | 2010-04-23 | 2015-06-01 | System and method for definition, creation, management, transmission, and monitoring of errors in soa environment |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/766,712 US8407520B2 (en) | 2010-04-23 | 2010-04-23 | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment |
US13/850,021 US9069665B2 (en) | 2010-04-23 | 2013-03-25 | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment |
US14/727,574 US20150261595A1 (en) | 2010-04-23 | 2015-06-01 | System and method for definition, creation, management, transmission, and monitoring of errors in soa environment |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/850,021 Continuation US9069665B2 (en) | 2010-04-23 | 2013-03-25 | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment |
Publications (1)
Publication Number | Publication Date |
---|---|
US20150261595A1 true US20150261595A1 (en) | 2015-09-17 |
Family
ID=44816814
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/766,712 Expired - Fee Related US8407520B2 (en) | 2010-04-23 | 2010-04-23 | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment |
US13/850,021 Active US9069665B2 (en) | 2010-04-23 | 2013-03-25 | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment |
US14/727,574 Abandoned US20150261595A1 (en) | 2010-04-23 | 2015-06-01 | System and method for definition, creation, management, transmission, and monitoring of errors in soa environment |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/766,712 Expired - Fee Related US8407520B2 (en) | 2010-04-23 | 2010-04-23 | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment |
US13/850,021 Active US9069665B2 (en) | 2010-04-23 | 2013-03-25 | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment |
Country Status (1)
Country | Link |
---|---|
US (3) | US8407520B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10558514B2 (en) | 2017-11-06 | 2020-02-11 | International Business Machines Corporation | Error handling in a cloud based hybrid application integration |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8407520B2 (en) * | 2010-04-23 | 2013-03-26 | Ebay Inc. | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment |
US8527814B1 (en) * | 2010-10-22 | 2013-09-03 | Intuit Inc. | Method and system for repairing an error in a software application |
US8949991B2 (en) * | 2011-01-28 | 2015-02-03 | International Business Machines Corporation | Testing web services that are accessible via service oriented architecture (SOA) interceptors |
US8990770B2 (en) | 2011-05-25 | 2015-03-24 | Honeywell International Inc. | Systems and methods to configure condition based health maintenance systems |
CA2762696C (en) * | 2011-12-20 | 2018-11-20 | Ibm Canada Limited - Ibm Canada Limitee | Client selectable server-side error resolution |
WO2013095470A1 (en) * | 2011-12-21 | 2013-06-27 | Intel Corporation | Error framework for a microprocessor and system |
US8949678B2 (en) * | 2012-05-15 | 2015-02-03 | Sap Se | Generation of error messages and progress information messages via a common interface |
US9037920B2 (en) * | 2012-09-28 | 2015-05-19 | Honeywell International Inc. | Method for performing condition based data acquisition in a hierarchically distributed condition based maintenance system |
KR101400214B1 (en) * | 2013-01-28 | 2014-05-28 | 주식회사 알티베이스 | Appratus for providing a hybrid c interface |
US9223673B1 (en) * | 2013-04-08 | 2015-12-29 | Amazon Technologies, Inc. | Custom host errors definition service |
US20150012505A1 (en) * | 2013-07-02 | 2015-01-08 | Honeywell International Inc. | Configurable data masks supporting optimal data extraction and data compaction |
CN104301131A (en) * | 2013-07-19 | 2015-01-21 | 中兴通讯股份有限公司 | Fault management method and device |
US9477728B2 (en) * | 2013-08-09 | 2016-10-25 | Oracle International Corporation | Handling of errors in data transferred from a source application to a target application of an enterprise resource planning (ERP) system |
US9430319B2 (en) | 2014-08-26 | 2016-08-30 | Oracle International Corporation | Traffic capacity based optimization of SOA fault recovery using linear programming model |
US10339151B2 (en) * | 2015-02-23 | 2019-07-02 | Red Hat, Inc. | Creating federated data source connectors |
US10331507B2 (en) * | 2016-12-21 | 2019-06-25 | Mastercard International Incorporated | Systems and methods for real time computer fault evaluation |
US10866849B2 (en) * | 2017-01-17 | 2020-12-15 | American Express Travel Related Services Company, Inc. | System and method for automated computer system diagnosis and repair |
US10409667B2 (en) * | 2017-06-15 | 2019-09-10 | Salesforce.Com, Inc. | Error assignment for computer programs |
US11416329B2 (en) | 2019-06-13 | 2022-08-16 | Boomi, LP | System and method for community driven error handling system for platform users |
US11385948B1 (en) * | 2019-11-27 | 2022-07-12 | Amazon Technologies, Inc. | Distributed database exception handling |
US11221907B1 (en) * | 2021-01-26 | 2022-01-11 | Morgan Stanley Services Group Inc. | Centralized software issue triage system |
US20220300547A1 (en) * | 2021-03-19 | 2022-09-22 | EMC IP Holding Company, LLC | System and Method for Generating Defect Identifiers |
US11829230B2 (en) * | 2021-09-23 | 2023-11-28 | International Business Machines Corporation | Globally unique error codes for knowledge document indexing in software systems |
Citations (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6530041B1 (en) * | 1998-03-20 | 2003-03-04 | Fujitsu Limited | Troubleshooting apparatus troubleshooting method and recording medium recorded with troubleshooting program in network computing environment |
US6775238B1 (en) * | 1999-07-01 | 2004-08-10 | Ricoh Company, Ltd. | Image forming device management system and method |
US20050028145A1 (en) * | 2003-07-31 | 2005-02-03 | Sun Microsystems, Inc. | Flexible error trace mechanism |
US20060171055A1 (en) * | 2005-01-31 | 2006-08-03 | Ballard Curtis C | Recording errors in tape drives |
US20070067156A1 (en) * | 2005-08-30 | 2007-03-22 | Samsung Electronics Co., Ltd. | Recording medium for recording automatic word spacing program |
US7200779B1 (en) * | 2002-04-26 | 2007-04-03 | Advanced Micro Devices, Inc. | Fault notification based on a severity level |
US20070079168A1 (en) * | 2005-06-10 | 2007-04-05 | Microsoft Corporation | Exception handling in content based routing solutions |
US20080086515A1 (en) * | 2006-10-06 | 2008-04-10 | International Business Machines Corporation | Method and System for a Soft Error Collection of Trace Files |
US20080215925A1 (en) * | 2007-03-02 | 2008-09-04 | International Business Machines Corporation | Distributed fault injection mechanism |
US20090204697A1 (en) * | 2003-01-21 | 2009-08-13 | Tellabs San Jose, Inc. | Methods and apparatus for extended error reporting in network management |
US20090249031A1 (en) * | 2008-03-31 | 2009-10-01 | Fujitsu Limited | Information processing apparatus and error processing |
US20110031977A1 (en) * | 2008-04-16 | 2011-02-10 | O'sullivan Charles Brendan | System and method for locating line faults in a medium voltage network |
US20110302192A1 (en) * | 2010-06-04 | 2011-12-08 | International Business Machines Corporation | Systems and methods for first data capture through generic message monitoring |
US20120005297A1 (en) * | 2010-06-30 | 2012-01-05 | Robles Gil Daellenbach Francisco Xavier | System and method for controlling devices |
US20120151278A1 (en) * | 2010-12-13 | 2012-06-14 | Efstratios Tsantilis | Advanced management of runtime errors |
US8527814B1 (en) * | 2010-10-22 | 2013-09-03 | Intuit Inc. | Method and system for repairing an error in a software application |
US20140365828A1 (en) * | 2013-06-07 | 2014-12-11 | Successfactors, Inc. | Analysis engine for automatically analyzing and linking error logs |
US20150033202A1 (en) * | 2013-07-26 | 2015-01-29 | Fujitsu Limited | Method and apparatus for porting source code |
US20150269793A1 (en) * | 2014-03-19 | 2015-09-24 | Cummins, Inc. | Fault code hierarchy system |
US20160102975A1 (en) * | 2014-10-10 | 2016-04-14 | Hand Held Products, Inc. | Methods for improving the accuracy of dimensioning-system measurements |
Family Cites Families (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5892898A (en) * | 1996-10-04 | 1999-04-06 | Honeywell, Inc. | Error management system for supporting the identification and logging of error messages |
US6269460B1 (en) * | 1998-09-01 | 2001-07-31 | International Business Machines Corporation | Dynamic enhancement of error condition handling and displayed error messages in computer operations |
US6243778B1 (en) * | 1998-10-13 | 2001-06-05 | Stmicroelectronics, Inc. | Transaction interface for a data communication system |
US6446058B1 (en) * | 1999-04-26 | 2002-09-03 | At&T Corp. | Computer platform alarm and control system |
US6526529B1 (en) * | 1999-06-29 | 2003-02-25 | Microsoft Corporation | Dynamic error messaging |
US6526524B1 (en) * | 1999-09-29 | 2003-02-25 | International Business Machines Corporation | Web browser program feedback system |
US8707185B2 (en) * | 2000-10-10 | 2014-04-22 | Addnclick, Inc. | Dynamic information management system and method for content delivery and sharing in content-, metadata- and viewer-based, live social networking among users concurrently engaged in the same and/or similar content |
AU2002241770A1 (en) * | 2000-10-20 | 2002-06-11 | Accenture Services Limited | Method for implementing service desk capability |
US7076695B2 (en) * | 2001-07-20 | 2006-07-11 | Opnet Technologies, Inc. | System and methods for adaptive threshold determination for performance metrics |
US7089154B2 (en) * | 2001-08-09 | 2006-08-08 | Rovsing Dynamics A/S | Automatic machinery fault diagnostic method and apparatus |
US6946715B2 (en) * | 2003-02-19 | 2005-09-20 | Micron Technology, Inc. | CMOS image sensor and method of fabrication |
AU2003244927A1 (en) * | 2002-07-24 | 2004-02-09 | Koninklijke Philips Electronics N.V. | Forestalling long time-outs in processes |
US6829527B2 (en) * | 2002-08-26 | 2004-12-07 | Honeywell International Inc. | Relational database for maintenance information for complex systems |
GB2398969B (en) * | 2003-02-27 | 2006-07-05 | Ericsson Telefon Ab L M | Message management |
US7693952B2 (en) * | 2003-03-27 | 2010-04-06 | Microsoft Corporation | Availability and scalability in a messaging system in a manner transparent to the application |
JP4443200B2 (en) * | 2003-12-01 | 2010-03-31 | 富士通株式会社 | Information system |
US8001527B1 (en) * | 2004-12-21 | 2011-08-16 | Zenprise, Inc. | Automated root cause analysis of problems associated with software application deployments |
JP4686257B2 (en) * | 2005-05-25 | 2011-05-25 | 株式会社東芝 | Mask manufacturing system, mask data creation method, and semiconductor device manufacturing method |
DE102005041632A1 (en) * | 2005-09-01 | 2007-03-08 | Siemens Ag | Method and device for monitoring a technical device |
US7661013B2 (en) * | 2006-01-13 | 2010-02-09 | Agilent Technologies, Inc. | System and method for error recovery |
US7823053B2 (en) * | 2006-12-19 | 2010-10-26 | International Business Machines Corporation | System and method for searching error messages |
US20080228338A1 (en) * | 2007-03-15 | 2008-09-18 | Honeywell International, Inc. | Automated engine data diagnostic analysis |
US8010321B2 (en) * | 2007-05-04 | 2011-08-30 | Applied Materials, Inc. | Metrics independent and recipe independent fault classes |
WO2009034512A2 (en) * | 2007-09-14 | 2009-03-19 | Koninklijke Philips Electronics N.V. | Referencing out-of-band notification objects in dvb-ipdc |
JP4630350B2 (en) * | 2008-02-29 | 2011-02-09 | 株式会社沖データ | Image processing apparatus and image processing method |
US20090013208A1 (en) * | 2008-03-31 | 2009-01-08 | Dimuzio Thomas M | Real time automated exception notification and reporting solution |
JP2009282319A (en) * | 2008-05-22 | 2009-12-03 | Toshiba Corp | Pattern verification method, pattern verification system, pattern verification program, method for manufacturing mask, and method for manufacturing semiconductor device |
US8645760B2 (en) * | 2008-07-29 | 2014-02-04 | FAQware | Alternate procedures assisting computer users in solving problems related to error and informational messages |
US8949788B2 (en) * | 2008-12-17 | 2015-02-03 | Red Hat, Inc. | Building and packaging software |
US8589196B2 (en) * | 2009-04-22 | 2013-11-19 | Bank Of America Corporation | Knowledge management system |
US8788097B2 (en) * | 2009-06-22 | 2014-07-22 | Johnson Controls Technology Company | Systems and methods for using rule-based fault detection in a building management system |
US8132060B2 (en) * | 2009-11-25 | 2012-03-06 | Red Hat, Inc. | Comprehensive application programming interfaces for handling logical volume manager |
US8949867B2 (en) * | 2009-12-23 | 2015-02-03 | Oracle International Corporation | System and method for providing transaction monitor integration with service component architecture (SCA) runtime |
US8516437B2 (en) * | 2010-01-22 | 2013-08-20 | Ebay Inc. | System and method for creating, managing, and reusing schema type definitions in services oriented architecture services, grouped in the form of libraries |
US8407520B2 (en) * | 2010-04-23 | 2013-03-26 | Ebay Inc. | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment |
-
2010
- 2010-04-23 US US12/766,712 patent/US8407520B2/en not_active Expired - Fee Related
-
2013
- 2013-03-25 US US13/850,021 patent/US9069665B2/en active Active
-
2015
- 2015-06-01 US US14/727,574 patent/US20150261595A1/en not_active Abandoned
Patent Citations (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6530041B1 (en) * | 1998-03-20 | 2003-03-04 | Fujitsu Limited | Troubleshooting apparatus troubleshooting method and recording medium recorded with troubleshooting program in network computing environment |
US6775238B1 (en) * | 1999-07-01 | 2004-08-10 | Ricoh Company, Ltd. | Image forming device management system and method |
US7200779B1 (en) * | 2002-04-26 | 2007-04-03 | Advanced Micro Devices, Inc. | Fault notification based on a severity level |
US20090204697A1 (en) * | 2003-01-21 | 2009-08-13 | Tellabs San Jose, Inc. | Methods and apparatus for extended error reporting in network management |
US20050028145A1 (en) * | 2003-07-31 | 2005-02-03 | Sun Microsystems, Inc. | Flexible error trace mechanism |
US20060171055A1 (en) * | 2005-01-31 | 2006-08-03 | Ballard Curtis C | Recording errors in tape drives |
US20070079168A1 (en) * | 2005-06-10 | 2007-04-05 | Microsoft Corporation | Exception handling in content based routing solutions |
US20070067156A1 (en) * | 2005-08-30 | 2007-03-22 | Samsung Electronics Co., Ltd. | Recording medium for recording automatic word spacing program |
US20080086515A1 (en) * | 2006-10-06 | 2008-04-10 | International Business Machines Corporation | Method and System for a Soft Error Collection of Trace Files |
US20080215925A1 (en) * | 2007-03-02 | 2008-09-04 | International Business Machines Corporation | Distributed fault injection mechanism |
US20090249031A1 (en) * | 2008-03-31 | 2009-10-01 | Fujitsu Limited | Information processing apparatus and error processing |
US20110031977A1 (en) * | 2008-04-16 | 2011-02-10 | O'sullivan Charles Brendan | System and method for locating line faults in a medium voltage network |
US20110302192A1 (en) * | 2010-06-04 | 2011-12-08 | International Business Machines Corporation | Systems and methods for first data capture through generic message monitoring |
US20120005297A1 (en) * | 2010-06-30 | 2012-01-05 | Robles Gil Daellenbach Francisco Xavier | System and method for controlling devices |
US8527814B1 (en) * | 2010-10-22 | 2013-09-03 | Intuit Inc. | Method and system for repairing an error in a software application |
US20120151278A1 (en) * | 2010-12-13 | 2012-06-14 | Efstratios Tsantilis | Advanced management of runtime errors |
US20140365828A1 (en) * | 2013-06-07 | 2014-12-11 | Successfactors, Inc. | Analysis engine for automatically analyzing and linking error logs |
US20150033202A1 (en) * | 2013-07-26 | 2015-01-29 | Fujitsu Limited | Method and apparatus for porting source code |
US20150269793A1 (en) * | 2014-03-19 | 2015-09-24 | Cummins, Inc. | Fault code hierarchy system |
US20160102975A1 (en) * | 2014-10-10 | 2016-04-14 | Hand Held Products, Inc. | Methods for improving the accuracy of dimensioning-system measurements |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10558514B2 (en) | 2017-11-06 | 2020-02-11 | International Business Machines Corporation | Error handling in a cloud based hybrid application integration |
Also Published As
Publication number | Publication date |
---|---|
US20110264964A1 (en) | 2011-10-27 |
US8407520B2 (en) | 2013-03-26 |
US20130290794A1 (en) | 2013-10-31 |
US9069665B2 (en) | 2015-06-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9069665B2 (en) | System and method for definition, creation, management, transmission, and monitoring of errors in SOA environment | |
US9645880B2 (en) | Supportability framework for mobile software applications | |
US20180321993A1 (en) | System and method for management of deployed services and applications | |
US9323647B2 (en) | Request-based activation of debugging and tracing | |
US9697104B2 (en) | End-to end tracing and logging | |
US20020087734A1 (en) | System and method for managing dependencies in a component-based system | |
Soldani et al. | The μTOSCA toolchain: Mining, analyzing, and refactoring microservice‐based architectures | |
US8433782B2 (en) | Simplifying determination of dependencies among SOA services | |
US9143407B2 (en) | Granular client inventory management with conflict resolution | |
US8984034B2 (en) | Calculation engine and calculation providers | |
US11362912B2 (en) | Support ticket platform for improving network infrastructures | |
CN107908488B (en) | Message request interface interaction method and device, computer equipment and storage medium | |
US10831565B2 (en) | Fault tolerant adapter system to consume database as a service | |
US20230319054A1 (en) | Tenant-specific solution subscriptions for an extensibility platform | |
US20080209400A1 (en) | Approach for versioning of services and service contracts | |
US7934221B2 (en) | Approach for proactive notification of contract changes in a software service | |
US20180359317A1 (en) | System and method for non-intrusive context correlation across cloud services | |
Hummer et al. | Testing of data‐centric and event‐based dynamic service compositions | |
US10868719B2 (en) | System and method for federated configuration in an application server environment | |
US20100162205A1 (en) | Apparatus and method for automatically generating capability statements for management interfaces | |
US8694596B2 (en) | Systems and methods for information brokering in software management | |
US20230315418A1 (en) | Flexible meta model (fmm) for an extensibility platform | |
CN107911442B (en) | Receiving response interface interaction method and device, computer equipment and storage medium | |
US9436440B1 (en) | System, method, and computer program for validating web service interface design | |
Leida et al. | Facing big data variety in a model driven approach |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: EBAY INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MURPHY, RONALD FRANCIS;MALLADI, SASTRY K.;DENG, WEIAN;AND OTHERS;SIGNING DATES FROM 20100408 TO 20100414;REEL/FRAME:035758/0503 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |