I am currently working on small project to lern about Web Services in .NET, my problem is as follows.
I have Bank WebService that 'handles' transfer of money, and another one Offer Service, What I would like to do is to have Bank Service inform my Offer Service when some money transfer happens. One solution would be call Offer Service directly, but that's not really the best solution. I thought about UDDI but that's too much work I think. As I understand ESB could be used here, but frankly I have no idea how to use it. I mean how do I call offer service from bank service without direct call.
Maybe NServiceBus could be use here, but again no idea how to get it to work with WCF.
Any thoughts ?
Edit:
Ok to make it clearer, I would like to know, how could I user ESB, or other framework / service to decouple WebServices, so that one doesn't directly calls the other.
One solution would be call Offer Service directly, but that's not really the best solution.
Why? It is a good solution. Many systems work like that. I am not sure why you think messaging will magically solve this problem. In fact, messaging is just another type of communication.
You should use the same communication technology to call one service into another service. This reduces complexity. Less stuff to learn, fewer places for things to go wrong, and more importantly same communication API, when you use Bank WebService, Offer Service or both.
You may also need to use transaction or distributed transaction. Local transaction is much easier to implement and is preferred way to guard operations.`
Related
I am currently involved in a simple to medium complex IOT project. The main purpose of our application is gathering data from our devices and analyzing that data as well as calculating statistics.
On the server side we run a MVC application. Up until now we used Hangfire to schedule the calculations. Hangfire is an amazing tool for scheduling emails and other simple stuff, for more advanced things it's too slow. The calculations can take up a lot of time and are processor-intensive (we are trying to optimize them though), so we need to call them in a background task, a simple API call won't be enough.
I thought about splitting the application into multiple parts, the website, the core and a windows service.
The problem is, I never tried that before and I have no idea what the best practice is to achieve that kind of thing. I searched for examples and articles, but all I found were suggestions to use Hangfire and/or Quartz.NET.
Does anyone have any resources on what the best practice is to build a MVC application, a Windows service and how they could communicate (probably through a queue)? What is the best practice in such a situation?
Although there may be many different possible ways to connect a site with a windows service, I'd probably chose one of the following two, based on your statements:
Direct communication
One way of letting your site send data to your backend windows service would be to use WCF. The service would expose an endpoint. For simplicity's sake this could be a basicHttpBinding or a netTcpBinding. The choice should be made based on your specific requirements; if the data is small then basicHttp may be "sufficient".
The advantage of this approach is that there's relatively little overhead needed: You'll just have to setup the windows service (which you'll have to do anyway) and open a port for the WCF binding. The site acts as client, the service as server. There's nothing special with it, just because the client being a MVC site. You can take almost any WCF tutorial as a starting point.
Note that instead of WCF you could use another technology like .NET Remoting or even sockets just as well. Personally, I often use WCF because I'm quite used to it, but this choice is pretty opinion based.
Queued communication
If reliability and integrity is crucial for your project, then using a queue might be a good idea. Again: depending on your needs, there may come diffeent products into consideration. If you don't need much monitoring and out-of-the-box management goodies, then even a very simplistic technology like MSMQ may be sufficient.
If your demands to the aforementioned points are more relevant, then maybe you should look for something else. Just recently I got in touch with Service Bus for Windows Server (SBWS). It's the Azure Service Bus's little brother which can be used on premises locally on your windows server. The nice thing about it is, that it comes at no extra charge as it's already licensed with your windows server licence.
As with the first point: MSMQ and SBWS are just two examples. There may be a lot of other products like NServiceBus, ZeroMQ or others usable, you name it.
I am relatively new to the Azure world and would like some information about using ESB, and if I am not providing enough details, please just ask for more...
I have a public-facing WCF service that is running just fine, and I am aware that the WCF service itself is quite resilient in handling a large number of requests.
The requests are relatively short-lived, and database back-end is fully optimized (low latency).
I would like to know at what point should Enterprise Service Bus be considered and thrown into the mix, and whether it is worth it?
If you plan to have one service only, then it seems you don't need an ESB. Also, the properties of the service you mentioned (resilience, etc.) should not affect your decision as an ESB will not help you solve this type of issues.
If you were to have several services that perhaps even interact between each other, then you might need to provide transformation of protocol/transport between them, perhaps orchestration, monitoring (SLA) and statistics, common security, etc. In that case you could think about having an ESB that would handle this for you.
Again, think about how your whole "business" will look like in the future.
You can implement your own service registry if you follow tutorials like this: http://www.infoq.com/articles/net-service-registry
Or you can a middleware provided by http://www.oracle.com/technetwork/middleware/registry/overview/index.html.
Open source alternative could be the following: http://www.membrane-soa.org/service-proxy/
Even though the website says ESB on the documentation, it is really just providing the feature of service registry and api to make calls to your registered endpoints
I'm interested in gaining a better understanding of WCF.
Of course, I can read books and tutorials about it, but it seems that a better way would be to actually come up with some project idea (either open-source or a startup) which would actually benefit from using WCF, and then build it using WCF.
What are your ideas for small-scale projects which might benefit from WCF?
I'm not sure it is really a matter of scale that drives a decision to use WCF. If a learning project is all you are interested in, then take a normal idea for a project, and turn the entire data access layer into WCF calls.
This should give you a fair understanding of all the little nooks and crannies of WCF, and allow you to fail in a controlled manner. That way you can make decisions in the future about when are where it is best to apply a service boundary using WCF.
As was already mentioned, anything to do with the web can benefit tremendously from WCF. Heck, you could build a pure JavaScript and HTML 5 application using WCF without ever touching ASP.Net.
A hosted service that a mobile device (such as a WP7 or iPhone) could connect with to retrieve data
WCF is great for setting up non-ASPX endpoints for Ajax clients. See for example this article. There are many more out there.
Any project involving .NET and communication is likely to benefit from WCF. WCF is the replacement for ASMX web services and for .NET Remoting. There's no one particular type of application that it is suited for. For instance, it's not like it's suitable for Enterprise applications but not for small ones.
WCF data contracts are very easy and handy for storing application configuration, settings and state. Write a library/application to take care of serialisation and editing.
Im looking to implement a .net remoting system, where a number of clients will need access to a server database. Client calls may be concurrent, but Im wanting to queue client requests to the database to avoid concurrent database access.
Im just learning .net remoting and have read about singlecall, singleton and client activated objects. Do any of these methods do what I want or at least support what I want?
Also, should I be using .net remoting or is the way to go WCF?
Kind Regards
Ash
You might want to look at creating a WCF Data Service. You should definitely look at this rather than Remoting.
In a nutshell, you can use it to expose an Entity Framework or Linq to SQL model as a Webservice. It's pretty neat!
Marc Gravell has a very good blog post on the topic: http://marcgravell.blogspot.com/2008/12/astoria-and-linq-to-sql-getting-started.html.
Update: I don't know if you can configure the data service itself to queue requests, but you might be able to achieve it by configuring IIS to queue the requests for you. There will probably be a web.config setting you can use to do it.
One request at a time is a bit of an odd requirement though... WCF Data Services do support optimistic concurrency, might that be better suited to your needs? Without more information on your requirements it's only a guess, but it's worth considering.
I'm not sure why you're trying to achieve one request at a time, but it's worth asking yourself if there's a better way of achieving your goal. Limiting database access to one user at a time seems very heavy handed to me.
.NET Remoting has been deprecated in favor of WCF. You should not be using it for any new development.
I have been working with webservices for over 2 years now. I have lot to say about services like Soap 1.2, WSDL, the way communication is taking place and 100 of other things.
I have seen people talking about their heavy ASMX background and web services expertize. But, when it comes to implementation I don't find anything but adding a web reference and calling few methods from C#. All the things that we talk about (serialization, deserialization, soap, blah blah) is taken care by Microsoft internally.
So I want to know if it is all we have to do while dealing with WebServices or is there anything more to it?
Rephrase: I wana know what an expert of ASMX must know about these services.
I'll appreciate if you can provide some good references, material or any comments on this.
I think you are approaching this from a implementor/tools standpoint; yes, Visual Studio does a lot of the heavy lifting to make a developer feel like calling Web services is the same as calling any method -- but developers who use the tools blindly without knowing what code is being generated and how it all works are, as you suggest, not experts.
To say you are an expert, I think you would need to be able to talk about things like the following:
Pros and Cons of using services in your architecture (performance considerations, versioning issues, synchronous versus async, etc.)
Reasons you would want to use ASMX versus WCF
Internal implementaiton of the SOAP protocol, how SOAP headers can be used for security, etc.
Knowledge of the "internals", so you could potentially expose services for consumption by non-Microsoft clients (java, etc.)
Features of WSE, including the different versions
Security concerns -- how to secure access to a service, and how to secure the data being transferred back and forth
If you want to consider yourself an expert in ASMX, then you need to understand the SoapExtension class and the related SoapExtensionAttribute. I do not feel that it's necessary to understand SoapExtensionImporter and SoapExtensionReflector.
You should also understand XML Serialization, since that is what is used to serialize and deserialize between objects and SOAP in an ASMX service.
You should also understand that Microsoft now considers ASMX web services to be "legacy technology" (reference on request).
I would say that just knowing ASMX and/WCF basics doesn't make an expert out of you from a web service point of view.
It is true that all the plumbing is taken care of, but you generally have to go back to it at one point or another. It's always very easy to connect asmx to asmx, wcf to wcf, axis2 to axis2... But once you start to make these communicate together, problems start to show. Did you ever worked on a project using web services where at some point you had issues with the generated WSDL, or the generated proxy?
I would say that for someone to claim being asmx expert, he shouldn't look surprised if you start talking about soap 1.1 and 1.2, WS basic profile, WS-*, and all those things that apears to be abstracted away at first sight, but which you'll have to come back to at some point.