Service Oriented Architecture

[ludwig_stuyck]

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?

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

[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.

[ludwig_stuyck]

On 12 apr, 16:53, Arne Vajhøj <[e-mail]:

[e-mail] 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). .

[ludwig_stuyck]

On 13 apr, 05:52, Lav <[e-mail]:

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!

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

lu***********@hotmail.com wrote:

On 12 apr, 16:53, Arne Vajhøj <[e-mail]:

>[e-mail] 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