Provider implementation should override this method and set the value to ETrue, if it wants to receive complete messages instead of plain message bodies (example: full SOAP Envelope vs. SOAP Body).

Default implementation typically returns EFalse, which means that provider will receive the body of the message only.

Separate session initialization method, which is called when some session of certain requester (service consumer) is "attached" to this provider. In case of non-sharable provider, this happens only once. Method performs some auto-configuration to that session, describing the capabilities (facets), that are enabled in this provider implementation.

Typically, frameworks should call this method when they find provider to be local, in order to fully initialize their client side session which represents the provided service.

So, this method is performing "auto-configuration" for service sessions, so that caller (session itself) can read these properties of the provider from the XML SD (aSession). This way, a deployed provider does not need to be followed by explicit Service Management API calls configuring, lets say, whether a provider is exposed or not. Provider implementation, which wishes to explicitly expose it's service to outside world (outbound requests from network) should override this method and make it return ETrue. This would cause "expose" facet to be added to service session (SD), granting access from otherwise *trusted* requester (access control is done using policies). Even trusted identities cannot access providers in the device, if they don't explicitly expose their service.

Default implementation typically returns EFalse, which means that the provider is meant for local service consumers only.

Default implementation typically returns EFalse, which means that provider will not be loaded on WSF main process (Symbian server) start-up.

Re-init should be implemented by those Hostlets (providers), which want to allow that instance to be re-used, that is resetted by the invoker. For example, then some component responsible of loading of the providers might be able to improve performance of slowly constructed providers by calling this method, instead of de-allocating that instance and making a ECOM lookup creating a similar, but new instance to same service provider endpoint. Implementations should thus reset any state variables that they have, and set themselves to the state in which they were right after first construction. However, some performance benefits can be achieved if some class members can be treated as "stateless objects", which can be re-used without possibly much slower re-instatiation.

This method is a pair to Reinitializable() function, meaning that when one develops such provider which supports reinitialization, that re-init should be implemented behind this ReinitL() method.

Default implementation typically does nothing and returns KErrNotSupported, since most of the providers don't support re-initialization.

Provider implementation should override this method and make it return ETrue, if they are capable of returning their internal state to one equal with state that they were right after original construction.

Provider implementation should override this method and set the value to ETrue, if it implements capability to server several service consumers (sessions).

Default implementation typically returns EFalse, which means that provider is NOT shared between multiple consumers (sessions).

Provider implementation should override this method and make it return EFalse, if it wants to implement multi-threaded, non thread-safe ServiceL. This typically means that such providers will make use of RCriticalSection inside of their own implementation.

If a provider is sharable *but not* thread-safe, it means, that it is possible that multiple requests to ServiceL, from multiple consumers are executed simultaneously from separate threads. It is strongly recommended to use critical sections inside the provider plug-in implementation. This kind of sharable providers might be serving under quite heave load. The requesters (threads) should be identified by the information available in hostlet request interface

Then again, if provider is not sharable *but not* thread-safe, it means that multiple request threads from *same service consumer* might execute ServiceL simultaneously. Provider implementation should therefore offer thread-safe functionality inside ServiceL, possibly via use of RCriticalSection instance, or through some other mutex.

MSenHostletRequest to figure out ids for requesters / addressees

Re-initializable or shared service providers, which instance is being called from multiple threads may wish to override this method in order to act on this signal and to properly initialize their thread specific components, like those which have Thread Local Store (TLS) based implementation.

If the method leaves, it is treaded equally as if the leave occured in the actual ServiceL. Re-initializable or shared service providers, which instance is being called from multiple threads may wish to override this method in order to act on this signal and to properly initialize their thread specific components, like those which have Thread Local Store (TLS) based implementation.