Consumer endpoints and remote operations/input message types formation

Question

Hello,
Couple of questions;
1) In case of a BC, a consumer endpoint (i.e. a proxy for an external consumer) doesn't need to be activated with the NMR -- is this understanding correct?
2) Moreover, as the SU for this component defines a "consumes" element in the jbi.xml , but the operation is not specified in the jbi.xml (but will be specified, in a configurtion artifact that goes inside the SU, as I understand).
Now, how would the BC dynamically form an NMR message that conforms to the operation input message type of the service it's consuming ? The BC will know about the remote operation and it's input message type only upon SU deployment..
Hope I am articulating my question clearly..

Answer 1

A binding component (BC), when dealing with a newly received request message from an external service consumer, must map the message to a particular service and operation (as defined by JBI's WSDL-based services model). How this mapping is performed depends on the nature of the protocol the BC handles, as well as the implementation of the BC.
To answer your specific questions:
1. Only provided services are activated, by the provider. Consumers (including a BC acting as a proxy for an external consumer) need only discover the service (at design- or run-time) in order to use it.
2. The SU jbi.xml exists to help design tools which wish to recompose service assemblies. The "consumes" element gives tooling information about static service dependencies of the SU. (This avoids requiring that the tooling have deep knowledge of the contents of the SU itself -- composition can be done using any SUs, regardless of how they were created.)
Recomposition of a service assembly is accomplished by matching service types, not individual operations.
3. The BC can create a NormalizedMessage (and a MessageExchange the will hold it) using three sources of information:
- The message from the external consumer
- BC configuration information (from SUs deployed to it)
- Service metadata (WSDL), as published by the service provider.
Note that in some protocols the message from the external consumer is not sufficient to determine which service and operation are required. In such cases so-called trading-partner data are needed, as part of the BC's configuration data (from SU deployments), to map an inbound request message to the service and operation needed.
So, to answer your final question (and hopefully I understand it correctly), in general the BC needs to be configured to create the external endpoint to which the external consumer can send messages. Depending on the nature of the BC, it may also need additional data about mapping messages to JBI's service-and-operation model of services. Dynamic mapping is certainly supported.
In typical binding components, the BC only "learns" of a new external endpoint that it must expose when a service unit is deployed to it. However, JBI does not restrict BC's to only using this mechanism. A BC could use a different mechanism, but this in general complicates administration and component portability.
Does that answer your questions?