Showing posts with label Web Services. Show all posts
Showing posts with label Web Services. Show all posts

Friday, September 18, 2009

* Exchange 2010 : Integration with Line of Business applications

All the communication and collaboration products from Microsoft like Exchange, Office Communications Server and SharePoint MOSS provide excellent clients to harness the server capabilities in most effective manner. Like Exchange comes with Outlook, OCS comes with communicator and SharePoint comes with Outlook & Groove integration & SharePoint workspace from SharePoint 2010.

Apart from providing standalone clients they also ship enough programming interfaces so that these server capabilities can also be integrated within Line of Business applications. This helps customers to extract maximum value out of their server investments. Exchange server comes with Web services interface, OCS comes with UCCAPI – unified communications client APIs and now SharePoint 2010 will come with client APIs.

Here are some of the programming interfaces provided by Exchange Server 2010:

  • Exchange Web Services Managed API 1.0 sdk : The typed .NET sdk which can be used from .NET applications to access Exchange Web Services.
  • Exchange Web Services (EWS) : Allows custom applications to access Exchange mailboxes over Http/SOAP protocol.
  • Autodiscover (SOAP) service : Helps in creating custom applications which can autodiscover mailboxes based on client profiles. The communication is over Http/SOAP.
  • Autodiscover (POX) service : Same as above but over Http/POX protocol. The recommended way is using the Http/SOAP.
  • Exchange 2010 beta Transports Agents sdk : Helps in creating server side agents which can access e-mail messages and their contents while the messages are being transported to users’ mail boxes. Thus helps in extension of Exchange transport behavior.
  • Exchange 2010 beta backup & restore sdk : create custom backup, restore and recovery systems.

Exchange Server Developer Center

Thursday, June 19, 2008

* SOA Development : Specifications supported by WCF

If you are into developing and consuming services in SOA environment , Interoperability is something which is assumed. Interoperability is best achieved by following standards.

WCF provides a system binding called ‘BasicHttpBinding’ which conforms to the minimum requirement for having a standard compliant web service as specified by WS-I organization.

'BasicHttpBinding’ of WCF 3.5 is compliant to Basic Profile 1.1 standard of Web Service.

Basic Profile 1.1 in turn is the umbrella term which list down versions/editions of various underlying standards/specifications that need to be supported.

Following is the list of standards which Basic Profile 1.1 contains :

  • Extensible Markup Language (XML) 1.0 (Fourth Edition)
  • Extensible Markup Language (XML) 1.0 (Second Edition)
  • Namespaces in XML
  • RFC2246: The TLS Protocol Version 1.0
  • RFC2965: HTTP State Management Mechanism
  • Simple Object Access Protocol (SOAP) 1.1
  • UDDI Version 2 XML Schema
  • UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002
  • UDDI Version 2.03 Data Structure Reference, Section 7
  • WSDL 1.1
  • WSDL 1.1 Binding Extension for SOAP 1.2
  • XML Schema Part 1: Structures

Basic Profile 1.2 is under progress.

Understanding the content specifications of Basic Profile is more important because each of them evolve independently.

Current Versions of some them are :

  • XML 1.1 Second Edition
  • WSDL 2.0
  • SOAP 1.2

WCF Tutorials

Tuesday, June 12, 2007

* REST vs rest

You have come to the right place :

  • if you have never heard about the architecture style called 'REST'.
  • You have heard about it but don't know anything about it.

REST is an acronym standing for 'Representational State Transfer'.  Its an architecture style for network-based software systems first proposed by Roy Fielding in 2000.

This architecture style is mainly recommended for network based software systems which do not have complex requirements at both server and client end. An example of complex need will be, client should be able to send complex queries to host over web for retrieval of data. An example of simple requirement will be requesting a static html page from server.

The objective of this style is to design systems in as simple manner as possible to give them maximum scalability and ease of use.

The main features of 'REST' style of architecture are :

  • All resources should be available over http protocol.
  • Every resource should have a fixed named URI like http://productcompany/details/product1.
  • Stateless : All request from client to server should have enough formation so that server doesn't need to track requests from same client. This is to achieve maximum scalability.
  • Cache : Clients should be capable to cache responses where ever possible so that network trips can be avoided.
  • All interactions between client and server should happen using only following commands : GET, POST, PUT and DELETE.
  • All resources should have hyperlinks which can take client to details.

The best example of REST style architecture is classic Web with static HTMLs linked to each other.

REST is called 'Representational State Transfer' because as client moves from resource to other its state changes where the resource is accessed using named URI.

Although it was mainly recommended for accessing static data over web but with web becoming programmable through web services, it is now being compared with SOAP which is a style of transferring resources/data using web services.

Although web services can be designed in both REST and SOAP style, they are recommended in different kinds of problem space.

REST believes in fast and simple, so it should be used to build web services which are more oriented towards simple CRUD style of transactions but no or very less security requirements.

SOAP gives the power of tightly coupled systems to loosely coupled systems and is recommended for building complex, secure and robust network-based systems.

A very recent implementation of RESTful web services is 'Astoria' data services framework released by ADO.NET team at Microsoft.

Other Posts

    Tuesday, December 05, 2006

    * Architecture : When to use Web Services ?

    You can hear about Web Services everywhere now. People who dont know basics of RPC also will advice you to use Web Services. Although Web Services concept is the best thing to have happened to distributed computing, its also the over-hyped and over used phenomenon.

    Web Services should be prescribed only when following requirements exists :

    1. Interoperability : When various heterogeneous systems need to be integrated e.g. UNIX/Windows , J2ee/.NET , http/tcp. As each platform has its own distributed computing proprietary technology, Web service came as a common standard to communicate between different platforms.

    2. Loose Coupling : When two systems having different owners separated by WAN or firewalls which restrict any tight coupling between them. Like when two applications need to be integrated over internet with no control over each other.