Are objects with behavior bad for SOA?

posted Thursday, February 26, 2004 9:42 PM

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?

12 Comments

# re: Are objects with behavior bad for SOA?

Thursday, February 26, 2004 11:54 PM by Dave    
I just implemented a service that works sort of like what you're talking about for a web app:

myObject.DoSomething(context1, context2, etc);

instead of,

SomeService.DoSomething(myObject, context1, context2, etc);

Now, under the covers, myObject.DoSomething calls SomeService.DoSomething.

But personally, I'm not proud of the smoke-and-mirrors act. Hmmm, I wonder if the object.DoSomething call will be inlined....

# re: Are objects with behavior bad for SOA?

Saturday, February 28, 2004 1:38 AM by Udi Dahan - The Software Simplist    
"The author" == Me ?

I don't suggest that ALL objects be without behaviour. Objects that are internal to a service can and probably should have behaviour. I mean, implementing services in an OO way is just fine.

The problem I have is how "stuff" is passed between services. Everybody is always talking about passing DATA between tiers, and then they go passing objects with behaviour instead. Finally, the methods are (obviously) invoked on those same objects, because they're there. This isn't exactly passing data between tiers.

IMO, if you want to pass around data, do JUST that. If somebody needs functionality, let them go to the appropriate place and use it.

Although I don't agree with a lot of things in the Pet Shop v3, there you can see an example of a layered architecture. Even there, you see that Data Transfer Objects are used to pass data between tiers, NOT behaviourly rich objects.

# re: Are objects with behavior bad for SOA?

Sunday, February 29, 2004 6:05 PM by Sebastien Lambla    
See my response
<a target="_new" href="http://blog.thetechnologist.net/PermaLink,guid,35b9d67f-2368-431d-ab70-7ca90596239f.aspx">http://blog.thetechnologist.net/PermaLink,guid,35b9d67f-2368-431d-ab70-7ca90596239f.aspx</a>

# re: Are objects with behavior bad for SOA?

Monday, March 01, 2004 12:27 AM by Steve    
Udi, As you know you are one of the &quot;authors&quot; I talk about above. You are most certainly not alone. Almost everything I've read has taken that stance.

I agree that we shouldn't say we're just passing data and then also pass objects with behavior. I also agree that objects used within SOA should not have behavior (that the client knows about). What I'm still trying to form is my thoughts on the best way to design the underlying objects that are used within a SOA. This post was just one step in that process. I think we can have a rich object model behind our service (meaning objects with behavior), and then hide this to clients of our services by only exposing the data through the WSDL and schemas for our services. What this doesn't account for is the non-web service service, such as remoting. In that scenario its a little harder to hide the behavior.

Thoughts?

# re: Are objects with behavior bad for SOA?

Monday, March 01, 2004 2:47 AM by Edneeis    
Maybe in the remoting case you would have a provider for the service that handles that specific issue. It could also just translate the remote data object to just strict data to be passed into the regular service that everything else talks to. Thats a bit of a hack though.

Or am I wrong in the idea that the services will be generic and then more specific implementations would be written as providers that interop with said services for certain access paths?

# re: Are objects with behavior bad for SOA?

Monday, March 01, 2004 2:48 AM by Sebastien Lambla    
Steve,

the reasonning about remoting is not right. Remoting is a distributed objects architecture, and doesn't respond to any of the pillars that supports the SOA architecture.

# re: Are objects with behavior bad for SOA?

Monday, March 01, 2004 3:16 AM by Udi Dahan - The Software Simplist    
Isn't it reasonable to assume that client code would want/need to have access to the object model ?

Assuming that the client code has access to the Orders collection ( property ) of the Customer object, how would it add a new Order to the customer ?

I know that this is a work in progress, so I'm not trying to shoot it down, but rather raise some issues with it in order to increase its quality.

# re: Are objects with behavior bad for SOA?

Monday, March 01, 2004 3:59 AM by Steve    
The client code would have access to the object model, it would just have access to it through a schema. If the client is .NET the client would get the parts of the object model that we wanted them to have when they added the service as a Web Reference.

Regarding adding a order to the customer object, wouldn't we want to do that through a service rather then on our object? The Order collection on the client may have an array of orders on the Customer if the service returned the Customer with that data, but the client would not be able to add an order there via Orders.Add(new Order()); but instead would do that through the service. Agree?

Now when we actually write the code for the service, we can just do customer.Orders.Add(order); since behind our service we have our rich object model.

# More on objects in SOA...

Monday, March 01, 2004 4:14 AM by Steve Eichert    
More on objects in SOA...

# re: Are objects with behavior bad for SOA?

Monday, March 01, 2004 4:26 AM by Steve    
Sebastien, Have you checked out Shadowfax? It's Microsoft's SOA reference architecture. One of the channels it makes services available through is Remoting. Although Remoting might not be the recommended or preferred way to expose services it is an option in .NET only environments.

# re: Are objects with behavior bad for SOA?

Monday, March 01, 2004 7:17 AM by Udi Dahan - The Software Simplist    
Just playing the devil's advocate here :-)

What's to stop client code from calling:
myCustomer.Orders.Add(myOrder);
and assume that everythings been done ?

Why should client code call the &quot;more cumbersome&quot; service:
Service.AddOrderToCustomer(myOrder, myCustomer);

Once we expose the Orders collection, how do we communicate that the proper API to use is sometimes the object model, like the Orders property, and sometimes the &quot;service model&quot;, like the AddOrderToCustomer call ?

Maybe it makes more sense to settle on one direction and follow it ?

# re: Are objects with behavior bad for SOA?

Monday, March 01, 2004 11:46 AM by Steve    
The Orders property of the customer object would be an array of order objects:

public class Customer {
public Order[] Orders {
get {...}
}
}

Since the array doesn't have a .Add() method the client wouldn't be tempted into calling it :) Would you argue that the Customer class shouldn't even have the Orders collection? I'm ok with not exposing the orders collection to clients by not putting that in the schema that is exposed to clients. As you know I'd likely have the collection on my rich object model which lives behind my service. Just to be clear what one direction do you recommend following? Thanks for the continued pressure to think this thing through ;-)

Post a Comment

 
 
Prove you're not a spammer: 
8 + 7 =