SOA and WCF design questions: Is this an unusual system design?

Question

I found myself responsible for developing a system that I did not initially develop, and I can not ask the original designers why some design decisions were made, since they are no longer there. I am a junior design developer, so I did not know what to ask when I started the project, which was my first SOA / WCF project.

The system has 7 WCF services, will grow to 9, each of which will be placed in a separate console application / window service. All of them are single and single-threaded. All services have the same OperationContract: they set the Register () and Send () methods. When client services want to connect to another service, they first call Register (), and then, if successful, they perform all their communication with Send (). We have a DataContract that has a MessageType and Content propety enumeration that may contain other useful DataContract data. What the service does with the message is determined by the MessageType enumeration ... everything comes through the Send () method and then goes to the switch statement ... I suspect this is unusual

Register () and Send () are actually OneWay and Async ... ALL results from services are returned to WCF CallbackContract client services. I believe that the resonance for using CallbackContracts is to facilitate the use of the Publish-Subscribe model that we use. The problem is not that our communication is suitable for publishing-subscribing and using CallbackContracts means that we must include the source data in the returned result messages so that clients can decide what results were returned from ... again, clients have switch statements for development what to do with messages coming from MessageType-based services (and other built-in details).

In terms of topology: services form “nodes” in a graph. Each service hard-coded a list of other services to which it should connect when it starts, and will not allow client services to "Register" with it until it makes all the connections it needs. As an example, we have a LoggingService and a DataAccessService. DataAccessSevice is a LoggingService client, so the DataAccess service will try to register with the LoggingService when it starts. Until he can successfully Register the DataAccess service, he will not allow clients to register with it. As a result, when the system starts up as a whole, services start in a cascading manner. I do not see this as a problem, but is it unusual?

To make things more complex, one of the system requirements is that services or “sites” do not have to be directly registered with each other in order to send messages to each other, but can be linked through indirect links. For example, suppose we have 3 services A, B, and C connected in a chain, A can send message C through B ... using 2 flights.

Actually, I was entrusted with this, and I wrote a routing system, it was fun, but the leadership remained before I could ask why it was really necessary. As far as I can see, there are no reasons why services cannot simply connect directly to other services that they need. Most of all, I had to write a reliability system on top of everything, since the requirement was to have reliable message passing through the nodes in the system, but with simple point-to-point connections, WCF reliably performs this work.

Prior to this project, I only worked on winforms desktop applications for 3 years, but did not know anything better. My suspicions that this project is too complex: I think my questions are:

1) Is this the idea of ​​a graph topology with messages jumping on indirect links unusual? Why not just connect the services directly to the services that they need to access (which is actually what we do anyway ... I don’t think we have any messages jumping)?

2) Opens only 2 methods in OperationContract and uses the MessageType enumeration to determine what message is for / what is unusual to do with it? Should the WCF service expose many methods with specific goals, and the client chooses which methods he wants to call?

3) Makes all communication with the client through CallbackContracts unusual. Of course, synchronization or asyc request-request is easier.

4) Is the idea of ​​a service that does not allow client services to connect to it (Register) until it connects to all its services (to which it is a client) sound design? I think this is the only design that I agree with, I mean that the DataAccessService should not accept clients until it is associated with the logging service.

I have so many WCF questions, more will appear in subsequent threads. Thanks in advance.

Answer 1

Well, everything seems a little strange, agreed.

All of them are one instance and single-threaded.

It will definitely come back and cause serious performance headaches - guaranteed. I don’t understand why someone would want to write a Singleton WCF service to start with (except for a few cases with edges where it makes sense), and if you have a single-point WCF service, to get decent performance, it should be multi-threaded (this is complicated programming , and that is why I almost always advise against it).

All services have the same OperationContract: they set Register () and Send ().

This is pretty weird. So, does anyone call .Register () first and then call .Send () with different parameters several times? Funny design, actually ... It is assumed by SOA that you design your services as a model of a set of functions that you want to open to the outside world, for example. your CustomerService can have methods like GetCustomerByID , GetAllCustomersByCountry , etc. - depending on what you need.

Having only one Send () method with parameters that determine what is being done seems a little ... unusual and not very intuitive / understandable.

Is this the idea of ​​a graph topology with posts linking indirect links to the unusual?

Not necessary. It makes sense to expose only one interface to the outside world, and then use some internal backend services to do the actual work. NET 4 will actually introduce the RoutingService in WCF , which simplifies such scenarios. I don't think this is a big no-no.

Performs all communication with the client through unusual CallbackContracts.

Yes, unusual, fragile, dirty - if you ever get along without it - go for it. If you have mostly simple calls, such as GetCustomerByID - make them a standard request / response - the client requests something (by providing the client ID) and returns a Customer object as the return value. Much easier!

If you have long service calls that may take several minutes or more to complete, then you can consider one-way calls that simply queue the request and this request is processed later. As a rule, here you can postpone the response to the response queue that the client checks, or you can have two additional service methods that give you the status of the request (not done yet?), And the second method to get the result of this request.

Hope that helps you get started!

Answer 2

All services have the same OperationContract: they set the Register () and Send () methods.

Your design seems unusual in some parts that specifically expose only two operations. I did not work with WCF, we use Java. But based on my understanding, the whole purpose of web services is to disclose operations that your partners can use.
For me, there are only two Operations. You usually publish your API using WSDL. In this case, WSDL will not add anything useful to partners if you have a lot of documentation. As a rule, the name of the operation should be taken for granted. Right now, your system cannot be used by partners without internal knowledge.

Performs all customer feedback through unusual CallbackContracts. Of course, synchronization or asyc request-request is easier.

Agree with you. Async should only be used for long processes. Async adds correlation overhead.