Let's start with the DRY principle and how OSB supports it. DRY is important, no doubt. Working with a complex product I expect that I can easily implement something in one place and then just reuse it in several places.
Being an enterprise product OSB is no exception here. But looking at the "do not repeat yourself" possibilities provided by OSB I wonder what has happened to people who had added these possibilities to the product.
My guess so far is that the functionality available now was released by mistake. After a release it was too late to remove or disable it. People who have added this functionality were probably fired on the spot. And since then adding anything that actually increases reuse within OSB projects was a big no-no. I am almost certain that somebody working on the next version of the product is contemplating the possibility to disable copy-paste.
In OSB there are like two or three places where you as a developer (designer? mouse-driven integration architect?) can reuse some other component or piece of code. And even these possibilities are crippled. Like the notorious OSB XQuery support (emphasis mine).
The Oracle XQuery engine fully supports all of the language features that are described in the World Wide Web (W3C) specification for XQuery with one exception: modules. For more information about ...
But OK, let's talk about a specific example, like validating an XML message against an XML schema definition. Unlike other, no so enterpricey, products, OSB is "XML- or nothing- inside" technology. All messages are converted to XML when they received, they stay XML as they pass through OSB and only when a message leaves OSB it might be converted to something else. Quite a logical requirement that it is sometimes necessary to validate these XML messages against some XML schema.
For example, I am building an OSB proxy service that is accessible as a SOAP webservice, and I want to "XML schema" validate incoming messages. OSB provides such a possibility with a nice "Validate" message processing stage action. (Too many words? Do not worry, it is just some diagram element in the design palette that I can insert somewhere in the message flow of the service I am building.) I place it on the message flow and go about configuring it (more mousing around): specify what part of the message I want to validate and the schema element or type to validate against.
This was easy. Except... What is this story about selecting a schema's type or element? I guess somebody had to think hard to come up with such a way to validate XML against a schema. I have to select not only a schema but also an element or a type within that schema! (And do not get me started on the fact that the schema has to be present somewhere within the project. I can't specify URI, URL, reference to classpath or whatever.)
Remember DRY? Now imagine a webservice with 10 or 20 operations defined in its WSDL. As a matter of fact WSDL adds some complexity of its own here, like multipart messages. But let's keep things simple: these WSDLs all use messages with a single part. And now imagine you need to deal with 5 to 10 such webservices.
This can't be true I thought! Let's google.... Hmmm... Uguh... Aha, this way... I see.... And here?... So, that's it?... No, here is another one... Guys, can I have a different Google?
The search was not really useful except for one post. But it confirmed my suspicion. Here is the list of possibilities to deal with XML schema validation in OSB, both googled and the ones I came up with:
- Pretty obvious: ditch OSB in favor of something usable. Unfortunately won't work in most situations.
- Delegate: find some junior developer and ask him to do it. But it is cruel. This poor soul does not deserve such a torture.
- Much better delegation: find the person or persons responsible for choosing this product in the first place and let them do it. Ah dreams....
If you lucky this might bring discussion back to point 1 above. If you are not... Either way you don't have to work with OSB anymore.
Unfortunately this is not a realistic scenario either. - Fight against the requirement of XML schema validation. Explain. Demonstrate. Say Oracle is aware of the problem so when you migrate once more (like to version 50g) this functionality will be there for you to use.
- Follow a Scrum master. Redefine the definition of XML validation. Be creative. If you are lucky the requirements do not say explicitly "validate XML messages against XML schema". Maybe it's just "validate". Most likely you will have to perform some business validation anyway. Sheer by mistake OSB allows some degree of freedom here. Instead of having to write N XQuery files, drag-and-drop one "case" box and then another N expression boxes you can get away with at most (N + 1) XQuery files and 1 expression box. What a relief.
- Be creative. Ever heard about void*? java.lang.Object? xsd:any is your friend! Take your schema, copy it, change the copy to replace bulk of the existing definitions with xsd:any here and there and use this schema for validation. Nobody will notice anyway.
- Fight against the requirement of XML schema validation. Explain. Demonstrate. I know I have this one already above. But still if none of the above solutions worked try this one again.
- OK, you do not have a choice. XML schema validation is here and you have to implement it. Bite the bullet. If it is a single webservice with 10 or even 20 operations it is not a big deal to do it once. I mean, other options will cost more.
- You are lazy. This is good, really. What options are left? Again, delegate. But this time delegate to some non-OSB code. There are several possibilities: OSB java callout functionality, xpath external functions, even external web services. All these solutions have their own set of challenges which you would need to solve. And this will cost you. Time to build and test it, runtime performance penalty, whatever. I did not go that far yet. But it looks like I have got myself couple of volunteers who might just go all the way. We'll see what happens.
- Working with OSB makes you think. OSB actually encourages you to think. Or drink a lot of coffee. All that time it takes to start IDE or the OSB server, to stop the OSB server, and especially to do something in IDE.
I am sorry I can't drink that much. So I ended up thinking. I'll probably switch jobs. But while I am still here I am going to try something. One never knows...
Good post, thanks. As a newbee to OSB, I designed a first proxy service for the first operation of my WSDL. I added XML validation - pretty good. Then I checked how to factor XML validation so as to reuse it for my second operation. What a surprise! Like you, I am astonished that I have to copy / branch / select XML element, etc. Looks like Oracle has no shares in AspectOriented, Inc.
ReplyDeleteIvan dal Bosco
I agree completely with you. It's a rediculous design choice made by Oracle. I came up with a workaround, which works quite well. The trick is not to validate the SOAP body content, but to body itself to a newly created complexType which has a nested choice of all the input elements to your web service. This way you can stick to one Validate action in the incoming pipeline.
ReplyDeleteThe design choice was made long ago, before Oracle, by BEA I guess. And even then they were most likely forced by the implementation: OSB is heavily on XMLBeans.
ReplyDeleteAnyway, I tested something similar, except my first version was based on XML schema types inheritance, but it required also some changed to the content that has to be validated. Choice is a better choice here :-)
This works as long as the number of schema/wsdl files is limited. After all, one has to build the modified schema files. I could not imagine me doing it for more than 4-5 files.
Fortunately I do not have to do it anymore: I quit that project. OSB and its development tooling is such an unproductive and painful thing to use! I really glad I do not have to do it anymore.
Dude, you are hilarious, well-said. Been working with OSB for a year and a half now and consider myself a half-baked expert, not b/c I'm good, but b/c it's inevitable with time. What got me is the XQuery transformation engine does no validation, sh*t in = sh*t out despite whatever your schema says. And the Validate Action does not work with "nillable=false" attributes in your XSD. If you have to have data in an element, tough cr*p, you're SOL. Found a work-around xslt that will remove empty nodes (http://blog.ipnweb.com/2011/04/xsl-remove-empty-nodes.html, remove the //, no-no for xpath performance), then the validate works for required fields (still you can't distinguish b/w required tags and required data, but is good enough). Recently took Oracle's SOA Suite training, and guess what, that doesn't use XQuery at all, only uses XSLT (the Mediator). At least they are consistently inconsistent. There's some Schematron thing out there for Validation but they don't use it, probably b/c it works and is too simple to use, then they wouldn't need integration blah-blahs like us, so I guess we should be happy.
ReplyDeleteNice one but do think you have over exaggerated the problem a bit... It would be nice to have some more re-usability but the way you have written this is nice:P
ReplyDeleteNitin,
ReplyDeleteif you read my other posts you can see that I do exaggerate. Well, just a bit :-)
But in case of OSB... It looks like this product was made to disregard any sound bit of "good practices". Reusability? Testability? KISS? "Never heard of them".