SOA
A pattern for organizing and
utilizing distributed capabilities that may be under the control of different
ownership domains. It provides a uniform means to offer, discover, interact
with and use capabilities to produce desired effects consistent with measurable
preconditions and expectations.
loosely coupled
-units of functionality that are self-contained
Architectures can operate
independently of specific technologies
Criticisms
Some criticisms of SOA depend on
conflating SOA with Web
services.[35] 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. 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.
Services implemented using JSON instead of XML do not suffer from this
performance concern.[36][37][38]
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 ultimately,
some critics feel that SOA services are still too constrained by applications
they represent
Internet of Things - a proposed development of the Internet in
which everyday objects have network connectivity, allowing them to send and
receive data. As the idea of SOA is extended
to large numbers of devices, we see the emergence of the Internet of
Things
Web services
Web services architecture:
the service provider sends a WSDL file to UDDI. The service requester contacts
UDDI to find out who is the provider for the data it needs, and then it
contacts the service provider using the SOAP protocol. The service provider validates
the service request and sends structured data in an XML file, using the SOAP
protocol. This XML file would be validated again by the service requester using
an XSD file.
Client proxy will work if we change the content or logic in the method without changing the method signature
Client proxy will work if we change the content or logic in the method without changing the method signature
Element
|
Description
|
Required
|
Envelope
|
Identifies the XML document as a SOAP
message.
|
Yes
|
Header
|
Contains header information.
|
No
|
Body
|
Contains call, and response
information.
|
Yes
|
Fault
|
Provides information about errors
that occurred while processing the message.
|
No
|
Windows
Communication Foundation (WCF) is a framework for building service-oriented
applications. Using WCF, you can send data as asynchronous messages from one
service endpoint to another. A service endpoint can be part of a continuously
available service hosted by IIS, or it can be a service hosted in an application.
An endpoint can be a client of a service that requests data from a service
endpoint. The messages can be as simple as a single character or word sent as
XML, or as complex as a stream of binary data. A few sample scenarios include:
·
A secure service to process business transactions.
·
A service that supplies current data to others, such as a
traffic report or other monitoring service.
·
A chat service that allows two people to communicate or exchange
data in real time.
·
A dashboard application that polls one or more services for data
and presents it in a logical presentation.
·
Exposing a workflow implemented using Windows Workflow
Foundation as a WCF service.
·
A Silverlight application to poll a service for the latest data
feeds.
While
creating such applications was possible prior to the existence of WCF, WCF
makes the development of endpoints easier than ever. In summary, WCF is
designed to offer a manageable approach to creating Web services and Web
service clients.
Features of WCF
·
Service Orientation
One consequence of using WS
standards is that WCF enables you to create service oriented applications. Service-oriented
architecture (SOA) is the reliance on Web services to send and receive data.
The services have the general advantage of being loosely-coupled instead of
hard-coded from one application to another. A loosely-coupled relationship
implies that any client created on any platform can connect to any service as
long as the essential contracts are met.
·
Interoperability
WCF implements modern industry
standards for Web service interoperability. For more information about the
supported standards,.
·
Multiple Message
Patterns
Messages are exchanged in one
of several patterns. The most common pattern is the request/reply pattern,
where one endpoint requests data from a second endpoint. The second endpoint
replies. There are other patterns such as a one-way message in which a single
endpoint sends a message without any expectation of a reply. A more complex
pattern is the duplex exchange pattern where two endpoints establish a
connection and send data back and forth, similar to an instant messaging
program. For more information about how to implement different message exchange
patterns using WCF
·
Service Metadata
WCF supports publishing
service metadata using formats specified in industry standards such as WSDL,
XML Schema and WS-Policy. This metadata can be used to automatically generate
and configure clients for accessing WCF services. Metadata can be published
over HTTP and HTTPS or using the Web Service Metadata Exchange standard. For
more information,
·
Data Contracts
Because WCF is built using the
.NET Framework, it also includes code-friendly methods of supplying the
contracts you want to enforce. One of the universal types of contracts is the
data contract. In essence, as you code your service using Visual C# or Visual
Basic, the easiest way to handle data is by creating classes that represent a
data entity with properties that belong to the data entity. WCF includes a
comprehensive system for working with data in this easy manner. Once you have
created the classes that represent data, your service automatically generates
the metadata that allows clients to comply with the data types you have
designed. For more information, see Using
Data Contracts
·
Security
Messages can be encrypted to
protect privacy and you can require users to authenticate themselves before
being allowed to receive messages. Security can be implemented using well-known
standards such as SSL or WS-SecureConversation. For more information, see Windows
Communication Foundation Security.
·
Multiple Transports and
Encodings
Messages can be sent on any of
several built-in transport protocols and encodings. The most common protocol
and encoding is to send text encoded SOAP messages using is the HyperText
Transfer Protocol (HTTP) for use on the World Wide Web. Alternatively, WCF
allows you to send messages over TCP, named pipes, or MSMQ. These messages can
be encoded as text or using an optimized binary format. Binary data can be sent
efficiently using the MTOM standard. If none of the provided transports or
encodings suit your needs you can create your own custom transport or encoding.
For more information about transports and encodings supported by WCF see Transports
in Windows Communication Foundation.
·
Reliable and Queued
Messages
WCF supports reliable message
exchange using reliable sessions implemented over WS-Reliable Messaging and
using MSMQ. For more information about reliable and queued messaging support in
WCF see Queues
and Reliable Sessions.
·
Durable Messages
A durable message is one that
is never lost due to a disruption in the communication. The messages in a
durable message pattern are always saved to a database. If a disruption occurs,
the database allows you to resume the message exchange when the connection is
restored. You can also create a durable message using the Windows Workflow
Foundation (WF). For more information, see Workflow
Services.
·
Transactions
WCF also supports transactions
using one of three transaction models: WS-AtomicTtransactions, the APIs in the System.Transactionsnamespace, and Microsoft
Distributed Transaction Coordinator. For more information about transaction
support in WCF see Transactions
in WCF.
·
AJAX and REST Support
REST is an example of an
evolving Web 2.0 technology. WCF can be configured to process "plain"
XML data that is not wrapped in a SOAP envelope. WCF can also be extended to
support specific XML formats, such as ATOM (a popular RSS standard), and even
non-XML formats, such as JavaScript Object Notation (JSON).
·
Extensibility
The WCF architecture has a
number of extensibility points. If extra capability is required, there are a
number of entry points that allow you to customize the behavior of a service.
For more information about available extensibility points see Extending
WCF.
WCF Integration with Other Microsoft Technologies
WCF is
a flexible platform. Because of this extreme flexibility, WCF is also used in
several other Microsoft products. By understanding the basics of WCF, you have
an immediate advantage if you also use any of these products.
The
first technology to pair with WCF was the Windows Workflow Foundation (WF).
Workflows simplify application development by encapsulating steps in the
workflow as “activities.” In the first version of Windows Workflow Foundation,
a developer had to create a host for the workflow. The next version of Windows
Workflow Foundation was integrated with WCF. That allowed any workflow to be
easily hosted in a WCF service; you can do this by automatically choosing the
WF/WCF a project type in Visual Studio 2012.
Microsoft
BizTalk Server R2 also utilizes WCF as a communication technology. BizTalk is
designed to receive and transform data from one standardized format to another.
Messages must be delivered to its central message box where the message can be
transformed using either a strict mapping or by using one of the BizTalk features
such as its workflow engine. BizTalk can now use the WCF Line of Business (LOB)
adapter to deliver messages to the message box.
Representational state transfer
representational state transfer (REST) is an architectural style used
for web development. Systems and sites designed using this style aim for fast
performance, reliability and the ability to scale (to grow and easily support
extra users). To achieve these goals, developers work with reusable components
that can be managed and updated without affecting the system as a whole while
it is running.
Technically, REST consists of a coordinated set of components,
connectors, and data elements within a distributed hypermedia system,
where the focus is on component roles and a specific set of interactions
between data elements rather than implementation details.[1][2] Its
purpose is to induce performance, scalability, simplicity, modifiability,
visibility, portability, and reliability.[1][2] REST is
the software
architectural style of
the World Wide Web
Architectural
constraints[edit]
The architectural properties of REST are realized by applying
specific interaction constraints to components, connectors, and data elements.[1][10] One can characterise applications conforming
to the REST constraints described in this section as "RESTful".[3] If a service violates any of the required
constraints, it cannot be considered RESTful. Complying with these constraints,
and thus conforming to the REST architectural style, enables any kind of
distributed hypermedia system to have desirable non-functional
properties, such as performance, scalability, simplicity,
modifiability, visibility, portability, and reliability.[1]
The formal REST constraints are
Client–server[edit]
See also: Client–server model
A uniform interface separates clients from servers. This separation of
concerns means that,
for example, clients are not concerned with data storage, which remains
internal to each server, so that the portability of client code is improved. Servers
are not concerned with the user interface or user state, so that servers can be
simpler and more scalable. Servers and clients may also be
replaced and developed independently, as long as the interface between them is
not altered.
Stateless[edit]
See also: Stateless protocol
The client–server communication is further constrained by no
client context being stored on the server between requests. Each request from
any client contains all the information necessary to service the request, and
session state is held in the client. The session state can be transferred by
the server to another service such as a database to maintain a persistent state
for a period and allow authentication. The client begins sending requests when
it is ready to make the transition to a new state. While one or more requests
are outstanding, the client is considered to be in transition. The
representation of each application state contains links that may be used the
next time the client chooses to initiate a new state-transition.[12]
Cacheable[edit]
See also: Web cache
As on the World Wide Web, clients and intermediaries can cache
responses. Responses must therefore, implicitly or explicitly, define
themselves as cacheable, or not, to prevent clients from reusing stale or
inappropriate data in response to further requests. Well-managed caching
partially or completely eliminates some client–server interactions, further
improving scalability and performance.
Layered system[edit]
See also: Layered system
A client cannot ordinarily tell whether it is connected directly
to the end server, or to an intermediary along the way. Intermediary servers
may improve system scalability by enabling load balancing and by providing
shared caches. They may also enforce security policies.
Code on demand (optional)[edit]
See also: Client-side scripting
Servers can temporarily extend or customize the functionality of
a client by the transfer of executable code. Examples of this may include
compiled components such as Java applets and
client-side scripts such as JavaScript.
Uniform interface[edit]
The uniform interface constraint is fundamental to the design of
any REST service.[1] The uniform interface simplifies and
decouples the architecture, which enables each part to evolve independently.
The four constraints for this uniform interface are
Identification of resources
Individual resources are
identified in requests, for example using URIs in web-based REST systems. The
resources themselves are conceptually separate from the representations that
are returned to the client. For example, the server may send data from its
database as HTML, XML or JSON,
none of which are the server's internal representation.
Manipulation
of resources through representations
When a client holds a
representation of a resource, including any metadata attached,
it has enough information to modify or delete the resource.
Self-descriptive
messages
Each message includes
enough information to describe how to process the message. For example, which
parser to invoke may be specified by an Internet media type(previously
known as a MIME type).[1]
Hypermedia
as the engine of application state (HATEOAS)
Clients make state
transitions only through actions that are dynamically identified within
hypermedia by the server (e.g., by hyperlinks within hypertext). Except for simple fixed entry
points to the application, a client does not assume that any particular action
is available for any particular resources beyond those described in
representations previously received from the server. There is no universally
accepted format for representing links between two resources. RFC 5988 and JSON Hypermedia API Language (proposed) are two popular formats
for specifying REST hypermedia links.[13]
Applied to web services[edit]
Web service APIs
that adhere to the REST architectural constraints are called RESTful APIs. HTTP-based RESTful APIs are
defined with the following aspects:[4]
·
an Internet media type that defines state transition data
elements (e.g., Atom, microformats, application/vnd.collection+json,[4]:91–99 etc.) The current representation tells the
client how to compose all transitions to the next application state. This could
be as simple as a URL or as complex as a java applet.[14]
Relationship between URL and HTTP methods[edit]
The following table shows how HTTP methods are typically used in
a RESTful API:
HTTP
methods
|
||||
Uniform
Resource Locator (URL)
|
GET
|
PUT
|
POST
|
DELETE
|
Collection,
such as
http://api.example.com/resources/ |
List the URIs and perhaps other details of the
collection's members.
|
Replace the entire collection with another
collection.
|
Create a new entry in the collection. The new
entry's URI is assigned automatically and is usually returned by the
operation.[16]
|
Delete the entire collection.
|
Element,
such as
http://api.example.com/resources/item17 |
Retrieve a representation of the addressed member of
the collection, expressed in an appropriate Internet media type.
|
Replace the addressed member of the collection, or if
it does not exist,create it.
|
Not generally used. Treat the
addressed member as a collection in its own right and create a new entry in it.[16]
|
Delete the addressed member of the collection.
|
The PUT and DELETE methods are referred to as idempotent, meaning
that the operation will produce the same result no matter how many times it is
repeated. The GET method is a safe method (or nullipotent), meaning that calling it
produces no side-effects.
In other words, retrieving or accessing a record does not change it. The
distinction between PUT/DELETE and GET are roughly analogous to the notion of Command-Query
Separation (CQS). For example: A query operation (like GET) promises
no side-effects (e.g. changes) in data being queried. Commands (like
PUT/DELETE) answer no questions about the data, but compute changes applied to
the data (e.g. UPDATE or INSERT to use database terms).
Unlike SOAP-based
web services, there is no "official" standard for RESTful web APIs.[17] This is because REST is an architectural
style, while SOAP is a protocol. Even though REST is not a standard per se, most RESTful
implementations make use of standards such as HTTP, URL, JSON,
and XML.[17]
No comments:
Post a Comment