Skip to content

Service Oriented Architecture

August 10, 2009

Introduction

A service-oriented architecture is a collection of services that communicate with each other. The services are self-contained and do not depend on the context or state of the other service. They work within a distributed systems architecture.

  • Can correspond to real-life business activities
  • Is the interface for a business function or functions (a service can have many operations)
  • Is usually discoverable, but not always
  • Has a clearly defined interface, which is exposed through some kind of standard contract
  • Interacts with other services and components using loosely-coupled, message-based architecture and synchronous or asynchronous access models
  • Uses standards for communication
  • Provides interoperability
  • Is up and running all the time, unlike components that must be instantiated before use
  • The service interface layer communicates with the business logic classes, business workflows, and other components at the business layer, which then communicates with the data access classes, which connect to data sources to access data.

Benefits of a Service-Oriented Architecture

  1. Complexity is encapsulated. Any system has an inherent complexity the details of which are not important to the users of the system. Service-oriented architectures recognize this complexity, and provide a way to encapsulate it in order to hide it from the consumer of the service.
  2. Code is mobile. In distributed applications, components can reside on any machine, anywhere in the world and still be accessed the same way. The client or other services that access the service doesn’t care where the service is, or in which language it is written.
  3. Development efforts can be done in parallel. A service oriented architecture will force applications to have many different layers. Having many application layers in a project means multiple teams can work on their own components independently and in parallel after the architecture and design is complete. This solves many problems in enterprise-scale application development.
  4. The service definition supports multiple client types. Services and clients can be written in any language and deployed in any platform, as long as they can speak the standard languages and protocols that are used.
  5. More security can be included. By adding the additional service interface layer, it is possible to provide more security. Different parts of the final application that need different security measures can be deployed behind firewalls. These firewalls can be secured as tight as the components require and still be accessed by internal or external components.
  6. More re-usability of components across the heterogonous platforms is possible. There are no language and platform integration problems when the functions are defined as services. The service components can be re-used by other components or services.

What Are Web Services?

Building on the broad acceptance of XML, Web services are applications that use standard transports, encodings, and protocols to exchange information. With broad support across vendors and businesses, Web services enable computer systems on any platform to communicate over corporate intranets, extranets, and across the Internet with support for end-to-end security, reliable messaging, distributed transactions, and more.

Web services are based on a core set of standards that describe the syntax and semantics of software communication: XML provides the common syntax for representing data; the Simple Object Access Protocol (SOAP) provides the semantics for data exchange; and the Web Services Description Language (WSDL) provides a mechanism to describe the capabilities of a Web service. Additional specifications, collectively referred to as the WS-* architecture, define functionality for Web services discovery, eventing, attachments, security, reliable messaging, transactions, and management.

WS-* Architecture

  1. The most important attribute of the WS-* architecture is composability.
  2. Protocol composability enables incremental development of Web services solutions only as individual requirements (such as security, reliable messaging, attachments, discovery, etc.) are needed.
  3. In isolation, each of these requirements solves an elemental need. In composition, they address higher-level functionality commonly required by distributed applications.
  4. As such, the WS-* specifications can be used either independently or in combination with one another. This eliminates the complexity and overhead associated with specifications that attempt to define multiple capabilities or are tightly coupled with other specifications.
  5. It also enables developers to apply only the specific functionality needed to solve the immediate need. As new application requirements arise, new specifications can be authored without compromising backwards compatibility.

Messaging Services

  1. MSMQ-based applications support message queues for reliable message delivery, and they also support a trigger-based event model that fires up the application code when an incoming message is received.
  2. Messaging applications that are built around MSMQ are almost considered to be a non-standard type of application. If they were standard, then all of us would be incorporating message queues into every application that we build. Of course this is not the case, largely because it creates a level of overhead that is considered unnecessary for many applications.
  3. In service-oriented applications, reliable message delivery is not an abstract concept; instead, it represents a quality of service expectation on the part of your clients. Message delivery and the potential for message loss are critically important to service-oriented applications.
    WSE 3.0 does not natively integrate with MSMQ, which is essentially just an alternate transport channel for messages.
  4. The .NET Framework provides a namespace called System.Messaging, which allows you to interact with an MSMQ queue.

Design Goals for Web Service Enhancement(WSE) 3.0

Simplified Development of Service-Oriented Systems Using the Web Service Protocols and .NET Framework v2.0

Essential specifications such as Message Transmission Optimization Mechanism (MTOM), take advantage of improvements to the .NET Framework 2.0, and provide an integrated set of tools with Visual Studio 2005.

Sending Large Amounts of Data with MTOM

  1. MTOM, otherwise known as Message Transmission Optimization Mechanism, enables you to send binary data efficiently as part of a SOAP message.
  2. MTOM is a W3C recommendation that replaces DIME and WS-Attachments as the mechanism for sending large amounts of data such as document files and images.

Three key benefits in using MTOM over the existing technologies

Security

The primary benefit is that MTOM composes with security (via WS-Security), meaning that the data is secure as well as the SOAP message.

Reduced Wire Size

  1. With MTOM, binary character values are sent on the wire as a MIME attachment and these are referenced from the body of the SOAP message.
  2. MTOM is simply another encoding algorithm that does not suffer from this size expansion and so the wire size is smaller

Simplified Programming Model

  1. All you do is write the service and then simply indicate that this service supports MTOM encoding in the application’s configuration file.
  2. Any byte[ ] types returned from the service are then MTOM-automatically encoded.

Improved Session Management

In WSE 3.0 sessions can now be established via the policy for the service, such that any given service can also act as a Security Context Token (SCT) issuer, otherwise known as a Security Token Service (STS).

Session cancellation

In addition to SCTs having a time out, SCTs can now be cancelled explicitly by obtaining the SCT from the client’s proxy and calling its Cancel method. This means that the service now knows that the session has finished and that it can clean up its SCT cache.

Stateful sessions

  1. WSE 3.0 now has the ability to create stateful sessions from the client’s perspective, otherwise referred to as stateful SCTs
  2. Messages are secured with the SCT as both ends map the identifier value to the cached SCT.

Integrate Web Services and MSMQ

WSE 3.0 does not implement reliable messaging, nor does it provide any kind of support for managing message delivery. If you want to implement this capability today, you will need to custom build the support infrastructure using MSMQ.

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: