Service Oriented Architecture seems to be more and more of a hot quote these days, but after asking around the office I have found that I seem to get many different definitions for it. How would you guys define SOA? What would you consider the official definition?
As Martin Fowler says, it means different things to different people. His article on the topic is pretty good although it isn't quite a definition.
http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
It may explain, the difficulty coming up with a concrete definition.
Wikipedia: "A SOA is a software architecture that uses loosely coupled software services to support the requirements of business processes and software users. Resources on a network in an SOA enviroment are made available as independent services that can be accessed without knowledge of their underlying platform implementation."
SOA is not that new, but it has potential to achieve some amazing things. But the organization has to be ready for it: the business has to think in processes and that's the big problem
I'd go with:
Defining a series of stateless, client
agnostic business operations created
to be leveraged in multiple
applications.
An SOA design includes components (i.e., services) that can be used by code regardless of implementation (i.e., any OS or langauge). A single instance of a service may also be used by multiple applications, whereas, e.g., a DLL would have to be duplicated for each app and require the same implementation technology as the linking application.
Services in an SOA design are usually implemented as interoperable web services.
There isn't an official definition as Ryan mentioned eariler. However, I find Thomas Erl's view of the whole service-orientation quite well-structured and relevant. Here is the definition of SOA from his SOA Glossary (more):
Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the overall burden of IT on an organization.
Thomas Erl is the author of many SOA titles most of them receiving endorsement from SOA vendors including IBM, Oracle, and Microsoft. The nice thing about his books is that they are as SOA vendor independent as possible. It means you learn more about service-orientation itself and less about some vendor's middleware that supports SOA.
I agree with all of the people that point you to Fowler on this. Basically it runs like this: service oriented architecture got a reputation as being good, so anything that people want to be associated with good they call SOA. In reality it has a lot of downsides and can create a Service Oriented Gridlock or Dependency Oriented Architecture.
Here's my go at a definition:
Service Oriented Architecture is a systems integration and code reuse approach where applications are dependent on connecting to services provided by other running applications across the network. This is distinct from component architectures, where software components are shared statically between applications in the form of libraries or SDKs, for example.
A clarification here - "Service Oriented Architecture is a systems integration and code reuse approach where applications are dependent on connecting to services provided by other running applications across the network."
I have a scenario where two j2ee applications have been integrated using event driven messaging. Here the above phrases of systems integration and connecting to services provided by other running applications across the network hold good. Can i call this SOA ?
The following principles would hold good here
1) statelessness
2) message oriented - loosely coupled infact de-coupled
3) extensible.
However, the following do not apply
1) platform independence - neither of the applications being integrated has been designed to work in a different platform.
2) The applications are plain j2ee applications which have not been designed with all soa concepts.
I attempted to define SOA in one of my blog posts. Here's an excerpt...
For years it's been standard practice to separate functionality into functions, classes, and modules. The idea has always been that these smaller, highly specialized components are easier to share and maintain than monolithic blocks of code.
Functionally, SOA is not much different. The goals are the same - reusability and easy maintenance. The biggest difference - in the case of a web service SOA - is that the shared library included in your application is replaced with an HTTP call.
Here's a definition for you:
SOA - Software Over Architected. The inclusion of pointless, over-bloated, functional interface framework called an architecture in a pretty web site with a 3d graphic folder flying from one side to the other where "dir /s > a.txt | ftp -s:upload.ftp" did the job.
Software components are not bricks, cannot be generalised by common functional patterns and architecture emerges in the enterprise from good practice, not good design. Software isn't architected, it's engineered.
SCRUM ON!
Related
What is "Clean Architecture" in .NET ? What doesn't qualify as "Clean Architecture" ?
Are CQRS, DDD mandatory for "Clean Architecture" ?
What is onion architecture ?
Please clarify ... I am actually lost with "Clean Architecture".
Since the question is too broad, I try to answer it on a high level.
What is "Clean Architecture" in .NET ?
In short: "The same as in every other language". Architecture is mainly about managing dependencies, because dependencies are the main problem when it comes to code smells like fragility, rigidity and immobility. It is also often called the structure of the system and I can structure .NET application the same way as Java, JavaScript or even C++ applications. The concepts of repositories, use cases (interactors), entities and so on stay the same, even though their implementation differ based on the language features.
What doesn't qualify as "Clean Architecture" ?
I would say each architecture that breaks the main rule of separating the business value from technical details. That's the core of the clean architecture - to make the business rules technology agnostic with the goal to make them easy to test.
So whenever you have a system structure that needs to boot up a complex framework, a web server or a database (that must be initialized with ddl and dml) just to test your business rules, you don't have a clean architecture.
Are CQRS, DDD mandatory for "Clean Architecture" ?
No, these concept usually fit very well with the clean architecture, but they are concepts that the clean architecture does not require. E.g. you can implement your domain logic as an anemic model and still be clean architecture compliant. But I think it would be a better idea to use DDD or at least a kind of rich domain model.
What is onion architecture ?
The onion architecture is an architecture that was introduced by Jeffrey Palermo. He also wants to decouple the business rules from the technology details. Jeffrey Palermo says:
Hexagonal architecture and Onion Architecture share the following premise: Externalize infrastructure and write adapter code so that the infrastructure does not become tightly coupled.
and he says:
The database is not the center. It is external.
Thus the clean archtitecture and the onion architecture have a lot in common. That is not a big suprise, because Robert C. Martin says in his The Clean Architecture blog:
Over the last several years we’ve seen a whole range of ideas regarding the architecture of systems. These include:
Hexagonal Architecture (a.k.a. Ports and Adapters) by Alistair Cockburn and adopted by Steve Freeman, and Nat Pryce in their wonderful book Growing Object Oriented Software
Onion Architecture by Jeffrey Palermo
Screaming Architecture from a blog of mine last year
DCI from James Coplien, and Trygve Reenskaug.
BCE by Ivar Jacobson from his book Object Oriented Software Engineering: A Use-Case Driven Approach
Though these architectures all vary somewhat in their details, they are very similar.
Thus the clean architecture is a consoidation of other architectures that is enhanced with ideas from Robert C. Martin.
I hope my answer helps you to classify the different terms.
We've been having a discussion at work over how widely used SOA is. We've been building our businesses processes using SOA for a few months now with varying degrees of success and the question came up about how widely used this architecture is. My manager believes that "most" of the big companies are using SOA and it is gaining steam among the industry, is cutting edge technology and everybody will doing it shortly. I argued that it seemed to be the new buzzword about 2-3 years ago and was never widely adopted.
Does anybody feel strongly one way or another?
Thanks.
SOA is an easy, standard way to write web services that other middleware (and user-space code) can use. If you need to integrate existing code/services with web clients or other middleware clients, its a good thing to consider.
You didn't mention much about what you're trying to accomplish or what technologies you need to integrate, but I have written Oracle SOA web services that are consumed by Android in the mobile sphere, Spring in the web sphere, and other Oracle SOA clients in the enterprise sphere.
All depends on what you're looking to do, but SOA is more of a concept - and a borderline standard for integration architecture, that presupposes any particular implementation.
As a modern large company, is one ERP system better than hundreds of highly specialized applications which are service oriented? To provide a little bit of background, we are providing consulting for a client who wants to invest their resources in a monolithic ERP system which will manage everything! What are the pro's and con's of this approach?
As an application developer, I tend to believe that specialized well written and managed software packages tied together by a service architecture would out perform a monolithic approach.
What do you think?
As an application developer, I tend to
believe that specialized well written
and managed software packages tied
together by a service architecture
would out perform a monolithic
approach.
Maybe, but getting support for one system from one party is easier than getting support from multiple parties and making sure that integration works and keeps on working.
I think a more important question is whether to pick a general ERP or a custom fitted one. Whether the architecture is service oriented or monolithic is maybe is related, but also general ERP systems can be service oriented.
This almost feels like a traditional question on buy vs. build. I will try to lay out
some importan points.
If you clients has deep pockets only then can they viably maintain the high total
cost of ownership and complexity associated with developing and
maintaining custom-designed applications.
Off-the-shelf ERP solutions integrate the best business practices from a variety of
industries and incorporate these best business practices into your
client's operations which ultimately translates into bottom-line improvements.
Custom-designed applications provide the desired degree of functionality,
but their size and complexity require lengthy design, development, and
implementation efforts.
A good example that I can think of is Microsoft. Microsoft spent 10 months and $25 million installing SAP R/3 to replace a
tangle of 33 financial-tracking systems in 26 subsidiaries. As a result of the
implementation, Microsoft estimates annual savings at $18 million,
leading Bill Gates to call SAP "an incredible success story."
Hope this helps you think more broadly from all angles.
One of the stated goals of the PureMVC framework is to avoid platform dependencies in order to be portable. Considering that because of language and API differences application code will always be heavily dependent on the platform, and that avoiding platform dependencies makes the framework reinvent the wheel and/or only provide a least-common-denominator feature set, in what way does the portability of the framework benefit me as an application developer?
I've worked with PureMVC. They're trying to implement their stuff in quite a lot of languages. You may be right about the least common denominator, but overall, it's not a bad framework, and I've seen a really nice AS3 app in PureMVC.
I don't think they're talking about portability in terms of porting actual code. The idea there is more that you're using a generalized MVC architecture, which you could apply to other projects and other languages.
They're trying to say that if you become familiar with the PureMVC pattern, you could potentially come into a new PureMVC codebase, even if it's another language, and you would already know the lay of the land.
You might also say that developers who develop good PureMVC skills are likely to develop good habits which will translate as they go from language to language. But then again, maybe not.. for the reasons you mentioned.
We've been using PureMVC on two projects now and in my opinion the attempted language-independence is quite a burden.
The promise of jumping straight in a project because the framework is already know does not seem relevant to me if the languages are not already pretty similar (C# to java would make sense, as3 to php not) -- I agree that it is useful to have known ways of solving things, but for that the 'plain' patterns are good enough.
However, I also don't really agree with the usage of the various patterns the project uses, so our choice to not use it on the next project might be related to both issues, and not just the attempt at language/platform independence.
PureMVC's portability will help you when you migrate to or reimplement in another language.
I can't count the number of platforms and languages I've written code for that are now extinct and for which, even if I still had the source code it would be mostly worthless and have to be rewritten from the ground up today, since the code was usually 100% platform specific.
But all application code need not be heavily dependent upon the platform. View components and services (the boundaries of your application) will necessarily be, but your application logic which is sandwiched between the boundaries need not be.
The scope of PureMVC is really quite narrow; merely to help you split your code into the three tiers proscribed by the MVC meta-pattern. There is no reason why this code has to be tied deeply to your platform in order to be optimal.
When it comes time to migrate, you'll appreciate that the framework actors and their roles, responsibilities and collaborations remain the same. This leaves you to deal with syntactic differences of the language, recreating the view components and services. At least you won't have to completely re-architect.
And for the case of reimplementing in a different language, imagine you're trying to capture a significant part of the mobile market with your app. The market is so fractured, you'll have to implement the same program on 2 or more of Windows Mobile, iPhone, Flash, and Java. Sure you'll probably have separate teams in charge of the apps, but why have a totally different architecture? With PureMVC, you could have a single architecture for all versions of your application.
-=Cliff>
PureMVC is the only real option for Flash Platform developers who choose not to use the Flex Framework. For certain projects the size cost of Flex is too expensive (it happens!).
I like to prototype in Flex and then rip it out and replace my views with custom components when the application is near completion. PureMVC makes this really easy to do with it's Mediator pattern. I'm not sure there is any other framework that would allow me this workflow.
Personally, I think PureMVC went too far with it's portability goals: I enjoy that fact that it works with Flash AND Flex (for the reasons mentioned above), but feel that it should have stopped there, and made use of the native Flash Player event architecture.
Are there examples of people using PureMVC to build and port applications across multiple platforms?
My company is building a Flex application that we may need to port to other platforms:
Silverlight (likely)
Mobile (maybe)
Desktop (maybe -- not just AIR!)
TV sets (maybe eventually)
I am considering PureMVC as a framework if it can ease porting and maintenance. I am curious to know if other people have ported a PureMVC app to a different platform and what their experience was with porting and then having development proceed in parallel for the app on multiple platforms.
Cheers,
Karthik
PureMVC does not rely on a platform for its internal workings (Flash Events etc).
So, while it does not make porting any easier per-say, it can assist simply by showing us its friendly and familiar face wherever we may choose to go ;-)
Can somebody provide real world examples of software products or applications (commercial or open source) that have SOA in them?
Like for example some X company claiming that the latest released version of their software product is now SOA compatible.
SOA is not a specification that a software product could be claimed to be SOA compatible. Read more on what SOA is at http://en.wikipedia.org/wiki/Service-oriented_architecture
SOA is basically an architecture/implementation technique which aims towards loose-coupling of the presentation layer with the data layer. Thus, multiple services/modules/applications could access the same data and use it as per their need. This loose-coupling can lead to more of distributed programming. The day you see that a particular service is more in demand, you could add nodes to your cluster for the particular service.
Examples per se would be applications that were build with SOA architecture. Liferay (an open source Java CMS) is a service-based application. All application that expose some sort of an API (see programmableweb.com) can be termed as SOA-enabled where in you pull data and consume it the way you want.
But yes, for sure, SOA is not a specification.