I'm looking for any recommended articles that discuss the pros/cons of building a web service vs. a component assembly. I'd like to find something that provides some guidelines for choosing one implementation method over another.
Does anyone know where I can find an article like this?
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
Please explain what you mean by "in-process" component assemblies, and how that would save on network/xml processing overhead.
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.
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.
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"
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)
Hope it helps!
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
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 |
