This subject has been extremely difficult for me to grasp, because there seems to be so little information about it, and what there is seems to conflict a lot.
So, I have a few questions about SOA in general, and also as concerns the .NET framework.
From what I understand, the basic concept is that application components are turned into services, which may be reused by other applications if needed, or may be separated out onto other servers, etc. Also of course there are third-party services that can
be used.
I've read a bit about data services; i.e., the services that interact with the database. I am having some trouble here though.
I don't think the business services should directly contact the database, since that'd be cutting out the data layer. However, I still think they should be the ones to know about the data they hold, and be aware of the structure of it. They should not know
about which type of data storage is being used, or how to connect to it, but still shouldn't they be the ones to specify the structure of that data?
I think if that's done, the data service can almost be reused in multiple applications, since it wouldn't know anything about application-specific data. Also, then, the business services can be reused, since they aren't reliant on the data service.
I may be totally off track here; if so please let me know.
However, if this is the case, I'm trying to find a way to let the data service know about how to connect to the database, since this is usually specified in the application's web configuration.
Also, I've read about service routers, so that the services aren't dependent on the location of other services. How would such a router be built? Would it be a service that was the intermediary of all services, and knew about the location of all these services?
Again, sorry if I'm totally off track, but these are the ideas I've formed after doing a lot of reading in both the MSDN library and by searching on Google. I wanted to ask these questions here so i can grasp these ideas a bit better, and in case I am off
track, lol.
SOA indeed is the buzzword and there is a lot of confusion/misconcetions regrading it. Though I am by no means an SOA expert but would like to share my views here.
First thing to absorb is that SOA is not related to design or implementation (that is SODA) but only high level architectural bindings. Another thing to note is that SOA and OOAD are not mutually exclusive but can complement each other. SOA intends to streamline
business processes and create some sort of reusable library for business processes.
Ideally, SOA doesn't care if you have a data layer or not. It is simply not related to (aka "does not dictate") the specific implementation details. Amazingly, SOA is not at all related to Web Services! XML Web Services can be a conevenient method
(since XML is platform neutral) to implement an SOA based architecure but the association ends here only.
SOA focusses on abstracting the business processes, reusing them, fault tolerance, loose coupling, scalability, and minimizing deployments costs etc. It is upto you how you implement it really.
For more information, try going through this book (I found it useful):
"Understanding SOA with web services"-Addison Wesley
I do understand that it doesn't necessarily need to use XML web services, but this seems too be the easiest way, and so is what I'm focusing on for now.
I guess it is a good thing that the implementation doesn't matter much. But I still would like to know what is considered good practice when it comes to the issues I raised.
So, I guess you are saying that it doesn't really matter how and where the data access is implemented?
Sorry for the duplicate post, but I've been doing some more reading.
It appears that different people have different views on when SOA should be used. I think that it'd be good for separate components of an application, so that they can be deployed wherever necessary, and can be reused by other applications.
Others seem to think that services themselves are applications, and so SOA is the communication between several applications, and that the services have their own layers, similar to a regular application.
I'm one for using business objects, instead of datasets. So how would something like this be handled? Unless business objects are just used internally within a service, but transformed into a DTO for the outgoing message. It'd accept a DTO as a request,
also, and I guess transfer it into the appropriate business object(s).
I've searched arou nd these forums for discussions on SOA, but what I did find were pretty generic questions, and pretty generic standard answers to match. So maybe we can get into a pretty in-depth discussion here. [:)]
Here's what I was thinking of doing regarding data access.
The data layer of the business services would know what stored procedure to use for the needed operation, and what parameters it takes. It would pass this data onto a thin layer, which would be application-specific, and would be responsible for knowing what
kind of database is supposed to be used, and the connection string for that database.
This thin layer would then call the data service, depending on the type of data store it wanted to send this data to. It would basically just pass on the message, but add to it the connection string.
The data service would be responsible for formulating the query, and possibly a transaction if there are multiple.
So then this data service could be used in multiple applications, and could be in a location that has access to the database.
It again depends, but if you follow the true essence of SOA, then basically all services should be independent of each other (and may be a separate application altogether) but that doesn't mean you can't use the DLLs for DAL and BL. Let me elaborate.
Suppose you developed a simple application divided into 3 logical layers: DAL, BL and WebForms GUI. Now you are planning to have another web service wrapper on your BL and DAL. This web service would be a new project altogehter and would act as a new UI
over BL. You can re-use the BL and DAL assemblies in this new service project.
But, as Rocky advises, the Service layer should not act as a "tier" inside an application. This would basically defeat the SOA architecture.
So if you have a BL (with business objects) and a separate DAL (which might use DTOs for loose coupling) and a Web Service UI above these, then I don't see any issues with this.
> But, as Rocky advises, the Service layer should not act as a "tier" inside an application. This would basically defeat the SOA architecture.
That is, look at it as a "facade" to wrap and decouple components, just like an UI layer but here the client is another program or component...
-LV
Hi,
So, are you saying that services should not be dependent upon any other services? However, could services still make up the components of a single application? I mean they wouldn't be a tier of the application, but they would provide features that the application
required?
I just got the book, "Enterprise SOA Service-Oriented Architecture Best Practices" today. I'm working on reading it now. Hopefully it'll answer some of my questions about this. Has anyone here read that book?
So, I've read the first four chapters so far. From what I'm understanding, services should be standalone components/applications, that should be as decoupled as possible from the other services.
However, it does seem that services can rely on other services to do certain functions, though it might not be the best idea to refer to those other services statically, but perhaps using a service repository or some such so the location of the services
doesn't need to be known by dependent services or application frontends.
A few questions:
It seems there are two major ways to implement SOA, that being using some RPC implementation, or a MOM implementation. Is either prefered over the other? It seems a little too complex sometimes to use the latter form. But is it possible to call services
asynchronously using web services?
Is a service bus generally needed? In .NET, what's the best way to implement this if needed?
By the way, it's an excellent book so far, in case anyone is looking for a good book on the subject.
From what I understand, the basic concept is that application components are turned into services, which may be reused by other applications if needed, or may be separated out onto other servers, etc. Also of
course there are third-party services that can be used.
Components is already about reuse. Services is a further and higher level step, where you turn a component into a self-standing application (a service) to be accessed from some client application. To get the picture: To use components in your project, you
have to get the dll and add a reference to your project. All code, including those components, gets built into a single application, your application. To use services - say implemented as web services - you just get a web reference and access the wrapping
proxy classes. In this case there's anything you are building apart from your specific logic. The service you access is a distinct and separate application.
With services you components become external self-standing applications. Here you can swap a node with another, provided they expose the same interface, and here not only you can cross the boundary of machines, but also that of organizations...
So, components is about modularization, and services is about making those modules self standing applications.
I don't think the business services should directly contact the database, since that'd be cutting out the data layer. However, I still think they should be the ones to know about the data they hold, and be aware
of the structure of it. They should not know about which type of data storage is being used, or how to connect to it, but still shouldn't they be the ones to specify the structure of that data?
I think "business services" is a bit misleading here. As already stated by [vivek], the point is a service needs a facade to expose to the external world. This facade must provide an "usable" interface to the client, and maybe handle related things, like
authentication, validation, (requests) state management, and similar interface stuff. Then, behind the facade there's a self standing application, where you apply all the needed engineering practices, including layering and tiering when needed...
Also, I've read about service routers, so that the services aren't dependent on the location of other services. How would such a router be built? Would it be a service that was the intermediary of all services,
and knew about the location of all these services?
I think a "locator" rather than a "router". You just ask it for the current address of some service. It answers the address, and you can connect to the target service...
It appears that different people have different views on when SOA should be used. I think that it'd be good for separate components of an application, so that they can be deployed wherever necessary, and can
be reused by other applications.
Others seem to think that services themselves are applications, and so SOA is the communication between several applications, and that the services have their own layers, similar to a regular application.
Are both of these correct?
You cannot deploy components anywhere (apart from the datastores), as they are logical bulding blocks of a single application. That's where services come into play. Anyway, provided we keep in mind components are building blocks for a service, not at the
same "level", then i guess we can say the two positions above are both part of the overall picture.
I'm one for using business objects, instead of datasets. So how would something like this be handled? Unless business objects are just used internally within a service, but transformed into a DTO for the outgoing
message. It'd accept a DTO as a request, also, and I guess transfer it into the appropriate business object(s).
This is irrelevant to services. Even if you are for business objects, services just exchange "data", so making objects to/from data in just up to your logic. Services exchange messages. Semantics is not in the message, it's in the applications logic.
Quoting Mr Lhotka: "In my business objects books and framework I talk about moving actual business objects across the wire using remoting. Of course the reality here is that only the data moves – but the code must exist on both ends."
So, are you saying that services should not be dependent upon any other services? However, could services still make up the components of a single application? I mean they wouldn't be a tier of the application,
but they would provide features that the application required?
SOA as an abstract architectural concept might be applied at any level imho, including the single application. Be worn anyway that there are many ways to implement a service in concrete, from "i've written it so that i might make a real service of it at
any time", to separate web services. I'd say components are degree zero for services. So design your high-level components architecture, then when comes time to allocation and design, just don't overengineer...
devbanana
Member
105 Points
21 Posts
SOA
Aug 20, 2006 06:49 PM|LINK
Hi,
This subject has been extremely difficult for me to grasp, because there seems to be so little information about it, and what there is seems to conflict a lot.
So, I have a few questions about SOA in general, and also as concerns the .NET framework.
From what I understand, the basic concept is that application components are turned into services, which may be reused by other applications if needed, or may be separated out onto other servers, etc. Also of course there are third-party services that can be used.
I've read a bit about data services; i.e., the services that interact with the database. I am having some trouble here though.
I don't think the business services should directly contact the database, since that'd be cutting out the data layer. However, I still think they should be the ones to know about the data they hold, and be aware of the structure of it. They should not know about which type of data storage is being used, or how to connect to it, but still shouldn't they be the ones to specify the structure of that data?
I think if that's done, the data service can almost be reused in multiple applications, since it wouldn't know anything about application-specific data. Also, then, the business services can be reused, since they aren't reliant on the data service.
I may be totally off track here; if so please let me know.
However, if this is the case, I'm trying to find a way to let the data service know about how to connect to the database, since this is usually specified in the application's web configuration.
Also, I've read about service routers, so that the services aren't dependent on the location of other services. How would such a router be built? Would it be a service that was the intermediary of all services, and knew about the location of all these services?
Again, sorry if I'm totally off track, but these are the ideas I've formed after doing a lot of reading in both the MSDN library and by searching on Google. I wanted to ask these questions here so i can grasp these ideas a bit better, and in case I am off track, lol.
Thanks in advance for any help.
Brandon
vivek_iit
All-Star
17778 Points
3189 Posts
MVP
Re: SOA
Aug 20, 2006 08:42 PM|LINK
Hi Brandon,
SOA indeed is the buzzword and there is a lot of confusion/misconcetions regrading it. Though I am by no means an SOA expert but would like to share my views here.
First thing to absorb is that SOA is not related to design or implementation (that is SODA) but only high level architectural bindings. Another thing to note is that SOA and OOAD are not mutually exclusive but can complement each other. SOA intends to streamline business processes and create some sort of reusable library for business processes.
Ideally, SOA doesn't care if you have a data layer or not. It is simply not related to (aka "does not dictate") the specific implementation details. Amazingly, SOA is not at all related to Web Services! XML Web Services can be a conevenient method (since XML is platform neutral) to implement an SOA based architecure but the association ends here only.
SOA focusses on abstracting the business processes, reusing them, fault tolerance, loose coupling, scalability, and minimizing deployments costs etc. It is upto you how you implement it really.
For more information, try going through this book (I found it useful):
"Understanding SOA with web services"-Addison Wesley
Hope this helps,
Vivek
Communifire: Social Networking and Business Collaboration Platform
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 20, 2006 09:47 PM|LINK
Hi,
Thanks for the reply.
I do understand that it doesn't necessarily need to use XML web services, but this seems too be the easiest way, and so is what I'm focusing on for now.
I guess it is a good thing that the implementation doesn't matter much. But I still would like to know what is considered good practice when it comes to the issues I raised.
So, I guess you are saying that it doesn't really matter how and where the data access is implemented?
Thanks again.
Brandon
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 20, 2006 11:26 PM|LINK
Sorry for the duplicate post, but I've been doing some more reading.
It appears that different people have different views on when SOA should be used. I think that it'd be good for separate components of an application, so that they can be deployed wherever necessary, and can be reused by other applications.
Others seem to think that services themselves are applications, and so SOA is the communication between several applications, and that the services have their own layers, similar to a regular application.
Are both of these correct?
Also, this is an interesting post: http://www.lhotka.net/weblog/CommentView,guid,5ac19dbd-eac1-4546-ba7b-2e5e21c9a328.aspx
I'm one for using business objects, instead of datasets. So how would something like this be handled? Unless business objects are just used internally within a service, but transformed into a DTO for the outgoing message. It'd accept a DTO as a request, also, and I guess transfer it into the appropriate business object(s).
I've searched arou nd these forums for discussions on SOA, but what I did find were pretty generic questions, and pretty generic standard answers to match. So maybe we can get into a pretty in-depth discussion here. [:)]
Here's what I was thinking of doing regarding data access.
The data layer of the business services would know what stored procedure to use for the needed operation, and what parameters it takes. It would pass this data onto a thin layer, which would be application-specific, and would be responsible for knowing what kind of database is supposed to be used, and the connection string for that database.
This thin layer would then call the data service, depending on the type of data store it wanted to send this data to. It would basically just pass on the message, but add to it the connection string.
The data service would be responsible for formulating the query, and possibly a transaction if there are multiple.
So then this data service could be used in multiple applications, and could be in a location that has access to the database.
vivek_iit
All-Star
17778 Points
3189 Posts
MVP
Re: SOA
Aug 21, 2006 11:14 AM|LINK
Brandon,
It again depends, but if you follow the true essence of SOA, then basically all services should be independent of each other (and may be a separate application altogether) but that doesn't mean you can't use the DLLs for DAL and BL. Let me elaborate.
Suppose you developed a simple application divided into 3 logical layers: DAL, BL and WebForms GUI. Now you are planning to have another web service wrapper on your BL and DAL. This web service would be a new project altogehter and would act as a new UI over BL. You can re-use the BL and DAL assemblies in this new service project.
But, as Rocky advises, the Service layer should not act as a "tier" inside an application. This would basically defeat the SOA architecture.
So if you have a BL (with business objects) and a separate DAL (which might use DTOs for loose coupling) and a Web Service UI above these, then I don't see any issues with this.
Regards,
Vivek
Communifire: Social Networking and Business Collaboration Platform
LudovicoVan
Star
9692 Points
1935 Posts
Re: SOA
Aug 21, 2006 04:27 PM|LINK
I do agree with [vivek] on this matter.
> But, as Rocky advises, the Service layer should not act as a "tier" inside an application. This would basically defeat the SOA architecture.
That is, look at it as a "facade" to wrap and decouple components, just like an UI layer but here the client is another program or component...
-LV
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 22, 2006 02:54 AM|LINK
Hi,
So, are you saying that services should not be dependent upon any other services? However, could services still make up the components of a single application? I mean they wouldn't be a tier of the application, but they would provide features that the application required?
I just got the book, "Enterprise SOA Service-Oriented Architecture Best Practices" today. I'm working on reading it now. Hopefully it'll answer some of my questions about this. Has anyone here read that book?
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 22, 2006 05:01 PM|LINK
Hi,
So, I've read the first four chapters so far. From what I'm understanding, services should be standalone components/applications, that should be as decoupled as possible from the other services.
However, it does seem that services can rely on other services to do certain functions, though it might not be the best idea to refer to those other services statically, but perhaps using a service repository or some such so the location of the services doesn't need to be known by dependent services or application frontends.
A few questions:
It seems there are two major ways to implement SOA, that being using some RPC implementation, or a MOM implementation. Is either prefered over the other? It seems a little too complex sometimes to use the latter form. But is it possible to call services asynchronously using web services?
Is a service bus generally needed? In .NET, what's the best way to implement this if needed?
By the way, it's an excellent book so far, in case anyone is looking for a good book on the subject.
vivek_iit
All-Star
17778 Points
3189 Posts
MVP
Re: SOA
Aug 22, 2006 05:13 PM|LINK
Hi again,
A service can indeed rely on other services. Regarding the type of implementation, you can go through this nice article which explains the same:
http://www.codeproject.com/cs/webservices/Web_Services.asp
And yes, web services can be called asynchronously.
I'll have a look at the book. Thanks for your feedback on it!
Regards,
Vivek
Communifire: Social Networking and Business Collaboration Platform
LudovicoVan
Star
9692 Points
1935 Posts
Re: SOA
Aug 22, 2006 05:22 PM|LINK
Let's try to reconsider this all.
Components is already about reuse. Services is a further and higher level step, where you turn a component into a self-standing application (a service) to be accessed from some client application. To get the picture: To use components in your project, you have to get the dll and add a reference to your project. All code, including those components, gets built into a single application, your application. To use services - say implemented as web services - you just get a web reference and access the wrapping proxy classes. In this case there's anything you are building apart from your specific logic. The service you access is a distinct and separate application.
With services you components become external self-standing applications. Here you can swap a node with another, provided they expose the same interface, and here not only you can cross the boundary of machines, but also that of organizations...
So, components is about modularization, and services is about making those modules self standing applications.
I think "business services" is a bit misleading here. As already stated by [vivek], the point is a service needs a facade to expose to the external world. This facade must provide an "usable" interface to the client, and maybe handle related things, like authentication, validation, (requests) state management, and similar interface stuff. Then, behind the facade there's a self standing application, where you apply all the needed engineering practices, including layering and tiering when needed...
I think a "locator" rather than a "router". You just ask it for the current address of some service. It answers the address, and you can connect to the target service...
You cannot deploy components anywhere (apart from the datastores), as they are logical bulding blocks of a single application. That's where services come into play. Anyway, provided we keep in mind components are building blocks for a service, not at the same "level", then i guess we can say the two positions above are both part of the overall picture.
This is irrelevant to services. Even if you are for business objects, services just exchange "data", so making objects to/from data in just up to your logic. Services exchange messages. Semantics is not in the message, it's in the applications logic.
Quoting Mr Lhotka: "In my business objects books and framework I talk about moving actual business objects across the wire using remoting. Of course the reality here is that only the data moves – but the code must exist on both ends."
SOA as an abstract architectural concept might be applied at any level imho, including the single application. Be worn anyway that there are many ways to implement a service in concrete, from "i've written it so that i might make a real service of it at any time", to separate web services. I'd say components are degree zero for services. So design your high-level components architecture, then when comes time to allocation and design, just don't overengineer...
-LV