| 
| 
| |
To understand the structure of the messages that are part of the API, you need a basic appreciation for the different data structures and XML formats that are used. This section discusses the major data structures that are passed as input and output parameters for major API messages.
A <businessEntity> structure holds basic business information such as contact information, categorization, identifiers, descriptions, and relationships to other businesses.
The <publisherAssertion> structure establishes a relationship between two <businessEntity> structures. In order to prevent any unfair relationship claim, a relationship between two <businessEntity> structures is visible to the "public" only when a reciprocal assertion has been created by the two companies. To do so, the two businesses publish independently two separate <publisherAssertion> documents that each claim relationship with one another. The <publisherAssertion> structure defines a fromKey that identifies the <businessEntity> at the first "side" of the relationship and a toKey that identifies the <businessEntity> at the other "side".
A <businessService> represents a single service. A <businessService> is part of the definition of a <businessEntity> structure, a <businessEntity> being potentially composed of several <businessService> structures. A business service can be just any type of service a company can provide, from a manual, fax, E-mail or phone service to a fully automated XML-based Web service. A <businessService> is a reusable structure that can potentially be referred to by several <businessEntity> structures. This is particularly useful to holding structures, for example, as this allows subsidiary to refer to common services provided by the company. A <businessService> contains one or more <bindingTemplate> structures.
A <bindingTemplate> contains pointers to technical descriptions of services as well as their access points. An optional text description of the web service can be provided. A <bindingTemplate> does not contain the details of the service's specification. Rather, it refers to <tModel> structures that hold pointers to the actual location of these specifications.
A <tModel> is an abstract description of a particular specification or behaviour to which the web service adheres. A <tModel> is a type of digital "fingerprint" for determining the specifics of how to interact with a particular web service. The <tModel> structure does not provide the web service's specification directly. Rather, it contains pointers to the locations of the actual specifications. Companies can use the information pointed to by a <tModel> to determine whether a web service is compatible with their business requirements.
| |
(c) INSPIRE IT, 2003 | Send us your feedback: developers@ruddi.biz