Stefan, I think we agree on several things here, and maybe this is more a matter of emphasis. The main point I am trying to make is that the industry needs new and better tools for SO since OO is not a good match for SO design. Yes, you can use OO, but shouldn't we have tools that support SO directly rather than indirectly? Eric
----- Original Message ---- From: Stefan Tilkov <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, August 18, 2006 5:35:21 AM Subject: Re: MDA/UML/OO and SOA (was Re: [service-orientated-architecture] John on Gartner, AJAX & Assorted TLAs) On Aug 18, 2006, at 10:42 AM, Lukas Barton wrote: > Hello, > I wrote a thesis about MDA (only in Czech, see abstract athttp:// > www.archaebacteria.net/?p=5). > I mean that MDA as described by MDA Guide V1.0.1 and MDA > Foundation Modelfrom OMG forces OOAD (Object Oriented Analysis and > Design). MDA is now too object oriented. > The main problem is in tools (and you cannot do MDA without > tools). I learned that majority of tools support OOAD (Object > oriented analysis and design). Most of them only transforms class > models into static object structure. That’s useful. It could save > time during developmnet phase. Etc… but does not help with SOA. I don't understand this statement. First of all, lots of tools support generation from other models; e.g. it's easily possible to use UML activity diagrams to describe a business process and generate e.g. BPEL from it. Secondly, I don't see how generating WSDLs from UML class models "does not help with SOA". > OOAD is not enough for SOA. The world is not composed only from > objects (object model). There could be another views - service > oriented, event oriented,hirearachical or data (document) oriented > (mixture possible). Detailed example of OOAD inadequacies for SOA > were described at Elements of Service-Oriented Analysis and Design. The key piece from this article regarding OO seems to be this: "The main issue with current OO design practices in relation to SO is that its level of granularity is focused at the class level, which resides at too low of a level of abstraction for business service modeling. Strong associations such as inheritance, create a rather tight coupling (and, consequently, a dependency) between the involved parties. In contrast, the SO paradigm attempts to promote flexibility and agility through loose coupling. There, currently, is no cross- platform inheritance support and first-class notion of a service instance in SOA in order to avoid having to deal with service lifecycle housekeeping issues such as remote garbage collection." Which sounds like Eric's argument to me. To which I say: Don't use inheritance (even though WSDL 2.0 supports it, see http://www.w3.org/ TR/2006/CR-wsdl20-20060327/#Interface_extends_attribute), and don't model your services as "stateless classes" (or rather interfaces). As the authors write "current design practices", which is emphasized in the next paragraph: "These considerations make OO difficult to align with the SO architectural style straightaway. However, OO still is a valuable approach for design of the underlying class and component structure within a defined service. Furthermore, many OOAD techniques such as classes, responsibilities, and collaborations (CRC) cards can be leveraged for service modeling, if elevated up to a higher level of abstraction." Which is exactly my point - the fault is not in UML, nor OO, but in using it wrongly. Stefan > But there is no Rational for SOA, if you want to do SOA you have to > use at least five different tools. I dont know whether does this > mean that is too hard to make homogenous tools supporting SOA? > > My two cents, > > Lukas > > Yahoo! Groups Links Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
