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.
Related
After reading this great article I thought about migrating our platform to micro-services architecture.
Our stack is Asp.Net Web API (Rest...) on the server.
Angular 2 in the front.
I wanted to make a little proof of concept to check if we should continue down this road.
As for my understanding, I need to take some chunks from our web app and slice it into micro services. As for the beginning, I want to take 2 screens I have, "Users" And "Purchase History" (each of them is too big to be micro service but this is just for the POC) and create each one of them as micro service.
I read that the UI should be part of the microservice, so should I create a new angular two app for each one of them?
If so, should I use rest to call for the rendered HTML?
Frontend and backend API, two services (components) – it’s already some kind of microservice architecture. The questions are how big your components, what kind of logic they have, will you have benefits if you split some logic to different services?
Per microservice architecture every service (component) of your system should have some dedicated logic (domain), solves some related problems, persists data to its own data-store, can be developed and deployed separately. In some cases, data-store can be shared between services.
So, the goal of splitting logic into different services is making your application easier to develop, maintenance, support and understand. Too many small services can bring a lot of overheads. To create a service, you need to spend additional development time, a service is also a deployment item, communication between services has network overheads. So, you should careful consider all pros and cons of splitting logic into services. Some balance should be found.
Going back to the question if "Users" and "Purchase History" are totally different, they don’t have common logic, can be stored in different databases and both are complicated enough, so you can split them into two services. The same about UI parts. The main thing is that splitting should bring you benefits - not overheads.
About using rest - it’s up to you, rest architecture is not required for microservice architecture but very often they are used together. Rest is about design of your services, how they expose API and so on.
Both ESB and BPM tools that I have worked on take in some input , call multiple steps to fulfill a task. The difference that I have seen is that in ESB everything is automated - the process is automatically triggered and involves a number of external calls / data is transformed and sent to appropriate system for consumption. In case of BPM system , the process is either started manually or automatically and it involved series of decision steps some of which involve manual decision steps.Once the steps are done , the task is marked as complete. Is it possible to explain the clear distinction between BPM and ESB?
I think you are right that anything achievable with a BPM can be achieved just fine with an ESB and some Web UI that enables invocation of manual steps. But this is true if you are only looking strictly from the technical point of view. In a more mature SOA, where a lot of different parties and roles are involved, both ESB and BPM have their distinct place.
The distinction you're looking for is more "fuzzy" and it is about the focus of these tools, their intended end-users and the type of logic they compose. Here is my humble attempt at explaining the difference between ESB and BPM:
Focus and goals
ESB is more focused on enablement of interoperability, separation of concerns, and abstraction of technical details. It has much more of an infrastructural role, it also cares about monitoring, scalability performance, availability, state deferral. In the ESB your goal is to enable the creation of a federated interoperable layer, by abstracting all technical details and to exposing reusable functionality.
BPM is more business-focused and in a perfect world scenario it is managed by business people and business analysts themselves that modify processes without having any idea about any technical details. The BPMN language is all about workflows and is designed to be business-friendly. In the BPM your goal is to implement real business processes by using these building blocks.
Intended users
ESB services will be governed by architects and custodians (still, in accordance to requirements by business analysts).
BPM workflows will ideally be managed and modified by business people, business analysts and the like.
Composed logic
In a BPM the compositions (workflows) consist of business-oriented tasks (e.g. check customer loyalty level and give him a discount if user X approves and his level is gold).
In the ESB the compositions generally consist of more technical services (e.g. retrieve this from the database, combine with that from this component, transform with xslt). It is possible to have an orchestrated task that implements an entire workflow the way a BPM does, that is entirely business-centric and without any reusability whatsoever, but you don't have the handy tools and visualisation to be able to easily delegate the management of this business logic to business people.
Having said all the above, ideally if you have a mature SOA, you'll have a BPM layer on top of one or multiple ESBs and corresponding Service Inventories that have:
Entity and Utility services on the bottom (implemented in the ESBs)
Task, and in some cases Orchestrated Task services that compose said entity and utility services (implemented in the ESBs)
Workflows that use and reuse all these services in the BPM layer on top of the ESBs.
I hope this gave you a good initial idea of the differences. Feel free to ask if you need more information.
Plamen's answer is already very good. I disagree with the introduction
anything achievable with a BPM can be achieved just fine with an ESB
and some Web UI that enables invocation of manual steps
His later explanation puts this into perspective though.
From the top of my head some aspects a modern Business Process Management Suite (BPMS) handles (better) in comparison to an ESB:
Graphical modelling of the business process suitable for domain experts
No technical detail required, e.g. without service composition
the right granularity is reached when the task performer can be specific automated (system) vs manual (Human, possibly with system support).Below this granularity level the service composition start (ESB)
Simulation of the workflow (without or without services connectivity), based on assumptions or real-life audit data
Dashboard and Reporting features for operational control, tactical analysis and strategic continuous process improvement (all on business level / KPIs)
Organizational modeling, management of authorizations
task routing and assignment based on the business process model (e.g. roles) or dynamic based on conditions, business rules, decision tables, real-time analysis of user skills, workload and capacities, etc.
Management of the context of the business process, e.g. business objects, documents,references to data in external systems, references to other workflows belonging to the same business entity
Keeping an Audit Trail of all activities on business level (not a log file)
Comprehensive worklist management and search features
Features to operational management like definition and monitoring of business SLAs, priorities, benchmarks, criticalities, automated or manual task delegation
Organizational aspect like deputy management, business calendar
initiation of or changes to existing workflows based on defined internal or external technical or business events
BPMS and ESBs are complementary systems. The BPMS is the business layer which orchestrates the composite business services defined in the underlying ESB layer. The ESB layer is a technical mitigation layer which supports the definition of basics services, their aggregation into composite services and other aspects like transformation and standardization of data formats. Since the layers are close the products in both areas have adopted more and more features from the the other layer. The overlaps are increasing as the vendors extend their feature sets.
Depending on the complexity of the system landscape a comprehensive BPMS which covers many ESB features can make an ESB obsolete. An ESB which extends into the business layer is unlikely to reach the feature set and ease of use required by business users. If an ESB reached this business level then it would likely be rebranded and offered as a BPMS.
If you compare the website of ESB's like Mule and BPMS like Eclipse Stardust then the different focus (technical integration platform vs business process management: modeling, simulation, execution, reporting, analysis & improvement) should become evident.
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.
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.
Using a web service is often an excellent architectural approach. And, with the advent of WCF in .Net, it's getting even better.
But, in my experience, some people seem to think that web services should always be used in the data access layer for calls to the database. I don't think that web services are the universal solution.
I am thinking of smaller intranet applications with a few dozen users. The web app and its web service are deployed to one web server, not a web farm. There isn't going to be another web app in the future that can use this particular web service. It seems to me that the cost of calling the web service unnecessarily increases the burden on the web server. There is a performance hit to inter-process calls. Maintaining and debugging the code for the web app and the web service is more complicated. So is deployment. I just don't see the advantages of using a web service here.
One could test this by creating two versions of the web app, with and without the web service, and do stress testing, but I haven't done it.
Do you have an opinion on using web services for small-scale web app's? Any other occasions when web services are not a good architectural choice?
Web Services are an absolutely horrible choice for data access. It's a ton of overhead and complexity for almost zero benefit.
If your app is going to run on one machine, why deny it the ability to do in-process data access calls? I'm not talking about directly accessing the database from your UI code, I'm talking about abstracting your repositories away but still including their assemblies in your running web site.
There are cases where I'd recommend web services (and I'm assuming you mean SOAP) but that's mostly for interoperability.
The granularity of the services is also in question here. A service in the SOA sense will encapsulate an operation or a business process. Data access methods are only part of that process.
In other words:
- someService.SaveOrder(order); // <-- bad
// some other code for shipping, charging, emailing, etc
- someService.FulfillOrder(order); //<-- better
//the service encapsulates the entire process
Web services for the sake of web services is irresponsible programming.
Nick Harrison, a brilliant developer in Charlotte, suggested these scenarios where using a web service makes sense:
On a Web farm, where there are multiple web servers hosting website(s), all pointing to web service(s) running on another web server. This allows for distributing the load over multiple servers.
Client/server, where Windows forms apps can call a web service.
Cross platform
Passing through a firewall
Just because the tool generates a bunch of stubs doesn't mean it's a good use. WS-* excels in scenarios where you expose services to external parties. This means that each operation should be on the granularity of business process as opposed to data access.
The multitude of standards can be used to describe different facets of your contract in great detail and a (hypothetical) fully compliant WS stack can take away a lot of pain from the third party developers and even allow the fabled point and click integration a'la Yahoo Pipes. With good governance controls you can evolve your public interface and manage the backward compatibility as needed.
All this is next to impossible to be generated automatically. The C# stub generator knows only the physical interface of your class, but doesn't have any idea about the semantics involved. See this paper for more detailed discussion.
If you are building a web site, then build a web site. If you want asynchronous messaging inside your application, use MSMQ. If you want to expose data to internal clients, use POX. If you need efficient binary message format, check Google's Protocol Buffers or if you need RPC check Hessian for C# or DCOM.
Web services are a coarse grained integration solution. They are rigid, they are slower than alternatives, they take too much effort to do well (and when not done well are next to pointless).
To summarize: "When should a web service not be used?" - anytime you can get away without it
If you are just coding a tiny (less than 50 users) web application for your intranet, a web service seems overkill. Especially if its primary function (providing a single point of access to many services) won't be used.
I agree that the use of a web service in a small scale web app adds a layer of complexity that does not seem justified. Most of my solutions, internet and intranet, 10-50 users, do not employ web services. I am glad others feel the same...I thought I was the only one.
For a small scale web app I think that using web services is often quite a good idea, you can use it to easily decouple the web server from the data tier. With the straightofrward development requirements and great tooling I don't see the problem.
However don't use web services in the following scenarios:
When you must use Http as the transport and Xml serialization of your data and you need lots of different bits of data, synchronously and often. Whether REST or SOAP or WS-* you're going to suffer performance issues. The more calls you make the slower your system will be. If you want medium size chunks of data less frequently, asynchronously and you can use straight TcpIp (e.g. Wcf netTcpBinding) you'd be better off.
When you need to query and join data from your web service with other data sources, rather motivate for a data warehouse which can be populated with properly consolidated and rationalized data from across the enterprize
This is my experience, hope it helps.
For a small-scale web app (You have to ask the question, "Will it always remain small scale?" though) using web services, separate business layers, data layers, and so on and so forth can be overkill.
Before anyone shoots me, I do agree that separation of logic between layers along with unit tests, continuous integration, et al are bloody brilliant. In my current role I'd be utterly lost and rocking in the corner without them. However for a very small-scale web app being used to, for example, track contact numbers and addresses for a company of 36 employees, the cost/benefit analysis would suggest that all the "niceties" listed above would be overkill.
However... Remember to ask the question "Will it always remain small scale?" :-)