Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Stadiumite

  • Rank
  1. There's a debate going on within my company and I'm seeking outside opinions.We're building web services for internal use, for communication between applications. Initially we were not using SOAP at all. Our services were delivered by MQ. Within the payload of these messages, we established a "header", which gives some context to the service (transactionID, sourceID, DestinationID), and had some exception handling.Now that we've moved to SOAP, we're using the fault constructs, outside of our payload, for exceptions.There is a camp that believes that we should move the context information out of the body and into the SOAP header. The argument is that the payload should only contain business objects. Anything "systemy" belongs in the header.There's another camp that says the context has to remain in the body, because there are some circumstances where the header will have been stripped off from the body, and the consumer will still need the context information.I tend to agree with the use-the-header camp in principle. But I have difficulty with the details. SOAP header is an "any" that depends on the use of some other schema to define its contents. There seems to be a sea of cryptically explained SOAP header extensions. I'm at a loss to know which ones I should consider using or how to map our existing context data to them. Anyone else out there facing this dilemma?
  2. For some time now, I've been working with a large set of XML request and response messages that are delivered by MQ. We've gradually started to migrate some of these existing messages to web services, and some new projects are introducing web services.Our MQ messages had a set of data within the payload that we called "the payload header". This included a transacationId, an identifier for the requesting application, an identifier for the responding application, and an identifier for the environment (test, prod etc.) in which the service exists. The question has come up as to whether or not we should continue to keep this "payload header" information inside the body, or if we should move it into the SOAP header.There is an assumption that I've been making that I'm beginning to believe is false. I felt that somewhere within a standard or recommendation from w3c or oasis there would be header elements already defined that I could map my payload header elements to. Then we'd be in compliance to an industry standard, and get all the benefits that go along with that. But as I look around, I'm not finding the elements that I expected in things like WS-SEC, the addressing standard etc. Googling around, I see lots of examples on various forums where they seem to have extended the soap header with a proprietary schema to contain the sort of information I'm talking about. Am I just looking in the wrong place? Forgive me, this is a new area for me. We could easily move our existing payload header out of the body and into the SOAP header. But I would have thought there was a standard that I could follow instead.
  3. In an XML instance based on a schema, I can have something like this:<Message xmlns="http://www.whatever.com/xxxx/myXML"'>http://www.whatever.com/xxxx/myXML" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.whatever.com/xxxx/myXML {path}/ServiceXYZ.xsd">I'm declaring that this message is based on a particular namespace, which is defined in my schema, and I declare where that schema can be found.Am I correct that I can't do something similar if my Message is defined by a WSDL instead of an XSD? I can declare a namespace for a WSDL, and I can declare in my instance document that it complies with constraints of that namespace. But I can't mechanical verify that Message is really valid? This seems like something that's very natural to do. I'm really surprised that it's not there.
  4. Thanks for the hint. I must have looked at that spec 100 times and I didn't pick up on that.
  5. P.S. This is the recommendation that I mentioned http://www.w3.org/TR/xmlenc-core/
  6. I've been working on passing some encrypted data in XML messages. There's a w3c recommendation that defines an EncryptedData type. Within that type, you can pass the value you want to encrypt as "CipherData" <EncryptedData> <xenc:CipherData> <xenc:CipherValue></xenc:CipherValue> </xenc:CipherData> <xenc:EncryptionProperties> <xenc:EncryptionProperty> <!--IV?????--> <ds:KeyName></ds:KeyName> </xenc:EncryptionProperty> </xenc:EncryptionProperties> </EncryptedData>The type has lots of elements defined within it, for representing details about the encryption that you may need to pass tothe consumer for decryption.If I'm using an encryption method that requires the encryptor and the decryptor to use the same Initialization Vector (IV), I would think that I should be able to represent that IV somewhere in the EncryptedData block. But I haven't been able to figure out exactly how. It's not a key, so I don't think it belongs in ds:keyInfo. None of the other elements seems to be an exact fit either.If I'm going to bother to follow this recommendation, I want to do it correctly. Nothing I can find tells me how to do this. Is the IV somehow embedded in CipherValue?
  7. For the last 18 months or so, I've been creating services from a Rational Rose UML object model. The model is set up sothat operations can be defined on interface classes. This definition includes input and output parameters.I have a generator tool that exports these operations to DTD, XSD, or WSDL. In the case of schema, the operation becomes two complexTypes; one for the request and one for the response. Each input parameter is an element within the request. Each output parm is an element within the response. Classes that those parameters are dependent on also become complexTypes.With DTD or Schema, I can use XMLSpy to "Generate Sample XML", and choose the Request type (or the response type) as theroot. Then I can fill in the contents of my message, and validate it against the schema. So I can produce a sample requestmessage and a sample reponse message.Then I pass the sample messages and schema on to developers who develop code that produces messages that adhere to the schema, and to architects who publish that schema as a contract with our consumers. Make sense?In today's world our services are queue-based. So it's just fine to represent them with a schema.But soon, we'll want to be doing web services. So I want to use a WSDL.I've been playing around with WSDL for the last several days to figure out how to do this, and I am baffled.There seems to be no tool that lets me generate a sample message against a WSDL, in the sense that I could with DTDor XSD. The best I can do is "Create SOAP Request" from the SOAP menu in XMLSpy Enterprise Edition. But that only generatesa request, not a response. And (annoyingly) it creates a tag for every possible element in the message, so the message is sohuge that you can't work with it.Also there's no mechanism to validate messages. So when my customer asks me, "What will our messages look likewhen we're using web services", I can't really answer them. Even though I've declared types in my WSDL, there's no mechanism to actually link the instance documents that represent the request and response to that WSDL. Why did I bother to definemy types at all?I've actually used two different approaches. In the first case, my types are defined within the WSDL itself. In thesecond case, I've imported a schema, and the types of my messages are defined by it. Like this: <xsd:complexType name="serviceXYZRequest"> <xsd:complexContent> <xsd:extension base="importXSD:serviceXYZRequest"/> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="serviceXYZReresponse"> <xsd:complexContent> <xsd:extension base="importXSD:serviceXYZResponse"/> </xsd:complexContent> </xsd:complexType> <message name="ServiceXYZRequest"> <part name="serviceXYZ" type="myWSDL:ServiceXYZRequest"/> </message> <message name="serviceXYZReponse"> <part name="serviceXYZ" type="myWSDL:ServiceXYZRequest"/> </message>Then in my request and response instance documents, I can validate the contents of the message against importXSD. But thisis still only part of what I want to do. If I were to declare attributes or additional elements on the type declaration in the WSDL, there's no way to validate them.
  • Create New...