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.
one for internal use
ISvcInternal: ISvcCustomerMgmt,
ISvcOrderMgmt, ISvcInvoicesMgmt
//,maybe more in the future
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.
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.
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.
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.
Related
One of the architecture decision that i am going through is to build 2 services vs 1 for almost 90% same functionality. The key here is performance factor.
Logic for 2 services is:
External client service will be more high performance
Possibly if there are methods that only are required for external clients then this methods can be specific to this service.
There will be some common dll for core DAL, SAL functionality that will be utilized by both internal & external services. To ensure no code redundancy.
Logic for 1 service:
If the functionality of external vs internal is not too different, adding a few methods should work.
Single high performance service, why should internal users suffer ? :)
With time, branching 2 services might add more overhead & risk of keeping some logic in sync as there will be 2 different teams involved. This can create discrepancies in similar appearing functions.
Is there a standard industry wide approach used for this classic argument?
Thanks.
I think it will depend alot on how much common functionality and code there is between the 2 services. If it's 90% like you suggest it would seem silly to duplicate that code for another service. Also, from a maintenance perspective this would mean double the work is required for each change that is common to both external and internal.
It should be fairly simple to separate out functionality required for only external clients vs internal within 1 service (interfaces perhaps?). I would think it's more a matter of carefully designing 1 service at this point rather than trying to create and maintain 2.
Base on your problem statement I would like to suggest use of one service.
if you use two services for the same functionality maintenance cost and integrity of your service might get compromise.Also if the problem is in the performance, better solution would be to use multiple service endpoints and load balancing to provide efficient use of the service.
In implementation you might have two different implementation to cater internal and external users ( use of interfaces and overriding functionalities) but all users points to the same service
I have a set of services I want to be able to access via one end point altogether.
Now I want to build something in wcf rather than use an existing framework/software so that is out of the question.
Suppose I have 10 contracts each representing a contract of an indepedent service that I want to "route" to, what direction should I go?
public partial class ServiceBus : ICardsService
{
//Proxy
CMSClient cards = new CMSClient();
public int methodExample()
{
return cards.methodExample();
}
So far I've tried using a partial class "ServiceBus" that implements each contract but then I have more than a few (60+) recurrences of identical function signatures so I think I should think in a different angle.
Anyone got an idea of what I should do? or what direction to research? currently I'm trying to use a normal wcf service that's going to be configured with a lot of client end points directing to each of the services it routes TO - and one endpoint for the 'application' to consume.
I'm rather new at wcf so anything that may seem too trivial to mention please do mention it anyway.
Thanks in advance.
I have a set of services I want to be able to access via one end point
altogether.
...
So far I've tried using a partial class "ServiceBus" that implements
each contract
It's questionable whether this kind of "service aggregation" pattern should be achieved by condensing multiple endpoints into an uber facade endpoint. Even when implemented well, this will still result in a brittle single failure point in your solution.
Suppose I have 10 contracts each representing a contract of an
indepedent service that I want to "route" to, what direction should I
go?
Stated broadly, your aim seems to be to decouple the caller and service so that the caller makes a call and based on the call context the call is routed the relevant services.
One approach would be to do this call mediation on the client side. This is an unusual approach but would involve creating a "service bus" assembly containing the capability to dynamically call a service at run-time, based on some kind of configurable metadata.
The client code would consume the assembly in-process, and at run-time call into the assembly, which would then make a call to the metadata store, retrieving the contract, binding, and address information for the relevant service, construct a WCF channel, and return it to the client. The client can then happily make calls against the channel and dispose it when finished.
An alternative is to do the call mediation remotely and luckily WCF does provide a routing service for this kind of thing. This allows you to achieve the service aggregation pattern you are proposing, but in a way which is fully configurable so your overall solution will be less brittle. You will still have a single failure point however, unless you load balance the router service.
I'm not sure about making it client side as I can't access some of the
applications (external apis) that are connecting to our service
Well, any solution you choose will likely involve some consumer rewrite - this is almost unavoidable.
I need to make it simple for the programmers using our api
This does not rule out a client side library approach. In fact in some ways this will make it really easy for the developers, all they will need to do is grab a nuget package, wire it up and start calling it. However I agree it's an unusual approach and would also generate a lot of work for you.
I want to implement the aggregation service with one endpoint for a
few contracts
Then you need to find a way to avoid having to implment multiple duplicate (or redundant) service operations in a single service implementation.
The simplest way would probably be to define a completely new service contract which exposes only those operations distinct to each of the services, and additionally a single instance of each of the redundant operations. Then you would need to have some internal routing logic to call the backing service operations depending on what the caller wanted to do. On second thoughts not so simple I think.
Do you have any examples of a distinct service operation and a redundant one?
I'm working on a fairly straight forward multi-tier application (WPF, WCF, EF 4, and SQL). As far as architecture is concerned, we were planning to include a single "Common" project which will include both entities as well as service contracts.
Are there any advantages/disadvantages to having entities and service contracts in separate assemblies? Or is it usually good to keep them together?
I'm interested in hearing the opinion of others.
Thanks!
Having Contracts in a separate assembly gives you the advantage of the ability injecting to a different entities in a different assembly by providing the Contracts assembly to a developer , and he would implement it and give you a dll that you can put inside the project folder and inject to it using IoC framework like StructureMap without rebuilding,
having the contracts in the same assembly that contains the entities tie the contracts to the implementations...
If you are using a RESTful architecture with other .NET platform consumers - it's helpful to have the Service Contracts in a separate assembly (Shared) so that you can easily share your operation and data contracts with RESTful consumers without exposing any unnecessary data access components to your clients.
I would recommend that you keep the data access and service contracts isolated for this reason.
That is exactly how I structured the design for an e-commerce n-tier app I designed.
There are two common libraries - one for DTO's and another for interfaces.
Then the client and server included those librarues, and the service proxies were generated using common types.
The main advantage here is ease of compilation - you don't have to recreate the proxies when you change the insterface, the client and server are updated automatically.
I also had a utilities app that contained all the helper type stuff I needed.
EDIT: Sorry, just re-read your question. In my case, I had multiple interface libraries - one for the workflow library (with composed interfaces), and another for services (the thing being composed into workflow operations)
So in my case it made sense to keep them seperate.
If you only have one set of interfaces, and those interfaces all make use of your DTO's, there is no reason to seperate them into two libraries - one would be sufficient. Consider though if you may need to share your DTO's between more interface libraries in future, in that case rather keep the DTO's seperate from the interfaces from the start.
In the last 2 years I've been developing a distributed application in c# 3.5 using WCF at communication tier on TCP/IP protocol; so far I've been using the integrated Add Service Reference... to generate service proxies on the client side, but I also know that using channel factories to create a communication channel (thus accessing service contract methods) is a viable approach.
The questions are pretty straightforward (please argument the answers):
Which are the pros & cons of either approach?
Should the "automatic" generation method be preferred in most contexts, and if so, why?
Under wich circustances (if any) is the "custom" approach justified/needed?
(please tell me if more contextualization is needed to answer)
For me the one reason to use custom proxies is to be able to use the same interface[type] and domain types on both the client and the server. The automatic generation creates quite a few classes that will inevitably increase the size of your assembly, so if you're building a silverlight app where download time is critical or if you have a hefty memory constraint, channel factory might be the way to go.
I also like the DRY-ness of channel factory, since i typically have my domain objects anyway, why generate them again? Especially if i have a bunch of buisness logic in them. Ofcourse, that is really only applicable to wcf-to-wcf communication, if you're talking to any other service, you'd want to have the domain objects generated
(Im also assuming here that the domain types and interfaces are in their own assembly, separate from the actual back-end persistance code)
I'm working on a system right now that is in a single process space; we are breaking this up into several processes, initially to run on the same box but ultimately to distribute across several separate machines. I'm leaning towards using an ESB (NServiceBus, Rhino ESB) or possibly rolling my own with WCF + queues to handle the pub/sub and request/response scenarios our app has.
However, I'm struggling with the abstraction: I don't want the various components to know they are talking over the bus. The current APIs connecting the various services translate pretty well to this kind of model, but I want to hide that from the client and server sides. Short of writing a lot of custom proxy code for the client and server, is there a better way to approach this? I realize WCF can auto-generate proxies based on the service definition, but I really like some of the other stuff I get with (say) rhino servicebus.
Ideally, I'd like to be able to swap out different implementations (with and without an ESB/messaging layer) just using IoC (knowing there would have to be limits enforced by convention on what can be passed across the interfaces), but I'm not sure where to go with that. I'd really prefer to not have to change every method call on the current interfaces into its own discrete message class, either.
Any resources/patterns/tools to help me do this? Please ask questions if I'm not clear. Thanks.
There may not be one solution/off-the-shelf component that might help you.
Problem 1:
The basic problem can be solved via an ESB, as it provides location transparency and service aggregation. A regular ESB mediates/brokers requests between service consumer and service provider.
Take a simple example:
Service_A depends on Service_B
Service_C depends on Service_B
Service_B depends on Service_D
In this scenario, the best way to progress is this:
Define contracts exposed by Service_B and Service_D as external dependencies (possibly as a web service, though an ESB supports multiple protocols) in services Service_A, Service_C and Service_B, and consume via an ESB.
In ESB, to start with, route thes services Service_B and Service_D on the same instance.
If you migrate Service_D and Service_B as Service_Dx and Service_Bx on a different location, the ESB can be reconfigured to route to the new location. Also, an ESB can be configured to route to Service_B or Service_Bx based on some set of parameters (eg., test data to Service_B and production data to Service_Bx)
Problem 2:
The problem of IOC could probably be hard to achieve; there may not be a need.
I presume the clients, instead of consuming from a known location, are injected with the whereabouts of service location. This in reality transfers the configuration to client side. With this, for every new client added to the system there needs to be a separate configuration control. This might lead to logistical issues.
Please post your final solution, very interested to know your approach.