4

I have some entities like: Customers, Orders, Invoices.

For each one of them I grouped their CRUD operations and few other in interfaces like: ISvcCustomerMgmt, ISvcOrderMgmt, ISvcInvoicesMgmt, ISvcPaymentsMgmt.

Now I need to create few WCF service contracts independent to each other which will consist of implementing one or more of this interfaces.

  1. one for internal use ISvcInternal: ISvcCustomerMgmt, ISvcOrderMgmt, ISvcInvoicesMgmt //,maybe more in the future
  2. one for external use (3rd parties) ISvcExternal: ISvcCustomerMgmt //,maybe more in the future

So, my real services look like this: 1) SvcInternal: ISvcInternal, 2) SvcExternal: ISvcExternal.

When I see SvcInternal implementation, it gets bigger with a lot of operations.

Is this method flexible enough? Do you recommend another approach of splitting them up somehow? Feel free to share your thoughts.

Thank you.

Learner
  • 3,297
  • 4
  • 37
  • 62

3 Answers3

3

if i have to implement this i would say i will put all the code and Operations in a Worker Manager or Fascade Layer... that will consist of all operations... (Real coding logic).

my service will be only a thin client that will only pass request to Fascade layer.... This allows me to reuse a great amount of code... and it also allows me to expose same method in more then one services without ReImplementation.... One point though why don't you use differentiate b/w you internal and external services with different bindings... e.g. even if you are going to use WSHttpBinding or BasicHttpBinding for both services create different endpoints and binding for them....

in terms of Code Hirerachy my idea would be of using folder hirerachy and namespaces to differentiate b/w this... e.g. Namespace.Interfaces.Internal and vice versa...

hope that helps.

Usman Masood
  • 1,937
  • 2
  • 17
  • 33
  • Since I have different DTOs b/w the internal and external service, I thought I should create 2 different services, 2 different assemblies. – Learner May 17 '11 at 16:40
  • Yes, you're right... each service will request to another common shared assembly for the real operations behind... I already have this in mind. My question is more on WCF side... and how is best to play with these interfaces. Is it a good practice with this one interface which inherit others from which at the end it will define the service contract? – Learner May 17 '11 at 16:48
  • Could you please answer http://stackoverflow.com/questions/9553267/design-parameter-decision ? – LCJ Mar 04 '12 at 09:45
2

This can be an endless debate... How you choose to group your service operations is up to you.

One way is to put everything in a single, cover-it-all service, which acts as a façade to cover the internal complexities. But, as you say, that can grow quickly.

Another option is to have one service per entity type, or per aggregate root. An aggregate root is an entity that has an ID and is independently manageable from other entities. An example: you may have an Invoice entity and an InvoiceLine entity; then the Invoice entity is an aggregate root but the InvoiceLine entity is not, because it cannot exist without an Invoice -- therefore, it is not independent.

Yet another approach is to divide up per domain -- that is, divide up the service into smaller services that are each consistent and independent of the other services. Sometimes that is possible, sometimes it isn't. Use your judgment.

Roy Dictus
  • 32,551
  • 8
  • 60
  • 76
  • Yeah, I like somehow your idea with one service per aggregate root... but then if we have an internal application which should connect to these multiple different services... is it really a good practice? – Learner May 17 '11 at 16:53
  • 1
    Why not? It's perfectly normal to have apps that integrate multiple services. It's what SOA is based on. – Roy Dictus May 18 '11 at 05:09
  • Thanks a lot. Do you mind giving me a good link which describes very well SOA principles? – Learner May 18 '11 at 09:50
  • 1
    Take a look at http://www.softwareadvice.com/articles/manufacturing/service-oriented-architectures-soas-a-plain-english-guide-1052110/ and good luck with your project! – Roy Dictus May 18 '11 at 10:34
  • Could you please answer http://stackoverflow.com/questions/9553267/design-parameter-decision ? – LCJ Mar 04 '12 at 09:45
1

At our company, services consist of 3 assemblies:

1) the "contract" assembly which we name [Company].[Project].Contract. This assembly contains the DTO (Domain) objects, the Interface definitions and a Client class to access the service. This assembly can be shared with those who want to consume your service.

2) the "business" assembly which we name [Company].[Project].Business. This assembly exposes a factory class that returns interfaces to the internal business worker classes.

3) the "service" assembly, which we name [Company].[Project].Service for a traditional SOAP service or [Company].[Project].Rest in case of a REST service, it is the "facade" that publishes the service's interfaces and covers the transport and protocol logic.

Putting all functionality in one service is a good option to start with, but you will soon find that certain classes belong together naturally, so you will probably end up with a number of domain specific services.

Now, WCF has this great concept of configuration, but those who have field experience with this will agree that this can be very tedious and error-prone, especially when your SOA becomes more complex (as it always does, eventually). This always results in very complex configurations, multiplied by the various environments (development, test, staging, production) the services will run in. Needless to say this might result in errors.

To cope with this, we use the broobu framework that allows near-zero config for WCF services using WS-Discovery and dynamic proxy generation the only drawback for this solution is that you preferably use IIS-hosted services with AppFabric 1.1. This way, you use IIS to configure the services: much safer (since you won't use XML config files) and much more scalable.

Rafael Lefever
  • 11
  • 2