Hi Eric, Comments inline. I've also changed the subject ... a gut feeling tells me this is going to be a long thread :-)
On Aug 17, 2006, at 3:38 PM, Eric Newcomer wrote: > > Hi Stefan, > > Certainly you can use UML to create services - as has been > mentioned many times in this forum you can really use any > technology, including procedure oriented technologies such as COBOL > or PL/I. > > I agree EMF is simpler uhm .... I'm not sure I said it's simpler - it's just (depending on how you use it) on a different meta level. > and it is easier with EMF to create a modeling language for > services, and we are currently currently working along those lines > at the Eclipse STP Project. Microsoft has recently also released a > Web service software factory, which also looks on first glance to > be more service oriented. > > But the point is more about what's better suited to service > orientation, and because UML is object oriented it forces the same > kind of mental translation as you'd have to do in going from > procedure orientation to object orientation or service > orientation. Why not work with tools more suited to the SO concept? I honestly don't see this point. In OO modeling with UML, an interface containing methods (or operations, if you prefer) is a first class concept. As is something that implements this interface. Sounds very service-oriented to me. You can use a UML class model to describe a graph of data objects, or entities, or whatever you prefer to call them. There's not a 1:1 mapping to XML, but many (excluding me) agree this is not a SOA requirement. You seem to confuse concepts here: Using UML for modeling, or more generally, doing object-oriented analysis, does not mean that you have to end up with tons of (identifiable) objects that have methods somehow forced on them. Singletons - objects that are instantiated only once - are basically indistinguishable from modules. > > Objects are really overkill for software design. I believe it's > time to basically turn back the clock and reject objects as the > conceptual basis of modeling software. OO creates more problems > than it solves. (Implementing services using objects, procedures, > queues, etc. is ok but let's not design them that way.) It is much > better to model, design, and develop using services natively. I don't even know what this means! If you argued that it's better to develop Web services are better developed starting with explicit XML document design, I would probably agree - but describing SOA as an abstract, architectural concept, and then rejecting a general, abstract modeling language such as UML, seems contradictory. What methodology (and *available* tooling) would you recommend to someone who wants to model services now? > Most software applications are designed around implmenting > functions rather than things. > ... which is perfectly doable based on OO analysis ... > > Modeling services such as "get customer data" as the "get method on > the customer object" is overly complex, .. no one forces you to do that. What's the name of your service? CustomerManagement? Design a CustomerManagement interface, exposing a getCustomerData() method, and have it implemented by CustomerManagementImpl. What's the conflict with SO? > and assumes that it's useful to categorize the world of software in > terms of "things" before you can use them. Ultimately we end up > trying to resolve unnatural and impossible mappings such as OO- > Relational and OO-XML, which creates even more difficulties. I totally agree the O/X and O/R mapping are a PITA, but that's totally beside the point here IMO. I find this really strange - every time I claim that SOA requires XML, people start screaming at me that it's an abstract architectural concept, independent of any technology. But when I suggest to use the most widely spread, supported, available analysis and design notation - UML - , they cite problems with O/X mapping :-) For the record, my preferred approach (next to REST) for SOA is to start with XML document design, not objects in any programming language, nor WSDL. If UML is used, I prefer to reference XML Schema types (identified/mapped via their namespace) from the UML models. This enables the usage of the many useful UML 1.x and 2.x diagram types without the burden of O/X mapping. And it makes MDA-style WSDL and implementation code generation easy. > > > Software tools need to improve the level of abstraction, not > introduce additional complexities. The purpose of software is to > allow humans to tell computers what to do, and it therefore needs > to be as simple and natural as possible. Objects are counter- > intuitive since computers are all about executing functions (i.e. > it all boils down to CPU instructions), as are businesses for that > matter. MDA and UML do not really help since they expect us to > first learn how to reinterpret the world of functions into objects > with methods. At the risk of repeating myself: not true. I fail to see the difference here. Unless you mandate XML (or the XML Infoset) as the data model, I clearly see OO (as supported by UML) as a superset of SO. > As you said you can definitely create services this way but I would > personally prefer to see better tools for developing services > natively than try to retrofit SO into OO based systems. > > We could have another interesting discussion here about whether or > not pictures help. I am not sure they really do. At least not > alone. It isn't possible to express completely in graphics what > instructions you want the computer to execute. > Correct (although the Exectuable UML proponents or the MetaCase folks, who sell successful products, would likely disagree). Which is why in our MDA projects, we only specify structural aspects in modeling languages and implement logic using the programming language of choice. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ > Eric > > > ----- Original Message ---- > From: Stefan Tilkov <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, August 17, 2006 4:34:02 AM > Subject: Re: [service-orientated-architecture] John on Gartner, > AJAX & Assorted TLAs > > Eric, I remember us having this discussion a couple of years ago ... > > First of all, MDA is not necessarily based on UML, it can also be > used with MOF. For example, Eclipse's EMF, which contains an > implementation of EMOF, can be used to build domain specific modeling > languages that are not object oriented. These can then become part of > an automated tool chain that would clearly qualify as "MDA > compliant" (although there is no such thing). > > Secondly, it's perfectly possible to use UML to model services. You > model classes, including attributes and associations, and specify > them as types for the single parameter in service classes' method > signatures. What's not service-oriented about this? > > Thirdly, what's the (simpler) modeling alternative you suggest? > > MDA, or in fact any form of model-driven software development, has > many pros and cons. There's also a lot to be said against UML (e.g. > its complexity and number of features which are largely unused in > practice); its OO features are, IMO, definitely not a problem for > applying it to SOA, though. > > Stefan > -- > Stefan Tilkov, http://www.innoq. com/blog/ st/ > > On Aug 16, 2006, at 4:24 PM, Eric Newcomer wrote: > > > > > I just want to point out that MDA is not a good fit for SOA since > > it's based on UML, which is object-oriented, not service oriented. > > > > UML has some value for whiteboarding and design, but in general OO > > analysis and design is overly complex for SO. > > > > Regards, > > > > Eric > > > > ----- Original Message ---- > > From: Gervas Douglas <gervas.douglas@ gmail.com> > > To: service-orientated- architecture@ yahoogroups. com > > Sent: Monday, August 14, 2006 2:56:32 PM > > Subject: [service-orientated -architecture] John on Gartner, AJAX & > > Assorted TLAs > > > > <<Model-driven and event-driven architectures are two technologies > > expected to have a big impact on developers over the next decade. > And > > while many IT professionals are in the dark about much of Gartner's > > "Hype Cycle for Emerging Technologies, " these architectures, along > > with AJAX apps, have very bright futures. > > > > The Gartner report released last week includes an analysis of 36 > > technologies and trends that are expected to mature within the > next 10 > > years in a five-step process Gartner calls the "hype cycle." > > > > Emerging trends begin at the "technology trigger" stage with a > product > > launch, move on to the "peak of inflated expectations" stage > thanks to > > media-generated buzz, then advance to the "trough of > disillusionment" > > period when the technology fails to meet developers' expectations, > > proceeds to the "slope of enlightenment" phase when IT professionals > > continue to experiment and apply the technology despite the > decline in > > media coverage, and finally peak at the "plateau of productivity" > > stage, as the industry absorbs and accepts its advantages. And the > > increasing popularity of SOA is responsible for these emerging > > technologies. > > > > "SOA─that' s the current big wave that everyone needs to be > > aware of > > and tapped into," said Jackie Fenn, Gartner fellow and creator of > the > > hype cycle. > > > > While Fenn explains that some enterprises have already begun > > implementing service-oriented architectures, many have yet to > explore > > migration of their event-driven and model-driven apps to SOA. But > that > > will likely change. "We think this is becoming a hyped and > focused-on > > approach." > > > > Event-driven architecture (EDA) is a common style for distributed > apps > > that are typically designed into modular, encapsulated, shareable > > components with event services. The services can be created > through an > > app, an adapter or agent acting non-invasively. According to the > > report, those in the financial trading, energy trading, > > telecommunications and fraud detection industries have begun > using EDA > > technology, along with the Department of Homeland Security. But > > Gartner says EDA is at least five years from mainstream maturity. > > > > As for Model-driven architecture (MDA), a technology from the Object > > Management Group, the process will turn the heads of developers > simply > > for its increased flexibility through SOA. The technology > > distinguishes biz-level functionality from the technical > complexity of > > its implementation, enabling the apps to be modeled by standards > like > > Unified Modeling Language. This allows the models to operate free > from > > potential platform limitations and instantiate them into specific > > runtime implementations using a target platform of choice. Fenn says > > both MDAs and EDAs will find their niche with developers largely > > thanks to SOA and their bottom-line boosting perks. > > > > And Fenn says a third "high impact" technology, AJAX, will soon > enough > > prove influential to the dev lifecycle and should reach maturity > > within the next two years. > > > > "AJAX gives you that more responsive user experience in the browser > > environment, " Fenn says. > > > > The Web 2.0 technology is a combination of processes that developers > > use to increase functionality for their end users, metamorphosing a > > limited and frustrating Web app into a more readable service. While > > the improvements may not be extreme, the report says AJAX apps have > > the ability to raise bottom lines by enhancing the user-friendliness > > and reliability of such Web apps. > > > > The "Hype Cycle for Emerging Technologies 2006" is one of 78 `hype > > cycle' reports Gartner released this year. The report evaluated > nearly > > 2,000 information technologies and trends among more than 75 > > industries. Gartner analysts reviewed and debated each technology > > within a "cross-industry view," rating performance, services and how > > each technology will impact an org's bottom line. > > > > According to Fenn, those emerging technologies deemed "high impact" > > will pay the biggest dividends for businesses over the next decade. > > But while each trend's maturity rate remains constant, she cautions > > that each technology's benefits will vary throughout industries. > > > > "Be selectively aggressive&# 9472;identify which technologies could > > benefit > > your business, and evaluate them earlier in the hype cycle," she > says. > > "For technologies that will have a lower impact on your business, > let > > others learn the difficult lessons, and adopt the technologies when > > they are more mature.">> > > > > You can find this at: > > > > http://www.adtmag. com/article. aspx?id=19054 > > > > Gervas > > > > > > > > > > > > > > > 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/
