As it relates to Web Services:
Native using the org.jboss.soa.esb.actions.soap.SOAPProcessor
Non-Native using org.jboss.soa.esb.actions.soap.SOAPClient
Native means it is based on JBossWS and hosted within our container.
Non-Native means it is normally external to our container (e.g. a .NET service).
Does that help a little?
The definition should be irrespective of the transport.
A native ESB service, aka ESB-aware service, is on that understands the Message format directly and without the aid of an intermediary or adapter (e.g., gateway).
A non-native service is one that is deployed outside of the ESB and communicates using a data format that is not supported directly by ESB-aware services. It needs an adapter (e.g., gateway) to interact with services/consumers.
Thanks, that does help a little. Does that mean there will be similar paris of methods
for every other 'preexisting' or legacy service (EJBs, Spring-POJOs, ...) which we want to acces from the ESB?
Not really. EJBs can be handled via their remote interface therefore can be local or remote. Spring has its own action that assumes it is local.
By "local" I mean in the same container/JVM.
We do have quickstarts for both SLSB and Spring POJOs that demonstrate how to interact. So while not the same exact technique it is close. The difference is that with SOAP/XML you can essentially generate a client on the fly. With Spring & EJB that is a little bit harder.