Am I correct in thinking that the purpose of a service layer includes the following?
thinning out of domain models (i.e. movement of certain functions like in caching, instantiation)
reduction in dependencies from domain models
API minimisation
Traditionally (when not using Domain Driven Design) the service layer, or 'business layer' as it is also called, is where you code all the business logic for your application. So, for example in an application that deals with giving out bank loans, the service layer is where the code goes that decides whether or not a certain loan should be given.
Obviously, the service layer would require some information about the applicant of the loan to be able to make a decision on her credibility. To retrieve this information, the business layer calls the 'data' or 'repository' layer, which deals with extracting and storing information into the database.
The service layer does not deal with matters like persistence or other infrastructural concerns.
If your design is domain-driven, anthares' answer is true.
In terms of domain-driven design for example the domain service layer is used for operations that cannot be defined in the context of you Domain objects. For example if you have an object CreditCard, a suitable operation in your service layer would be Issue a new Credit Card.
In bigger application is used the pattern Anemic Domain Models, where the domain objects are used only as data containers and the whole business logic is in your domain service layer (this is sometimes refered as anti-pattern, but may be very useful in big solution, with adding another abstraction layer).
In difference solution architectures and patterns, service layer may have difference purpose, though.
Service Layer as the name suggests provides services that are not directly responsibility of any other domain object.
Service Layer also helps in decoupling of responsibilities. Service Layer forms the middle part between Database/persistence layer and the Client/UI/Web layer.
Properly designing the Service Layer allows it to be used from any client be it a Web Client or a Web Service (SOA) or Mobile device.
Related
Hello I am a newbie to n-tier architecture and was trying to find out the difference between what an application server hosting application layer of code does, and what a web service does?
So I'll tell you people my understanding of the whole n-tier concept, we have the UI -> Web Server -> business logic/application logic on an Application server -> Database Server. (Of course load balancers and multiple server instances would also be existent to fasten and store the state of processes)
But to be specific, the business logic layer would not be tied to a UI, so it is more or less independent and can be reused.
A web service on an other hand too provides functionality similar to the business logic, where it is not tied to a UI, and can be reused for different cases.
Could anybody explain if what I just explained above is right? And as I did mention earlier, I am a newbie to this, so if this sounds stupid or naive please do not bash me :)
Here's a quick, dirty, and very general explanation of a 4-tier architecture, which I'm assuming may best apply to your application:
Presentation Layer : The interface to the outside world (web site)
Application Layer : The mechanics necessary to create the interface(s) to the outside world (web application frameworks, web services)
Business Logic Layer : The actual logic that embodies/simulates/emulates your business's processes and workflows (algorithms, transformations, approval processes, etc.)
Database Layer : The database and the logic needed to query information from it
In general, web services are not part of the business logic layer. That layer is usually protected as much as the database layer, because there could be trade secrets or confidential ways of doing things in there, and you usually don't want anyone accessing that directly, except programatically or through approved interfaces (such as web services).
Web services, application layers, and business logic can be aptly compared to Coca-Cola and it's business. Bottles and cans are usually how Joe Blow consumes Coke's product (e.g. web site in the presentation layer), but other businesses want to be able to serve Coca-Cola to their customers as well, so Coke lets them use carbonated water and Coca-Cola syrup (e.g. web services in the application layer). Coke's secret formula (e.g. business logic layer), and Coke's distribution processes to get it into the store (e.g. application layer) are all hidden from the consumer. Joe Blow doesn't care how it gets into the store, he just knows he can get Coke from a variety of sources (web site, mobile client, etc.). And Coke doesn't want people knowing its secret formula (business logic). If you want a Coke, you have to go through a store or a restaurant (approved interfaces).
What exactly is web service composition?
Composition refers to the way something is build, the new term at the moment is mash-up which basically means utilising a variety of different services in a composite application. So that functionality of disparate application can be used in one application.
I think your referring to service granularity - which means how much functionality a service exposes. a coarse grained service will expose a whole process as a consumable unit whereas a fine grained service will expose a specific unit of logic from a larger process. Obviously, it is up to the service architects to determine what granularity of service works best in the given environment.
This also, in a way has to do with the style of SOAP message you are using whether it is RPC style or document and that a service should be atomic and not hold external state. Meaning it does not need to know any more information other than that in the SOAP message to perform its function.
Hope this gives you a good starting point. The trouble with service-orientation is that it differs depending on who you read, but the main points stay the same!
Jon
Some web services which are provided for clients are abstract and composition of some smaller web services and it's called web service composition.
Sometimes there are more than one web service in order to use as the mentioned small web services, so we choose them based on QoS (Quality of Service) and many researches have been done on this subject.
Web service composition involves integration of two or more web service to achieve more added value of business functionality. A work flow composer is responsible of aggregating different web services to act as a single service according to functional requirements as well as QoS constrains. BPEL is one of the popular composers uses XML language to perform service composition. Fine-grained services perform single business task and provides higher flexibility and reusability. However, coarse-grained service involves performing complex business functionality leading to lower flexibility
I've built a RESTful service for the Data Access Layer (DAL) of my architecture:
POST http://example.com/data/User
GET|PUT|DELETE http://example.com/data/User/{UserId}
However, for the Business Logic Layer (BLL), a second non-RESTful service is used:
POST http://example.com/accountapi/register
POST http://example.com/accountapi/login
This BLL service, instead of making calls to the DAL service, it talks directly to the database.
How would you improve this architecture?
Should the BLL service call the DAL service ?
Should I drop the DAL service and only expose the BLL service ?
Should I, somehow, inject business logic on my RESTful DAL service ? If yes, how ?
To answer the main question. No, not really. To answer the secondary questions. None of the above.
REST based architectures do not fit nicely into the standard 3 tier model. The simplistic view of the three tiered model looks like this:
Presentation Layer <-> Business
Logic Layer <-> Data Layer
Consider for a moment breaking the presentation layer into two parts,
Rendering Layer <-> User Interface
Content <-> BLL <-> DAL
If you think about a regular Web application, the browser takes HTML, CSS and Javascript content and renders them visually in a browser. It is the User Interface Content layer that the REST constraints apply to. This is most obvious if you think about the hypermedia constraint. REST interfaces are mean to be navigated just like user interfaces are. REST interfaces return representations of resources.
REST interfaces should return user interface content that is independent of how the user interface will be displayed.
REST Client <-> REST Interface <-> BLL <-> DAL
In my opinion REST clients come in two forms, either very thin media type rendering engines (e.g. Web browsers) or screen scrapers (spiders, mashups). I use the term "screen scraper" loosely because if you choose your media-types wisely it should be trivial for the client to scrape the data out of your user interface content.
Any attempt to expose Business Logic Layers as REST interfaces usually has a few effects. Developers end up asking how to do transactions in REST. They end up creating huge amounts of coupling between the client and the BLL interface because of the need to expose semantically rich representations. They forget all about the hypermedia constraint, because much of that linking information is not available in the business logic layer. And they start to complain about the performance overhead of HTTP and text based content types.
(1) Avoid having your (non-REST) web service business logic layer make further (RESTful) HTTP requests onto the data access layer. Doing so of course would be less efficient than making direct method calls. But much more importantly, it would require you to deploy the BLL web services and the DAL web services onto separate web server instances (or separate clusters). Otherwise you can have a case where all your HTTP worker threads are busy trying to serve up BLL responses, and each is blocked waiting fruitlessly for a free HTTP worker thread to serve it a DAL response. This can lead to stalls (if you do timeout/retry processing) or outright deadlocks (if you don't).
(2 and 3) If your web service clients need both business logic and data access, provide those as a unified set of services. Internally they both depend on the same data access layer method calls: it's just that the data oriented web service implementations make just one data access layer call while the business logic oriented web service implementations may make many DAL calls. You do most definitely want to structure the BLL and DAL layers separately beneath the web service layer though.
I like to think of the web services as just the part of the presentation layer oriented towards "users" who happen to be other programs.
If this is the same application, then you should probably have the BLL layer call the DAL layer directly in code instead of using a service call again. That would keep it more performant while keeping the fundamental purposes of the code separate (high cohesion).
Probably so. Your services should generally be course-grained components that perform a business function. Saving a user in the database isn't a business function, it's a specific implementation. The Register function abstracts that notion into a business function. The BLL layer can then enforce things like password strength, password encryption, uniqueness of usernames, etc. that aren't directly related to data access.
Probably not. See #2.
The basic client-server model (even when implemented using questionable interfaces) had a presentation layer, a business layer, and a data layer. Are the directory and discovery methods using webservices models considered a entirely new layer? I would argue that the discovery layer is actually just expanding the role of the data layer to include information on where a service can be found. I am struggling to understand the interplay between webservices and the MVC framework and I am trying to understand the bigger picture as to where the directory and discovery components fit into that framework.
I would say that there is an additional layer -- the service layer -- that sits between your business layer and the presentation layer or your business layer and the data layer depending on whether you're doing a thin- or thick-"client" implementation. This layer would encapsulate service discovery and delivery, including marshaling/unmarshaling data for transfer. See Fowler's Principles of Enterprise Application Architecture Service Layer description. In his concept the service layer sits between the business layer (domain model) and the presentation layer (UI). This concept would apply to a thin-client or web-based client implementation.
I would say there are not basically 3 tiers in the web services model.
Web services is essentially SOA (Service Oriented Architecture), which can imply a multi-tier (n-tier) model. It refers to distributed computing and could be scaled up to a massive system with hundreds of "tiers".
I would agree with you that conceptually, getting your data from a service as compared to a database, could be similar to getting data from other data sourced like databases, etc., and that this could be conceived of as an additional function of the data access layer.
Of course it also depends on semantics. Often "tiers" refers to discreet parts of the overall system (i.e. front-end, middle-tier, back-end data sources, other tiers such as integration with web services, etc.); while "layers" often refers to the vertical layers in the code such as presentation, controller, business logic, data access, etc.
We are developing a web application. We want to possibly reuse the work we do here for a different application that will use the same database, and use the same business rules for reading and writing to said database.
Which design would be more correct
Having the UI call web services, which would use business objects containing the business logic, which would talk to the data access layer.
Have the UI use business objects containing the business logic, which would call web services, which would then talk to the data access layer.
Have the UI user business objects containing the business logic, which would talk to the data access layer.
Don't mix logical design with physical design. Logical design operates over layers and physical design - tiers. Web Service is not a layer. It is simply a tier.
In logical design there is standard approach: UI layer-> BL layer -> DAL
In physical design all layers can reside within one client-side application connecting local database, or can be distributed over the remote tiers. But for distributed applications usually is added one more layer: Application layer, which hides from BL layer communication over the wire.
I would say the 3rd one. I tend to think of web services as another presentation layer.
Think of it this way: you have a web UI, which calls your business layer code to do things like create a new user (User.Add), find all products that match a given description (Products.FindByDescription), etc.
You can now re-use that same business layer code to build a set of public-facing web services for 3rd parties to make use of. There can be a method which adds a user - that calls your internal User.Add() method, another one to find products, etc..
What you get is a parallel set of presentations/interfaces to the same underlying data and business logic.
Behind the scenes (totally out of the scope of web services or UI layers), the business layer calls a data access layer that takes care of physically querying the database. If you were to change to a different DBMS, you should ideally (and in theory) be able to rebuild the data layer for the new database and have everything simply work.
Your business layer contains the rules like a username has to be 4 to 15 characters long; users are only allowed to search for and load products that are at a store they have access to; etc.
If you decide to change a business rule - like a user is allowed to search for products in any store in their state - then you change it in once place, and don't have to touch the web service or UI to make it work.
From your description, you haven't provided a reason why you would need the use of a web service layer. Assuming your database is reachable by your UI system, i.e. within the same network behind your firewall, a basic business-object layer that your website UI code (server-side, I'm assuming) will employ meets your requirements.
Bring in a web service tier when the distance between your UI system and your data layer starts to cross boundaries that a Data access layer or Business logic layer would begin to encounter difficulties.
In terms of the design being "correct" or not, it's not really possible to give a 100% answer to the correctness of a design without the full context. What are the requirements (functional and non-functional)? What design goals do you want to fulfill? How important is each goal?
The only goal your question mentions is that you want to reuse the business logic with another application. When I want to reuse the business logic of an application in a standard way I choose web services. So based solely on your one requirement I would say that option 1 ( UI->Web Service->Business Layer->Data Layer ) is a good choice.
Logically, web-services belong in the UI layer. Think of "User" being not only a human but another system and it becomes clear. Maintaining strict separation of concerns between these logical layers will allow you to easily implement and maintain your application.
Check Out: http://www.icemanind.com/layergen.aspx
The way it should go is, you have your UI layer on top, your data layer on the bottom and your business layer in between the two. Each layer can only communicate with the layer below it. So the UI talks to the business layer only...the business layer talks to the data layer only. Your UI should never talk with the data layer and your data layer should never interact with your UI.
Unless you have a reason to use a web service, then I wouldn't.
Do you hear anything about Service layer ? I think you can use a service layer for your transactions and operations and using a facade layer helps you to isolate and manage accessing from UI to data access layer directly or indirectly after visiting the Business layer . it depends on your requirements.