Introduction

In my previous article we had concentrated on Design Patterns and UML which
are the most important fundamentals for architecture interviews. One of the other areas which needs to be strong for architects is
an understanding of SOA.

Again I repeat, do not think that you will get an architecture position by reading interview questions. But yes there should be some kind of
a reference which will help you quickly revise what the definitions. Just by reading these answers you get to a position where you are aware of the fundamentals. But if you have not really worked
on these you will surely fail with scenario based questions. So use this as a quick revision rather than
as a shortcut.

(B) What is SOA?

SOA stands for service oriented architecture. Before we define SOA let's first define a service. In
the real world, a service is what we pay for and we get the intended service. For instance you go to a
restaurant and order food. Your order first goes to the counter and
then it goes to the kitchen where the food is prepared and finally the waiter serves the food.

Figure: Restaurant and services

So in order to order an item from a restaurant you need three logical departments / services to work together (counter, kitchen, and waiter).

In the same manner in software world, these services are termed as business services. They are self contained and logical. So let’s first define a business service,
SOA definition will be just an extension of that.

Definition of business service: It’s a logical encapsulation of a self contained business functionality.

For instance the figure ‘order system’ shows a simple ordering system which is achieved by different services like payment gateway, stock system, and delivery system coming together. All the services are self contained and logical. They are like black boxes. In short we do not need to understand the internal details of how the business service works. For the external world it’s just a black box which takes messages and serves accordingly. For instance the ‘payment gateway’ business service takes
the message ‘check credit’ and gives out output: does the customer have credit or not. For the ‘order system’ business service ‘payment gateway’ service is a black box.

Figure: Order system

Now let’s revise some bullet points of SOA before we arrive to the definition of SOA.

SOA components are loosely coupled. When we say loosely coupled
that means every service is self contained and exists alone logically. For instance we take the ‘payment gateway’ service and attach it to a different system.

SOA services are black boxes. In SOA, services hide there inner complexities. They only interact using messages and send services depending on those messages. By visualizing services as black boxes, services become more loosely coupled.

SOA service should be self defined: SOA services should be able to define themselves.

SOA services are maintained in a listing: SOA services are maintained in a central repository. Applications can search the services in the central repository and use them accordingly.

SOA components can be orchestrated and linked to achieve a particular functionality: SOA services can be used/orchestrated in a plug and play manner.
For instance, the figure ‘Orchestration’ shows two services ‘Security service’ and ‘Order processing service’. You can achieve two types of orchestrations from
it: one you can check the user first and then process the order, or vice-versa. Yes, you guessed right, using SOA we can manage
a workflow between services in a loosely coupled fashion.

Figure: Orchestration

So let's define SOA.

SOA is an architecture for building business applications using loosely coupled services which act like black boxes and can be orchestrated to achieve a specific functionality by linking together.

(I) In SOA do we need to build systems from scratch?

No. If you need to integrate or make an existing system as a business service, you just need to create loosely coupled wrappers which will wrap your custom systems and expose the systems functionality in
a generic fashion to the external world.

(I) Can you explain business layers and plumbing layers in SOA?

In SOA we can divide any architecture in two layers. The first which has direct relevance to
the business as it carries out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server, etc. This division is needed to identify a service. Consider the figure ‘Simple order system’. It has various components which interact with each other to complete
the order system functionality.

Figure: Simple order system

The simple order system can be divided in to two layers (see figure 'business and plumbing layer'
- one which is business related and second which is more technical related). You can see the plumbing layer consisting of data access layer, AJAX,
and yes more technical stuff.

Figure: Business layer and plumbing layer

(I) What’s the difference between services and components?

Services are logical grouping of components to achieve a business functionality. Components are implementation approaches to make a service. The components can be in Java, C#, C++ but the services will be exposed in a general format like Web Services.

(A) Can you describe the complete architecture of SOA?

Figure ‘Architecture of SOA’ shows a complete view of an SOA. Please note this architecture diagram is not tied up with implementations of Microsoft, IBM etc. It’s a general architecture. Any vendor who implements SOA needs to fulfill the below SOA components. How
they do it is completely their own technological implementation.

Figure: Architecture of SOA

The main goal of SOA is to connect disparate systems. In order that these disparate systems work they should message each other. ESB (Enterprise
Service Bus) acts like a reliable post office which guarantees the delivery of messages between systems in a loosely coupled manner. ESB is a special layer which delivers messages between applications. In the figure we have shown a huge plump pipe. It’s not hardware or some wire etc. It’s a group of components/software which helps you send and receive messages between the disparate applications. Do not try to code your own ESB, you can think of buying one from Microsoft, IBM, Oracle,
Progress, etc.

SOA registry is like a reference database of services. It describes what each service does, where they
are located, and how they can communicate. It’s a central reference of meta-data for services.

SOA workflow allows us to define a work flow using services in
the SOA registry. We will read more about BPM in further questions.

Service broker reads the work flow and takes services from the SOA registry and ties them together.
Service brokers are normally middleware like EAI (Enterprise application Integration) products. You can get a list of decent EAI from Sun, Microsoft, and IBM etc.

Process manager is nothing but a collection of SOA registry, SOA workflow, and service broker.

SOA supervisor is a traffic cop ensuring that services do not have issues. It deals mainly with performance issues of the system so that appropriate service levels are met. If any of the services have performance problems it sends messages to the proper infrastructure to fix the issue.

Note: The above explanation is of the general architecture for SOA. Any vendor (Microsoft, IBM, SUN, etc.) who gives
a solution for SOA should have the above components
in some or the other manner. As this is a software architecture book, we will not be covering specific vendor implementations. We would advise the reader to map this
to their vendor products for a better understanding.

(I) Can you explain a practical example in SOA?

(I) What are ends, contract, address, and bindings?

These are the three terminologies on which SOA service stands. Every service must expose one or more ends by which the service can be
made available to the client. The End consists of three important things: where, what,
and how:

Contract (What): Contract is an agreement between two or more parties. It defines the protocol how clients should communicate with your service. Technically, it describes parameters and return values for a method.

Address (Where): An Address indicates where we can find this service. Address is a URL, which points to the location of the service.

Binding (How): Bindings determine how this end can be accessed. It determines how communication is done. For instance, you expose your service, which can be accessed using SOAP over HTTP or
binary over TCP. So for each of these communication mediums, two bindings will be created.

Below figure show the three main components of the end. You can see the stock ticker is the service class, which has an end hosted on
www.soa.com with HTTP and TCP binding support and using the Stock Ticker interface type.

Figure: Endpoint Architecture

Note: You can also remember the end point by ABC where A stands for Address, B for bindings, and C for Contract.

(I) Are web-services SOA?

SOA is a thinking, it’s an architectural concept, and web service is one of the technical approaches to complete it. Web services are the preferred standards to achieve SOA.

In SOA we need services to be loosely coupled. A web service communicates using
the SOAP protocol which is XML based, which is very loosely coupled. It answers the what part of the service.

SOA services should be able to describe themselves. WSDL describes how we can access the service.

SOA services are located in a directory. UDDI describes where we can get the web service. This
is nothing but the implementation of the SOA registry.

i am muhammad and from pakistan ,the thing i want to thanks to you for such a wonderful sharing of knowledge in a very brief way that even a beginner can understand and can get the true meanings of the technology,i think this information technology is just alive because of the persons like you,your every article is astonishing and more nd more interesting ,reader likes to read and dont get bore .

i dont know about any one else but i feel honour to admitt you as a mentor.

I have reported this to code project, i hope they take action. By the way its good that Indian have their own perspective and yes you need to change it. Just because you have nothing to comment nobody has given you rights to talk about my country.

I agree that live working is very much different. My perspective is to make a reference material , a quick revision. I have not written that you will get a job. Its a revision material. If you have a job in hand its garbage , if you have a interview tommorrow then probably you will call it something else....Its perspective.

But yes experiences can not be replaced by interview questions agreed...

if you have a interview tommorrow then probably you will call it something else

