Where are web services typically found in three-tier architecture? What are some guildines for adding a new layer?
Web services usually, in fact, ARE middle tier. Client calling web services calling a storage (i.e. database) is a general pattern.
Well, if you go by the definition here, the webservice would be between the Business Access Layer and the Presentation Layer. It is simply a transport between the two layers. Your webservice could contain the Business Access logic but I don't think that is good design.
Well it depends, are you using them for Tier communication? are you setting up public facing web services? etc.
If you are using them for Tier communication they exist as inner layers at the tier level.
If you are making a public facing web service(as in out side of the application), then they are at the UI layer, depending on your needs this could be the same project as your UI or it's own.
You start by mixing up layers with tiers; they are not the same. You don't provide any information about your application which makes it impossible for people to answer you anyway.
I strongly recommend you to read some books about enterprise architecture; Fowler is a good author.
Related
I need the opinion of the person who has used/uses 'Restier' in the production.
I see some issues - security is disabled by default - all data can be read by the user who is not even authorized on site. Even if we plan to restrict some data - you can not remove one column from the table - only all columns will be visible to the client.
And the last - all business-logic moved to browser javascript - which is not good. If we need to perform a complex operation (which must be in a single transaction) - it is not possible.
My opinion - 'Restier' is designed for very simple RESTful projects - such as the address book, todo list etc. If you develop the big commercial application - that operate complex data scheme and operate money transactions - you should avoid using 'Restier' in a project.
Any thoughts appreciated.
REST is an arquitectural style for Web Services.
OData is a standard that describes a good technology independent implementation of REST.
RESTier is a library that implements OData V4.
The complexity of your domain must be in your Domain and Application Layer.
You can use RESTier to expose your domain functionality as a WebService the way you like. You could expose your entities only for Read operations and expose your use cases (Application Layer) as OData Actions and Functions which can the be consumed by any kind of client (iOS, Android, Web Client such as Asp.Net Mvc, Wpf , any JavaScript Frontend etc.)
If you have a complex domain I would suggest you to investigate Domain Driven Design.
Now to your questions...
Regarding security you can implement all the goodness of Asp.Net in Restier.
Regarding data shaping you never expose your domain entities directly through the Web Service. I would suggest to implement factories that convert back and forth between for example Customer (domain entity which represents the business logic) and CustomerDto (simple Data Transfer Object) . With this you can shape your data to be exposed the way you require.
Having the business logic in the Front End (UI Layer), as you mentioned, is considered an anti pattern (smart UI anti pattern) if you have big domain complexity. (For simple CRUD apps is ok). Restier does not push you in this direction. It is a matter of how you architect your solution.
Hope this helps you.
I have worked with both technologies yet I’m about to build a new backbone services layer and thinking about WCF vs Web-Api.
The idea is to create a layer of services that will be consumed by both internal .NET components and by front applications.
The following are issues are not relevant to this case:
TCP, UDP
Proxy generator
WS-* standards like Reliable Messaging, Transactions
I'm considering about 2 approaches:
Web-api for app front application above n-tier WCF services
Web-api for app front and for a flexible services layer, thus avoiding HTTP hop between services
Our system is financial oriented, some services will operate as data services using the using some kind of OData and some will perform complex financial transaction (using complex types).
I've read about the new stuff that was recently added to Web-Api 2 and it seems to be a leading platform. I've Googled a lot about pros and cons and that WCF is still alive (or frozen).
A few of the relevant references:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
http://msdn.microsoft.com/en-us/library/jj823172.aspx
Under the assumption that all the services are on the same LAN and this is targeted to enterprise system, what would you recommend and why?
Here's the question... Do you need transport layer flexibility or are you fine with them being http(s) only services? If the services are HTTP-only and (as you say) you don't care about proxy gen and WS-* then I can't for the life of me think of a reason why you'd use WCF.
The programming model for REST / plain old http(s) is just so much leaner, the MVC "style" much more natural and not to mention that WCF can just get really complex really fast, makes me think that I would need a really good reason to choose WCF in 2013...
Not to throw a spanner into the works, but have you considered Service Stack:
https://servicestack.net/download
That's what I'd be using... (btw I'm not affiliated with them in any way / shape / form).
If you need multiple endpoints/transport protocols, or the ability for other applications to consume your services in .NET and work with them as you would any other referenced library (via web reference and a SOAP endpoint) the WCF should be your choice.
If you're looking for something lightweight and convention-based and/or you're looking to create a RESTful API, and HTTP(S) is an adequate transport, then Web API is the way to go. In this case, if you want the strong typing that you'd get with a SOAP web reference you'd probably be wise to write a reusable library that acts as middleware for consuming the services and providing data.
I want to understand if there are any benefits of creating a WCF service layer for a asp.net web application, knowing that UI layer will always be asp.net web forms.
I would recommend designing the "service" layer around a service contract, but not implementing as a WCF service unless required. This will make it easier to use WCF in the future if required, while not wasting your time with issues relating to networking and such, which you do not need at this time.
Learning about SOA. Is it mostly decoupling by way of web services, one service provides web services to another, thereby staying decoupled and encapsulated? Thanks.
edit: that and maybe a good front end to them like some MVC design?
SOA is commonly implemented using web services but can be implemented using any method of decoupling the service implementation from the interface. These are then often presented to the business in a directory when apps can request details for any service provision that offers the desired service criteria.
MVC is a pattern for applications that could access SOA but I would use the best pattern for your application rather than trying to shoehorn into a single pattern. Just remember that SOA calls are likely to be operated asynchronously.
Here's an answer I provided to another question a while ago which may help with SOA principles: Rebuild N-tier app into Service-Oriented Architecture (SOA)?
Also the following is an intro to SOA: http://www.ibm.com/developerworks/library/ws-soa-design1/
In short there's a lot more to it than just web-services, its how you make available coarse grained 'business services' for reuse by multiple systems, and how you then make calls across multiple business services to meet wider business processes.
Developing some web-services != SOA
Here is a good selection of links that challenge the idea that SOA is only about web services, it explores the idea that every class in the application is a service and we can use many different transports (web, tcp, queues) within our SOA. SOA is the methodology you use to build a service orientated application.
Here are some practical examples of how to build a SOA.
I would suggest you read articles by Thomas Erl and Roger Sessions, this will give you a firm handle on what SOA is all about.
SOA Design Pattern
Achieving integrity in a SOA
Why your SOA should be like a VW Beetle
SOA explained for your boss
Building a SOA
WCF Service Performance
Choosing a presentation pattern for a new or enterprise web development is a daunting task, in my opinion there are only three; View Model, Model-View-Presenter (MVP) or ASP.NET MVC (a Model2 derivative).
You can read the full article here ASP.NET MVC Patterns
Despite the (incorrect) selected answer I have to state that SOA has nothing to do with web services.
The "service" term is so overloaded in English, so people are getting confused sometimes.
SOA is an architectural style, a set of guidances and principles that help us model our systems as "systems which consist of other systems".
The service term in SOA can be defined as a "technical authority for a specific business capability".
SOA helps to deal with coupling between capabilities, including temporal and spatial coupling.
As you can see, designing your system as an open set of loosely coupled and self-responsible systems (services) has nothing to do with using web services, WCF or other "cool things". You may use them or you may not use them. Or use them in one context, but not in another.
Most definitely you will NOT use web services as a communication protocol between your services in SOA because they immediately introduce temporal and spatial coupling.
I am building an ASP.NET 3.5 Web Application which has the three standard layers (DAL,BLL and UI). I have to consume some third party web services and display the information on the UI. In which layer should I consume this web services and can you also point me to some good examples?
As is normally the case in questions like this, "it depends." It depends on what the Web Service is doing for you and whether you need to do anything else with the response when you get it. I'm guessing, however that it's giving you supplementary data to your BLL. In that case some Infrastructure service between your DAL and BLL might be a good place.
It's never a good idea to have your UI layer directly depend on a third-party service. What happens if it changes?
In this kind of situation I've generally regarded the third-party Web service as a similar resource to a SQL database, so I've wrapped it in its own layer which is then called from the business logic.
This makes it possible to map the Web service objects to my own domain objects. It also makes it easy to stub out the Web service for testing, and decouples my business logic from the third-party service.
In many cases its usually in the business or service layer. Usually several different combinations of MVC layers make calls into the service layer, and so the common functionality of a Web service should be found there.