Service-oriented architecture - Wikipedia

Service-oriented architecture - Wikipedia
Jump to content
From Wikipedia, the free encyclopedia
Architectural pattern in software design
In
software engineering
service-oriented architecture
SOA
) is an architectural style that focuses on discrete services instead of a
monolithic design
SOA is a good choice for
system integration
By consequence, it is also applied in the field of
software design
where services are provided to the other components by
application components
, through a
communication protocol
over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.
Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
A service has four properties according to one of many definitions of SOA:
It logically represents a repeatable business activity with a specified outcome.
It is self-contained.
It is a
black box
for its consumers, meaning the consumer does not have to be aware of the service's inner workings.
It may be composed of other services.
Different services can be used in conjunction as a
service mesh
to provide the functionality of a large
software application
a principle SOA shares with
modular programming
. Service-oriented architecture integrates distributed, separately maintained and deployed software components. It is enabled by technologies and standards that facilitate components' communication and cooperation over a network, especially over an IP network.
SOA is related to the idea of an API (
application programming interface
), an interface or communication protocol between different parts of a computer program intended to simplify the implementation and maintenance of software. An API can be thought of as the service, and the SOA the architecture that allows the service to operate.
Note that Service-Oriented Architecture must not be confused with Service Based Architecture as those are two different architectural styles.
Overview
edit
In SOA, services use protocols that describe how they
pass
and parse messages using description
metadata
. This metadata describes both the functional characteristics of the service and quality-of-service characteristics. Service-oriented architecture aims to allow users to combine large chunks of functionality to form applications which are built purely from existing services and combining them in an ad hoc manner. A service presents a simple interface to the requester that abstracts away the underlying complexity acting as a black box. Further users can also access these independent services without any knowledge of their internal implementation.
Defining concepts
edit
The related buzzword
service-orientation
promotes
loose coupling
between services. SOA separates functions into distinct units, or services,
which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.
10
SOA can be seen as part of the continuum which ranges from the older concept of
distributed computing
11
and
modular programming
, through SOA, and on to practices of
mashups
SaaS
, and
cloud computing
(which some see as the offspring of SOA).
12
Principles
edit
This article
is in
list
format but may read better as
prose
You can help by
converting this article
, if appropriate.
Editing help
is available.
July 2024
There are no industry standards relating to the exact composition of a service-oriented architecture, although many industry sources have published their own principles. Some of these
13
14
15
include the following:
Standardized service contract
16
Services adhere to a standard communications agreement, as defined collectively by one or more
service description
documents within a given set of services.
Service reference autonomy (an aspect of loose coupling)
The relationship between services is minimized to the level that they are only aware of their existence.
Service location transparency (an aspect of loose coupling)
Services can be called from anywhere within the network that it is located no matter where it is present.
Service longevity
Services should be designed to be long lived. Where possible, services should avoid forcing consumers to change if they do not require new features; if you call a service today, you should be able to call the same service tomorrow.
Service abstraction
The services act as black boxes, that is their inner logic is hidden from the consumers.
Service autonomy
Services are independent and control the functionality they encapsulate, from a Design-time and a run-time perspective.
Service statelessness
Services are stateless, that is either return the requested value or give an exception hence minimizing resource use.
Service granularity
A principle to ensure services have an adequate size and scope. The functionality provided by the service to the user must be relevant.
Service normalization
Services are decomposed or consolidated (normalized) to minimize redundancy. In some, this may not be done. These are the cases where performance optimization, access, and aggregation are required.
17
Service composability
Services can be used to compose other services.
Service discovery
Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
Service reusability
Logic is divided into various services, to promote reuse of code.
Service
encapsulation
Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.
Patterns
edit
Each SOA building block can play any of the three roles:
Service provider
It creates a web service and provides its information to the service registry. Each provider debates upon a lot of hows and whys like which service to expose, which to give more importance: security or easy availability, what price to offer the service for and many more
The provider also has to decide what category the service should be listed in for a given broker service
18
and what sort of trading partner agreements are required to use the service.
Service broker, service registry or service repository
Its main functionality is to make information regarding the web service available to any potential requester. Whoever implements the broker decides the scope of the broker. Public brokers are available anywhere and everywhere but private brokers are only available to a limited amount of public.
UDDI
was an early, no longer actively supported attempt to provide
Web services discovery
Service requester/consumer
It locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its web services. Whichever service the service-consumers need, they have to take it into the brokers, bind it with respective service and then use it. They can access multiple services if the service provides multiple services.
The service consumer–provider relationship is governed by a
standardized service contract
19
which has a business part, a functional part and a technical part.
Service composition patterns
have two broad, high-level architectural styles:
choreography and orchestration
. Lower level enterprise integration patterns that are not bound to a particular architectural style continue to be relevant and eligible in SOA design.
20
21
22
Implementation approaches
edit
Service-oriented architecture can be implemented with
web services
or
Microservices
23
This is done to make the functional building-blocks accessible over standard Internet protocols that are independent of platforms and programming languages. These services can represent either new applications or just wrappers around existing legacy systems to make them network-enabled.
24
Implementers commonly build SOAs using web services standards. One example is
SOAP
, which has gained broad industry acceptance after the recommendation of Version 1.2 from the W3C
25
(World Wide Web Consortium) in 2003. These standards (also referred to as
web service specifications
) also provide greater interoperability and some protection from lock-in to proprietary vendor software. One can, however, also implement SOA using any other service-based technology, such as
Jini
CORBA
Internet Communications Engine
REST
, or
gRPC
Architectures can operate independently of specific technologies and can therefore be implemented using a wide range of technologies, including:
Web services
based on WSDL and
SOAP
Messaging, e.g., with ActiveMQ, JMS, RabbitMQ
RESTful HTTP, with
Representational state transfer
(REST) constituting its own constraints-based architectural style
Data Distribution Service
(DDS)
OPC-UA
Internet Communications Engine
WCF
(Microsoft's implementation of Web services, forming a part of WCF)
Apache Thrift
gRPC
SORCER
Implementations can use one or more of these protocols and, for example, might use a file-system mechanism to communicate data following a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks. SOA enables the development of applications that are built by combining loosely coupled and
interoperable
services.
These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition
hides the implementation
of the language-specific service. SOA-based systems can therefore function independently of development technologies and platforms (such as Java, .NET, etc.). Services written in C# running on .NET platforms and services written in Java running on
Java EE
platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as web services that facilitate reuse. Managed environments can also wrap COBOL legacy systems and present them as software services.
26
High-level programming languages
such as
BPEL
and specifications such as
WS-CDL
and
WS-Coordination
extend the service concept by providing a method of defining and supporting orchestration of fine-grained services into more coarse-grained business services, which architects can in turn incorporate into workflows and business processes implemented in
composite applications
or
portals
Service-oriented modeling
is an SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented assets. The
Service-oriented modeling framework (SOMF)
offers a modeling language and a work structure or "map" depicting the various components that contribute to a successful service-oriented modeling approach. It illustrates the major elements that identify the "what to do" aspects of a service development scheme. The model enables practitioners to craft a
project plan
and to identify the milestones of a service-oriented initiative. SOMF also provides a common modeling notation to address alignment between business and IT organizations.
Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama
27
SOA meta-model, The Linthicum Group, 2007
Organizational benefits
edit
Some
enterprise architects
believe that SOA can help businesses respond more quickly and more cost-effectively to changing market conditions.
28
This style of
architecture
promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to—and usage of—existing IT (legacy) assets.
With SOA, the idea is that an organization can look at a problem holistically. A business has more overall control. Theoretically there would not be a mass of developers using whatever tool sets might please them. But rather they would be coding to a standard that is set within the business. They can also develop enterprise-wide SOA that encapsulates a business-oriented infrastructure. SOA has also been illustrated as a highway system providing efficiency for car drivers. The point being that if everyone had a car, but there was no highway anywhere, things would be limited and disorganized, in any attempt to get anywhere quickly or efficiently. IBM Vice President of Web Services Michael Liebow says that SOA "builds highways".
29
In some respects, SOA could be regarded as an architectural evolution rather than as a revolution. It captures many of the
best practices
of previous software architectures. In communications systems, for example, little development of solutions that use truly static bindings to talk to other equipment in the network has taken place. By embracing a SOA approach, such systems can position themselves to stress the importance of well-defined, highly inter-operable interfaces. Other predecessors of SOA include
Component-based software engineering
and Object-Oriented Analysis and Design (OOAD) of remote objects, for instance, in
CORBA
A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of "nano-enterprises" that are easy to produce and improve. Also services can be "mega-corporations" constructed as the coordinated work of subordinate services.
Reasons for treating the implementation of services as separate projects from larger projects include:
Separation promotes the concept to the business that services can be delivered quickly and independently from the larger and slower-moving projects common in the organization. The business starts understanding systems and simplified user interfaces calling on services. This advocates
agility
. That is to say, it fosters business innovations and speeds up time-to-market.
30
Separation promotes the decoupling of services from consuming projects. This encourages good design insofar as the service is designed without knowing who its consumers are.
Documentation and test artifacts of the service are not embedded within the detail of the larger project. This is important when the service needs to be reused later.
SOA promises to simplify testing indirectly. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation. If an organization possesses appropriately defined test data, then a corresponding stub is built that reacts to the test data when a service is being built. A full set of regression tests, scripts, data, and responses is also captured for the service. The service can be tested as a 'black box' using existing stubs corresponding to the services it calls. Test environments can be constructed where the primitive and out-of-scope services are stubs, while the remainder of the mesh is test deployments of full services. As each interface is fully documented with its own full set of regression test documentation, it becomes simple to identify problems in test services. Testing evolves to merely validate that the test service operates according to its documentation, and finds gaps in documentation and test cases of all services within the environment. Managing the data state of
idempotent
services is the only complexity.
Examples may prove useful to aid in documenting a service to the level where it becomes useful. The documentation of some APIs within the Java Community Process provide good examples. As these are exhaustive, staff would typically use only important subsets. The 'ossjsa.pdf' file within
JSR-89
exemplifies such a file.
31
Criticism
edit
SOA has been conflated with
Web services
32
however, Web services are only one option to implement the patterns that comprise the SOA style. In the absence of native or binary forms of remote procedure call (RPC), applications could run more slowly and require more processing power, increasing costs. Most implementations do incur these overheads, but SOA can be implemented using technologies (for example,
Java Business Integration
(JBI),
Windows Communication Foundation
(WCF) and
data distribution service
(DDS)) that do not depend on remote procedure calls or translation through XML or JSON. At the same time, emerging open-source XML parsing technologies (such as
VTD-XML
) and various XML-compatible binary formats promise to significantly improve SOA performance.
33
34
35
Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. This constraint has the drawback that it could reduce the overall
scalability
of the service provider if the service-provider needs to retain the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult.
36
Ultimately, some critics feel that SOA services are still too constrained by applications they represent.
37
A primary challenge faced by service-oriented architecture is managing of metadata. Environments based on SOA include many services which communicate among each other to perform tasks. Because the design may involve multiple services working in conjunction, an Application may generate millions of messages. Further services may belong to different organizations or even competing firms creating a huge trust issue. Thus SOA governance comes into the scheme of things.
38
Another major problem faced by SOA is the lack of a uniform testing framework. There are no tools that provide the required features for testing these services in a service-oriented architecture. The major causes of difficulty are:
39
Heterogeneity and complexity of solution.
Huge set of testing combinations due to integration of autonomous services.
Inclusion of services from different and competing vendors.
Platform
is continuously changing due to availability of new features and services.
Extensions and variants
edit
Event-driven architecture
edit
Main article:
Event-driven architecture
Application programming interfaces
edit
Main article:
Application programming interfaces
Application programming interfaces (APIs) are the frameworks through which developers can interact with a web application.
Web 2.0
edit
Tim O'Reilly
coined the term "
Web 2.0
" to describe a perceived, quickly growing set of web-based applications.
40
A topic that has experienced extensive coverage involves the relationship between Web 2.0 and service-oriented architectures.
which?
SOA is the philosophy of encapsulating application logic in services with a uniformly defined interface and making these publicly available via discovery mechanisms. The notion of complexity-hiding and reuse, but also the concept of loosely coupling services has inspired researchers to elaborate on similarities between the two philosophies, SOA and Web 2.0, and their respective applications. Some argue Web 2.0 and SOA have significantly different elements and thus can not be regarded "parallel philosophies", whereas others consider the two concepts as complementary and regard Web 2.0 as the global SOA.
41
The philosophies of Web 2.0 and SOA serve different user needs and thus expose differences with respect to the design and also the technologies used in real-world applications. However, as of 2008
[update]
, use-cases demonstrated the potential of combining technologies and principles of both Web 2.0 and SOA.
41
Microservices
edit
Main article:
Microservices
Microservices are a modern interpretation of service-oriented architectures used to build
distributed software systems
. Services in a microservice architecture
42
are
processes
that communicate with each other over the
network
in order to fulfill a goal. These services use technology agnostic
protocols
43
which aid in encapsulating choice of language and frameworks, making their choice a concern internal to the service. Microservices are a new realisation and implementation approach to SOA, which have become popular since 2014 (and after the introduction of
DevOps
), and which also emphasize continuous deployment and other agile practices.
44
There is no single commonly agreed definition of microservices. The following characteristics and principles can be found in the literature:
fine-grained interfaces (to independently deployable services),
business-driven development (e.g.
domain-driven design
),
IDEAL cloud application architectures,
polyglot programming and persistence,
lightweight container deployment,
decentralized continuous delivery, and
DevOps with holistic service monitoring.
Service-oriented architectures for interactive applications
edit
Interactive applications requiring real-time response times, for example low-latency interactive 3d applications, are using specific service oriented architectures addressing the specific needs of such kind of applications. These include for example low-latency optimized distributed computation and communication as well as resource and instance management.
45
46
47
See also
edit
Application programming interface
Loose coupling
OASIS SOA Reference Model
Service granularity principle
SOA governance
Software architecture
Service-oriented communications
(SOC)
Service-oriented development of applications
Service-oriented distributed applications
Web Application Description Language
References
edit
"SOA Source Book - What Is SOA?"
collaboration.opengroup.org
. Retrieved
March 30,
2021
Fundamentals of Software Architecture: An Engineering Approach
. O'Reilly Media. 2020.
ISBN
978-1492043454
"Chapter 1: Service Oriented Architecture (SOA)"
msdn.microsoft.com
. Archived from
the original
on July 7, 2017
. Retrieved
September 21,
2016
"Service-Oriented Architecture Standards - The Open Group"
www.opengroup.org
"What Is SOA?"
www.opengroup.org
. Archived from
the original
on August 19, 2016
. Retrieved
September 21,
2016
Velte, Anthony T. (2010).
Cloud Computing: A Practical Approach
. McGraw Hill.
ISBN
978-0-07-162694-1
Fundamentals of Software Architecture: An Engineering Approach
. O'Reilly Media. 2020.
ISBN
978-1492043454
"Migrating to a service-oriented architecture, Part 1"
. December 9, 2008. Archived from the original on December 9, 2008
. Retrieved
September 21,
2016
{{
cite web
}}
: CS1 maint: bot: original URL status unknown (
link
Michael Bell (2008). "Introduction to Service-Oriented Modeling".
Service-Oriented Modeling: Service Analysis, Design, and Architecture
. Wiley & Sons. p.
ISBN
978-0-470-14111-3
Michael Bell (2010).
SOA Modeling Patterns for Service-Oriented Discovery and Analysis
. Wiley & Sons. p.
390
ISBN
978-0-470-48197-4
Thomas Erl (June 2005).
About the Principles
. Serviceorientation.org
"Application Platform Strategies Blog: SOA is Dead; Long Live Services"
. Apsblog.burtongroup.com. January 5, 2009. Archived from
the original
on January 15, 2009
. Retrieved
August 13,
2012
Yvonne Balzer
Improve your SOA project plans
IBM
, July 16, 2004
Microsoft Windows Communication Foundation team (2012).
"Principles of Service Oriented Design"
msdn.microsoft.com
. Retrieved
September 3,
2012
Principles by
Thomas Erl
of SOA Systems Inc.
eight specific service-orientation principles
"4.4 Guidelines for Using Web Service Contract Technologies - Anatomy of a Web Service Contract"
InformIT
. June 11, 2021
. Retrieved
September 9,
2021
Tony Shan (2004). "Building a service-oriented eBanking platform".
IEEE International Conference on Services Computing, 2004. (SCC 2004). Proceedings. 2004
. pp.
237–
244.
doi
10.1109/SCC.2004.1358011
ISBN
978-0-7695-2225-8
S2CID
13156128
2004
Duan, Yucong; Narendra, Nanjangud; Du, Wencai; Wang, Yongzhi; Zhou, Nianjun (2014). "Exploring Cloud Service Brokering from an Interface Perspective".
2014 IEEE International Conference on Web Services
IEEE
. pp.
329–
336.
doi
10.1109/ICWS.2014.55
ISBN
978-1-4799-5054-6
S2CID
17957063
Duan, Yucong (2012). "A Survey on Service Contract".
2012 13th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing
IEEE
. pp.
805–
810.
doi
10.1109/SNPD.2012.22
ISBN
978-1-4673-2120-4
S2CID
1837914
Olaf Zimmermann, Cesare Pautasso, Gregor Hohpe, Bobby Woolf (2016).
"A Decade of Enterprise Integration Patterns"
IEEE Software
33
(1):
13–
19.
doi
10.1109/MS.2016.11
{{
cite journal
}}
: CS1 maint: multiple names: authors list (
link
Rotem-Gal-Oz, Arnon (2012).
SOA Patterns
. Manning Publications.
ISBN
978-1933988269
Julisch, Klaus; Suter, Christophe; Woitalla, Thomas; Zimmermann, Olaf (2011).
"Compliance by design – Bridging the chasm between auditors and IT architects"
(PDF)
Computers & Security
30
6–
7):
410–
426.
CiteSeerX
10.1.1.390.3652
doi
10.1016/j.cose.2011.03.005
Brandner, M., Craes, M., Oellermann, F., Zimmermann, O., Web Services-Oriented Architecture in Production in the Finance Industry, Informatik-Spektrum 02/2004, Springer-Verlag, 2004
"www.ibm.com"
IBM
. Retrieved
September 10,
2016
"SOAP Version 1.2 の公開について (W3C 勧告)"
(in Japanese). W3.org. June 24, 2003
. Retrieved
August 13,
2012
Okishima, Haruhiru (2006).
". "Case Study of System Architecture that use COBOL assets"
(PDF)
Enterprise SOA
. Prentice Hall, 2005
Christopher Koch
A New Blueprint For The Enterprise
Archived
January 16, 2009, at the
Wayback Machine
CIO Magazine
, March 1, 2005
Elizabeth Millard (January 2005). "Building a Better Process".
Computer User
. Page 20.
Brayan Zimmerli (November 11, 2009)
Business Benefits of SOA
University of Applied Science of Northwestern Switzerland, School of Business
"JSR-000089 OSS Service Activation API Specification 1.0 Final Release"
. July 26, 2011. Archived from
the original
on July 26, 2011
. Retrieved
May 18,
2024
Joe McKendrick.
"Bray: SOA too complex; 'just vendor BS'
. ZDNet.
Jimmy Zhang (February 20, 2008)
"Index XML Documents with VTD-XML"
Archived
July 4, 2008, at the
Wayback Machine
XML Journal
Jimmy Zhang (August 5, 2008)
"i-Technology Viewpoint: The Performance Woe of Binary XML"
Archived
January 9, 2020, at the
Wayback Machine
Microservices Journal
Jimmy Zhang (January 9, 2008)
"Manipulate XML Content the Ximple Way"
Archived
July 30, 2017, at the
Wayback Machine
devx.com
"The Reason SOA Isn't Delivering Sustainable Software"
. jpmorgenthal.com. June 19, 2009
. Retrieved
June 27,
2009
"SOA services still too constrained by applications they represent"
ZDNet
. June 27, 2009
. Retrieved
June 27,
2009
"Governance Layer"
www.opengroup.org
. Archived from
the original
on June 4, 2016
. Retrieved
September 22,
2016
"How to Efficiently Test Service Oriented Architecture | WSO2 Inc"
wso2.com
. Retrieved
September 22,
2016
"What Is Web 2.0"
. Tim O'Reilly. September 30, 2005
. Retrieved
June 10,
2008
Christoph Schroth; Till Janner (2007).
"Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services"
IT Professional
(3):
36–
41.
Bibcode
2007ITPro...9c..36S
doi
10.1109/MITP.2007.60
S2CID
2859262
. Archived from
the original
on December 3, 2013
. Retrieved
February 23,
2008
Dragoni, Nicola; Giallorenzo, Saverio; Alberto Lluch Lafuente; Mazzara, Manuel; Montesi, Fabrizio; Mustafin, Ruslan; Safina, Larisa (2016). "Microservices: yesterday, today, and tomorrow".
arXiv
1606.04036v1
cs.SE
].
James Lewis and Martin Fowler.
"Microservices"
Balalaie, A.; Heydarnoori, A.; Jamshidi, P. (May 1, 2016).
"Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture"
(PDF)
IEEE Software
33
(3):
42–
52.
Bibcode
2016ISoft..33c..42B
doi
10.1109/MS.2016.64
hdl
10044/1/40557
ISSN
0740-7459
S2CID
18802650
Frank Glinka; Allaithy Raed (2009).
"A Service-Oriented Interface for Highly Interactive Distributed Applications"
European Conference on Parallel Processing
. Lecture Notes in Computer Science. Vol. 6043. pp.
266–
277.
doi
10.1007/978-3-642-14122-5_31
ISBN
978-3-642-14121-8
. Retrieved
February 9,
2021
Dieter Hildebrandt; Jan Klimke (2011).
"Service-oriented interactive 3D visualization of massive 3D city models on thin clients"
COM.Geo '11: Proceedings of the 2nd International Conference on Computing for Geospatial Research & Applications
. p. 1.
doi
10.1145/1999320.1999326
ISBN
9781450306812
S2CID
53246415
. Retrieved
February 9,
2021
Mahy Aly; Michael Franke (2016).
"Service Oriented Interactive Media (SOIM) Engines Enabled by Optimized Resource Sharing"
2016 IEEE Symposium on Service-Oriented System Engineering (SOSE)
. pp.
231–
237.
doi
10.1109/SOSE.2016.47
hdl
1854/LU-7215326
ISBN
978-1-5090-2253-3
S2CID
9511734
. Retrieved
February 9,
2021
Mauro, Christian; Leimeister, Jan Marco; Krcmar, Helmut (January 2010).
"Service Oriented Device Integration - an Analysis of SOA Design Patterns"
(PDF)
2010 43rd Hawaii International Conference on System Sciences
. pp.
1–
10.
doi
10.1109/HICSS.2010.336
ISBN
978-1-4244-5509-6
S2CID
457705
. Archived from
the original
(PDF)
on January 24, 2022
. Retrieved
September 21,
2021
Wikimedia Commons has media related to
Service-oriented architecture
Listen to this article
54
minutes
This audio file
was created from a revision of this article dated 27 October 2011
2011-10-27
, and does not reflect subsequent edits.
Audio help
More spoken articles
Software engineering
Fields
Computer programming
DevOps
Empirical software engineering
Experimental software engineering
Formal methods
Requirements engineering
Search-based software engineering
Site reliability engineering
Social software engineering
Software deployment
Software design
Software maintenance
Software testing
Systems analysis
Concepts
Abstraction
CI/CD
Compatibility
Backward compatibility
Compatibility layer
Compatibility mode
Forward compatibility
Software incompatibility
Component-based software engineering
Data modeling
Enterprise architecture
Functional specification
Modeling language
Programming paradigm
Software
Software archaeology
Software architecture
Software configuration management
Software development process/methodology
Software quality
Software quality assurance
Software system
Software verification and validation
Structured analysis
Essential analysis
Orientations
Agile
Aspect-oriented
Object orientation
Ontology
SDLC
Service orientation
Models
Developmental
Agile
EUP
Executable UML
Incremental model
Iterative model
Prototype model
RAD
Scrum
Spiral model
UP
V-model
Waterfall model
XP
Model-driven engineering
Round-trip engineering
Other
CMMI
Data model
ER model
Function model
Information model
Metamodeling
Object model
SPICE
Systems model
View model
Languages
IDEF
SysML
UML
USL
Related fields
Computer engineering
Computer science
Information science
Project management
Risk management
Systems engineering
Category
Commons
Authority control databases
International
GND
National
United States
Israel
Other
Yale LUX
Retrieved from "
Categories
Software design patterns
Architectural pattern (computer science)
Enterprise application integration
Service-oriented (business computing)
Web services
Hidden categories:
CS1 maint: bot: original URL status unknown
CS1 maint: multiple names: authors list
CS1 Japanese-language sources (ja)
Webarchive template wayback links
Articles with short description
Short description matches Wikidata
Use mdy dates from April 2015
Articles needing cleanup from July 2024
All pages needing cleanup
Articles with sections that need to be turned into prose from July 2024
All articles with specifically marked weasel-worded phrases
Articles with specifically marked weasel-worded phrases from October 2016
Articles containing potentially dated statements from 2008
All articles containing potentially dated statements
Commons category link from Wikidata
Articles with hAudio microformats
Spoken articles
Articles prone to spam from December 2018
Service-oriented architecture
Add topic