JSON Description of Services

Name identifies the service. The other attributes identifying the service are the Domain and Version. The Domain typically identifies the category of the service and Version is a string representing a version number. The combination of Name, Domain, and Version is unique for each service registry entry. For example, two or more services may have the same name as long as the domains are different or the versions are different.

Domain specifies the category of the service.

Version identifies the version of the service.

Lifecycle Stage describes the development state of the service. It can have one of the following values: Concept, Development, Test, Staging, Live, Deprecated, and Defunct.

Service Protocol describes the protocol used by the client to access the service. It can have any of the following values: File, FTP, HL7, HTTP, REST, SOAP, SQL, X12, and any custom value.

Description provides a brief explanation of the service

Endpoint specifies the location of the service. This is the location you use to call the service.

Response Style describes how the service returns a value. It may have one of the following values: Sync, Callback, Remote Deposit, or a blank value.

The date and time that the registry entry was last changed in the ESB registry. you can discover services that were added or updated since a specified date and time by calling Get Services By Modified.

Topics provide a series of terms that are useful in searching for services using the Get Services By Word call.

Contacts specify people or organizations that support or are associated with the service. A contact can contain the following subfields:

• Identity—Specifies the name or other identity of the person or organization.

• Type—Specifies whether the contact is the service Author, Consumer, Provider, Operator, Manager, or Sponsor.

• Details—Specifies details about the contact.

• Business Partner—A field that is used internally by the service registry but that is not useful to an application using the public API.

• Notes—Specifies supplementary information about the contact.

The Schema describes the structure of the service messages. Schema contains subfields that describe or contain the structure definition. Schema can contain the following subfields:

• Type—Specifies the name of the schema definition mechanism used to describe the schema. It can bee WSDL, XSD, HL7, SEF, X12, AST, EDF, or a custom schema definition mechanism.

• Ref—Specifies the URL of the schema definition.

• Content—Provides the full text content of the schema definition.

• Notes—Provides supplementary information about the schema.

• Thumbnail—Provides a brief excerpt from the schema.

Always has a true value. Used internally in the service registry.

Attributes specify a list of Name-Value pairs that allow an ESB service registry to contain any information about a service.

Files provide a way to include one or more files in a registry entry. For example, a file can contain documentation on the service. Each file in a single registry entry must have a unique filename. When you make a Get Services call, the returned JSON message does not include the file contents. To get the file contents, you make a separate GetFileByID call. Each File element consists of the following subfields:

• Filename—Provides the name of the file. Typically, this includes the file extension. You cannot have two files in a single registry entry that have the same filename.

• File Extension—Provides information on the format and purpose of the file. Optional.

• MIMEType—Provides information on the application used to access the file. Optional.

• CharEncoding—Provides the character encoding information. Optional.

• File Size—Provides the file size. Optional.

• Contents—This field is always null in the JSON service description. You must call the Get File By ID call to get the file contents.

Actions specify the SOAP actions or the REST HTTP request methods that you can use with the specified URL. SOAP actions provide a summary of the information defined in the WSDL. An action can contain the following subfields:

• Name—Specifies the name used by the Registry to identify this action.

• Ref—Specifies a string identifier of the action.

• Verb—Specifies the HTTP request method. Typically, this is GET, PUT, POST, or DELETE, but it can be any HTTP request method.

• Description—Specifies a text explanation of the action.

• Request Schema—Specifies the format of the incoming message body and consists of the following subfields: Type, Ref, Notes, Thumbnail, and Content.

• Response Schema—Specifies the format of the response message body and consists of the following subfields: Type, Ref, Notes, Thumbnail, and Content.

• Read Only—If checked, specifies that the call does not make any changes to the state of the server.

• Idempotent—If checked, specifies that making multiple identical calls have the same impact on the server as making a single call.