service a serviceoriented architecture soa is a style of software design where services are provided to the other components by application components through a communication protocol over a network the basic principles of serviceoriented architecture are independent of vendors products and technologies 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 a service has four properties according to one of many definitions of soa it logically represents a business activity with a specified outcome it is selfcontained it is a black box for its consumers it may consist of other underlying services different services can be used in conjunction to provide the functionality of a large software application a principle it shares with modular programming serviceoriented architecture integrates distributed separatelymaintained and deployed software components it is enabled by technologies and standards that make it easier for components to communicate and cooperate over a network especially an ip network overview 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 qualityofservice characteristics serviceoriented 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 the related buzzword serviceorientation promotes loose coupling between services soa separates functions into distinct units or services a manifesto was published for serviceoriented architecture in october 2009 this came up with six core values which are listed as follows business value is given more importance than technical strategy strategic goals are given more importance than projectspecific benefits intrinsic interoperability is given more importance than custom integration shared services are given more importance than specificpurpose implementations flexibility is given more importance than optimization evolutionary refinement is given more importance than pursuit of initial perfection soa can be seen as part of the continuum which ranges from the older concept of distributed computing principles there are no industry standards relating to the exact composition of a serviceoriented architecture although many industry sources have published their own principles some of these include the following standardized service contract services adhere to a standard communications agreements as defined collectively by one or more servicedescription 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 designtime and a runtime 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 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 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 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 the 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 requesterconsumer 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 serviceconsumers 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 consumerprovider relationship is governed by a standardized service contract which has a business part a functional part and a technical part service composition patterns have two broad highlevel 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 implementation approaches serviceoriented architecture can be implemented with web services implementers commonly build soas using web services standards one example is soap which has gained broad industry acceptance after recommendation of version 12 from the w3c world wide web consortium in 2003 these standards also referred to as web service specifications also provide greater interoperability and some protection from lockin to proprietary vendor software one can however also implement soa using any other servicebased technology such as jini corba or rest 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 eg with activemq jms rabbitmq restful http with representational state transfer rest constituting its own constraintsbased architectural style opcua wcf microsofts implementation of web services forming a part of wcf apache thrift sorcer implementations can use one or more of these protocols and for example might use a filesystem 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 interoperate based on a formal definition or contract eg wsdl that is independent of the underlying platform and programming language the interface definition hides the implementation of the languagespecific service soabased 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 highlevel programming languages such as bpel and specifications such as wscdl and wscoordination extend the service concept by providing a method of defining and supporting orchestration of finegrained services into more coarsegrained business services which architects can in turn incorporate into workflows and business processes implemented in composite applications or portals serviceoriented modeling is an soa framework that identifies the various disciplines that guide soa practitioners to conceptualize analyze design and architect their serviceoriented assets the serviceoriented modeling framework somf offers a modeling language and a work structure or map depicting the various components that contribute to a successful serviceoriented 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 serviceoriented 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 soa metamodel the linthicum group 2007 organizational benefits some enterprise architects believe that soa can help businesses respond more quickly and more costeffectively to changing market conditions this style of architecture promotes reuse at the macro service level rather than micro classes level it can also simplify interconnection toand usage ofexisting 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 enterprisewide soa that encapsulates a businessoriented 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 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 welldefined highly interoperable interfaces other predecessors of soa include componentbased software engineering and objectoriented analysis and design ooad of remote objects for instance in corba a service comprises a standalone unit of functionality available only via a formally defined interface services can be some kind of nanoenterprises that are easy to produce and improve also services can be megacorporations constructed as the coordinated work of subordinate services a mature rollout of soa effectively defines the api of an organization 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 slowermoving 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 timetomarket 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 crosscutting 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 outofscope 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 ossjsapdf file within jsr89 exemplifies such a file criticism soa has been conflated with web services stateful services require both the consumer and the provider to share the same consumerspecific 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 serviceprovider 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 a primary challenge faced by serviceoriented architecture is managing of metadata environments based on soa include many services which communicate among each other to perform tasks due to the fact that 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 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 serviceoriented architecture the major causes of difficulty are 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 see dropsdagstuhlde for additional challenges partial solutions and research roadmap input regarding software service engineering extensions and variants eventdriven architectures eventdriven architecture web 20 tim oreilly coined the term web 20 to describe a perceived quickly growing set of webbased applications 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 complexityhiding and reuse but also the concept of loosely coupling services has inspired researchers to elaborate on similarities between the two philosophies soa and web 20 and their respective applications some argue web 20 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 20 as the global soa the philosophies of web 20 and soa serve different user needs and thus expose differences with respect to the design and also the technologies used in realworld applications however as of 2008 microservices microservices microservices are a modern interpretation of serviceoriented architectures used to build distributed software systems services in a microservice architecture there is no single commonly agreed definition of microservices the following characteristics and principles can be found in the literature finegrained interfaces to independently deployable services businessdriven development eg domaindriven design ideal cloud application architectures polyglot programming and persistence lightweight container deployment decentralized continuous delivery and devops with holistic service monitoring loose coupling oasis soa reference model service granularity principle soa governance software architecture serviceoriented communications soc serviceoriented development of applications serviceoriented distributed applications wikimedia commons has media related to serviceoriented architecture listen to this article infodl this audio file was created from a revision of the article serviceoriented architecture dated 20111027 and does not reflect subsequent edits to the article audio help more spoken articles a guide to creating a successful soa system a comparison of soa standards carried out for ministry of defence united kingdom in 2010 soa in the real world microsoft developer network soa reference architecture from ibm soa practitioners guide part 2 soa reference architecture soa for existing applications a case study keen m et al patterns implementing an soa using an enterprise service bus ibm redbook 2004 web services architecture w3c working group note 11 february 2004 how to implement soa vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons authority control gnd 48410159 