View Complete Post
When I create a REST data source to access a sharepoint list, I have permission issues because of the Forefront sever in front of my SharePoint 2010 server. I've tested in an environment without the Forefront server and it works as expected.
1. Tested in browser and works fine againsted forefront server (https://myforefrontserver.com/site/sub/_vti_bin/ListData.svc/MyList)
2. Added this to web.config
<proxy autoDetect="true" />
3. Created Rest Data Source in SharePoinbt designer pointing to
https://myforefrontserver.com/site/sub/_vti_bin/ListData.svc/MyList and tried all logon options with no sucess.
Out of ideas
We want to upgrade from VS2005 to VS2010. Before we do that, I would like some clarity about some things.
Can we build typical SOAP webservices with the 4 Framework as I could with 2.0?
Would a WCF Service allow me to have both REST/SOAP services in one application?
Is Framework 4 ONLY for REST services and I need to stick to 3.5 for SOAP?
I downloaded the free Web Developer 2010, but I cannot seem to get anywhere trying to figure this out.
Thanks for any input.
This month's column answers frequently asked questions about implementing REST.
MSDN Magazine July 2009
It's that time again. Time to answer some of the questions I get on a regular basis. This month I'll look at service orientation and policy-based compatibility, SOAP's transport-neutral design, and Web Services Enhancements (WSE) 3.0.
MSDN Magazine June 2006
MSDN Magazine March 2004
When creating a distributed system you frequently need to provide for communication between two entities that are not in sync. Microsoft Message Queue Server (MSMQ) provides the kind of store-and-forward messaging in a pre-built infrastructure that can help you address these kinds of messaging needs. In the past, MSMQ was accessed using a COM wrapper. Now there's a .NET wrapper that lets you accomplish your messaging goals easily from your Framework-based code. To illustrate the use of the wrapper, the author builds a messaging application, sends MSMQ messages over the Web, and discusses messaging security.
David S. Platt
MSDN Magazine December 2003
As more organizations adopt XML-based Web Services, the need for message-level security has become evident. WS-Security, now supported in the Microsoft .NET Framework, addresses this need. Using the WS-Security framework, developers can implement channel sinks to intercept Remoting messages as they pass through the .NET Remoting infrastructure. The sink can read the message, change it, and pass it along. During this process, the message can be signed for added security. This article explains how to implement a Remoting channel sink that will modify the Remoting message by including a UserName token in the header, then sign the body using the token.
MSDN Magazine November 2003
Web Services exchange XML messages. Most of today's Web Service toolkits do their best to hide this fact from developers, by exposing a Web Service's behavior as method invocations against objects instead.
MSDN Magazine March 2003
Direct Internet Message Encapsulation (DIME) is a new specification for sending and receiving SOAP messages along with additional attachments, like binary files, XML fragments, and even other SOAP messages, using standard transport protocols like HTTP. In this article, the author explains what DIME is and how it differs from MIME encapsulation. A detailed description of the message format and how it is parsed, as well as working with SOAP and extending it with WSDL, is also included.
Jeannine Hall Gailey
MSDN Magazine December 2002
MSDN Magazine November 2002
SOAP opens up a new world of Web Services, letting you make function calls across a network or the Internet. But this flexibility creates new problems when your app needs to wait for calls to return from halfway around the world. What you need is an asynchronous SOAP client that takes advantage of threading to continue execution while waiting for calls over the wire. This article covers the basics of building such a client with ATL.
Pranish Kumar and Bogdan Crivat
MSDN Magazine April 2002
In SOAP Toolkit 2.0, the Services Description Language (SDL) has been replaced with the Web Services Description Language (WSDL) and the Web Services Meta Language (WSML). WSDL and WSML files describe the interfaces to a service and expose COM objects to SOAP clients. This article describes a custom tool, IDL2SDL, which takes an IDL file and produces WSDL and WSML files without waiting for a DLL or TLB file to be generated. Also shown is a customized development environment in which WSDL and WSML files automatically reflect the changes to IDL files.
Carlos C. Tapang
MSDN Magazine April 2001
XML and HTTP are cross-platform technologies especially suited for building applications that can communicate with each other over the Internet, regardless of the platform they are running on. Web Services in the Microsoft .NET Framework make it easy to write components that communicate using HTTP GET, HTTP POST, and SOAP. An understanding of these concepts, along with knowledge of synchronous and asynchronous operations, security, state management, and the management of proxies by the .NET Framework is essential in building these applications. This article has been adapted from David Platt's upcoming book introducing the Microsoft .NET Platform to be published by Microsoft Press in Spring 2000.
MSDN Magazine February 2001
The new Simple Object Access Protocol (SOAP) Toolkit for Visual Studio 6.0 provides the infrastructure for developers to build, expose, and consume Web services. With a few exceptions that are outlined in the toolkit, the SOAP Toolkit complies with the SOAP version 1.1 specification. It includes the Remote Object Proxy Engine (ROPE), a Service Description and Code Generation Wizard, and code that provides ASP and ISAPI reference implementations of SOAP listeners. This article describes the tools and the object model of the SOAP Toolkit, and then demonstrates ASP and ISAPI implementations of a functional Web service using this toolkit.
MSDN Magazine August 2000
The Simple Object Access Protocol (SOAP) facilitates interoperability among a wide range of programs and platforms, making existing applications accessible to a broader range of users. SOAP combines the proven Web technology of HTTP with the flexibility and extensibility of XML. This article takes you on a comprehensive tour of Object RPC technology to help you understand the foundations of SOAP and the ways it overcomes many of the limitations of existing technologies, including DCOM and CORBA. This is followed by a detailed treatment of the SOAP encoding rules with a focus on how SOAP maps onto existing ORPC concepts.
MSDN Magazine March 2000