I'm pretty new to SOAP so go easy on me. I'm trying to setup a SOAP service that accepts the following header format:
<soap:Header>
<wsse:Security>
<wsse:UsernameToken wsu:Id='SecurityToken-securityToken'>
<wsse:Username>Username</wsse:Username>
<wsse:Password>Password</wsse:Password>
<wsu:Created>Timestamp</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
The application I'm incorporating this service into is an ASP.NET 3.5 web application and I've already setup a SOAP endpoint using WCF. I've setup a basic service to make sure the WCF works and it works fine (disregarding the header). I heard that the above format follows WS-Security so I added WSHttpBinding in the web.config:
<service name="Nexternal.Service.XMLTools.VNService"
behaviorConfiguration="VNServiceBehavior">
<!--The first endpoint would be picked up from the confirg
this shows how the config can be overriden with the service host-->
<endpoint address=""
binding="wsHttpBinding"
contract="Nexternal.Service.XMLTools.IVNService"/>
</service>
I downloaded a test harness (soapUI) and pasted in a test message with the above header and it came back with a 400 Bad Request error.
...for what it's worth, I'm running Visual Studio 2008 using IIS7.
I feel like I'm going in circles so any help would be awesome. Thanks in advance.
Figured it out. I was able to customize what was generated in the WSDL using MessageContracts (http://msdn.microsoft.com/en-us/library/ms730255.aspx). This allowed me to specify the format of the header. For each node that contained child nodes I created a class to represent that node and used .NET's serializing tools (e.g. XmlElementAttribute, XmlArrayAttribute, etc.) to specify how this should be reflected in the generated WSDL. DataContract could also be used although from my understanding DataContract was just for basic formats and don't allow you to really dive into how it's formatted.
Hope this helps anyone having similar issues.
If anyone that knows more about SOAP finds a flaw please let me know. Input is greatly appreciated.
Related
All,This question may be ignored everyday by us asp.net developer like air. If you think it is dumb, Please don't laugh. Thanks,
We knew the web.config is hosted in every Asp.Net web application. And It's syntax is restricted by the xml and DotNetConfig.xsd. The schema will describe what can be allowed in the web.config.
But When we look in a specified web.config.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
....
</configuration>
We didn't see any place to show this xml is based on the DotNetConfig.xsd.I mean any xml need to be validated should be documented which schema it is from
So that It can be validated in the runtime. Is that right ?
How does the validation works ? Could someone please tell me something about it .
Thanks.
web.config is not strictly validated against the XSD file at runtime. The XSD file is used by Visual Studio as an assistance to developers to avoid typos and other errors in known parts of the configuration file, however because .NET configuration is entirely extensible there is little point in performing XSD-based validation at runtime.
Some validation is performed by System.Configuration classes in the class library when they load configuration data, however per-element validation (in this sense) is the responsibility of the consuming configuration classes rather than the web.config loader/parser itself.
Is there any way to include documentation in the WSDL when publishing a WCF using "Biztalk WCF Publishing Wizard" or any other way?
The wsdl documentation tags are empty by default in the wsdl, example:
<wsdl:documentation>
<CreationInfo Created="2014-02-17 11:09:45Z"/>
</wsdl:documentation>
or
<wsdl:portType name="CustomerService">
<wsdl:documentation/>
<wsdl:operation name="RequestCustomerInfo">
<wsdl:documentation/>
....
Yes, but I'm ~95% sure what you asking can only be done with a custom Behavior.
I have a send port with a pipeline with an XML assembler. All my files that it creates look like this:
<?xml version="1.0" encoding="utf-8"?>
<Root xmlns="http://LMS.OIv2.Sierra.SierraRouteUpdate">
<Orders OrderCode="" SCAC="" CarrierName=" />
<Orders OrderCode="" SCAC="" CarrierName="" />
</Root>
How can I get rid of that xmlns attribute from the root node?
The use-case for this type of message processing is when integrating with legacy systems that do not implement a fully compliant XML parser. While "in theory", all systems should be able to handle valid XML, back in the real world I find a lot of applications still treat XML in the same way they treat a string or flat-file.
I've updated my blog post to include a sample Visual Studio project, showing the implementation of the code inside a BizTalk pipeline component. I hope this helps.
So as you may or may not know, BlazeDS (open source version of LiveCycle Data Services) is a nice way to get your server-side Java and client-side Flex application to play together. Unfortunately, it does have several pitfalls that need to be corrected. I'll try to explain one of them here.
All of BlazeDS's configuration is written via XML files in the flex/ folder of your webapp. The default names are separated for clarity, such as services-config.xml, remoting-config.xml, messaging-config.xml, etc. In these configuration files (particularly services-config.xml), Channels are defined; these setup URIs and objects used to capture and send information between the server and the client. In these config files, it is quite common to use a syntax like so:
<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
<properties>
<add-no-cache-headers>false</add-no-cache-headers>
</properties>
</channel-definition>
Unfortunately, what they don't tell you is that some of these key-in replacements (ie: {context.root}) are not replaced dynamically upon execution but upon compilation of the WAR file you intend to distribute. Obviously not a good idea when switching domains.
So, instead I seek to dynamically define these channels. According to the documentation, that's all good and fine, but it only works if the channel already exists when the webapp is launched. I feel like that sort of defeats the point.
So my question is, how do you truly create channels dynamically so that both the client and the server recognize their existence?
Read this blog post; I believe it is what you're after.
I believe these xml config files have no direct relation to the server at all. They are used to tell the SWF how to find the server.
During Compile time of your Flex App; the services-config information is, in essence, hard coded into the SWF.
Rather than calling it a question, i would like to call it a discussion and the topic is Flex Remoting. Forms and blogs explaining remoting in flex always mention 2 things:
service-config.xml
endpoint url
Now what i want to know is that
1. is service-config file actually needed if we need to bind our front end (which is in flex / air) with some database (mySql for instance). Coz i've done a couple of projects in flex and air and didn't use this config file. I used Flex 3. Though i used this config file in the projects i did in earlier version of flex 2.0 .
2. What actually this endpoint url does; could someone please explain it.
The way i implement remoting is like this:
<mx:RemoteObject id="remoteObj" source="MyPHPCls" destination="AMFPHP" result="remoteResult(event)">
<mx:method name="someServerSideMethod" result="onMethodResult(event)" />
</mx:RemoteObject>
Also if you could please tell me if the approach i am following to use remoting is incorrect.
Hope to hear from someone soon :).
Thnx,
Jatin
The services-config.xml data is compiled, or hard coded, into your application at compile time. You don't need to use a services-config.xml file if you don't want to; but if you want to use RemoteObject, that data will need to be available to your SWF somehow.
Here is a good blog post on setting the services-config file at runtime.
The end-point URL is just a URL to a Remoting Gateway.