Nope. It's still garbage. You either know it before hand or you don't. If you don't know it, then don't waste your prospective employers time and apply for the job. The reason I have the job I do now is because I'm the 4th person to apply for it in a year. The previous people all passed phone interviews, face-to-face interviews, and did well, but when they sat their butts down in the chair in their cube, they couldn't do a damn thing. They knew the answers to the interview questions, but didn't have any experience (they lied about it), nor any clue how to apply what they knew.

The last person before me, had someone else do the phone interview, then he came in for the face-to-face interview and knew the answers to common interview questions for that job, even some questions you don't normally get in an interview, and passed. He boasted about how he wrote operating systems for embedded devices, and yada, yada, yada, but when his ass hit the chair, he couldn't (no joke here!) drag and drop an icon to copy a file in Windows.

I got the job on the third try I applied for it and have since made a very good impression with my abilities and work ethic. I didn't know everything I needed to know to get the job. Where I emphasized my skills is my extremely strong ability to pick up something I don't know, learn it VERY quickly, and be productive with it in, at most, a few days.

It's the difference between being "book smart" and "street smart" when it comes to doing the actual job. There is a reason why you hear of "paper CNE"'s and "paper MCSE"'s.

In India, to get the best chance at an H1B, groups of friends used to get together, buy books on the tests. Then everyone would sit around the table and study the books like mad, never having touched a computer. Since the tests all want the "book" answers, it was relatively easy to pass the tests. But, when you go to apply what you "know" from those books at an actual job, it's impossible to do without the experience go with the knowledge.

In India, to get the best chance at an H1B, groups of friends used to get together, buy books on the tests. Then everyone would sit around the table and study the books like mad, never having touched a computer

Thats too Exaggerated .I do not think that happens in India, atleast i can bet on it as a localite.Not sure if you have seen yourself people do that.If that was a case i do not think outsourcing would have come to India.I think the so called H1 craze has completely gone off...not many people are interested in US travel now a days.

Dave Kreskowiak wrote:

But, when you go to apply what you "know" from those books at an actual job, it's impossible to do without the experience go with the knowledge.

Agreed with out experience its of no use. But some times only street smart does not work you need to revise a bit and this article was written from that perspective.

I do not think that happens in India, atleast i can bet on it as a localite.Not sure if you have seen yourself people do that.

Haven't seen it myself, but I've heard the same story, multiple times, from Indians.

Shivprasad koirala wrote:

If that was a case i do not think outsourcing would have come to India

