Hi I'm really stuck on getting my SOAP messages to work. I've tried many approaches but they all have the same problem in common: they don't have a security header. The security header needs to contain a username and password. In VB.Net this is done by:
userNameAssertion.UsernameTokenProvider = new
UsernameTokenProvider(username, password);
Policy policy = new Policy();
policy.Assertions.Add(userNameAssertion);
proxy.SetPolicy(policy);
Two routines which I am developing which don't work are at the end of this message. There is a third which uses the MS SOAP Toolkit 3, but this gives so many errors it doesn't seem worth using if it's not necessary. If it is, then the errors alternate on first run are "class not registered" but subsequently "no such interface supported". That error occurs on the line:
Set sc_partservice = New SoapClient30
Any help to get this working will be greatly appreciated! Thanks David
Dim ENC As String
Dim XSI As String
Dim XSD As String
Sub SOAPsuds()
'Define Envelope Constants
ENC = "http://schemas.xmlsoap.org/soap/encoding/" 'Encoding
XSI = "http://www.w3.org/1999/XMLSchema-instance" 'Schema Instance
XSD = "http://www.w3.org/1999/XMLSchema" 'Schema
'Define Envelope Variables
URL = "omitted" 'Web Service
Uri = "omitted"
Method = "omitted" 'Web Method
'Instantiate things
Dim Connector As SoapConnector30
Dim Serializer As SoapSerializer30
Dim Reader As SoapReader30
Set Connector = New HttpConnector30
Set Serializer = New SoapSerializer30
Set Reader = New SoapReader30
'Prepare the Connector to talk to the SOAP Server
Connector.Property("EndPointURL") = URL
Call Connector.Connect
Connector.Property("SoapAction") = Uri & "#" & Method
Call Connector.BeginMessage
'Associate Serializer with Connector
Serializer.Init Connector.InputStream
'Start the SOAP Envelope and specify the Encoding and XML-Schema
Serializer.StartEnvelope , ENC
Serializer.SoapNamespace "xsi", XSI
Serializer.SoapNamespace "SOAP-ENC", ENC
Serializer.SoapNamespace "xsd", XSD
'Start the body of the message
Serializer.StartBody
Serializer.StartElement Method, Uri, , "method"
'Write each method parameter out as a child to the root element
Serializer.StartElement "Author"
Serializer.SoapAttribute "type", , "xsd:string", "xsi"
Serializer.WriteString "Wilde, Oscar"
Serializer.EndElement
'End the root element, the body and the envelope
Serializer.EndElement
Serializer.EndBody
Serializer.EndEnvelope
'Ending the message causes it to be sent
Connector.EndMessage
'Load the result into the Reader
Reader.Load Connector.OutputStream
'If ok then pull result out of DOM
If Not Reader.Fault Is Nothing Then
MsgBox Reader.FaultString.text, vbExclamation
Else
Set Result = Reader.Dom
'//parse the DOM to extract the result set
End If
End Sub
Dim oDoc As MSXML2.DOMDocument
Private Sub WSTest1()
On Error GoTo ErrorHandler
'Define Services
Dim PartService
Set PartService = CreateObject("MSSOAP.SoapClient30")
PartService.MSSoapInit URL 'string substituted
xmlSchema "C:\Documents and Settings\User\Desktop\SOAP XML VB\Schemas\Request\GetByIDRequest.xsd"
'Query Services
test = (PartService.GetByID(oDoc.documentElement))
Exit Sub
'Handle WSDL Errors
ErrorHandler:
If Err.Number = -2147024809 Then
MsgBox "run-time error: '" & Err.Number & "':" & Chr(13) & Chr(13) & Err.Description & Chr(13) & "This is a WSDL Error"
End If
End Sub
Function xmlSchema(StrXML)
Dim fSuccess As Boolean
Set oDoc = New MSXML2.DOMDocument
oDoc.async = False
oDoc.validateOnParse = False
fSuccess = oDoc.Load(StrXML)
If Not fSuccess Then
MsgBox oDoc.parseError.reason
End If
End Function
| | m4r5 | You know the SOAP Toolkit is obsolete, right? And that it was created before the WS-* standards existed? John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
| | John Saunders | Hi John Yes I know, but then everything becomes obsolete after a time. I've actually managed to resolve the issues with the toolkit, but all it does is build a class for you. Once that class exists the tool used to make it is irrelevant. So I have my class, and I can now asign it to an object without any problems. I now need to add a security header to my soap message which is achieved in vb.net by:
userNameAssertion.UsernameTokenProvider = new
UsernameTokenProvider(username, password);
// Set the policy onto the proxy
Policy policy = new Policy();
policy.Assertions.Add(userNameAssertion);
proxy.SetPolicy(policy);
So far I haven't found any articles (or encountered any programmers) which have the information needed to do the same thing in VB. Generally people say you need WSE, which by definition is nonsense. What I hope they mean is "It's easier to use WSE". Regardless, this has to be done in VB or from a library like CSoap. The same issue of the header will exist with CSoap, so I may as well do it all in VB. It has to be VB to plug into the CAD app. So, I need to add a security header, which I believe is just some xml in the schema made by WSE. According to the whole internet though (this is day 5) no one's ever done that before. | | m4r5 | The people who say use WSE are badly mistaken. WSE is obsolete. WCF should be used for all new development of web service clients and services. BTW, I disagree that the tool used is not relevant. If the tool is not supported, bugs won't be fixed. If the tool is badly out of date, you won't find new developers who know how to use it. If the tool does not make it easy to work with modern scenarios, then you'll be stuck with ancient ones (i.e., COM).
John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
| | John Saunders | Well, yes, but the tool just made the classes and they work fine now. Better to use it than to write them all out manually. I have been surprised by the difficulty of this task. It seems that the availability of modern tools means that very few people actually know what's really going on. I would much rather understand this before using the new tools. That said, I'd just take any solution at the moment. Thing is, .net isn't an option. It might be easy, but we're talking about sending XML over HTTP. It can't be hard. If I knew the format of the header made by WSE - which even the Web Service vendors advise, or some terminology appropriate to the equivilent of userNameAssertion.UsernameTokenProvider in vb6 then i'd be a lot better off.
| | m4r5 | But you're not using a modern tool - you're using an ancient one. The SOAP Toolkit was one of the first tools from Microsoft to deal with web services. It does an OK job of dealing with the web service standards that were in place at the time it was created, but has no flexibility or extensibility. As a result, it is totally incapable of dealing with the changed standards. I doubt it can even deal with SOAP 1.2! You would find this so much easier if you would use WCF. This is a typical scenario, but by insisting on remaining in the past, you're complicating it enormously.
John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
| | John Saunders | But John it's a toolkit. It made a class. Even if you wrote that class in VB.Net and used WCF you'd still need to add the security header. The toolkit really has no relevence - it's the language. Let's pretend I worte the classes by hand and now want to add security headers in VB. As I've said .Net isn't an option. I could explain why in the next few paragraphs but see no need to. If you don't believe that then fine. It's not like you're helping anyway.
| | m4r5 | No, if you used WCF you would not have to add the security header. Assuming the header was described in the WSDL, it would be done for you. If the toolkit understands your scenarios, then it can help. A toolkit developed before security headers existed will not be very helpful.
John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
| | John Saunders | Why are you so hung up on this toolkit? It made a class. It isn't relevant AT ALL! For goodness sake. I get that you have a point. You're point is "If you use tools that do the job for you the task will be easier". Thanks very much for that, I never would have worked that out without you repeating it so many times. I also get that it would be nice if the class already had the security header in it. However, given that WSE doesn't even have that ability I'm not too hung up on the missing feature. If you know how to add the security header then please say so. I have told you lots of times that .net isn't an option, so I don't know why you're wasting my time and yours telling me more about it. I'm sure it will also prove an amusing waste of time for anyone else who reads this thread in the future with the hope of actually achieving something.
| | m4r5 | Wait, "Assuming the header was described in the WSDL, it would be done for you".... Well I know that!! Obviously it isn't in the WSDL else the ancient toolkit that you despise so much would have done it too!
| | m4r5 | It fascinates me how you move between talking about the obsolete SOAP Toolkit and the obsolete WSE (Web Service Extensions). These were replaced for good reason. Now, as to telling you how to use the obsolete tools to do this job, I don't know, because I never learned how to use the obsolete tools. I'll shut up now, and maybe someone who knows how to use them will answer you. I simply wanted to make sure you were aware they're obsolete. Some developers find these tools through Google, and don't realize they're obsolete, so I try to make sure everyone is aware of that. If you've decided to use obsolete tools regardless, then go right ahead. I do suggest you keep an eye on the support status of these tools, however. I expect them to actually become unsupported fairly soon.
John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
| | John Saunders | No. If it was a header defined in one of the WS-* standards, then the tool would not have known about it. The fact that you were also talking about WSE (version 3.0, I hope) suggested that this was a WS-Security header of some kind.
John Saunders
WCF is Web Services. They are not two separate things.
Use WCF for All New Web Service Development, instead of legacy ASMX or obsolete WSE
Use File->New Project to create Web Service Projects
| | John Saunders | WSE, if I were using it, would be relevant as it is called when the code is run. The SOAP Toolkit is not. It can be installed, used, uninstalled and never even known about on the machine where the code is run. Perhaps you can't comprehend the difference. Since you don't even know this I'm inclined to assume you don't know what you're talking about at all; and since you have completely failed to pick up on every relevant point despite them being explained many times I also don't think you're someone worth talking to at all. The strangest thign about your replies is your love of WCF because "No, if you used WCF you would not have to add the security header. Assuming the header was described in the WSDL, it would be done for you." which is a feature you got in WSE anyway (which I'm not using, remember? and don't want to, remember?) and the Toolkit which just builds a class based on the WSDL. You clearly have a hatred of all thing from the past as can be seen on the main topics page. And have you picked up on any of my questions and given even a partial answer to anything at all.... erm, no. Neither havve you made any valid points that weren't already obvious to even the most half-witted of individuals. You also seem to have no idea about real world scenarios. Did it ever occur to you that a web service may belong to a different company and be ASMX? I'm sure it didn't based on what I've seen here. Maybe you'd want to multiply that by a few thousand web services, which incidentally (in this case) have nothing to do with WCF. They ARE different things. Amazon is quite happy to stick with the old methods. That must drive you nuts. Haha. Dont' loose too much sleep over it. You could write to them will all your excellent points like, er, ...oh, well nevermind.
| | m4r5 | If I may, I'd like to go back to a comment that was made earlier in the thread:
>So, I need to add a security header, which I believe is just some xml in the schema made by WSE
Well, yes and no. It's a little bit more than that. WS-Security (the spec from which this particular header is taken) is a protocol, meaning that it defines specific schemas as well as strict rules for processing those schemas. In this case, those rules govern things like the signing and encryption procedures necessary to provide the cryptographic guarantees that motivate the usage of the specification in the first place. Those rules are rather complex and definitely not something the average application developer would want to be attempting to recreate without help from a framework (think of ws-security sort of like SSL -- very few folks want to write their own SSL libraries either).
Things like the SOAP toolkit (which was written before these protocols existed) can generate classes to model the protocol schemas but have no idea about the processing rules that make up the rest of the protocol.
The Microsoft platform has great support for advanced Web Services standards like WS-Security via Windows Communication Foundation (WCF). WCF, as I'm sure you're aware, is a managed framework and as such isn't directly usable from unmanaged VB/VBA. However, there is a way of making this work -- see the COM Moniker sample here: http://msdn.microsoft.com/en-us/library/ms752245.aspx
You might also find this blog entry to be informative, as it describes a somewhat similar situation: http://www.hanselman.com/blog/BreakingAllTheRulesWithWCF.aspx
I'm sorry that you're finding things to be more complex that you would like. Hopefully the information above helps you move forward. -steve
Brain.Save() -- http://hyperthink.net/blog | | Steve Maine | Hi Steve That's some excellent info. Thanks. Perhaps my best bet would be to write a dll in c# and utilise that somehow from VB. I can write the dll easily enough, but I don't know if I'll encounter difficulties in utilising it from VB. Any thoughts? Thanks David
| | m4r5 |
|