"Max André Bündchen" <> wrote in message
news:%...
> I'm starting a new system form a retail chain and I could use a
> webservices architecture to make all points online with the head
> office.
>
> I have some doubts with the architecture details but I can't find good
> documentation about that (the .Net have many different ways
> to make systems like that). I read the Microsoft Patters but I have still
> some question in mind.
>
> For example, a major question, in this system I will have stock, sales,
> bills and so on, in other words, if I make a single
> webservice for each functionallity, I will take hundreds of that. I could
> make a 'proxy like' webservice, passing a id for each
> function and a object for the parameters taking just one webservice.
> What's the pros and cons of thats architectures? There's others
> options?
>
Hi Mark,
you may start with one service for each major part of your application. Many
web services however would be harder to manage and update so I would
restrain from creating a lot of them. If you combine all your services into
one, a little change on some method would require significant time for
updating the proxy class and this would slow the development process.
Separation can be useful if you need to locate the services on separate web
server, application pool or network.
my 2c
--
Martin Kulov
http://www.codeattest.com/blogs/martin
MVP, MCT, MCSD.NET Early Achiever