Feeling overwhelmed by the buzz about SOA—service orientedarchitecture? Take heart! Service Oriented Architecture ForDummies, 2nd Edition makes it easy.
Table of contents
- Service-oriented architecture - Wikipedia
- Frequently bought together
- Service Oriented Architecture (SOA) For Dummies, 2nd Edition
Modules are communicating by sending messages to each other over the network, rather than by more tradtional programming-language mechanisms like procedure calls. In particular, in a service-oriented architecture the parts generally don't share mutable state global variables in a traditional program.
Or if they do share state, that state is carefully locked up in a database which is itself an agent and which can easily manage multiple concurrent clients. I'd like to give a shot at explaining it for the layman, using an analogy in plain english. On one side we have the Provider and on the other side we have the Consumer , separated by a Bridge where the two sides communicate.
The consumer uses a number of Applications necessary for it's business and the provider uses Components that provide these applications with information. They communicate through a set of Services using a common architecture. The analogy Imagine a house on the country side, that in many ways is part of a larger community, like a city or town. The city has it's own complex systems for providing water and electricity, handling sanitation, providing transportation and other utilities. The House is the consumer in this model, the City or community is the provider and the pipes, sewers, powerlines, optical fibers etc.
This model could loosely be compared to a SOA. The people in the house uses a number of different "applications" like radiators, computers, toilets, lamps, underfloor heating, bathtubs etc. These applications don't care how the city generates the water, creates the electricity or handles the waste as long as it works. The components of the city are generators, water pumps and sanitation areas.
- The Struggle for the History of Education (Foundations and Futures of Education)!
- Service Oriented Architecture (SOA) For Dummies;
- Service-oriented architecture!
- English To German Dictionary;
- Charity Case and other stories.
It provides the house with all these needs but it's up to the house to use it in what ever way it sees fit. Let's assume you have four cooks. In SOA, you assume they hate each other, so you strive to let them have to talk to each other as little as possible. How do you do that? Well, you will first define the roles and interface -- cook 1 will make salad, cook 2 will make soup, cook 3 will make the steak, etc.. Then you will place the dishes well organised on the table so these are the interfaces and say, "Everybody please place your creation into your assigned dishes. Don't care about anybody else.
This way, the four cooks have to talk to each other as little as possible, which is very good in software development -- not necessarily because they hate each other, but for other reasons like physical location, efficiency in making decisions etc. It also means you can recombine the dishes services as you like.
For example, you might just use the dessert to service a cafe, or just take the soup and combine it with a bread you bought from another company to provide a cheaper menu, or let other restaurants use your salads to combine with their dishes, etc. One of the most successful implementation of SOA was at Amazon.
Because of their design, they could re-package their whole infrastructure and sell it as Amazon Web Service. SOA is an architectural style but also a vision on how heterogeneous application should be developped and integrated. The main purpose of SOA is to shift away from monolithic applications and have instead a set of reusable services that can be composed to build applications. With SOA, the idea is to have reusable services be made available enterprise-wide, so that application can be built and composed out of them.
The promise of SOA are. No need to reimplement similar features over and over e. The SOA vision requires an technological shift as well as an organizational shift. Whereas it solves some problem, it also introduces other, for instance security is much harder with SOA that with monolithic application. Therefore SOA is subject to discussion on whether it works or not.
This is the ft view of SOA. It however doesn't stop here. SOA is designing and writing software applications in such a way that distinct software modules can be integrated seamlessly with high degree of re-usability. But it is too small context of SOA. SOA is much larger than that and over the past few years web-services have been primary medium of communcation which is probably the reason why people think of SOA as web-services in general restricting the boundaries and meaning of SOA. You can think of writing a database-access module which is so independent that it can work on its own without any dependencies.
Service-oriented architecture - Wikipedia
This module can expose classes which can be used by any host-software that needs database access. There's no start-up configuration in host-application.
Whatever is needed or required is communicated through classes exposes by database-access module. We can call these classes as services and consider the module as service-enabled. Practicing SOA gives high degree of re-usability by enforcing DRY [Don't repeat your self] which results into highly maintainable software. Maintainability is the first thing any software architecture thinks of - SOA gives you that. As far as I understand, the basic concept there is that you create small "services" that provide something useful to other systems and avoid building large systems that tend to do everything inside the system.
So you define a protocol which you will use for interaction say, it might be SOAP web services and let your "system-that-does-some-business-work" to interact with the small services to achieve your "big goal". These are also good resources, look at the SOA explained for your boss one for a layman explanation. Achieving integrity in a SOA. SOA explained for your boss. Someone eventually comes in and says we've got a mess.
Frequently bought together
All the other players coming in have to work with SOA via a service web service or whatever it has. The Oracle monolith takes care of everything monolith is not meant derogatory. Oh yeah, you got ASP. To me it just means a bunch of web services or whatever we call them in the future with a good front end. And if you own the database just hit the database and stop worrying about buzzwords.
Service Oriented Architecture (SOA) For Dummies, 2nd Edition
In simplest words, you write a piece of code that is very generic i. So you provide a service through your code. So you are a service provider. Now someone wants to use a similar code then he does not have to write the code again. He simply uses your code maybe through a web service. Hence he becomes a service consumer. Hence making a program using such services is called SOA. And the loose coupling is there as the service provider and consumer may be interacting even if they are using diff programming languages. Most similar to subroutine calls where parameters are passed and the operation of the function is abstracted from the caller - e.
Copybooks are used to define data structure which is typically defined as an XML schema for services. SOA is loosely coupled implying changes to a service have less impact to the consumer the "calling" program and services are interoperable across languages and platforms. Encapsulation, Abstraction and Defined Interfaces o Differences: SOA is loosely coupled with no class hierarchy or inheritance, Low-level abstractions - class level versus business service. Reuse through assembling components, Interfaces, Remote calls o Differences: Wide adoption of standards, XML Schemas vs.
Marshaled Objects, Service Orchestration, Designing for reuse is easier, services are business focused vs. IT focused, business services are course grained broad in scope. Best practices well defined interfaces, standardized schemas, event driven architecture , reusable interfaces, common schemas o Differences: Standards, adoption, and improved tools.
Reading the responses above, it sounds to me that SOA is what developers good ones at least have been doing from day one. It could also stand for "Struct of Arrays" as opposed to "Array of Structs" which is a common topic in parallel especially SIMD programming, but I'm guessing that's not what you mean here! SOA is a buzzword that was invented by technology vendors to help sell their Enterprise Service Bus related technologies.
This book was just okay. It wasn't exactly what I was hoping for. It was more like a sales pitch for implementing SOA at your company. It explained SOA some, but I was looking for a little more detail. I don't regret reading it though. I did learn some stuff. SOA explained for 'regular' business folks. The authors did a wonderful job of keeping the explanations relevant to the non-IT professionals. This book explains basic SOA concepts but it is not a book that can get you started building services, SOA infrastructure and middleware.
It is a good book to brush up concepts. Nice overview on SOA. A non-technical book helped on understanding SOA big picture. Good for a start, but not very helpful on technical details level.
Roger Gilmartin rated it liked it Jun 13, Christopher LoPresti rated it it was amazing Sep 09, Hill rated it it was amazing Jul 22, Keith Svetlik rated it liked it Jan 20, Olafclem rated it really liked it Aug 24, Aprodita Hera rated it it was amazing Mar 04, Mahesh rated it liked it Nov 23, Brahmasta Adipradana rated it liked it Jun 29, Bill Sawyer rated it liked it Jan 02, Gopal Patel rated it really liked it Aug 02, Krzysiek rated it liked it Aug 14, Bond Bond rated it liked it Oct 20, Dante rated it it was ok Jul 06, Jovany Agathe rated it liked it Dec 31, Susan rated it really liked it Nov 14,