The level of skill doesn't matter. What motivates corporations is cheaper and cheaper labor. In 2004, the number of PC's per capita (1,000,000 people) in the US was about 763 (#4 in the world). In India, it was 12 (#128 out of 157 countries). Considering India's 2004 population of around 1.065 billion people, well, the math is pretty simple and it says that India doesn't exactly have a large experience base to drawn from there.

This thread is just a response to your comment raised for Indian's, which state that they got the jobs by buying some books from the street. Well, taking your favor, if I say that you are correct then please justify below statics:

1 : 38% of doctors in US are Indians.2 : 36% of scientist in NASA are Indians.3 : 34% of Microsoft employee are Indians.

There are many more statics but I think that would enough to remind you that if all those people raised from the book reading then I think other countries should adopt these methodology.

One more thing Dave, please never under estimate someone because you think he/she is inferior to you. As a Indian we taught this thing to respect those people also who abuse you.

Thanks for all your comments. I have written this article with my heart and as said its for revision. People who are worth are always worth , religion country does not matter, interview questions is just fast mechanism to revise and get ready.

Again said and done , comment on me not on a country or a national. The article is my thought process they do not depict a thought process of any country as such. We are all professionals , i saw yoru profile , definetly not worth for a MVP to comment on a certain section of a people.

I apologize to all ( specially Dave & Shivprasad) for being such a person. I do respect great minds and I feel no shame to say sorry to them. This indeed is a good article and I would like to see some more like this as eventually they make us more professional.

Looks like DAVE is one of those Americans whose job had been kicked off by a Indian....

Not by one, but by 4. And they all lost their jobs 6 months later.

I'm not talking about that one experience. I'm speaking from about the last 20 years of experience and the hundred or so people I've worked with directly, employees and contractors alike.

Funny though, even in my current job. I replaced a guy who, on his resume, said he wrote a couple of operating systems, but yet, couldn't drag and drop to copy a file, or understand and follow the simplest of instructions with just installing software. He replaced a guy who just couldn't get along with anyone who wasn't of his faith. Guess where they came from?

Or how about the 18 contractors we had to let go at the end of 2008, 3 of which we kept on longer than the rest because they were the only ones who had a clue about basic troubleshooting and software testing. That one taught us not to trust the contract house to do the interviewing. Oh, and of those 3, 2 were Indian, one was Japanese. The rest were Indian. The contract house even had the balls to call us up and request that we keep someone else on instead of one of the people we chose because the guys H1B would have expired if we did and he would have to go back to India.

Don't get me wrong. We do have Indian people around that I very much respect because they do know what they are doing. But, with the outsourcing boom, they have to fight to keep up their person reputation in the midst of a flood of others from their same country who have a hard time finding the power switch.

mallasharad wrote:

Thu tere zindagi pe ( I hope DAVE you can figure this sentence out if you have a indian freind).

I think that those QA are good only for a person who has some experience in Service Oriented design but lacks some theoretical knowledge. What happens in the programming world is that a new theory just comes to explain things that have been in the world for a while. Say, I figured out that my way of designing programming applications is called AGILE. Some how I missed the term, never paid attention to it, just designed accordingly. If I asked during an interview what the Agile was I would never be able to answer.Another example is Designing Patterns and so on.

I think that profiling programmers based on their nationality is incorrect.

I don't think that there is anything wrong with Indian programmers, I just think that programming boom forced many foreign people pretend to be programmers to get jobs in America, visas, etc... Or it forced many people obtain the computer science as their second degree even though they did not like it and initially did not intend to work as programmers.

So the interviewer should just filter a real programmer with knowledge and desire. It applies not only to Indians.I have some my very own experience in the matter.In year 1999 I interviewed 42 programmers (happened to be with computer science degrees from India) and found only one, but really good one.

This year my company was looking for programmers and again I interviewed about 15 programmers(mostly from India).

In their resumes they claim to know things and do things. Some of them have some theoretical knowledge. The last assignment was to write a simple web application to display a table with data taken from a database. An experienced programmer must have it done within 20 minutes. One person passed the test.The rest failed it either completely or it took them about hour and a half to display wrong data.

As for the article I think it is a good one. If you obtain a SOA position and have some experience in architecture this article may help to organize your thoughts before the interview

I think that profiling programmers based on their nationality is incorrect.

I don't profile based on nationality. I'm just using statistics pointing at the U.S. and the biggest supplier of off-shore "talent" to the U.S., namely India. I know a few Indian people in various position that can manage projects and write code as well as U.S. people who can do the same. I also know a bunch of U.S. people that I had the displeasure of working with who couldn't find their way around a computer (or their own ass) if they had a map, flashlight, compass, GPS, and a couple of tour guides. I've also had the displeasure of working with a bunch of "off-shores", mostly Indian, but some Chinese, and a couple of guys from Cambodia, none of which should have ever gotten an H1B for IT work.

My whole objection to the article was it came acrossed as a summary "cheat sheet", giving the answers specifically to pass interview questions. Again, "paper certified" instead of "street smart" IT. I'll take a street smart guy as a team member any day...

My whole objection to the article was it came acrossed as a summary "cheat sheet",

I agree its a revision material and if you want to say its a cheat sheet welcome. yes its a quick revision and equivalently important.

The point is how many interviews now a days ask situtaional questions to get those street smart guys.The other side is equally to be blamed. Recently one of my freinds went to IBM for interview the interviewers demand was he needed person who knows everything. This is the case with the most interviews now a days including US interviews. A poor chap working on a 1.1 maintenance project how the hell he will know about SOA , he needs to revise , cheat sheet and this article is that.

Dave Kreskowiak wrote:

giving the answers specifically to pass interview questions.

This article 1000 % can not help to get a job. Its a revision sheet.

Dave Kreskowiak wrote:

I'll take a street smart guy as a team member any day...

I agree street smart guys are important. But is the case with the all interviewers today.

I think the best way to take interview is to tell him to code , but thats not practically feasible in bigger companies.

There is a difference between cramming and revision. My intetion of writing this article is revision and not sending crammed developers in the market , they will eventually fall out.

I know that I am entering in someone's else discussion. But I read your article, I read some of the comments and I want to express my view on the situation.

I don't think Dave is wrong. I don't think you are wrong either. Personally, I don't like interview question articles. I really consider them cheat sheets, but I didn't vote, because I can also see that some interviews ask much more questions than they really need to ask, so we need to get ready to answer all of them. I personally don't like interview questions' articles or the like because I want to read an article to learn something, not to do a "basic review". But as I don't see anything wrong, I simply don't vote... it is not an article for me, and I understand that it can be useful to someone else.

But now I will talk about Dave's attitude, which some people seem to see as a problem with Indians. I don't see it that way. I live in Canada. I am Brazilian, so, I am an immigrant. I know there are people that are intolerant to any immigrant and I am sometimes seen as inferior... yet, I can't consider they wrong for acting differently with me before knowing me. In Brazil, people who finish university is usually much more incompetent than people who finish university in Canada (and from what I heard, the good US universities never allow an incompetent to get a diploma).

I usually see that Brazilians never buy components made by Brazilian companies, yet they buy components made in US, even if in fact those are components made by Brazilians... yet, I am one that says that I will never buy components made by Brazilian companies. The reason is simple: Brazilians lie. A lot.I myself interviewed some persons I made bad choices because all the "basic" answers were there. The person, in fact, knew all the interview questions and answers, but was the worst programmer I ever need to deal with.

So, before losing focus, I can see this:* An "Interview questions" article may help someone who already knows the topic but is not used to some terms... but it will more probably help an incompetent seem competent;* Judging people by their origin is not being regionalist... it is a reality. If you are a competent person judged as incompetent by your country, you will probably hate that... but if you are the one hiring, and living from the results, maybe you do the same. If you don't have time to know the person, you usually judge by what you see. I can say that: Brazilians lie, a lot. They will say they did things they didn't, they know technologies they don't etc. Canadians may study a lot but many don't know real world scenarios, because they've never worked in many cases, they have only studied. Indians follow rules. They learns well-known practices and follow, without thinking. Don't get offended, there are always exceptions, but that's the "before I know you thinking".

Well... I don't know how to make a conclusion, but I hope you see that it is not personal, but articles like this may really help bad people and regionalism is both a bad thing (when you are an exception) and a good thing to apply before knowing someone (especially when money is involved).

Thanks Paulo i agree to most of the things what you have said. I have already clarified my intent. If someone mugs up , its so easy to catch them up. Just put a couple of situation based question and they stumble.

Its a quick revision and reference sheet to get the right technical vocabulary.

Really? I just got done interviewing 35 people to fill 3 positions. Most of them could give me the answers to the questions you find on these sites, but when asked to anaylze problems, write small code blocks, or otherwise answer questions where concepts behind previous questions they answered are applied, NONE OF THEM could pass these simple tests.

There is nothing you can say about how good this idea is when I have a ton of experience that tells me they are a complete waste of the INTERVIEWERS time.

You seem to be someone who has lots of knowledge or at least posing to be someone with lot of skills on SOA.

Nope and I never said I was an expert on SOA.

bharatRajM16587 wrote:

How many articles have you published on SOA till now on codeproject? Have at least thought of writing a few articles which give insights to fellow readers on various issues they might come accross?

This question is completely irrelevent to the discussion I started, years ago. It's not the number of articles I've written, but the number of interviews I've had to conduct and waste my time on because the candidate was giving me book answers, if any at all, and had no experience to back up what they were telling me.

bharatRajM16587 wrote:

Instead of doing something productive, you come to these posts just to bash people who doing something good for others?

If you actually bothered to read the entire discussion thread, you would know why I believe this is FAR from doing "good for others". That's my entire point of the thread.

bharatRajM16587 wrote:

If you cannot like someone's work at least improve yourself by not hating it.

I can't stand "Interview Question ariticles" because, as I've just said, I've had to waste my time in too many interviews where the guy/gal sitting acrossed from me didn't really know anything about what they were regurgitating back at me.

bharatRajM16587 wrote:

I am very happy for you that you have a job in hand even with this sort of arrogant attitude!

I beg to differ. Arrogant is believing that you can bluff your way past me in an interview by reading a couple of these articles.

I think that those QA are good only for a person who has some experience in Service Oriented design but lacks some theoretical knowledge. What happens in the programming world is that a new theory just comes to explain things that have been in the world for a while

Exactly experience is one part and getting the right technological sentence is other part. For instance a developer working on a delegate knows everything about it.

But he needs to say that one liner "Its abstract pointer to a function". If he does not communicate that senetence , then how will the interviewer know about his knowledge.

many asians ( including me ) have english as second language and its essential to get things right before interviewer.

My whole point here is to do a revision of the WHAT part of it , if you do not have knowledge you will always get stuck with 'HOW" part which needs logical thinking.

You do not have to defend yourself so much on this.I really admire your work and there are many like me who like your work & these articles on codeproject.

Not that I have any objections on it, but may be its bit too far to title this article as Interview questions but its better to change it something like a ready reckoner for SOA and end this creepy sounding discussion to appease everyone.

I wrote this article 6 years back. I had lot of immaturity at that time. So those comments are quite old and i have answered them in immatured manner. I agree that reckoner would be a good idea but i think at the core its a interview question and answers , so changing that would lead to dilution of the topic.

Why to hide , yes its a interview question with answers . I know its not the best but that was my capability 6 years back.

Shivprasad, I commend you for your courteous response to a rude, irrelevant comment. I personally thought it was a very good article. I am going for an interview where I expect to be asked some questions about SOA, and your article has helped me get the "big picture".

I have also interviewed people, and, in general, I do not expect them to have "hands on" experience of everything that is in the job, but, I do expect them to have some top level view of the areas where they lack experience. eg. If the job description includes "database sharding", I expect the applicant to at least know what "database sharding" is, even if they have never done it. If the person learnt what "database sharding" is just the night before, by coming to an article like this, then he/she will get the job over someone who did not make that effort.

I constantly wonder why "articles" like this are posted. If you are giving people answers to questions that they couldn't answer on their own, does nobody any good. A company might hire this person because they don't do thorough vetting. So, we have another grossly unqualified person in a position that they should not be in.

You can try to cover yourself, by saying this is meant as a reference for someone to go over as a refresher. But in no uncertain terms, this is tantamount to cheating.

Microsoft has hired me in numerous occasions to assist them with their development for their customers.It is the only company that has done no nonsense interviews. This means that they have never asked a question like what is SOA. They have asked how I solve a problem. What technologies I use; what is the version history lets say of ASP.Net and what they accomplished with each version. What problem was solved.

Only companies that have ignorant people go to internet get a bunch of question like "What is SOA?" or "What is TDD?" or "How GC works?". One can read this, give answers and get a job. I would not like to work with a company that has such employees. Where is the responsibility? Where is the creativity? The ability to solve a problem? Will this programmer drag a drop and a 500gb zip file?

Do I like to work with Microsoft? They have an excellent cafeteria, nearly gourmet food. With unbeatable prices. You can not say though the words Google or Apple. It looks good in my CV after all they have bought my software and they have been an excellent customer.

I got inspired from Dave's point of view which I agree 100%.On the other hand there is a point of view for these articles. It does give an overview of a subject and a few points.

Elaborating on Dave's note there are countless people(interviewers) that I have met that ask questions irrelevant to comprehension of the subject. They are simply idiots. They find these questions by accessing articles like this one.