On Aug 18, 2006, at 2:15 PM, Eric Newcomer wrote: > 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? > Well, yes and no. I had a discussion about this some time ago: http:// www.innoq.com/blog/st/2005/01/05/uml_mof_and_generic_interfaces.html
The main point being that a tool designed specifically for SO (whatever that means) will be good for this one purpose, but only interoperable with other modeling languages to the degree it shares a common metamodel core with them. UML is at one extreme -- trying to support every modeling concept you could possibly need in one language. UML 2 even includes quite a few that don't map to any programming language I'm aware of. The other extreme would be MOF/ EMOF -- two languages defined in MOF can be very specific and don't need to have much in common. There's good reasons for both approaches. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ > 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/
