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?
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. [:)]
> 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.
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.
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).
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.
> 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?
> 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.
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.
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 22, 2006 06:14 PM|LINK
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?
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 22, 2006 06:22 PM|LINK
Yeah I understand this now.
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.
True. I'm also starting to understand this point better.
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.
LudovicoVan
Star
9692 Points
1935 Posts
Re: SOA
Aug 23, 2006 12:04 PM|LINK
> 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
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 23, 2006 12:45 PM|LINK
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.
TekisFanatik...
Member
160 Points
32 Posts
Re: SOA
Aug 23, 2006 11:34 PM|LINK
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 24, 2006 02:33 AM|LINK
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.
LudovicoVan
Star
9692 Points
1935 Posts
Re: SOA
Aug 24, 2006 10:05 AM|LINK
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
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 24, 2006 12:27 PM|LINK
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.
LudovicoVan
Star
9692 Points
1935 Posts
Re: SOA
Aug 24, 2006 01:06 PM|LINK
Must be the moon...
:) -LV
devbanana
Member
105 Points
21 Posts
Re: SOA
Aug 24, 2006 01:25 PM|LINK
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.