I just wanted to point this out for anyone else who hasn't already noticed. Domain Services are usually components in disguise (ie..same thing, different terminology).
While a lot of emphasis is put on statelessness for components, there is actually a finer grained definition.
A class is a component if its clients can be instance agnostic.
Whether it's an IEmailSender or an interface for a remote service, your application typically does not care which instance of the proxy or helper class it gets. In terms of state, it's less about not having state and more about not having internal state.
For example, Data Access Components are allowed to have external state. Their state is stored in the form of the database. The fact that they appear to have state (the data in the database) does not breach the component definition. The reason is that since the state is centralized and external, the clients are instance agnostic. This falls within the guidelines of component-orientation.
Much like the guys building component architectures, we too use classes whose clients are instance agnostic. Service Layer classes are components. Domain Service classes are also components. There are no rules as to how a component is built out internally (procedurally, functionally, object-oriented), etc. Those are just the implementation details. I use an implementation of the Notification Pattern for Dto validation. It too is a component.
Anything you are injecting today is very likely a component. You can inject state into classes using tools like Windsor, but it's not easy (and involves injecting a properties hashtable--no thanks).
Oh, and those "configuration" variables don't count as state either (ie..SmtpServer). Those are perfectly valid in both paradigms.
Domain model applications are really component sandwiches, where the OOP/Domain Model is the meat.
What about NHibernate? The SessionFactory is a component--although you only ever want one instance per application. This is perfectly valid as well.
Sessions are a little bit trickier. Each Session has a unique state. This can still be accounted for if the session state were externalized to the session class. COM+ did the equivalent thing with transactions. In that case, components were used inside a "transaction stream". The statefulness (ie..the current transaction) become a part of the Context (the environment). The clients were instance agnostic, but the behavior of the instance changed slighly based on the particular context of execution. The same technique could be used of NHibernate sessions if the state was externalized (ie..into the Request Cache in ASP.NET). Then the clients could be instance agnostic and the Session would become a component. The same can be said of a Session's database connection and transaction. Another alternative (which I've seen several people do) would be to encapsulate the Session as state of a larger component (say..a Repository class). The Repository becomes a component. The Session becomes a part of the execution context (the environment). This would allow multiple clients to use the same Repository instance, with the behavior varying slighly based on context.