RE: [AM] MDA & web services/SOA

Jason Gorman sent on Wed, 25 Feb 2004 13:24:31 -0000
>
>Folks
>
>I've been working on a project recently to put together a set web services
>for a client in the tourist industry, and it occured to me after a while
>that this is one area where something like MDA could prove invaluable. It's
>also an area where traditional analysis and design techniques may fall 
>down.
>
>For starters, there's the rather thorny problem of rules. We have a large
>domain model, with plenty of juicy constraints that are enforced on our
>servers, but when the clients generate their "dumb" proxies in Java, C# and
>wotnot, they get none of that. The only way to know if they've broken some
>rule is to "suck it and see" by calling the web method and seeing if our
>system complains. From a performance perspective, given the sheer size of
>some of these SOAP requests and the volumes involved, not the best 
>solution.
>
>Now, we have all our constraints neatly packaged away in classes that
>inherit an interface, IRule (geddit?), which are applied to incoming domain
>objects depending on their type. For a .NET client, we could quite easily
>package all this up into a validator component to be used client-side. We
>could also do it for Java, but would obviously have to rewrite 300+ rules 
>to
>achieve that against our own mock-up Java proxy. Then, we could do the same
>for the VB/C++/COM clients. And so on...
>
>There's also the problem of web service proxies not being able to take
>behaviour with them, so my nice neat AddRating(rating : Rating) method on
>Product stays strictly server-side. Client developers end up with a lot of
>extra code to write to build the complex objects they must send to our
>servers, and there's no point in their adding them to the proxy code itself
>because their SOAP client tools will just overwrite all that the next time
>they update the web reference. It's also a major imposition on people who
>"don't need to adopt your web service" if they don't feel like it!
>
>Now, if we could specify web methods in UML, and the constraints and
>operations on intermediate objects (objects specified in the WSDL file that
>defines the web service) so that a complete, functional proxy could be
>created - well, that would have saved us a whole heap of trouble and would
>be one less obstacle to the web service being adopted in the round.
>
>I think the term being bandied about is Service Oriented Architecture - so
>my question is this: does MDA go with SOA? And, given Gartner etc are
>predicting SOA to be the next "big thing" (and I already see it happening 
>in
>the marketplace as clients scale the web service learning curve this year),
>should we not now accept that MDA may also be an accompanying "megatrend"?
>I'm already perceiving a real growth in interest in both of these - and in
>connection with each other - in the marketplace this year. (I think it's 
>all
>bollocks, of course, but that's what I perceive...)
>
I don't think MDA goes with SOA specifically. I think the big thing with SOA 
is that lots of people who have never done it are jumping on the bandwagon. 
It is easy to say Web Services and SOA are the next big thing if you don't 
have to show anyone how to do it.

Web services and SOA appear very simple on the surface, but the actual 
implementation tends to be far more complex than anyone predicts. The 
problem doesn't tend to be the happy case, but as you've found, the unhappy 
case.

I've noticed most of the documentation talks about one application calling a 
web service provided by another application (both IBM and Microsoft claim 
this). My experience is that this is rarely a good idea in practice as it 
creates dependencies and expectations. Where I've seen services work 
successfully there has always been what I term a service orchestration 
layer, and normally a business process layer as well. The service 
orchestration layer effectively acts a broker between service requestors and 
providers, ensuring the request and response are properly formulated. This 
puts the broking, routing and transformation logic in the centre and 
abstracted from any one individual application. The basic sequence then 
goes:
1) Client makes request
2) Broker intercepts request and determines appropriate provider.
3) Broker transforms request to suit provider interface and calls provider.
4) Provider does its stuff and returns response.
5) Broker intercepts response and determines original requestor.
6) Broker transforms response to suit requestor interface and returns 
response.
An alternate publish/subscribe sequence goes:
1) Provider publishes event.
2) Broker determines subscribers to event.
3) Broker transforms event data to suit subscribers interfaces.
4) Broker calls subscribers to process event.
5) Subscribers provide a response to the event.
6) Broker works out what to do next depending on whether the response is a 
request or an event.
Often the broker will access a BPM or Rules engine or both to determine what 
is an appropriate action to take.

For services to be scalable they need to be at a relatively high level of 
granualarity and to not predict or expect a particular sequencing of events 
or requests. Because any one application cannot predict whether another 
application has taken an defensive approach or not defensive programming 
assumptions have to be made, but it is far better to put the defensive 
programming aspects in front of the service rather than behind the service. 
This allows for these aspects to be switched off without affecting the 
service.

Hope this makes sense and helps.

Regards

Ian Chamberlain

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------