SOA

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

Re: SOA

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

Re: SOA

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

Re: SOA

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.

Re: SOA

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

Re: SOA

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

Re: SOA

LudovicoVan

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

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?

Re: SOA

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.

Re: SOA

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

Re: SOA

Let's try to reconsider this all.

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

-LV

Re: SOA

vivek_iit

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

Thanks, I will be sure to read that article.

The more I read, the more I'm finally understanding about this.

About calling web services asynchronously: if you still want to get a response when the message is received, what happens if the caller of the web service exits before the receiver goes to reply?

Re: SOA

LudovicoVan

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.

Yeah I understand this now.

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

This is interesting. Regarding authentication and authorization, I would like to have all that information stored somewhere so that the required permissions to access the service could be changed dynamically. Would it be reasonable to have an authentication/authorization service, or just have a reusable component? I'm a bit confused about what should be services and what should be components.

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.

True. I'm also starting to understand this point better.

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

True, but the messages send/received by services, I don't think should be business objects. Generally, I think it'd be best to send data transfer objects with the required information included, and that again, perhaps it could be turned into the necessary business objects within the service.

Note: For those points I didn't respond to, I really just didn't have a response for it and mostly agreed. [:)]

Thanks for the replies.

Re: SOA

> Would it be reasonable to have an authentication/authorization service, or just have a reusable component?

It depends on the specific needs and there can't be fixed recipes. Have you got many applications all relying on the same authentication repository? Then it might make sense...

> I'm a bit confused about what should be services and what should be components.

As said it's not an aut-aut. Everything starts as a component, then it may become a self-standing service, as a farther step. The point of not overengineering (holding not only for services) is: do it if it makes sense; and, just do it if you need.

Best luck. -LV

Re: SOA

Hi,

Thanks for the reply. I have one more question for now.

I'm reading about a few terms I'm very confused about, including service bus and execution container. They sound somewhat similar, but I'm unsure about the implementation of either of them.

Is a service bus something that routes all requests to an appropriate service, and changes the message format if necessary? That's the view I had before, but I don't know if it's correct or not. An execution container sounds like some facade to the service, if you will, that handles logging, auditing, security, etc. But again it's hard to tell.

Even if I don't use these concepts, it's nice to know what they are.

Re: SOA

I wonder if there are any snippets out there that could illustrate these theories. Futhermore, I'm wondering if someone couldn't provide a simple example using lamens terms to try to explain this (ie. customer and order type system).

Re: SOA

TekisFanatikus
I wonder if there are any snippets out there that could illustrate these theories. Futhermore, I'm wondering if someone couldn't provide a simple example using lamens terms to try to explain this (ie. customer and order type system).

Hi,

No, I have looked around for a long time now trying to find a sample, and have come up with absolutely nothing. However, I don't think there is exactly one right way to implement it, so it is mostly up to what works for you, as long as it follows the guidelines of a proper SOA.

As for me, I will be trying to implement these concepts in both .NET and PHP, since those are my primary two languages. Hopefully I can make a framework on which I can build future projects, if I'm lucky. [:)]

The thing about .NET is that it wants you to specify the location of a web service at development time, so that it can create the proxy class that allows you to access the methods of that service. However, it seems that in a good SOA implementation, services shouldn't exactly know about the location of other services, in case they would ever need to move to a new location. It seems I will somehow need to get around the default implementation in .NET.

Re: SOA

devbanana:

> The thing about .NET is that it wants you to specify the location of a web service at development time, so that it can create the proxy class that allows you to access the methods of that service.

Might this ever be true? Everything you can do with a designer you can do at run-time as well, while it's seldom the reverse. I'd suggest you take the time to learn a bit more before telling what .NET can /can't do, otherwise you risk to miss anything not looking like PHP, and i must warn you they share almost nothing...

This apart, i don't get what kind of samples you are both looking for. There are millions of web services out there to serve as samples. What's actually unclear?

-LV

Re: SOA

LudovicoVan

devbanana:

> The thing about .NET is that it wants you to specify the location of a web service at development time, so that it can create the proxy class that allows you to access the methods of that service.

Might this ever be true? Everything you can do with a designer you can do at run-time as well, while it's seldom the reverse. I'd suggest you take the time to learn a bit more before telling what .NET can /can't do, otherwise you risk to miss anything not looking like PHP, and i must warn you they share almost nothing...

This apart, i don't get what kind of samples you are both looking for. There are millions of web services out there to serve as samples. What's actually unclear?

-LV

Wow, didn't mean to offend anyone. I wasn't comparing the two at all; I think .NET is hundreds of times better than PHP. If there is a way to do it at runtime, could you please tell me? The only way I have seen of using web services in .NET is creating a proxy class by using web references. I am sure there are other ways, and that's why I made the comment, to try to see how to alternatively do this.

Re: SOA

Must be the moon...

:) -LV

Re: SOA

LudovicoVan

Must be the moon...

:) -LV

Lol, no problem. [:)]

Let me try this again so I can try to get my intended meaning across.

I'm trying this implementation in both languages, because I do a lot of development in both languages, so I think I should have some base implementation for reuse in the future if I actually need to use this architecture.

I've been researching about how to dynamically call web services in .NET, but haven't found much. I guess I would need to manually create a proxy class, or a service stub if you will, to manually form the SOAP message and send it to wherever it needs to go. I think I might try to use content-based routing since it seems to allow for the most loosely coupled implementation.

I don't really want to go around the entire ws implementation in .NET, mostly just the proxy classes. But I'm finding the same limitation in any language that offers a SOAP/WS implementation. Any suggestions?

As for samples, there are tutorials out there for creating web services, but not within the context of SOA. I find most of the samples out there offer a very fine-grained interface to the web services, and don't cover how to make these services loosely coupled, or anything else that you'd be concerned with when trying to implement a SOA.