When I think about it pipelines seem to have been created for
performance reasons for ASP sites. Now that ASP.Net is here and alot
faster what are the advantages of the pipelines ?

I mean they don't do anything very compilcated so why don't I just
rewrite them as c# classes and leave the scary world of COM+ behind
forever ?

My company is thinking of redoing their pipelines for various reasons
and I can't bear to dig out an old VB compiler to rewrite COM objects !
Should I advise them to chuck out the pipelines and replace them wit
the C# classes ?

Thanks in advance for any opinions

Jim

[ Post a follow-up to this message ]

Hi Jim,

They can rewrite the pipeline components in managed code as well - that is
an option to consider as well for .Net. That would make the pipeline
component code much easier to work with.

The reason most businesses would like to have pipelines is to have a
pluggable system which contains all the business logic and business rules.
For e.g. you can have all that you want to make sure at the time the order
is placed in the checkout.pcf file and be able to update this without any
code changes required. It basically decouples your business logic from the
site code. The site only runs the pipelines - what those pipelines do - can
be controlled seperately. I think that is the main attraction with
pipelines.

Plus the fact that it is pluggable and you can buy and insert 3rd party
Payment processing or Tax processing components is the other big advantage.

Thanks,

Nihit Kaul[MSFT]
Commerce Server
http://blogs.msdn.com/nihitk

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

--------------------
From: "BeerBoy" <jim.macaulay@framfab.com>
Newsgroups: microsoft.public.commerceserver.general
Subject: Should I use Pipelines with ASP.Net - opinions needed !
Date: 1 Sep 2005 04:19:00 -0700
Organization: http://groups.google.com
Lines: 18
Message-ID: <1125573540.612078.65710@g14g2000cwa.googlegroups.com>
NNTP-Posting-Host: 194.201.25.93
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1125573545 22008 127.0.0.1 (1 Sep 2005 11:19:05
GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 1 Sep 2005 11:19:05 +0000 (UTC)
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET
CLR 1.1.4322),gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: g14g2000cwa.googlegroups.com; posting-host=194.201.25.93;
posting- account=TWSkKQ0AAACFRajyPiOqNaeuW33_VRZN

Path:
TK2MSFTNGXA01.phx.gbl!TK2MSFTFEED02.phx.gbl!tornado.fastwebnet.it!tiscali!ne
wsfeed1.ip.tiscali.net!news.glorb.com!postnews.google.com!g14g2000cwa.google
groups.com!not-for-mail
Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.commerceserver.general:3337
X-Tomcat-NG: microsoft.public.commerceserver.general


When I think about it pipelines seem to have been created for
performance reasons for ASP sites. Now that ASP.Net is here and alot
faster what are the advantages of the pipelines ?

I mean they don't do anything very compilcated so why don't I just
rewrite them as c# classes and leave the scary world of COM+ behind
forever ?

My company is thinking of redoing their pipelines for various reasons
and I can't bear to dig out an old VB compiler to rewrite COM objects !
Should I advise them to chuck out the pipelines and replace them wit
the C# classes ?

Thanks in advance for any opinions

Jim

[ Post a follow-up to this message ]

Thanks for your comment Nihit.  I see the advantage of separating the
business rules (which is why I would do them in their own class) but
would debate with you when you say ' be able to update this without any
code changes required' - since the pipelines are composed of  either
script or COM objects you will need to be a coder in order to change it
(i.e. not a business user). So when it comes down to it if the business
logic changes you will need to edit some code and put a new DLL on the
live machine - the same is true for the .Net solution, a coder makes
the change and deploys a DLL.

As for 3rd party components, with the uptake of .Net I see most 3rd
parties now either selling .Net class libraries or offering web
services, both of which should be trivial to plug into a .Net solution.

I must admit I am very tempted not to use the pipelines at all and do
all the processing in c#.

[ Post a follow-up to this message ]

Well BeerBoy, as much as you dislike COM+ it is only way you can scale your
solution into n+ tiers with Commerce Server... so the first teir has only
your web app (and also unfortunately all your ASP.NET), the second tier has
all the COM+ (pipelines, profiles, CSF, Order, Basket and such) and the thir
d
tier has the DB.

If you DO only ASP.Net you'd land up creating a very nice looking 2 Teir Web
App.. dependant on session objects, and such... how'd you scale that ? IMHO
you've only solved the client deployment issue associated with 2T apps ))
--
Ravi Shankar


"BeerBoy" wrote:

> Thanks for your comment Nihit.  I see the advantage of separating the
> business rules (which is why I would do them in their own class) but
> would debate with you when you say ' be able to update this without any
> code changes required' - since the pipelines are composed of  either
> script or COM objects you will need to be a coder in order to change it
> (i.e. not a business user). So when it comes down to it if the business
> logic changes you will need to edit some code and put a new DLL on the
> live machine - the same is true for the .Net solution, a coder makes
> the change and deploys a DLL.
>
> As for 3rd party components, with the uptake of .Net I see most 3rd
> parties now either selling .Net class libraries or offering web
> services, both of which should be trivial to plug into a .Net solution.
>
> I must admit I am very tempted not to use the pipelines at all and do
> all the processing in c#.
>
>

[ Post a follow-up to this message ]

Hi Ravi

I agree, this is a valid reason to use COM+.

I think I will recommend a 2 Tier approach and to scale just add more
load balanced servers :-)

[ Post a follow-up to this message ]

Hi BeerBoy,

That would be a nice interim measure. The reason I say this is that various
Commerce Server Resources use 'x' connections & resources on SQL... the more
front-end servers you add to your "load balanced" first tier, the more you
multiply the resource requirement on SQL tier and subsequently need a higher
than normal SQL machine... whereas in the n teir scenario only the web serve
r
increase, increasing your capacity to handle high traffic while the middle
teir benifits from aspects such as connection pooling and higher resource
availability... just as an example... your 4 proc SQL working at 80% normal
utilization with 4 load balanced front-ends might drop its utilization to
55-60% if you add a single middle teir box ..

Don't use these as performance figures but this was just to give you an idea
)))

--
Ravi Shankar


"BeerBoy" wrote:

> Hi Ravi
>
> I agree, this is a valid reason to use COM+.
>
> I think I will recommend a 2 Tier approach and to scale just add more
> load balanced servers :-)
>
>

[ Post a follow-up to this message ]