Thanks Keith.

Could you elaborate on the @Remote suggestion?

Elaborating on the @Remote suggestion... At the moment, we have it such that the service consumer references (changing to use your terminology... might make it easier) we inject into service consumers/clients are always proxies that capture the invocation parameters, wrap them up in an exchange and send the exchange to the Service using the ESB Exchange mechanism.  What Pete was suggesting (and I agree) is that we should make this explicit, only using an ESB proxy when the injection point has an appropriate annotation.  If this annotation is not present, then a reference to the actual @ESBService impl bean is injected i.e. invocations on that reference would not use an ESB proxy bean and the ESB Exchange mechanism.  My first suggesting was that this annotation could be called something like @Remote, but then I was thinking that we could just the same annotation as we're using to define the service i.e. @ESBService.

You are putting operation name in the message context, but this should be in the exchange context, no?

Yep... should be on the Exchange context.

We are using the same annotation for declaring that a bean  implementation is a service as we are for declaring an interface as a  consumer reference.  I haven't thought through the ins and out of this,  but that may end up being a problem later on.  Then again, maybe not.  :-)

If I'm reading you correctly.. presently we're not using any annotation (aside from the standard @Inject) for declaring a consumer reference, but we are suggesting that we should and I'm currently suggesting that we use the same annotation (i.e. @ESBService).  I agree that this might cause isues down the road (not sure what), but would like to try it initially anyway just to see.  For obvious reasons, I think using the same annotation is easier for developers using this.

How do we plan on dealing with non-object payloads (e.g. XML, JSON,  etc.)?  Obviously this can be handled through handlers or other  services, but my point is how would this be expressed easily by the  developer that is adding the @Service annotation to provide or consume a  service from a bean?

Yeah... been wondering about this too.  To me, this is a more general transformation issue and so is probably part of a wider discussion.

I don't think it makes sense to define transformation details on the @ESBService itself because that has implications all the way back.  I don't really like the idea of defining them on the Consumer class either because I think that's hardwiring details into the consumer + requires the consumer to have detailsed knowledge of the provider (tight coupling etc).

Ideally, I think transformation details should be defined as part of each possible Exchange, so that different transformations can be defined, depending on the source/target details of the exchange.

Some random use cases...

1. CDI <-> CDI:  No transformation required, or a Java to Java transform (e.g. where the API changed in a new version).  Or perhaps you want Java <-> JSON <-> Java on the exchange, where JSON is what's sent between sender and receiver etc etc
2. File Component <-> CDI:  Obviosuly depends on the file payload e.g. XML to Java.
3. CDI <-> XML Consumer Service: Java to XML
4. etc

How will this work in an environment where Weld and SwitchYard are  deployed as indpedent services?  Lifecycle and classloading are two  sticky points that need to be resolved.

Yeah... this is something that I'm wondering about too.  I'm going to start playing with some Seam and Weld+JSF examples.

However, I have been thinking that the consumer side of the equation needs to be able to "see" @ESBService contracts (Java interface for now) without visibility on the actual @ESBService impls (as is now the case).  The @ESBService impl shouldn't even need to be deployed yet (or could be remote).  But this probably goes back to how the registry will be used.  Will Service registrations only be in the registry when the Service is actually deployed (as is the case in ESB4, which is a bit of a cocked up approach IMO).  If service registrations were separate from the lifecycle of a service deployment then we could obviously query the registry and get the service contract details (java interface for now) and create injectable client/proxy beans for invoking those services, without requiring access to the implementations (as is currently the case with how I've done it).