9

I am taking over a project to replace an ancient legacy system from the ground up. Before I came on, the company hired a consultant who put together a basic sketch of the system and pushed SOA heavily. This resulted in a long list of "entity services", with the intention of them being composed into more complex service combinations. For instance, a user wanting committee info would hit the "Committee" service, which then calls the "Person" service to get its members, and the "Meeting" service to get its meetings, and so on.

I understand the flexibility gains in this, but my concerns are about performance. It seems to me that a system built with such a fine level of granularity to its services spends too many resources on translating service messages, and the performance will be unacceptable. It also seems to me that the flexibility gains can still be made using basic reusable objects, although in that case the benefit of a technology-agnostic interface is lost to gain performance.

For more background: The organization requesting this software does not currently have a stable of third-party software suites that need integrating with. This software will replace all suites. There are also currently no outside consumers who need to access the data outside of the provided website interface -- all service calls will be from other pieces inside our system. The choice of SOA in this case seems entirely based on the concept of "preparation".

So my question -- what level of granularity is acceptable in a stable of services without sacrificing performance? Am I being too skeptical of the performance hits we'll take implementing all our entities as services? Should functionality be available as web services only when they are needed, with the "preparation" focus instead going into designing the business layer for the probability of services later being dropped on top of it?

roberttdev
  • 42,762
  • 2
  • 20
  • 23

3 Answers3

4

First off, finding the "sweet spot" in the number of services is difficult for sure. Too many services, and your integration costs suffer, too few, and your implementation costs suffer. You have to find a good balance.

My advice to you is to follow Juval Lowy's methodology in that you should break down your services by areas of volatility, or areas of change. This will give you your granularity level. You should also read his WCF book if you can.

As for the performance, WCF will inherently support many thousands of calls per second depending on your use cases and hardware. Services calling services is not a problem. The platform will support it if you do your part. For example, use the right binding for the right scenario (named pipes to call services on the same machine and TCP to call services across machine where possible). You should also implement a vertical slice of the application and do performance testing before building the rest of the application. This will verify your architecture.

BrandonZeider
  • 8,014
  • 2
  • 23
  • 20
  • Could you point me to where in the "Juval Lowy's methodology" link I can go to get an idea of the actual methodology? – roberttdev Apr 01 '11 at 15:18
  • Unfortunately there isn't just one place on the internet to go and learn his methodology. For that you'd have to take his Architect Master's class. What you can do is listen to the episode of .NET Rocks featuring him, read his WCF book, and read his WCF best practices. All of these links can be found on the home page of http://www.idesign.net under Resources. – BrandonZeider Apr 01 '11 at 15:24
  • Could you please answer http://stackoverflow.com/questions/9538710/reports-in-soa-business-intelligence-service-oriented-architecture ? – LCJ Mar 02 '12 at 19:01
3

When I say "Service", I mean the complete vertical component that can perform a complete independent operation. And I don't prefer going in more granularity unless there is exceptional requirement. In my view of SOA, A service should perform the meaningful business function that can be independently performed. A service should not require another service to complete its function.

