What, Why and How: SOA With Microsoft

Abstract

SOA is a well-known term today, when we think of SOA, WCF comes to mind. WCF is a Microsoft technology to build SOA-based software solutions. This article will help you understand what exactly “SOA” is in an actual architectural manner, why architects suggest SOA-based application architecture and how SOA can be implemented, and so on.

What SOA is?

Service-Oriented Architecture (SOA) is an Architectural Design Pattern / Approach, under which distributed and decoupled applications can interact with each other. SOA is not a technology or a Language.

SOA provides the infrastructure for the idea of how two independent business entities communicate and work together. For example, a bank that offers Stock services, a travel site with the feature to book a flight, a hotel, a car or even a holiday package and so on., weather updates and currency rates, and so on. All such activities take place due to B2B integration and SOA is the oxygen for such type of business activities.

Before a service can be consumed, a request message needs to be sent to the service (the provider, or callee) by its client (the consumer, or caller). A request message contains information about the operation the service is being asked to perform and any additional data that the specific operation needs to have before executing. For example, a service that shows you a currency exchange rate needs to have two currency types and how much money you want to convert. For example 100 USD to INR.

Why SOA?

In today's world, we heavily rely on software systems, for example, a bank's system communicates with various other software and database systems.

This usually causes Software applications to encounter the following challenges.

• Applications are becoming more and more distributed.
• Business needs are changing very often.
• Collaboration with other systems is becoming key to the success of the application. For example B2B scenario.
• Operation costs need to be reduced.
• Scalable, secure, and reliable systems are needed by businesses.

SOA resolves these challenges by defining standards for interaction among decoupled systems and technologies based on policies and contracts.

SOA Objectives

SOA is intended to provide loosely coupled interaction among applications. Benefits offered by SOA are as follows:

• Agility: Enables your business to adapt to changes quickly.
• Productivity: Can implement complex applications using SOA more easily than with other architectural styles.
• Reusability: Able to reuse your services across systems instead of rewriting the same modules again and again in every system or specific to an individual system.
• Reduced cost: Software Architects think of Build vs. Buy vs. Reuse, The SOA-based approach allows either buying or reusing this feature/functionality, hence in most cases the cost is saved by reusing the existing services There are many commonly used services available for free.

Communicating with SOA-based Service

SOA-based services communicate with the outside world via endpoint(s). Hence, an endpoint is required to communicate with a service.

• An endpoint is the access point for the service.
• Accessing internal assets can be done only through the endpoint.
• The endpoint controls who can access the service, what operations they can perform, and so on.
• Services may expose multiple endpoints for various reasons (technology, topology, and so on).

Properties of SOA Architecture

Service-Oriented Architecture is based on the following four tenets.

Services handle data, not objects

Objects are known to have a direct dependency on a particular technology, while XML data is not technology-specific. Hence, services communicate by exchanging data as long as they use the same standards by which the service operates.

Services are autonomous

In order to utilize a Service, a client does not need to know the implementation technology and various other internal/implementation details. What all a client requires is the service's address (In other words endpoint) and the information to send the data to.

Services have explicit boundaries

The service is responsible for exposing its information. Everything inside the service's boundary is only accessible through the service endpoint. The service's boundaries are explicit, meaning that the service specifies precisely which messages it can receive and what the messages need to contain; messages that are not compliant with these specifications will be rejected with an error message.

Services expose contract and policy

The contract of the service defines the data that the client needs to use when calling a service. Service contracts also define the response that the service sends back to the client as a result of calls made to the service.

The service's policy defines additional information about the data that is being sent. For example, a policy can state that the data needs to be encrypted, and so on.

SOA Benefits

Productivity

• Services are autonomous: Services have explicit boundaries. Services can always be moved to some other location.
• Services depend on data: There is no dependency on the technology that creates the data.
• Service autonomy simplifies testing
• All major development frameworks (Microsoft.NET, Java) embrace SOA.
• Development tools like Microsoft Visual Studio provide an excellent environment for building SOA applications using WCF, ASP.NET WebAPI, or ASP.NET WebServices.

Agility

• Versioning is a major issue in the world of IT. Every change in the system requires regression tests to ensure nothing is broken.
• Services are isolated from the system by design. If the contract does not change, you can fix (and test) the service without worrying about the rest of the system.
• As long as a message can be sent from the client to the service and back, the system will work.
• Advanced integration systems (such as Microsoft BizTalk and other enterprise service buses), can be used to process messages before they arrive at the service.
  • Messages can be transformed dynamically.
  • Messages can be dynamically routed to one or more services.
  • Business processes can be implemented (orchestration).
  • Protocol bridging provides connectivity and interoperability across protocols and technologies.
  • Messages can be persisted to handle error conditions and long-running services.

Reduced IT Costs

