Why would I use Serviced Components?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

David Young - 13 Apr 2005 15:19 GMT

I've really been struggling with this question for weeks now. I've
litterally read EVERY article on the .Net Architecture site. I've read more
blogs than I care to admit and I still just don't get it. I understand SOA
and can see where it would benefit certain types of applications for certain
types of businesses. But I don't see practical application in my case.

I recently had a phone conversation with a collegue from another company.
After explaining our software's architecture to him, he had this to say.
"You said it's an N-Tier application, but I don't see that in your design.
I mean, you said yourself that your not using COM+ (I assumed he meant
Enterprise Services)." Obviously, my response was something along the lines
of "We'll just because there is no '' physical '' seperation of layer,
doesn't mean the N-Tier architecture isn't solid. You can have a logical
seperation without a physical one." We'll that got me thinking. Should I
physically seperate my components? Would that improve scalability or
performance? So I started doing some research into the Enterprise Services.
Serviced Components, Remoting, SOA, WebServices. Everything sounds nice,
but I've never found a difinitive answer to my question of How will this
improve my scalability and or performance.

I've babbled long enough. Lets get to the point. Can someone out there
please tell me or point me to something that will help me put this to bed.
Should I use serviced components and which components should I consider
making serviced?

Assumptions:

Main user interface is ASP.Net
Database is Sql Server 2K
Application configuration and administration interfaces are mixed. ASP.net
via internet or lan, and c# winforms via lan.
Future enhancements includes a C# winforms user interface (Smart Client)
that uses to WebServices.
Using Enterprise Library
Using business object classes and custom collections instead of datasets.

Right now the Business Object, Business Logic Layer and Data Access Layer
are all combined in the same project (dll) Making this dll a serviced
component would most likely be more overhead than what I'm wanting.

Should I pull the business objects out and make that a seperate project and
leave the Business Logic and Data Access as a single project? Should they
all be single projects? Does it make sense to even use Serviced Components.

Reply to this Message

Paul Glavich [MVP ASP.NET] - 14 Apr 2005 14:55 GMT

The answer to your question could potentially be a rather large book,
however I'll try and keep it small and concise.

- Dont separate tiers physcially if you dont have to. Performance will
*always* suffer if you do. Having the option to is nice, but if you dont
have to, then dont. It also aviods extra complication the extra
communication methods you are required to implement.
- Dont use COM+ unless you have to. From what you have described I can't see
a reason why you should, however you may want to use distributed trxs,
queued components, object pooling or other nice features of COM+. This may
or may not necessarily improve performance depending on your current
requirements, architecture and usage scenarios, however if your current
architecture and processes satisfy your business domain/problem domain well,
then I would *generally* not use them. Alternatively, you may want to expose
your .Net components via DCOM and COM+ is great for that, however I couldn't
see where you'd want to do that (given your brief description) so again, I
probably would not use it. Not using COM+ does not mean its less, or more,
scalable.
- I always separate my DAL into a separate assembly, as well as the business
logic layer (which may itself be multiple assemblies). Your business objects
should also be in a separate assembly. Are they shared across multiple
assemblies? If so, then keep them modular and in a separate assembly.
- Use a very thin assembly to expose your web services/service interface
layer. That assembly should then interface/call the other lower level,
business logic assemblies.

Again, dont feel like you have to use COM+ to make a scalable, high
performing app. Look at Microsoft for example. A lot of their applications
(forums, PetStore implementation for eg) dont use COM+, and service many
hundreds of thousands of clients.

This is a quick and short answer to what could amount to hours of discussion
and there are no definitive rules to apply. Everything usually *depends*.. I
hope it helps somewhat.

Signature

- Paul Glavich
ASP.NET MVP
ASPInsider (www.aspinsiders.com)

> I've really been struggling with this question for weeks now. I've
> litterally read EVERY article on the .Net Architecture site. I've read more
[quoted text clipped - 39 lines]
> leave the Business Logic and Data Access as a single project? Should they
> all be single projects? Does it make sense to even use Serviced Components.

Reply to this Message

David Young - 14 Apr 2005 15:45 GMT

Thanks.

> The answer to your question could potentially be a rather large book,
> however I'll try and keep it small and concise.
[quoted text clipped - 82 lines]
> > all be single projects? Does it make sense to even use Serviced
> Components.

Reply to this Message

Eric Giles - 22 Apr 2005 03:50 GMT

I made the decision a while ago to only use COM+ (Enterprise Services) when I
absolutely needed to. Funnily enough, I have yet to use one since making this
decision.

If you are going to rely on distributed transactions, then it may be a
choice you would make however there are many other approaches that can work
just as well that do not require distributed transactions. Also, obvious
performance/locking issues can be alleviated by avoiding them.

Another reason you may need to use them is if you want to use MSMQ or
Security however again, there are other methods available to do this.

I have also been told that internally, COM+ (Enterprise Services) team has
been scaled down and is not as large as some of the other development teams
working in the same enterprise arena and it would tend to indicate that it is
not going to have the same kind of development put into it as other options.
Indigo is already showing how COM+ Services can be wrapped in a service
interface layer very easily so I'm not 100% sure what this means other than a
way to move legacy software into the world of services using open messaging
standards.

They also say that DCOM is scheduled to be supported at least until 2020 and
has yet to be matched in terms of raw performance so go figure.

A choice needs to be made taking into account many of these factors however
I would certainly advise you to do whatever you need to do now to be
productive with a view to future change.

Reply to this Message

Why would I use Serviced Components?

Free Magazines