Tayyab
  • 9,951
  • 1
  • 16
  • 19
  • What about in the example above, where "Person" is a theoretical service? It performs an independent business function of returning all data relating to a person (name, DOB, addresses, etc), but it's also part of other business functions (returning committee info, returning donor/donation info, returning job applicants, etc..) – roberttdev Apr 01 '11 at 13:38
  • @Tayyab - I disagree. If you design your system that way you will end up with a lot of duplicated code or a tightly coupled application. While this certainly works, it's more OOP than SOA. In an SOA, consumers of a service only know about the contract of the service, not the underlying implementation. For example, if a service needs to instantiate a class from a DLL in order to perform it's work, then it has explicit knowledge of the implementation and not just the contract, and you're stuck shipping that DLL to every service that needs it whenever its implementation changes (coupling). – BrandonZeider Apr 01 '11 at 13:53
  • 1
    In my point of you have business entities (person, meetings etc...) and getting list of persons should not be a service. You call it a service when it performs a complete independent business process. You can have reusable entities like (person, meetings etc..) and you can use these entities in multiple services but interdependency between services makes no sense. When you think about services do not think from developer's perspective. Try to think from the perspective of business analyst when you identify "What should be a service". – Tayyab Apr 01 '11 at 14:21
  • 1
    @BrandonZeider: Well that's a separate discussion regarding internal implementation of the service. And also its sometimes fair to have explicit knowledge of some DLL for developer who is coding the service. The service contract is for "consumer" of the service and the consumer should be able to call a single service for a task or process. If consumer have to call multiple services to complete a single independent task then you are asking a "consumer" to have explicit knowledge of your solution. – Tayyab Apr 01 '11 at 14:29
  • @Tayyab - remember that services can also be consumers or clients of other services, and it's very common to have a high level service that needs to call several services in order to accomplish its task. An example would be a registration service. The Register() method might call UserService.Save(User user), EmailService.SendNewUserNotification(User user), etc. The UserService might then call even more services to save the User record (User.Address, User.Contact, etc). So while the INITIAL consumer might call 1 service, that service can be a consumer of many services to accomplish its task. – BrandonZeider Apr 01 '11 at 14:55
  • @BrandonZeider: Its all about how you perceive SOA. Different communities have different perception of SOA. The concept you are talking about is referred to SOA by some Microsoft people but I personally disagree with it. I think its more of a component oriented architecture, not a service oriented architecture. I agree more with the SOA perception of Open Source community where a service is a process that automates some business flow. So from your example I would consider "EmailService.SendNewUserNotification(User user)" as a part of "Notification Service" but "User" is just a business entity. – Tayyab Apr 01 '11 at 20:51
  • @BrandonZeider: Also there is no loose coupling in your example. There is synchronous communication between "Register Service" and "User Service". And also Register Service cannot work without Strong dependence on "User Service" so its not independent. – Tayyab Apr 01 '11 at 21:04
  • @Tayyab: Not sure why we're still talking about this...but...we can disagree on the definition of SOA, that's a pretty common thing to disagree on, but my example is loosely coupled. The various services only know about the service contract, not the service implementation. Sync/async has nothing to do with coupling, that's just an invocation detail of the consumer. I think you are a bit confused. Same story with dependency. Dependency does not equal coupling. No matter how you implement it (objects vs services) you are dependent on something, but that doesn't necessarily mean tight couplihng. – BrandonZeider Apr 02 '11 at 00:57
  • @BrandonZeider: Well its always good to have discussion. I would recommend you should have a look outside the Microsoft box. Let me share a few links, even if you don't want to read all, just have a look.... "http://blogs.sun.com/crupi/entry/soa_service_granularity" – Tayyab Apr 02 '11 at 10:17
  • @BrandonZeider: And I don't mean that a service cannot call another service. There can be compound services that call other services. But we shouldn't make everything a service. I am just saying that "Registration Process is a Service" BUT "A User is an entity, Not a service". Anyways, I didn't mean to impose my concepts on you or anybody... Its just that we agree or not but discussion is always good. – Tayyab Apr 02 '11 at 10:26
  • @Tayyab: Thanks for the link, but it gives a 404. I've had several looks outside the Microsoft box. Microsoft just has the winning hand right now with .NET (adoption rate in my area, ease of use, features, etc). And you're right, we do disagree on what should be services, because using WCF as your implementation stack, I subscribe to the "every class as a service" philosophy pioneered by Juval Lowy. I put all business functionality/data retrieval entry points into services, which freaks some people out big time. ;) Oh, and user was ALWAYS an entity, or a DataContract, as it's called in WCF. – BrandonZeider Apr 02 '11 at 13:02
  • Sorry a quote was appended to the link, please check that again http://blogs.sun.com/crupi/entry/soa_service_granularity – Tayyab Apr 02 '11 at 13:34
  • @BrandnZeider: Yeah you are right, but I strongly disagree with Microsoft when it comes to Enterprise Solutions... :) And of course they have Best IDE and easy to user components but that doesn't make them Architecture Experts... I have read Juval Lowy and he is Microsoft guy too... When it comes to Enterprise I go with Sun/Oracle, SAP and IBM.. They rulez... Maybe its just my hate for Microsoft ;) but I'm desperate to see Opensource kicking Microsoft out of Enterprise Business :) – Tayyab Apr 02 '11 at 13:40
1

What level of granularity is acceptable in a stable of services without sacrificing performance?

Individual entities. As described by the consultant.

Am I being too skeptical of the performance hits we'll take implementing all our entities as services?

Yes. Way too skeptical.

A decent framework can optimize some of these requests so that they don't involve a lot of network overheads.

As with SQL databases, the problems are largely solved. You'll find that the underlying applications that you're presenting as services are the bottlenecks. The SOA layer is largely plumbing. The bits still need to move through the pipes, the SOA layer just organizes them more intelligently than most of the alternatives.

Should services only be implemented when they are needed, with the "preparation" focus instead going into designing the business layer for the probability of services later being dropped on top of it?

Yes.

That's what "Agile" means.

Find a user story. Build just the services (and entities) for that story.

You will have some significant overhead for the first few stories in getting your SOA framework all squared away and deployable as a simple, repeatable release step.

Never do extensive "preparation" for things you "may" need in some improbable future. Read up on Agile and how to prioritize a backlog.

S.Lott
  • 384,516
  • 81
  • 508
  • 779
  • I think I was misleading in my "Should services only be implemented when they are needed" question. The question I meant to ask was.. is it prudent to only implement non-web-service objects/entities for a solution, up until the point there is an explicit need for a web service for that functionality? – roberttdev Apr 01 '11 at 14:34
  • IMO it depends how soon you want to ship... there's a right way to do things (which you can eventually work towards) and a way that makes everyone happy quickly without the extra work. – Mr Shoubs Apr 01 '11 at 14:39
  • Could you please answer http://stackoverflow.com/questions/9538710/reports-in-soa-business-intelligence-service-oriented-architecture ? – LCJ Mar 02 '12 at 19:02