• It is common to see separate systems doing the same tasks while running in the same organization.
• The bottom line is that such duality has a great cost.
• Once a system can be exposed as a service, all the clients in the organization can use the same system.
• Services are autonomous. This isolation can be used to tear the service out and send it for outsourcing.
• Usually, most of the IT tasks are generic. Only a small minority are tasks specific to the business. In such scenarios, generic tasks can be consumed from generic worldwide services, instead of developing and running local on-premises implementations.
• Once a capability is developed, a business can consider exposing it as a global service and create another source of income.
• There are numerous examples of companies who have bought some expensive piece of infrastructure for their internal use and after integrating and using it locally, decided to expose it as a service. Other companies can save the cost of the infrastructure because they can consume the service while the first company receives income from an unexpected source (win-win).

Many Communication Technologies

• Services might expose different edges using different technologies and policies. For example Transmission Control Protocol (TCP) for local clients; HTTP for remote clients.
• Multiple messaging patterns can be used. For example Request-response for VIP users (immediate response) and fire-and-forget for normal users.
• Different security policies and technologies can be used. For example Kerberos for internal users, username and password for remote users.
• Later in the course, students will be shown how to create multiple endpoints can be created for a single WCF service.
• It is common to have several instances, each exposing a number of endpoints (edge). Traffic can be load-balanced between the endpoints.
• Load balancing can be based on traffic (usually done by hardware infrastructure) or based on the content of the message.
• The technology for implementing a WCF service endpoint (edge) is expressed using WCF bindings and behaviors.

High Scalability

• Services can be multiplied. Because services are independent and isolated, they can be multiplied.
  • Real-life example: Add more tellers in the bank during peak hours.
• Different messaging patterns and topologies scale differently.
• Request-response is a simple pattern, yet it does not scale very well. The service must have the resources to respond immediately. The client is blocked until a response arrives.
  • Real-life example: website.
• Fire and forget (one-way messaging) is more complicated, but it scales better. The client sends a request and does not block.
  The service queues (persists) the message and handles it when resources are available. The service should have a channel to send the response back to the client (not trivial). When the load comes in bursts, queuing can dramatically improve scalability.
  • Real-life example: Mail.
• A façade can improve scalability. All requests are sent to the façade first.
  • Requests are validated.
  • Simple requests can be handled by the façade only.
  • Complicated requests are forwarded to the actual service.
    • Real-life example: Call center.

Interoperability among Systems

• Services deal with data. Data can be created and consumed by any technology. This is the core of interoperability.
• If data is encoded or compressed using a proprietary algorithm, interoperability breaks (but might provide better performance).
• To be fully interoperable, data is written in text format using standard encodings (for example, UTF-8).
• Services must not know what technology is used on the other side of the line. As long as the correct information is provided, the service is happy to respond.
• Sometimes simple message transformations are required to handle versioning issues.
  • Different versions of the standard used to transmit messages
  • Different versions of the service contract
• Message transformations might be required to bridge endpoints based on different technologies and standards. Example: SAP to WCF.
• Integration layers (for example, BizTalk can implement message transformations).
• WS Standards ensure that all implementation technologies speak the same language.
  • Example: A Java client would understand a security header created by a WCF service.

Service Reliability

• Customers expect systems to be as reliable as possible. In other words, 100 percent availability and resilience to connectivity and performance issues.
• It is not realistic to have a 100% reliable system, but there are actions that can improve reliability.
  • Backup lists: The client/router keeps a list of services to use when the original service fails. Such lists can mask unavailability issues from the final consumer of the service.
  • Retry policy: If the service fails, keep trying until a certain limit is reached. Retries can be uniformly spread, or follow a custom pattern.
  • Message persistence: You do not want to lose an important transaction because a message was lost.
  • Messages are saved in a database or a queue until the business transaction is confirmed.
  • The copy of the message enables future retries or other error handling.
• Distributed systems must be constantly monitored to ensure correct behavior. Runtime governance infrastructures are used to monitor the system, diagnose the situation, and help to solve problems.

Built-in Security

• Data can be extremely valuable.
• Distributed systems exchange data.
• In real life, no one would consider exchanging money, Gold, or Diamonds, without proper security measures. The same policy should apply when exchanging data.
• Web application security deals with the action required to maximize the security of distributed applications.
• Data must be protected in the infrastructure layer as well as in the application layer.
• Identity and integrity are handled by adding standardized information to the message (for example, tokens).
• Organizations like the Open Web Application Security Project (OWASP) or the Microsoft Patterns and Practices position, publish security best practices.
• Web application security deals with.
  • Input validation
  • Authentication
  • Authorization
  • Configuration management
  • Sensitive data
  • Session management
  • Cryptography
  • Parameter manipulation
  • Exception management
  • Auditing and logging

How to Implement SOA using Microsoft Technology Stack?

WCF is a prime member of Microsoft's SOA technology stack to implement the SOA Architecture.

• WCF was introduced in .NET framework 3.0 in late 2007. It is the framework for building Service-Oriented Applications.
• WCF is a unified framework meaning that it supports all communication protocols and messaging patterns. WCF interoperates with older technologies like Microsoft ASP.NET Web Services. Yet it is not recommended to build new services using these old technologies. WCF is the framework to use.
• Many of Microsoft's distributed technologies are based on WCF. For example, Windows Azure, AppFabric, which deals with connectivity in the cloud, actually provides WCF bindings.