The Service Candidate Model generally shows multiple candidate tasks for each service, one for each element of procedural functionality. During service-oriented design the candidate tasks for a single service are generally "collapsed" into a single message that is generic and parameter-driven (one of the message elements is the task name, derived from the name of the original candidate task).

Therefore, in the general case, there will be one message schema for each service (more accurately, for the single generic operation exposed by the service), and this schema will include every information element that might be required for all of the service's tasks, specified in a "polymorphic" way. The service's schema will include an abstract complexType containing a "task name" element (typically an enumeration) and any other elements that are common to all of the service's tasks, and one complexType that "extends" the abstract type for each defined task name. The result is that the service consumer only needs to "fill in" the elements of a single complexType in any message (the complexType that is specific to the desired task).

There may not be a one-to-one relationship between entity-centric services and the domain object entity model.

When creating a message schema for the operation that initiates an orchestrated service, the primary source of input is the definition of "data objects" shown on the BPMN diagram.