Service oriented architecture (soa)

1. Service oriented architecture(soa)

2. What is SOA ? • a Service-Oriented Architecture is essentially a collection of services. these services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. • Framework in which application components provide services to other components via a communication protocol(Network) • Services can be combined to provide the functionality of a large software (Core Banking System) • SOA makes it easier for a software components on computers connected over a network to cooperate. Every computer can run any number of services, and each service is built in a way that ensures the service can exchange information with any other service in the network without the need to make changes to the underlying program itself.

3. Each services implements at list one action by use of defined protocols that describe how services pass and parse(Analysing) messages. Examples of services include; • Registration • Account Creation • Withdrawals • Deposits • Standing orders • Bank Statements • Mobile Banking • Internet Banking

4. SOA Depends on data and services that are described by metadata that should meet the following criteria; • Be used by other applications without modifying the functional contract of a service. • System Designers can understand and manage with a reasonable expenditure of cost and effort.

5. WEB SERVICES Approach • Web services can implement a service-oriented architecture.they make functional building-blocks accessible over standard internet protocols 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. • Each SOA building block can play one or both of two roles: • Service provider: the service provider creates a web service and possibly publishes its interface and access information to the service registry. Each provider must decide which services to expose, how to make trade-offs between security and easy availability, how to price the services, or (if no charges apply) how/whether to exploit them for other value. 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. It registers what services are available within it, and lists all the potential service recipients. The implementer of the broker then decides the scope of the broker. Public brokers are available through the internet, while private brokers are only accessible to a limited audience, for example, users of a company intranet.. • Service consumer: the service consumer or web service client 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.

6. Principles of soa 1. Explicit boundaries • Everything needed by the service to provide its functionality should be passed to it when it is invoked. All access to the service should be via its publicly exposed interface; no hidden assumptions must be necessary to invoke the service. 2. shared contract and schema, not class • starting from a service description (a contract), both a service consumer and a service provider should have everything they need to consume or provide the service. following the principle of loose coupling, a service provider can not rely on the consumer’s ability to reuse any code that it provides in its own environment; after all, it might be using a different development or runtime environment. this principle puts severe limits on the type of data that can be exchanged in an soa. 

7. 3. Policy-driven • To interact with a service, two orthogonal requirement sets have to be met: • The functionality, syntax and semantics of the provider must fit the consumer’s requirements, • The technical capabilities and needs must match. • For example, a service provider may offer exactly the service a consumer needs, but offer it over JMS while the consumer can only use http (e.g. Because it is implemented on the .NET platform); a provider might require message-level encryption via the XML encryption standard, while the consumer can only support transport-level security using SSL. 4. Autonomous • Related to the explicit boundaries principle, a service is autonomous in that its only relation to the outside world – at least from the SOA perspective – is through its interface. In particular, it must be possible to change a service’s runtime environment, e.g. From a lightweight prototype implementation to a full-blown, application server-based collection of collaborating components, without any effect on its consumers. 

8. 5. Wire formats, not programming language APIs • Services are exposed using a specific wire format that needs to be supported. This principle is strongly related to the first two principles, but introduces a new perspective: to ensure the utmost accessibility (and therefore, long-term usability), a service must be accessible from any platform that supports the exchange of messages adhering to the service interface as long as the interaction conforms to the policy defined for the service. For example, it is a useful test for conformance to this principle to consider whether it is possible to consume or provide a specific service from a mainstream dynamic programming language such as Perl, python or ruby. Even though none of these may currently play any role in the current technology landscape, this consideration can serve as a litmus test to assess whether the following criteria are met: • All message formats are described using an open standard, or a human readable description • It is possible to create messages adhering to those schemas with reasonable effort without requiring a specific programmer’s library • The semantics and syntax for additional information necessary for successful communication, such as headers for purposes such as security or reliability, follow a public specification or standard • At least one of the transport (or transfer) protocols used to interact with the service is a (or is accessible via a) standard network protocol

