Does XmlChoiceIdentifierAttribute break the 3rd tenet of SOA ?
The 3rd tenet of SOA, according to MS, states that "Services Share Schema and Contract".
When I use the XmlChoiceIdentifierAttribute in my shema, I actually say "when you call me, you will get in response one of the following possible types and you should check yourself the returned value to decide what you got from me".
In the SO point of view, does this decleration of "possible" types makes my contract less structured ? or does the fact that I declare the possible values in my contract (via the WSDL file) means that is it well-formed (and the fact that the client needs to evaluate the response ismeaningless from the SO perspective) ?
What's your opinion of this matter ?
Ido.
Hi Ido,
I believe this tennet means "don't (expect me) to overshare" that is - the contract should not reflect your internal structure. That does not mean you cannot have multiple options in the contract, so in my opinion, the fact that you offer multiple choices for something is not a problem.
You said ""when you call me, you will get in response one of the following possible types and you should check yourself the returned value to decide what you got from me" - but it should probably be ""when you call me, you will get in response one of the following possible types" - you shouldn't care what the other side does with your data
By the way, the alternate way to model the contract will be to include all the options and allow them to be left out - but I don't think it matters that much.
HTH,
Arnon
Hi Arnon,
So, for example, if I declare a web method as "can receive either one of the following types X,Y,Z" it's like overloading a method ?!
(I guess this is the appropriate way to overload a method in web services ? since the default WSI Profile doesn't allow "standard" c# overloading by name
If I understancd the 3rd tenent correctly :
- It is wrong to create a WS method receives/returns a string/xmlnode that holds the message as XML without a given schema (xsd)
- It is wrong if the schema is given, but not in a way which is visible to everyone who wishes to use this service (for example, tell it over the phone, write it as pseudo "what you give, what you get" in a document etc.)
- It is correct if the service method publish in a formal way (xsd/wsdl) the contract, even if the contract is not explicit (for example, a value can be of different given types, a method can return value of a specific type or not at all etc.)
I'm accustomed to setting contract definition as part of the code (method declaration, class definition...) and making it explicit as I can - Maybe it's time for me to add the "one of the following" rule into the "explicit" bucket in my brain.
Thanks,
Ido.
 Ido Flatow wrote: |
| So, for example, if I declare a web method as "can receive either one of the following types X,Y,Z" it's like overloading a method ?! |
|
Basically yes
| Ido Flatow wrote: |
| (I guess this is the appropriate way to overload a method in web services ? since the default WSI Profile doesn't allow "standard" c# overloading by name |
|
You shouldn't really face this problem if you keep a proper separation between the edge of your service (in your case the web method) where in coming requests are parsed and the service itself - which can have several behaviours (or overloads) as usual.
| Ido Flatow wrote: |
| If I understancd the 3rd tenent correctly ... |
|
The way I see it (and not everybody thinks so) SOA is an architectural style which is not tied to a specific technology (though web services is a common technology to implement it) - you can read more on my opinion on SOA in the following presentation http://www.rgoarchitects.com/Files/SOA.ppt
So in this respect, the importance of the possibility for the contract to be machine enforceable can important on two counts
- If the technology used support it at all (for example plain messaging)
- Where is the service going to be deployed and what's relation with the service consumers (for example it is more important the the schema be strict and verifiable if the service is deployed on the web for general consumption vs. it is being deployed fro internal use by other services within the same company)
HTH,
Arnon
Ido,
I think the biggest problem I would have with a service that uses this is that it doesn't adhere to the first tenet of SO (Service Boundaries are explicit). You start to touch on it in your second response here so I think you're already thinking this. This type of service whether it is targted for use within an organization our outside will be very challenging for consumers to use.
I do like Arnon's response though that SOA is really not about a technology. The fact that you can do this doesn't necessarily make the technology feature a poor one. Web services can be built for non SO reasons. With that said, if you are exposing some meaningful business logic this way then I would say you have a problem. Well defined inputs and output are critical if you want your service to be self describing and easy to use.
| Mr. SOAPitStop wrote: |
| I think the biggest problem I would have with a service that uses this is that it doesn't adhere to the first tenet of SO (Service Boundaries are explicit). ... Well defined inputs and output are critical if you want your service to be self describing and easy to use. |
|
I don't think that the fact that there may be several outputs from a contract necessarily means the boundaries are not explicit (it may or may not be the case for Ido) - you are right though that it is better to have the contracts as clear as possible. Integration is hard as it is without adding ambiguity
Arnon
I have to admit that I do not know exactly how the XmlChoiceIdentifierAttribute works but it sounds like it will return some untyped message in raw XML and it'll be up to the consumer to to figure out how to cast it into the appropriate type. Which I guess you'll have in the WSDL so you can at least do some type of strange reflection thing.
Everytime I hear anything about a service that requires something like this I always feel like it is a violation of that first tenet. Am I wrong? Another example is services that return some type of internal error code that a consumer needs to read documentation to figure out what it means. In my mind these types of design decisions have significant parallels ... both of which are decreasing the explicitness of how a service communicates to a consumer.
First of all, since I had the same problem with the idea of untypes messages, I took the time to inspect how XmlChoiceIdentifierAttribute works (how the WSDL looks like, how the proxy code is generated, how it handles error and how non-.net apps sees the messages and wether or not they can parse them) and I have to admit - It seems that MS did a good job on this attribute.
As for the first tenet, I'm still having problems with the "one of the following" type of messages, but as I said, I'm trying to adapt. I think of it as follows:
- We usually declare our services as "can return a message", so what is the difference between "You may receive a response, but you might not" and "you can send a message that contains A or B", it's actually quite the same when you think of it
- As long as the contract defins specifically what A and B can be, I'm starting to see how the first tenet is not violated (as long as you follow the "rules" so called, the service will do what you requested)
As for the internal error, I usually do the following:
- Log the error before exiting the service
- Create a new SOAP error (exception) with minimal info ("The requested service failed") and that error includes (innerException) the original error
This way, if someone receives my error and they are not familiar with my errors - they will get a simple soap error. If they are familiar with my error, they will have the ability to inspect it further.
BTW, I discussed this issue with on the microsoft regional directorts in europe, and what he suggested was that the WS doesn't throw error at the client, but instead, returns with every message some sort of warning/error data (think of it as a message that contains returned message and a possible error string).
I myslef don't have a problem with that solution (I still wonder how java programmers parse a .net exception ...), but unfortunatelly for me, I see this type of error handling and reporting as an infrastructure solution for my whole organization (one may call it "shared enterprise infrastructure"), so I don't intend of using it right now (I'm waiting for someone to take the initiative).
Ido.
| Ido Flatow wrote: |
| As for the internal error, I usually do the following: - Log the error before exiting the service - Create a new SOAP error (exception) with minimal info ("The requested service failed") and that error includes (innerException) the original error This way, if someone receives my error and they are not familiar with my errors - they will get a simple soap error. If they are familiar with my error, they will have the ability to inspect it further. |
|
If there's anything I can tell you about passing the exception across the service boundary - it's DON'T
this principle is even true for layers within the same application - it is even more important across service boundary. - if someone actually does anything with your internal error she will be dependant on your implementation, very bad move for loose coupling.
The suggestion you've got is more plausible, also if you have an request/reaction semantics (I don't say request/reply since I think that is not a good SOA pattern either but that's another story) it is possible to add an error message in the contract
The fact that that message is part of the contract means that it will also get the same respect (i.e. not change as easy as internal implementation). By the way it shouldn't bubble into your service either (should be contained in the edge)
Arnon
