By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,664 Members | 1,592 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,664 IT Pros & Developers. It's quick & easy.

Service Oriented Architecture

P: n/a
I'm in the process of designing a Service Oriented Architecture. At
the moment I based the design on the Web Service Software factory
guidelines - so a services layer, business layer and resource access
layer. The services layer contains WCF services, which use the
business layer, which uses the resource access layer. I'm using data
contracts for data that is passed via the WCF services, and these are
converted to business entitities that pass to business layer and data
layer.

Meanwhile the data layer has become a WCF service. So, the question
arise: how do I pass the data now? Even further: imagine that I would
make everything a service, how would you pass data between tiers?

Can I define internal data contracts once, and use these over all WCF
services for example? Or how would the best approach be - if every
service uses its own data contract then I need to convert everything
in every service and I think that's overkill?
Jun 27 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
lu***********@hotmail.com wrote:
I'm in the process of designing a Service Oriented Architecture. At
the moment I based the design on the Web Service Software factory
guidelines - so a services layer, business layer and resource access
layer. The services layer contains WCF services, which use the
business layer, which uses the resource access layer. I'm using data
contracts for data that is passed via the WCF services, and these are
converted to business entitities that pass to business layer and data
layer.
Sounds very fine.
Meanwhile the data layer has become a WCF service. So, the question
arise: how do I pass the data now? Even further: imagine that I would
make everything a service, how would you pass data between tiers?

Can I define internal data contracts once, and use these over all WCF
services for example? Or how would the best approach be - if every
service uses its own data contract then I need to convert everything
in every service and I think that's overkill?
The approach is: don't !

SOA is about having systems provide a service at the business level
to other systems.

A data layer is not a business service. And a WCF interface to that
is not SOA and with 98% probability a bad idea.

Arne
Jun 27 '08 #2

P: n/a
Lav
Even if you want to expose all the Data layer as a WCF service,
access to it should be restricted.
Data Contract seems to be the correct way to communicate between
services.
Jun 27 '08 #3

P: n/a
On 12 apr, 16:53, Arne Vajhøj <a...@vajhoej.dkwrote:
ludwig_stu...@hotmail.com wrote:
I'm in the process of designing a Service Oriented Architecture. At
the moment I based the design on the Web Service Software factory
guidelines - so a services layer, business layer and resource access
layer. The services layer contains WCF services, which use the
business layer, which uses the resource access layer. I'm using data
contracts for data that is passed via the WCF services, and these are
converted to business entitities that pass to business layer and data
layer.

Sounds very fine.
Meanwhile the data layer has become a WCF service. So, the question
arise: how do I pass the data now? Even further: imagine that I would
make everything a service, how would you pass data between tiers?
Can I define internal data contracts once, and use these over all WCF
services for example? Or how would the best approach be - if every
service uses its own data contract then I need to convert everything
in every service and I think that's overkill?

The approach is: don't !

SOA is about having systems provide a service at the business level
to other systems.

A data layer is not a business service. And a WCF interface to that
is not SOA and with 98% probability a bad idea.

Arne
The reason to service enable (part of) the data layer was because I
needed to service enable a single-threaded COM API, and using WCF it
as rather easy to do (single concurrency service and making sure that
everything is executed in the same thread). .
Jun 27 '08 #4

P: n/a
On 13 apr, 05:52, Lav <gupta....@gmail.comwrote:
Even *if you want to expose all the Data layer as a WCF service,
access to it should be restricted.
Data Contract seems to be the correct way to communicate between
services.
Indeed, data contract. But only if I can share that data contract
between the various web services, because I don't want to do
conversion between data in each service!
Jun 27 '08 #5

P: n/a
lu***********@hotmail.com wrote:
On 12 apr, 16:53, Arne Vajhøj <a...@vajhoej.dkwrote:
>ludwig_stu...@hotmail.com wrote:
>>I'm in the process of designing a Service Oriented Architecture. At
the moment I based the design on the Web Service Software factory
guidelines - so a services layer, business layer and resource access
layer. The services layer contains WCF services, which use the
business layer, which uses the resource access layer. I'm using data
contracts for data that is passed via the WCF services, and these are
converted to business entitities that pass to business layer and data
layer.
Sounds very fine.
>>Meanwhile the data layer has become a WCF service. So, the question
arise: how do I pass the data now? Even further: imagine that I would
make everything a service, how would you pass data between tiers?
Can I define internal data contracts once, and use these over all WCF
services for example? Or how would the best approach be - if every
service uses its own data contract then I need to convert everything
in every service and I think that's overkill?
The approach is: don't !

SOA is about having systems provide a service at the business level
to other systems.

A data layer is not a business service. And a WCF interface to that
is not SOA and with 98% probability a bad idea.

The reason to service enable (part of) the data layer was because I
needed to service enable a single-threaded COM API, and using WCF it
as rather easy to do (single concurrency service and making sure that
everything is executed in the same thread). .
It can be an OK solution for a specific problem. I am not COM
knowledgeable enough to comment on the specifics.

But I would not call it SOA. Because you are exposing data not
a service.

Arne
Jun 27 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.