views:

52

answers:

2

Hi all,

we are building product that can be used by other systems. As we have SOA, we develop only a service (WCF). We had several controversial discussions about how to design an interface of that service. We are choosing between procedural and OO design for service.

As our service will be used from .NET and Java some say that it is hard to integrate with service if it has OO design. Other think that services mast not use OO approach. Some say that OO is completely OK. As result we there is no clear depression on it.

WCF provide easy way to use both designs but what is the best?

+1  A: 

I assume the definition of "Object Oriented" you are using is the concept of the program managing "Objects", and these individual objects manage their internal state and expose functions to be called.

The closest WCF parralel to this is Session-based services, where the lifetime of each service instance is controlled by the client.

If you want this service to be invoked by Java you would have to use basicHttpBinding, as this uses the classic web-service protocol.

This binding does not provide support for session-based services, so you literally cannot use session based services.

Therefore, you cannot apply the "object-oriented" paradigm with regard to the service itself.

Andrew Shepherd
+1, but also, adopting an OO approach to service design leads to services that are too fine grained. You should aim for services to be coarse grained. I'd thinking in terms of 'messages' rather than 'objects'.
Tim Roberts
+1  A: 

You clarify your original question by saying: "My question is about the methods of the service should they receive complex types instead of scalar parameters?"

You should ask yourself the following:

a) Is there any chance that the service may be used by non-OO clients? Dunno, a COBOL batch? Even if your company has standardized on OO tech (Java/.NET) is there any chance that this specific service may be used in the future by some external entity (customer, PHP website, whatever)

b) Have you already created many such a service in the past (so you are perfectly sure there is no marshalling/serializing/deserializing problems with complex types, or are at least aware what you can safely use)?

If you are fully confident about both points, then feel free to use an "OO" approach in designing both inputs and outputs for your service. Otherwise, go for the safest (if more primitive) approach, and decompose the "objects" in groups of scalars.

p.marino