Web Service vs. Component

Web Service vs. Component

• Chaepp

  Ah! Thanks for the clarification.

  The points you've listed above are exactly my concern. Using a local copy (or GAC) version of a dll provides obvious performance benefits, but does not necessarily fit most definitions of SOA.

  Our SOA will include reusability that is implemented via components as well as services. Consider it a hybrid, if that is more comfortable.

  Form an architectural or designer perspective, I need to evaluate whether reusability is best implemented on a case-by-case basis as a web service or a component. This isn't a broad generalization that I'm trying to make.

  In one instance I may have a service interface that deals with thousands of records of data. For argument sake, let's say that this service might be consumed by at most 3 consumers and the functionality is rock-solid. The data source isn't likely to change in 50 years! In this case it doesn't make sense to implement this as a service. This is a fairly static function with a small number of consumers and a large volume of data. Reusability is best implemented as a component assembly that is bound at compile time to the consuming application.

  In other cases I'm implementing functionality that has broad business impact and can be reused by dozens of existing and future consuming applications. This seems like a strong candidate for implementation as a web service.

  I'm hoping to find an article that gives advice on similar tradeoffs to help make the decision of implementing as a service or component.

  
  

• Pandaurae

  The in-process is an old term of MTS days and is not relevant in .NET terminology, - I am not sure what is the term for "non remoting" calls in .NET, hence used the same.

  By "In-process" - I mean Plain Old method call, directly, not via remoting. For which we refer the called class as DLL's as regular reference and not a web reference (or could have it in the same Visual studio project itself).

  This way your dll will be distributed in the same bin folder and loaded in the same runtime as consumer class - so there is no "over the network" call.

  When we architect based on SOA , we could end up with multiple layers - most commonly an orchestration layer calling multiple services. Now the physical architecture might demand these services and layers to sit on the same machine.

  In which case, making a .NET remoting call or a Web Services call over the network - between the orchestration layer and the service - could be avoided using local or in-process call.

  
  
  

• NewC#

  Ron,

  as some other colleagues are explaining, you can smartly combine inner components exposed to the outside as web services

  I can recommend you an article of John Evdemon, explaining the "must" and "must not"

  • Principles of Service Design: Service Patterns and Anti-Patterns

  Also, an article of Pat Helland explores the different level of coupling you should keep in components (data on the Inside) vs web services (data on the outside)

  • Data on the Outside vs. Data on the Inside

  Hope it helps!

  
  
  

• Mowali

  Please explain what you mean by "in-process" component assemblies, and how that would save on network/xml processing overhead.

  
  

• mmlodzik

  Thanks Diago. This was also very useful.

  
  

• dvboom

  Thank you.

  That's the kind of article that I was searching for.

  
  

• asiaindian

  Hi Ron,

  IMHO you shouldnot consider web servers VS component assemblies as Either/OR.

  The answer you should look for is whether Service Orientated Architecture is what fits you needs.

  If you are convinced about having a SOA architecture, you can still implement your application services and layers as in-process component assemblies to save on all the network/xml processing overheads. And if needed, you can always have Web Services wrappers over the same.

  Pranshu

  
  
  

• Zaph0d

  Hi

  I had created a document for myself that I think it might be useful for you for that decision making:

  Web Services VS Shared Components

  	Web Services	Shared Components
  Client Application	Can be any client application (.Net or not .Net) like: Other web services, web applications, windows application, Flex applications	must be .Net application only like: web services, web applications, windows application, …
  Client Environment	Local or Remote	local or Remote
  References	It can have a reference to other web services or other shared components	It can have only references to the other shared components and not web services.
  Client Update	Is updated automatically.	You must copy the new assembly to the client.
  Reusability	You should just know the URL of the existing web service, and enjoy using it.	You must copy the assembly with all its dependency involved to the new place.
  Performance in the same .Net environment	Lower, as it desterilize and serialize objects to XML	Higher, because you can access it directly in a .Net application only.
  Security	Higher because IIS applies its security	Lower, as you should apply the security manually

  
  
  

• NiklasECG2

  Hi Ron,

  If you are already convinced on SOA and on implementing a hybrid model - then your question is essentially on distributing and deploying the application right

  Will I be correct in restating your question as "When shall I distribute my reusable entities as components/SDK and when as Web Services "

  A google for component vs web services threw up the below URL which I think is quite accurate and to the point

  http://www.acmqueue.com/modules.php name=Content&pa=showpage&pid=246

  If you search for ".NET remoting VS Web services" or , you would be able to find many articles, and all of what they discuss will apply + more.

  have a look at the below for instance

  http://www.lhotka.net/weblog/CommentView,guid,be2ee6b3-9809-4007-93e1-bc0c405a48a2.aspx

  essentially, the discussions will revolve around the usual suspects:

  - Technology independance

  - hosting vs distributing.

  - Performance

  I dont want to distract you - but I must say that REST is becoming popular - and in a few days will rival SOAP, so I would rather design and implement my services as "Plain Objects" and then give them a SOAP wrapper or a REST wrapper - as need be.

  Pranshu

  
  
  
• Web Service vs. Component