In most of the discussions I've read regarding SOA the author makes a point of saying that any object being used in a SOA should only contain data and not behavior. My question is why? Your object's behavior isn't going to be exposed to the client if they access your objects via your services anyway. Well that's assuming your services are web services. Let's for a second forget about the fact that you can have SOA without web services. :-)
In a SOA with web services the request and response for your web services will be defined using WSDL and schemas. The schemas for your business object will not contain information about the behavior of your objects, so to the clients using your web service it looks like your objects only contain data. However, in the code for your web service you can use your objects, and their glorious behavior. Behind your web service you know your going to need to perform basic CRUD operations on your objects so why not make them available on your object rather then through a manager class. WHOA, but doesn't that create a coupling between your object and the data store? Absolutely not. That's what the provider model is for. If your objects are coded to use a provider to service the CRUD operations you can completely decouple the object from the actual implementation details of how the CRUD operations are performed for your object.
Do the objects behind your web services have behavior? Why not?