On Wed, 16 Nov 2005 12:52:12 -0000
"Jensen, J (Jens)" <[log in to unmask]> wrote:
<SNIP/>
> Eventually the SRM 2s will converge (hopefully). For DPM both
> 2.1.1 flavours are supported but I believe at compile time.
>
> Yes, I know that wasn't the point of wsdl and service oriented
> architectures and all that. Welcome to the Real World (tm).
Sorry I don't wish to be disrespectful but the is not the real world
this is LCG. We are not real (tm) when it comes to specifications!
This is all an implication of specifications being the 2nd priority of
all involved in making them and that each contributor to SRM2 not being
able to put the time in to specifications so we just give up before the
specifications are finished and don't update them as issues come up. (I
know Peter and I both feel this is the MOST productive thing we could be
doing is add the details missed in previous specifications to V3). We
are an extreme programing community and using service orientated
architectures so we have two contradictory philosophies being bleed
together, essentially continuous redesign and upfront design. This is an
issue and SRM 2 is likely to be as poorly specificity in practise as SRM
1 and the interoperability testing and developments will take as long
and possibly worse than SRM 1 as more functions exist. SRM 3 is also
likely to be poorly specified and not resolve the issues due to the
catch 22 of no demand and no expectation leading to no improvement so no
demand and no surpassing of expectations which I still maintain SRM 3
does even if we have not finalised all the error handling/specification.
I see the formalism of web services and the unfinalised specification as
being a real double whammy for non High Energy Physics SRM contributions
which will be available just not working without interoperability work.
This is a great loss of free solutions and resources. IN2P3 provide one
for Bio-med already but physics will not need this implementation.
I don't want error conditions and developers interpretations to only be
resolved during interoperability testing between tier 1 labs in Physics
but that is the way its always been and may always be in LCG and the
cost savings of getting it right at design time are contradictory to
higher priorities like getting something done yesterday and showing we
are productive.
> You may have heard of SRM 3; it is more than a glint in Arie's
> [Shoshani, from LBNL] eye but is not finalised. It is cleaner
> than 2.1. Doesn't help though because (1) experiments have
> asked for 2.1 and (2) 2.1 does at least have a few implementations,
> and (3) did I mention it was not finalised?
>
> Of course I could be a pessimist and everything is delivered
> on time and works perfectly from day 1...
>
> Hope that helps clarify the issue. If not, do let me know.
>
> Thanks,
> --jens
I hope my explanation of what I see as Jen's pragmatic pessimism on
service orientated does not cause offence and illuminates why he does
not follow the W3C text book response in the area of SOA
interoperability.
I believe both XP and SOA development models have their place but not
in the design of SOA specifications and this is what I feel XP lets the
side down on the SOA being essentially oposite aproaches.
I also belive that people like me, too young to have worked with Corba
are relearning the mistakes people made with Corba some time ago.
Regards one and all, and remember these are my opions in this email and
are ment to illuminate rather than critisise. I support the SRM effort
100% and only hope this SOA API continues with its current trend toward
simplification.
Owen Synge
PS
XP stands for extream programming and much can be found on the WWW.
|