Recently I've been working with MVC4 and have grown quite comfortable with the View > View Model > Controller > Service > Repository stack with IoC and all. I like this. It works well. However, we're moving towards company wide application platform that will serve the majority of all business applications needs within the company.
Basic architecture goals:
Client facing MVC site
Internal Admin web site
Plethora of scheduled jobs importing/exporting data/etc to third parties
Service Bus sitting in the middle to expose business events
Public API for customer consumption
My initial thoughts are to introduce an "enterprise service layer" by applying my service interfaces to WCF contracts and registering the WCF proxy classes in my IoC. This would allow me to reuse the same pattern I'm currently using, butt I've not found a lot of examples of this in practice. Except this guy.
Admittedly though, I'm unsure what the best solution is for a project this scale.
1) What are the considerations when centralizing business services?
2) How does this affect cross cutting concerns like validation, authorization, etc? I thought I had that figured out already, but putting DTOs between the layers changes all this.
3) I'm experienced with WCF, but I hear Service Stack is all the rage...Should SS be a consideration with its RESTful goodness?
This guy here. I am not an expert in this area by any means, but hopefully I can provide a bit more context around things.
The main problem with using IoC to resolve WCF ChanelFactory dependencies as per my post is that the client also needs to have access to the service contracts. This is fine for a View > View Model > Controller > Service > Repository type architecture but is not likely to be possible (or desirable) for a shared public API.
In an attempt to cover your other questions:
1) Some of the concerns are already mentioned in your second question. Add to that things like security, discoverability, payload type (XML, JSON etc), versioning, ... The list goes on. As soon as you centralize you suddenly gain a lot more management overhead. You cannot just change a contract without understanding the consequences.
2) All the cross cutting stuff needs to be catered for in your services. You cannot trust anything that comes in from clients, especially if they are public. Clients can add some validation for themselves but you have to ensure that your services are locked down correctly.
3) WCF is an option, especially if your organisation has a lot of existing WCF. It is particularly useful in that it supports a lot of different binding types and so means you can migrate to a new architecture over time by changing the binding types of the contracts.
It is quite 'enterprisey' and has a bewildering set of features that might be overkill for what you need.
ReST is certainly popular at the moment. I have not used Service Stack but have had good results with Asp.Net Web Api. As an aside, WCF can also do ReST.
I've previously provided a detailed explanation of the technical and philosophical differences between ServiceStack and WCF on InfoQ. In terms of API Design, this earlier answer shows the differences between ServiceStack Message-based approach and WCF / WebApi remote method approach.
SOAP Support
ServiceStack also has Soap Support but you really shouldn't be using SOAP for greenfield web services today.
HTML, Razor, Markdown and MVC
ServiceStack also has a great HTML Story which can run on stand-alone own with Razor support as seen in razor.servicestack.net or Markdown Razor support as seen in servicestack.net/docs/.
ServiceStack also integrates well with ASP.NET MVC as seen in Social Bootstrap Api, which is also able to take advantage of ServiceStack's quality alternative components.
Related
What is the difference between WCF Services and Web Services in .netWhen should I use WCF and when to use Web Services.Is REST and WCF service the same? Thanks
Web Service is an abstract term encompassing a large variety of data providers for distributed systems. Perhaps you are referring to ASMX web services, which can still be found in the wild but aren't really widely used in new development these days.
WCF Service is Microsoft's implementation of SOAP. There are others implementations or you could roll your own (not recommended).
SOAP is a kind of stateful, session-based, message-based web service. It's good if your service is designed as a set of complex actions.
REST is a stateless, sessionless, resource-based web service. It's good if your service is designed to access data and perform simple CRUD operations on it. SOAP and REST are mutually exclusive. A service cannot be both. There are ways to manipulate vanilla WCF to make is RESTful but these techniques are becoming deprecated. If you want to implement a RESTful web service there are two main choices in the Microsoft world: WCF Data Services and ASP.NET Web API.
REST is an architecture
WCF is a API in .NET Framework to build connected service oriented application.
In olden days a functionality developed as Web Service was accessible via internet and the same to be available on local network was available via Remoting.
Using WCF we don't need to develop different code for it to be accessible over internet and on local network. Just configuring it with bindings would be enough.
That is a very wide question...I am going to just give a brief high-level answer and suggest that you do some more searching as there are is already a lot written on each subject. But, hopefully this should give you a push in the right direction.
First, typically when people refer to WCF Services and Web Services, they are referring to the newer WCF conventions that make service calls fairly generic (they can be SOAP, REST, etc) and the old .asmx SOAP method of Web Services. So, along these lines, I would suggest looking more into WCF and SOAP/.ASMX for the difference of WCF and older Web Services.
As to WCF and REST, they are not the same. REST is more of an architecture, whereas WCF is a framework. As I already mentioned, WCF can be used to make SOAP calls or REST calls. I am not sure I can add much more without going into greater detail.
I will see if I can find some good articles on REST and WCF a little later, though. Personally, I do not see a reason to even pursue very far into the older way of calling web services (.ASMX pages) as WCF has pretty much made that obsolete. However, learning many different ways to skin a cat can be useful in an endeavor to find what fits you best.
Again, this is VERY high level, but these are very general topics with a lot surrounding each, so hopefully a high level overview will help direct you in studying deeper on each subject.
Some people mean "ASMX" when they say "Web Services".
Others just use "Web Services" to mean the generic technology, and consider WCF to be the current way to create Web Services on the .NET platform. The other kind are "ASMX Web Services", as distinguished from "WCF Web Services".
The "other kind" are a legacy technology, supported only for backwards compatibility. They should not be used for new development, so there's no point in you learning about them.
As others have stated, "REST" is an architecture style, not a technology.
WCF is multifaceted, so I'm going to speak of it with respect to its most common usage. The general difference between WCF and REST services is centered around the content. A REST call is usually more message/document/entity centered (With customer entities, find those starting with M; With order entities, get order 12 and is tied to the HTTP protocol. WCF tends to be more operation centered (Invoke find operation with params, Invoke get operation with parameters). WCF also isn't tied to HTTP.
FYI, there are extensions to create REST based services using WCF (WebInvoke, WebGet attributes).
Wcf:wcf is a technology as part of .net framework which provides environment to work with different distributed technologies an by following unified programming model.
wcf create a proxy.
wcf support data contract serializer.
records shown xml format.
**Rest:**Rest is an architectural style.which says use the existing features of the web in more effective,efficiency and simple manner.verbs like insert,update and delete.
Rest cannot create a proxy.
rest records shown jason format.
Web Service:a service which is hosted on website is called as webservice.
web service support xmlserializer
I see this is quite an old thread, but I have asked a similar question recently.
The answers given have all similar relevance, but in my opinion Ray was the closest to what was actually asked.
When designing or refactoring a web based solution, you always get the question should we go with SOAP or REST. The answer lies in the complexity of the business logic required behind the service. REST is good for simplistic API calls that usually contains small sets of requested data or over night processing with large sets, but mainly for data requests. SOAP is more of an interactive day to day service with business logic as well. For example many methods with plenty of parameters.
What we do as part of our web based solution, is to try and make use of both. For internal methods and primary functionalities we use SOAP, but for exposed APIs we prefer REST.
Framework related, definitely WCF as preferred choice, irrespective if SOAP or REST.
I'm working on adding a WCF services layer to my existing .NET application. This layer will be hosted in IIS and will be consumed by a variety of UIs, at least one of which will not use Microsoft technologies.
I can make a Web service in WCF that is consumed by my .NET application. However, I'm concerned about things that work in the .NET world but not with other technologies.
For example, simply throwing an exception from my WCF service works fine in .NET. But according to this article, one should approach exception handling with fault contracts to ensure compatibility with non-.NET consumers. The author labels this lack of foresight as The Fallacy of the .NET-Only World.
Does anyone have any high level suggestions or links to articles that cover interoperability between WCF and non-.NET consumers?
I realize I'm potentially working against the YAGNI principle. I'm only really looking to avoid things that will be incredibly difficult to overcome later when the developers of the non-.NET consumer report problems to me.
use any of the WCF bindings that don't start with net - avoid netTcp, netMsmq etc. - those are .NET only
make sure to make good use of DataContract/DataMember attributes, so that your method input and return parameters are easily and nicely serialized
avoid any .NET specific types in your data contracts - don't pass back an Exception or something like that - use the SOAP (or REST) elements for those things instead
don't use things like DataSet, DataTable etc. - they're all heavily tied to .NET
make sure to properly catch all errors on your service side - e.g. by implementing IErrorHandler - and pass back SOAP faults instead (if you're using a SOAP binding) or a HTTP error code (for REST)
TEST your services with non-.NET clients! Run a PHP page against them, code up something in Ruby - whatever - test it and make sure it works
One good way is to make your services RESTful.
From Wikipedia - Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web.
REST style web services leverage the existing capabilities of HTTP to expose the services. Since almost every technology of building software can deal with HTTP you can be sure that your web services can be consumed by any non-DotNet consumer.
A very good example of RESTful services would be the stackOverflow API.
Here are some good links you can start with -
http://www.oracle.com/technetwork/articles/javase/index-137171.html
http://msdn.microsoft.com/en-us/magazine/dd315413.aspx
I have just started evaluating whether or not I should be using OData influenced wcf data services or a standard WCF service application as the primary data source for Silverlight applications. I would like your thoughts on which is a better way under what situation/circumstance. What is lighter over the wire, easier to maintain, etc.
What I have gathered so far is:
There are no Wcf data service templates in VS2010 that I know of, and I will need to create a asp.net web project first and then add a wcf data service, so its going to affect how I structure my projects.
WCF Data services expose actual table names over the service. I don't know yet of a way I can alias them and I'm not sure its a good idea to let the world know my table structure
In a standard wcf service I will need to write linq queries against the EF or Domain service classes on the service side, while in a data service I can move that processing logic to the client.
At first glance examining the classes exposed by the wcf data services seem easier to read and understand than those exposed by the EF
Do add your thoughts on this..
Thanks for your time.
There are no Wcf data service
templates in VS2010 that I know of,
Not project template - just an item template (for use inside an ASP.NET web site or web app). WCF DataServices are very tightly coupled to HTTP, so they only make sense in a web site/app.
WCF Data services expose actual table
names over the service.
NO ! At least not necessarily. The whole point of EF is that you can decouple the actual physical structure of your database from the (conceptual) model that gets exposed. You can totally rename entities, you can map several entities onto a single table, split up an entity over several tables, you can leave out attributes - anything you like!
At first glance examining the classes
exposed by the wcf data services seem
easier to read and understand than
those exposed by the EF
I doubt it - because by default, WCF Data Services will use a Linq-to-SQL or EF model as their basis, really. You can make that as simple or as complicated as you like.
Using a "regular" WCF service allows you to use the netTcpBinding for much faster performance (thanks to binary message encoding vs. textual messages for other bindings), when using your Silverlight 4 app in a company-internal network (doesn't work for internet scenarios) - not something you can do with WCF DataServices.
The main difference in my opinion is the SOAP vs. REST difference:
SOAP (traditional WCF) is oriented towards methods - you think and design your system in terms of methods - things you can do (GetCustomer, SaveOrder etc.)
REST (the WCF DataServices approach) is all about resources, e.g. you have your resources and collections of resources (e.g. Customers) and you expose those out to the world, with standard HTTP verbs (GET, POST, PUT, DELETE) instead of separate specific methods that you define
So both approaches have their pros and cons. I guess the most important question is: what kind of app are you creating, and what kind of user audience are you targetting?
Update:
for intranet / internal apps, I would think the advantage of a netTcpBinding (binary encoding) would justify using a classic WCF service - also for data-intensive apps, I personally find a method-based approach (GetCustomer, SaveCustomer) to be easier to use and understand
for a public-facing app, using HTTP and being as interoperable as possible is probably your major concern, so in that scenario, I'd probably favor the WCF Data Service - easy to use, easy to understand URLs for the user
I was thinking about the architecture of a web application that I am planning on building and I found myself thinking a lot about a core part of the application. Since I will want to create, for example, an android application to access it, I was already thinking about having an API.
Given the fact that I will want to have an external API to my application from day one, is it a good idea to use that API as an interface between the interface layer (web) and the business layer of my application? This means that even the main interface of my application would access the data through the API. What are the downsides of this approach? performance?
In more general terms, if one is building a web application that is likely to need to be accessed in different ways, is it a good architectural design to have an API (web service) as the interface between the interface layer and business layer? Is REST a good "tool" for that?
Sounds like you've got two questions there, so my answer is in two parts.
Firstly, should you use an API between the interface layer and the business layer? This is certainly a valid approach, one that I'm using in my current project, but you'll have to decide on the benefits yourself, because only you know your project. Possibly the largest factor to consider is whether there will be enough different clients accessing the business layer to justify the extra development effort in developing an API? Often that simply means more than 1 client, as the benefits of having an API will be evident when you come to release changes or bug fixes. Also consider the added complexity, the extra code maintenance overhead and any benefits that might come from separating the interface and business layers such as increased testability.
Secondly, if you implement an API, should you use REST? REST is an architecture, which says as much about how the remainder of your application is developed as it does the API. It's no good defining resources at the API level that don't translate to the Business Layer. Rest tends to be a good approach when you want lots of people to be able to develop against your API (like NetFlix for example). In the case of my current project, we've gone for XML over HTTP, because we don't need the benefits that Rest generally offers (or SOAP for that matter).
In general, the rule of thumb is to implement the simplest solution that works, and without coding yourself into a corner, develop for today's requirements, not tomorrow's.
Chris
You will definitely need need a Web Service layer if you're going to be accessing it from a native client over the Internet.
There are obviously many approaches and solutions to achieve this however I consider the correct architectural guideline to follow is to have a well-defined Service Interface on the Server which is accessed by the Gateway on the client. You would then use POCO DTO's (Plain old DTO's) to communicate between the endpoints. The DTO's main purpose is to provide optimal representation of your web service over the wire, it also allows you to avoid having to deal with serialization as it should be handled transparently by the Client Gateway and Service Interface libraries.
It really depends on how to big your project / app is whether or not you want want to go through the effort to mapping your DTO's to the client and server domain models. For large applications the general approach would be on the client to map your DTO's to your UI Models and have your UI Views bind to that. On the server you would map your DTO's to your domain models and depending on the implementation of the service persist that.
REST is an architectural pattern which for small projects I consider an additional overhead/complexity as it is not as good programattic fit compared to RPC / Document Centric web services. In not so many words the general idea of REST is to develop your services around resources. These resources can have multiple representations which your web service should provide depending on the preferred Content-Type indicated by your HTTP Client (i.e. in the HTTP ACCEPT HEADER). The canonical urls for your web services should also be logically formed (e.g. /customers/reports/1 as opposed to /GetCustomerReports?Id=1) and your web services would ideally return the list of 'valid states your client can enter' with each response. Basically REST is a nice approach promoting a loosely-coupled architecture and re-use however requires more effort to 'adhere' to than standard RPC/Document based web services whose benefits are unlikely to be visible in small projects.
If you're still evaluating what web service technology you should use, you may want to consider using my open source web framework as it is optimized for this task. The DTO's that you use to define your web services interface with can be re-used on the client (which is not normally the case) to provide a strongly-typed interface where all the serialization is taken for you. It also has the added benefit of enabling each web service you create to be called by SOAP 1.1/1.2, XML and JSON web services automatically without any extra configuration so you can choose the most optimal end point for every client scenario, i.e. Native Desktop or Web App, etc.
My recent preference, which is based on J2EE6, is to implement the business logic in session beans and then add SOAP and RESTful web services as needed. It's very simple to add the glue to implement the web services around those session beans. That way I can provide the service that makes the most sense for a particular user application.
We've had good luck doing something like this on a project. Our web services mainly do standard content management, with a high proportion of reads (GET) to writes (PUT, POST, DELETE). So if your logic layer is similar, this is a very reasonable approach to consider.
In one case, we have a video player app on Android (Motorola Droid, Droid 2, Droid X, ...) which is supported by a set of REST web services off in the cloud. These expose a catalog of video on demand content, enable video session setup and tear-down, handle bookmarking, and so on. REST worked out very well for this.
For us one of the key advantages of REST is scalability: since RESTful GET responses may be cached in the HTTP infrastructure, many more clients can be served from the same web application.
But REST doesn't seem to fit some kinds of business logic very well. For instance in one case I wrapped a daily maintenance operation behind a web service API. It wasn't obvious what verb to use, since this operation read data from a remote source, used it to do a lot of creates and updates to a local database, then did deletes of old data, then went off and told an external system to do stuff. So I settled on making this a POST, making this part of the API non-RESTful. Even so, by having a web services layer on top of this operation, we can run the daily script on a timer, run it in response to some external event, and/or have it run as part of a higher level workflow.
Since you're using Android, take a look at the Java Restlet Framework. There's a Restlet edition supporting Android. The director of engineering at Overstock.com raved about it to me a few years ago, and everything he told us was true, it's a phenomenally well-done framework that makes things easy.
Sure, REST could be used for that. But first ask yourself, does it make sense? REST is a tool like any other, and while a good one, not always the best hammer for every nail. The advantage of building this interface RESTfully is that, IMO, it will make it easier in the future to create other uses for this data - maybe something you haven't thought of yet. If you decide to go with a REST API your next question is, what language will it speak? I've found AtomPub to be a great way for processes/applications to exchange info - and it's very extensible so you can add a lot of custom metadata and yet still be eaily parsed with any Atom libraries. Microsoft uses AtomPub in it's cloud [Azure] platform to talk between the data producers and consumers. Just a thought.
There a lot of different ways a Silverlight application can connect back to it’ server. Including
WCF - Windows Communication Foundation
REST (see also)
ADO.NET Data Services (or is this just REST?)
POX - Plain Old XML (E.g basic xml)
RIA services
For each of these please say what it’s for and when you would or wouldn’t use it. I am not looking for a great level of details just a set of “rules of thumb” for choosing between them.
(The problem is when designing your first Silverlight application knowing what to use when you don’t have time to learn all of them.)
If I was to replace Silverlight with WPF in this question what effect would it have on your answers? (I am assuming with WPF that due to firewalls and admin policies a direct connect to the database is not an option.)
My two (euro) cents:
WCF seems best suited when the service can be viewed as the business layer of the application, that is, when your service has "intelligent" operations like "CalculateDiscountForClient".
ADO.NET Data Services (indeed, just a REST implementation) seems appropriate when your application is basically data-centric and the service is simply a front-end for the database. That is, all your service methods are of type GetCustomers, CreateInvoice, etc.
RIA services is a very new technology that I haven't experimented with yet, but it seems to be useful to create applications in which the Silverlight part and the service are very tightly coupled: you define your service classes and methods in the service project, and they are automatically replicated to the Silverlight project in design time. Also, you can define both WCF-style "action" methods and ADO.NET Data Services-style "data" methods. Looks promising.
Use POX if there is a chance that you change the client part from Silverlight to any other technology (for example HTML+AJAX) in the future, since it is the most interoperable option.
About differences for WPF, the only I can think of, is that for data access, whenever possible I would use direct ADO.NET data connections (properly embedded in a data access layer, LINQ to SQL or the like) instead of ADO.NET Data Services, since it is way more flexible. I must say anyway that I have never developed anything in WPF.
We use RIA, and that's the only one of the options that I know, but I do know it, so here's some of my thoughts.
RIA isn't finished yet. It is being worked on. If you are planning to be finished soon, and you're worried about having to support something that has a potential to change quite a bit, then you might want to consider other options. If this is a new project, and you're going to be supporting it for a long time, RIA will probably get easier to use.
Having said that, I kind of think that there won't be many changes in the way the July Preview of RIA works and the way that a finished version will work. Also the level of support seems to suggest that this will become "The Way" to talk to a server in Silverlight.
Just cause it's worth mentioning, have some links:
http://blogs.msdn.com/brada/ Brad Abrams has an example that he is continually updating.
http://forums.silverlight.net/forums/53.aspx this is where you go to ask questions.
http://www.riaservicesblog.com/Blog/ Colin Blair knows his stuff, and he is very helpful.
I think I would not go POX ever again. If you write WCF so that the service itself is independent of the binding and binding is done in configuration files, then WCF is pretty much agnostic about transport and protocol. It can do SOAP, JSON, REST, or its own form of binary serialization. All of this is in the binding. Internally, WCF only specifies what gets exposed in terms of operation and data contracts (all defined by class, method, and property attributes). WCF gives you tremendous flexibility in this regard, with more to come in 2010.
From the Silverlight side, WCF requires that you write some plumbing code. The .NET frameowrk has the tools to build the proxy in your Silverlight project, but you must be prepared to handle all WCF responses asynchronously, and the proxy cannot catch exceptions thrown by the service.
.NET RIA Services hides all this. It uses WCF under the covers, but that is completely hidden. You don't have to write asynchronous code. You define validation once, mostly declaratively, and it works both server-side and client-side. Release 1 will be targeted for Silverlight, so you don't get the versatility to use the service elsewhere. That scope is supposed to be broadened in later releases.
I don't know enough about ADO.NET Data Services to compare. I suspect the answer would depend on whether you want to expose your data to more than just Silverlight usage.
.NET RIA Services looks like the direction I'd want to go (looking at these issues myself, with a large application in mind). The big issues for me will be implementing a very large collection of functionality in the service layer, and not being able to code directly to the data access layer (we have to be able to run on either SQL Server or Oracle).
Using WPF instead of Silverlight changes everything, depending on where your data resides. It's like the old question of Winforms vs. ASP.NET. With WPF, you're building a Windows client app, and you don't need to use any form of service-based data interface at all, unless your data access forces you into it. You'll still want to separate data and business from presentation code, using MVVM, MVC, or MVP. Other than that, you have the option to treat data access as a layer, rather than a wholy independent tier.
WCF is Microsoft's standard for service communication. I would strongly advise anyone to create a service layer using WCF Web APIs (uses WCF, but tailored specifically for REST), which is coming out this April 2012. WCF Web APIs is currently in preview mode.
Remember these rules of thumb:
- your UI will change faster than your service layer. RESTful services will be around in several years, Silverlight probably won't
- will your services ever be APIs? Well...WCF REST is the way to go
- will you mix JavaScript and Silverlight code? WCF REST will make your life easier
- will you have a mobile component (since Silverlight won't run on iOS or android)...REST is preferred.
Don't tailor to the technology, but the app as a whole.
If you want to create a Silverlight Application and you do not care about other clients, then I would choose RIA Services. It is quite painless to use and you do not need to worry how the connection from the client is made (i.e. no client side configuration necessary). RIA also generates classes for all your entities on the client and you can even share your own "server" code with the client if required (useful for enumerations or extension methods).
Remarks:
I never tried this, but if you really need you can access the RIA Service also with other clients, after all RIA Services are built on top of WCF services.
I do not quite understand Akash Kava's security concerns. You can (and have to) control security on the server-side as you would do with any other service.