The main use of SOA from what I have experienced is in Reusability of services and promoting business agility by connecting disparate systems. Is there other major importance. If yes, please state them?
I am looking for an answer which can make a novice understand what is SOA when you explain about its importance to him.
SOA is an architectural style, may be realized by web services, but SOA is not just about web services. Web services are all about exposing the implementation in a standard way, whereas SOA is concerned about integration.
It basically aligns your IT infrastructure towards the changing trends in the business.
Let us look at a simple scenario:
Let's say there is the company that has its IT infrastructure first developed in the late 80s and was completely running on the mainframe. IT dept had many alternatives to the mainframe, but since they are of different technologies, they follow different protocols, and so communication cannot happen directly. They need some sort of layer in between that acts as a translator. So, the IT department had to write the intercommunication layers to talk to legacy code, Everything went on well until a point when the competition in the business grew so much as of now where the same system is interacting with MDM, dot net, infra services etc.
All those cross-technology interactions had become too much to IT dept, both to develop and maintain.
So, SOA is like a set of standards that have to be followed while building the business application which enables applications to be cost-extendable, flexible and makes the overall application cost-effective.
Related
I was recently discussing with colleagues a push toward disciplined n-tier structure for our web application. It struck me that I couldn't think of any alternative.
Is it always the case that one should seperate out web applications into layers?
An alternative to the traditional N-tiered architecture is the Command-Query Responsibility Segregation (CQRS) architecture as discussed by Udi Dahan.
Like all architectural decisions you should really think about when to use it as discussed here
Personally, I tend to see a lot of "over architecture" in my software travels which can really over complicate matters and make things much more difficult to maintain and obviously cost a lot more too. You really need to think a lot about the business problem first rather than just picking an architecture.
Keep things as simple as possible for best results and easy refactoring.
Is it always the case that one should seperate out web applications into layers?
You should separate different logical parts of your system to avoid them being tightly coupled which turns makes them and more reusable. Into what you separate them is not really that important. You can call it layers or whatever.
Actually there could be 2 meanings of those layers:
Physical boundaries: client browser, web server, web services server, backend database, ...
Logical boundaries: GUI, service layer, DAL, ...
You might also take a look at the Onion Architecture. But onions still have layers :-)
It is highly recommended to read Microsoft Application Architecture Guide, 2nd Edition.
Then, you'll realize how important that separation is for every site which is anything more than 2 simple web pages or so.
It is a thorough guide that explains every layer's roles and responsibilities and how they all play together in a robust & scalable application.
You don't have to read it all, but for the beginning take a look at Chapter 5: Layered Application Guidelines.
There is an alternative "pattern" to Layered Architecture.
But it is the anti pattern that the Layered Architecture is trying to solve. Namely the "Big Ball Of Mud" :)
What do people consider scalability? I've always hear people talk about writing scalable apps. But as a developer, I've never really saw any pointers/tips in an article that normal developers dont know. Such as caching db calls, etc. Mostly what I see are options that are configured by system admins or anyone dealing directly with the servers.
So my question is, from a developers perspective, do we really have much effect on a website's scalability? If so, could we be pointed towards articles that aids us on the .net framework. (ASP.NET MVC)
Also, do we have to write our apps differently if we were to accommodate adding new hardware, such as another webserver. (or is it the same app, but more instance of it?)
You can maybe gather some input from here on SO:
What does scalability mean to you?
Engineering scalability into an application
Design Patterns (or techniques) for Scalability
As per my understanding regarding N-Tier and SOA architecture.
N-Tier
N-Tier means dividing application into layers, Example I am developing application in asp.net and I pushed total DB Layer to WCF then it is called N-tier.[Tightly coupled]
SOA[Loosely coupled]
As per my understanding regarding SOA its very generic term and how well we going to loosely couple our architecture then its called SOA. Best example for SOA services - Stock feeds/ weather feeds.
My conclusion:
Even though if we develop application using WCF it does not mean its SOA if it is tightly couple with single client/ or .net applications only can understand about services.
Can you help me in understanding of SOA VS N-Tier.
Those two cannot be compared because each describes a different thing. Also, be aware that Tier is not the same as Layer.
Tier - process boundary. When you build 3-tier applications you know that UI, BL, and DB will be in 3 different processes which can be on three different machines.
Layer - logical boundary. A single tier can contain multiple layers. It is just the way you build your application to follow OO principles.
SOA - SOA application can be multi-tier and multi-layer but generally it doesn't have to. SOA is an approach to architect the application in the meaning of reusable autonomous interoperable remotely called components. SOA services have to follow four tenets.
To show a simple difference between N-Tier and SOA, let's assume that you are building a service layer on the top of business logic which uses some database. It looks like you are building an N-Tier SOA application, doesn't it? Unfortunately, not every application exposing services follows those tenets. Probably the most critical in this case are "Explicit service boundary" and "Services are autonomous". If your services share some business logic functionality or data in a database, they don't have an explicit boundary and they are not autonomous => the application is not designed as SOA.
There is also a difference between small SOA and large SOA. Mentioned application is a small SOA - each service has to follow tenets. Large SOA is for enterprise integration where you count applications with all its services as a single unit which has to follow tenets.
Ladislav is spot on the money, and you are correct in your assumption that by using WCF alone you are not guaranteed of building a SOA.
Here are some practical examples of how to build a SOA using WCF.
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
I think the main point to SOA (as compared to standard N-Tier architecture) is re-usability of the underlying services. That is why you create web services to serve as your data sources with the intention that they might serve other applications that you will write in the future. This is where the aforementioned loose coupling comes in very handy - your web services are generic enough and independent enough to be used in many different applications.
Think about it this way: an SOA service is something that the data access layer in your N-Tier application could call but it is also something that the data access layer in my N-Tier application could call. However I probably wouldn't use your data access layer in my application.
For example:
Your data access layer for working with employee time sheets will be tailored to your application related to time sheets.
My data access layer for working with employee quality of work reviews will be tailored for the functionality of performing employee quality of work reviews.
However, both of our applications as well as any other employee related applications could benefit from an SOA service that works with core employee data like Employee ID, Name, Cubicle Number, etc..
You have a good software product, so why would you make it SOA compatible?
You may want to do this to provide a looser coupling between your data services and your application layer. This will give more flexibility to reuse the service components for other products and allow you to change the underlying service architecture if need be without the need for your application to even know about the change.
Having said all that, I would first want to have an actual business use case that warrants making the switch before making the change. Changing simply to keep up with the latest buzzwords is just a waste of money. If you're starting a new project, however, you may want to consider a service-based architecture if it makes sense for your application.
In my opinion, only one good reason: you need interoperability between different platforms or technologies. Otherwise, save yourself a lot of grief and "just" make a well-mudlarized architecture - tell your boss it is SOA if that's what he wants to hear. Don't do it because you might move to or use other platforms in the future - you don't have an interoperability problem yet.
If you want your product to be integratable with other applications and your customers have actually voiced this wish / requirement then I would consider it, but otherwise it might be a big waste of time and money, especially if doing it might cause some lengthly architectural refactoring to make it work. But with no clear reason, it probably doesn't make sense to follow a trend just because others maybe doing it. Your customers will let you know when this is necessary.
That's a very difficult question to answer without more detail about your "good software product", but speaking in sweeping generalities:
If you implement an SOA scheme on your product, more developers will be able to consume the API services provided by your product because web services work across almost any development platform.
If your product is already a web application that publishes certain data, you might discover that you have readers/consumers of your data that are interested in doing analysis or building additional applications that you never thought of or may not ever have the available time to build.
The fact is: you don't need to.
SOA structure is very complicated to achieve. It requires care and organization style that I believe most companies will not have. (I'm glad if yours has such organization).
Tomas Erls talks about Contemporary SOA and Web Service First Generation. WS-I is the traditional web service style such as asp.net web services. Actually this traditional web services doesn't mean any service oriented; And what happens is people build simple web services and call them SOA.
Contemporary SOA, I believe, is an entire system structured based on services. Inside this "ecosystem", services would call each other to perform some tasks.
SOA analysis is painful and you need care. To build an ecosystem like that, you need to be prepared from the first moment.
Engineering service interfaces (contracts) is also paradigm. If you put some Lean Thinking at your belt, you should cut some desire to make state-of-art design.
If your system already works, fine! If someone will need integration in possible future which you don't know yet about it, don't do it now. But if your system is born to be consumed, them you think about it.
Best
I have a web application that is arranged into data, business and UI projects. As the system evolves changes are deployed by building all three projects and deploying them in one package. This has worked well and has allowed the illusion of “three tiers” without tackling the communications, versioning issues of truly separate systems.
So along comes a request for XML summaries of some of the data and my thoughts turn to a fancy WCF service that, one day, could be my “Web API” (ahh… the mind.. what a evil little monkey it is). So, assuming this survives the “is that really the best idea?” test here is my question:
What structure have you had the most success with when posed with two
evolving “clients” serving content from a single evolving “model”?
James, your question is rather board as there are a large number of variables that go into choosing the right type of architecture for your needs. I would recommend reading the patterns & practices Application Architecture Guide 2.0 to better understand the options and pick the best one that suits your individual needs.