9. 6. Document-oriented • To interact with services, data is passed as documents. A document is an explicitly modeled, hierarchical container for data. Self-descriptiveness is one important aspect of document-orientation. Ideally, a document will be modeled after real-world documents, such as purchase orders, invoices, or account statements. Documents should be designed so that they are useful on the context of a problem domain, which may suggest their use with one or more services. 7. Loosely coupled • Most SOA proponents will agree that loose coupling is an important concept. Unfortunately, there are many different opinions about the characteristics that make a system “loosely coupled”. They include • Time: when participants are loosely coupled in time, they don’t have to be up and running at the same time to communicate. This requires some way of buffering/queuing in between them, although the approach taken for this is irrelevant. When one participant sends a message to the other one, it does not rely on an immediate answer message to continue processing (neither logically, nor physically). • Location: if participants query for the address of participants they intend to communicate with, the location can change without having to re-program, reconfigure or even restart the communication partners. This implies some sort of lookup process using a directory or address that stores service endpoint addresses. • Type: in an analogy to the concept of static vs. Dynamic and weak vs. Strong typing in programming languages, a participant can either rely on all or only on parts of a document structure to perform its work.

10. 4. Version: participants can depend on a specific version of a service interface, or be resilient to change (to a certain degree). The more exact the version match has to be, the less loosely coupled the participants (in this dimension). 5. Cardinality: there may be a 1:1-relationship between service consumers and service providers, especially in cases where a request/response interaction takes place or an explicit message queue is used. In other cases, a service consumer (which in this case is more reasonably called a “message sender” or “event source” may neither know nor care about the number of recipients of a message. 6. Lookup: a participant that intends to invoke a service can either rely on a (physical or logical) name of a service provider to communicate with, or it can perform a lookup operation first, using a description of a set of capabilities instead. This implies a registry and/or repository that is able to match the consumer’s needs to a providers capabilities (either directly or indirectly). 7. Interface: participants may require adherence to a service-specific interface or they may support a generic interface. If a generic interface is used, all participants consuming this generic interface can interact with all participants providing it. While this may seem awkward at first sight, the principle of a single generic (uniform) interface is at the core of the www’s architecture.

11. 8. Standards-compliant • A key principle to be followed in an SOA approach is the reliance on standards instead of proprietary apis and formats. Standards exists for technical aspects such as data formats, metadata, transport and transfer protocols, as well as for business-level artifacts such as document types (e.g. In UBL). 9. Vendor independent • No architectural principle should rely on any particular vendor’s product. To transform an abstract concept into a concrete, running system, it’s unavoidable to decide on specific products, both commercial and free/open source software. None of these decisions must have implications on an architectural level. This implies reliance on both interoperability and portability standards as much as reasonably possible. As a result, a service provider or service consumer can be built using any technology that supports the appropriate standards, not restricted by any vendor roadmap.

12. SOA Architecture • Service architecture • This is the physical design of an individual service that encompasses all the resources used by a service. This would normally include databases, software components, legacy systems, identity stores, XML schemas and any backing stores, e.g. Shared directories. It is also beneficial to include any service agents employed by the service, as any change in these service agents would affect the message processing capabilities of the service. • The (standardized service contract) design principle keeps service contracts independent from their implementation. The service contract needs to be documented to formalize the required processing resources by the individual service capabilities. Although it is beneficial to document details about the service architecture, the service abstraction design principle dictates that any internal details about the service are invisible to its consumers so that they do not develop any unstated couplings. The service architecture serves as a point of reference for evolving the service or gauging the impact of any change in the service.

13. Service composition architecture • One of the core characteristics of services developed using the service-orientation design paradigm is that they are composition-centric. Services with this characteristic can potentially address novel requirements by recomposing the same services in different configurations. Service composition architecture is itself a composition of the individual architectures of the participating services. In the light of the service abstraction principle, this type of architecture only documents the service contract and any published service-level agreement; internal details of each service are not included. • If a service composition is a part of another (parent) composition, the parent composition can also be referenced in the child service composition. The design of service composition also includes any alternate paths, such as error conditions, which may introduce new services into the current service composition. • Service composition is also a key technique in software integration, including enterprise software integration, business process composition and workflow composition.

14. Service inventory architecture • A service inventory is composed of services that automate business processes. It is important to account for the combined processing requirements of all services within the service inventory. Documenting the requirements of services, independently from the business processes that they automate, helps identify processing bottlenecks. The service inventory architecture is documented from the service inventory blueprint, so that service candidates can be redesigned before their implementation.

15. Service-oriented enterprise architecture • This umbrella architecture incorporates service, composition, and inventory architectures, plus any enterprise-wide technological resources accessed by these architectures e.g. An ERP system. This can be further supplemented by including enterprise-wide standards that apply to the aforementioned architecture types. Any segments of the enterprise that are not service-oriented can also be documented in order to consider transformation requirements if a service needs to communicate with the business processes automated by such segments. SOA main goal is to deliver agility to business.

16. BENEFITS OF SOA • Loose couplingbeing on a SOA stack means that your infrastructure and architecture are split up into various services. This makes it pretty obvious to write software that tends to be loosely coupled (or less dependent on each other).FlexibilitySOA gives you the flexibility to write various components of your architecture in whatever language and platform you choose to. So this means, you could write the client facing side in a more dynamic and productive language like python/ruby/javascript and write the performance critical components in lower level languages like java or C. 

17. Easier testing and debugginghaving all your components isolated into various services makes it easy to test and debug all of them individually. Many organizations have separate teams to develop, test and maintain these components. Scalabilitythis goes on a par with flexibility. Having separate components makes it much more simpler and stress-free to scale up your architecture. You could easily scale up a particular component and test it in isolation, without affecting other components at all. This makes it easy to add in servers without facing any downtime.Reusabilitysince various components are built out separately, it becomes much easier to reuse them later. For example, services like Netflix open sources various components of it's architecture, for others to learn, use and modify it as per their requirements.

18. Soa infrastructure • To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA platform. An SOA infrastructure must support all the relevant standards and required runtime containers. A typical SOA infrastructure looks like in the figure below. The following sections discuss the infrastructure's individual pieces.

19. SOAP, WSDL, UDDI • WSDL, UDDI, and SOAP are the fundamental pieces of the SOA infrastructure. WSDL is used to describe the service; UDDI, to register and look up the services; and SOAP, as a transport layer to send messages between service consumer and service provider. While SOAP is the default mechanism for web services, alternative technologies accomplish other types of bindings for a service. A consumer can search for a service in the UDDI registry, get the WSDL for the service that has the description, and invoke the service using SOAP.

20. Web services overview • A web service, in very broad terms, is a method of communication between two applications or electronic devices over the world wide web (www). Web services are of two kinds: simple object access protocol (soap) and representational state transfer (rest). • SOAP defines a standard communication protocol (set of rules) specification for xml-based message exchange. SOAP uses different transport protocols, such as HTTP and SMTP. The standard protocol HTTP makes it easier for SOAP model to tunnel across firewalls and proxies without any modifications to the SOAP protocol. SOAP can sometimes be slower than middleware technologies like CORBA or ICE due to its verbose XML format. • REST describes a set of architectural principles by which data can be transmitted over a standardized interface (such as HTTP). REST does not contain an additional messaging layer and focuses on design rules for creating stateless services. A client can access the resource using the unique URI(A uniform resource identifier (URI) is a string of characters used to identify a resource. Such identification enables interaction with representations of the resource over a network, typically the world wide web, using specific protocols). • and a representation of the resource is returned. With each new resource representation, the client is said to transfer state. While accessing restful resources with HTTP protocol, the URL of the resource serves as the resource identifier and GET, PUT, DELETE, POST and HEAD are the standard HTTP operations to be performed on that resource.

21. REST vs. SOAP • Multiple factors need to be considered when choosing a particular type of web service, that is between REST and SOAP. The table below breaks down the features of each web service based on personal experience. Rest • The restful web services are completely stateless. This can be tested by restarting the server and checking if the interactions are able to survive. • Restful services provide a good caching infrastructure over http get method (for most servers). This can improve the performance, if the data the web service returns is not altered frequently and not dynamic in nature. • The service producer and service consumer need to have a common understanding of the context as well as the content being passed along as there is no standard set of rules to describe the rest web services interface. • Rest is particularly useful for restricted-profile devices such as mobileand iPad for which the overhead of additional parameters like headers and other soap elements are less. • Rest services are easy to integrate with the existing websites and are exposed with xml so the html pages can consume the same with ease. There is hardly any need to refactor the existing website architecture. This makes developers more productive and comfortable as they will not have to rewrite everything from scratch and just need to add on the existing functionality. • Rest-based implementation is simple compared to soap.

22. Soap • The web services description language (WSDL) contains and describes the common set of rules to define the messages, bindings, operations and location of the web service. WSDL is a sort of formal contract to define the interface that the web service offers. • Soap requires less plumbing code than rest services design, (i.e. Transactions, security, coordination, addressing, trust, etc.) Most real-world applications are not simple and support complex operations, which require conversational state and contextual information to be maintained. With the SOAP approach, developers need not worry about writing this plumbing code into the application layer themselves. • Soap web services (such as jax-ws) are useful in handling asynchronous processing and invocation. • Soap supports several protocols and technologies, including wsdl, xsds, soap, ws-addressing • In a nutshell, when you're publishing a complex application program interface (API) to the outside world, SOAP will be more useful. But when something with a lower learning curve, and with lightweight and faster results and simple transactions (i.e. CRUD operations) is needed, my vote goes to REST.

23. What are the components of service-oriented architecture (SOA)? • Enterprise service bus (ESB): an ESB manages the flow of messages across different applications, orchestrating communications and allowing, for instance, an MDM hub to access application messages and data. It's not for data integration; rather, it's a messaging mechanism. • Service registry: a service registry is critical for an soa environment in order to track and publish services to applications developers, business partners and exchange members so they know which services exist and how they should be used in the form of service metadata. • Business processes: without business processes, soa is just a framework comprised of the above pieces. A business process can be in the form of a web service (e.g. "Update the customer's address" or "change the product's name"). The point of SOA is to unify these processes across systems and make them repeatable.

24. MDM hub: an MDM hub provides a means for reconciling common master data across systems and applications, providing an operational single version of the truth for customer, product, location or other reference data. Master data management ensures that the meaning and format of the data being accessed is unified across all the applications that access the hub; the data is understood by all the services that access it. • Data management: if your services are information-rich then data management is a must. Since the data that services access might not necessarily come from an MDM system but from a range of applications and databases, managing, tracking and maintaining that data at the enterprise level is a critical component of SOA. This means having business rules, policies and metadata used and enforced.

25. SOAP • What is SOAP?SOAP(simple object access protocol) is a way for a program running in one kind of operating system (such as windows 2000) to communicate with a program in the same or another kind of an operating system (such as Linux) by using the world wide web's hypertext transfer protocol (HTTP) and its extensible markup language (XML) as the mechanisms for information exchange. • Since web protocols are installed and available for use by all major operating system platforms, http and xml provide an already at-hand solution to the problem of how programs running under different operating systems in a network can communicate with each other. SOAP specifies exactly how to encode an HTTP header and an XML file so that a program in one computer can call a program in another computer and pass it information. It also specifies how the called program can return a response.

26.  Here is a list of advantages: • Using SOAP over HTTP allows for easier communication through proxies and firewalls than previous remote execution technology. • Soap is versatile enough to allow for the use of different transport protocols. The standard stacks use HTTP as a transport protocol, but other protocols are also usable (e.g. SMTP, RSS). • Soap is platform independent. • Soap is language independent. • Soap is simple and extensible.

27. The list of disadvantages are as follows: • Because of the verbose xml format, soap can be considerably slower than competing middleware technologies. • When relying on http as a transport protocol and not using ws-addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other. Developers must use polling instead of notification in these common cases. • Most uses of http as a transport protocol are done in ignorance of how the operation would be modeled in http. This is by design (with analogy to how different protocols sit on top of each other in the IP stack), but the analogy is imperfect (because the application protocols used as transport protocols are not really transport protocols). Because of this, there is no way to know if the method used is appropriate to the operation. This makes good analysis of the operation at the application-protocol level problematic at best with results that are sub-optimal (if the post-based binding is used for an application which in http would be more naturally modeled as a get operation).

28. SOAP MESSAGING • SOAP messagingA SOAP message may need to be transmitted together with attachments of various sorts, ranging from facsimile images of legal documents to engineering drawings. Such data are often in some binary format. For example, most images on the internet are transmitted using either GIF or jpeg data formats. • A soap message is an ordinary xml document containing the following elements: • A required envelope element that identifies the XML document as a SOAP message • An optional header element that contains header information • A required body element that contains call and response information • An optional fault element that provides information about errors that occurred while processing the message