Tech Talk with Jack Greenfield Posted, with new Text Interface

Discussions

News: Tech Talk with Jack Greenfield Posted, with new Text Interface

  1. A new Hard Core Tech Talk Interview with Jack Greenfield has been posted on TheServerSide. In this interview, Jack talks about how J2EE model-driven development tools and packaging are standardizing and automating J2EE application development. He discusses techniques for modelling J2EE applications, and the importance of JSR 26, an EJB-UML profile, and how it will impact EJB developers.

    In response thoughtful requests of our members, we have also added a new text interface to the interviews. You can now read the answers while Jacks in the video!

    Watch Jack Greenfield's Interview .

    Feel free to discuss the interview here.
  2. Sorry to post here, but has anyone ever managed to get these videos to view using Opera 6.0 ? It's a bit of a pain that I have to boot windows and use IE to view a video on J2EE ;)
  3. It appears the hoster (hostj2ee) is using microsoft extensions in their HTML, therefore it's unlikely to work
    outside of IE.
  4. It works in Netscape, but looks pretty godawful. The clip is JACK_DSL_01.ASF. So much for standards.
  5. Matt,

      What problems have you been having in Netscape? We tested it in 4.72 and the video runs fine.

    Floyd
  6. I actually meant the frame with the questions in it. It looks like the text of the questions drops one size from #1 to #2 to #3. After that it can get no smaller. If you open the page in a new window and edit it in Composer, you see all kinds of wacky font resizing. Could it be the <small> tags?

    I have Communicator 4.76 on NT4.
  7. I thought Jack did an excellent highlighting the gap between abstract modeling and the actual physical coding requirements required to develop an n-tier J2EE application. This isn't new, of course. It has always been the challenge of the developer, whether procedural language, client server or n-tier. It has always been the case on large project developments, that "programmer creativity" must give way to a "standard assembly" type process. In the old days of procederal languages you addressed the problem with code templates and cut and paste. Crude, but it worked. The new buzzword is "design patterns", but the problem that they are aimed at has always been around. The problem is, given the technology, language, platform ..., devise standards and best practices that turn the process into an assembly process. Devising good templates (throw in your new buzzword here) is important for several reasons but it's not near as important as actually creating them in the first place. Show me a large development effort allowing project team members coding similar requirements in different ways, and I will show you a project that will fail. At a minimum, it will be an absolute nightmare to maintain.

    So I agree 100% with Jack, that the development process must aim to be an "assembly process". However, I'm not convinced yet that a tool approach in all cases will beat a good manual procedure. As a developer, I'm very reluntant to sign up for tools that sound like "code generation" to me. In the past, they have failed for several reasons. One is that there is no such thing as code generation that you don't eventually have to touch and get to know, and maintain. In the past, this code has seldom been as clean and maintainable as what could be produced by skilled team members. I think the direction of new tools is to let development teams set up their own code templates, that are used for code generation, and that is good. As a developer, I see another potential mismatch between Rational's goal of selling robust, complex expensive software, and a developer's goal of producing maintainable code (we are in the software development business, and not diagram creation business). In my opinion, companies need to commit to maintaining project documentation (UML, requirement, ...) throughout the life of the project (i.e. the documentation becomes a contract). Therefore, I would think one has to determine the minimum documentation that serves the purpose or human nature will take over and documention will not be updated. We are in the "developing quality software" business, and not the "generate as much documentation as possible" business. A manager or individual charged with making tool purchases in a company needs to understand the development process before they can make an intelligent decision on where tools like Rational help, and where they are overkill (I'm not making a judgement call about Rational tools, just raising the issue). I would propose the following excercise to clients that are new to the J2EE world, and are trying to make decisions about what tool purchases make sense. Take a first cut at defining and automating the development process without the $2000 IDE's and UML tools. Use Ant, JUnit, maybe XDoclet, free IDE like Eclipse, free UML tool like Poseidon, and walk thru the process. Maybe even setup file structures and procedures for manually keeping revision histories during the development and maintenance life cycles. Once you taken a good cut at it, you will be educated and ready to make a decision about tool purchases that serve your purpose.

    JMO.
  8. I was at a J2EE session discussing code generation by Rational and when the speaker mentioned that the app server model must be known to properly generate the code because the provider URL must be placed in all the locations a JNDI lookup is required, my thoughts were this is not a good thing. A locator object fed from a properties file or other external configuration is the right way to go. So I generate all this app server specific code and then have to add business logic to the code, the point of no return has been reached because the generate button won't work for the next app server if I want to keep the added business logic. This is vertainly a place where better design wins big time over automation.
  9. Mike,

    I think your comments are exactly right. First of all, though, so as there is no misunderstanding:

    <shameless-vendor-plug>
    innoQ's iQgen is a model driven software generator that allows you to generate any textual software artefact, using XMI as its model format and JSPs to write templates. Check out iQgen 1.0 Early Access Release 2 at http://iqgen.innoq.org
    </shameless-vendor-plug>

    Now we have that out of the way, I'd like to comment on some of the points you make.

    >Show me a large development effort allowing project team
    >members coding similar requirements in different ways, and
    >I will show you a project that will fail.

    I couldn't agree more. In the projects I have participated in, we wrote huge architecture documents that specified how similar problems were to be solved, e.g. how to persist object structures, how to do bulk reads, how to connect the UI to the backend etc. Although it may seem strange, project success depended more on the fact that these rules were being followed than on their quality ;-)

    >As a developer, I'm very reluntant to sign up for tools
    >that sound like "code generation" to me. In the past, they
    >have failed for several reasons. One is that there is no
    >such thing as code generation that you don't eventually
    >have to touch and get to know, and maintain. In the past,
    >this code has seldom been as clean and maintainable as
    >what could be produced by skilled team members. I think
    >the direction of new tools is to let development teams set
    >up their own code templates, that are used for code
    >generation, and that is good.

    Again, I understand the skepticism, and I also agree with your statement regarding a template based approach. In my opinion, tools that generate code and don't allow you to modify both what and how they generate, are probably valuable when selling products to managers, but not at all usable in a real world situation. That's why we ended up writing project specific code generators in most projects. I think template-based generators are the best compromise: The project team doesn't have to build and maintain the generator core, but can develop or adapt templates to suit the project's need.

    The main problem I have with the generative approach taken by Rose and other CASE tools is that they expect you to specify everything in your model. That's also a main critique about the EJB (and also CORBA) UML profile: They allow you to specify appropriate stereotypes for different Enterprise Bean types, but you have to create a model element for each code element you want to generate. I prefer an approach where from a single model element - let's say a class with some attributes and a stereotype "<
    Stefan Tilkov
  10. Stefan,

    in my opinion the problem lays in another field. Programming is - if we accept this or not - still a craftsman discipline. So programmers often hesitate to use a code generator because they fear restrictions.

    To change this, you have to change the culture of software development. How to do this? Answer: Deliver code generators which don't have such restrictions. But currently I don't see such a tool (including the tool you proposed).

    Another point is code optimization. Templates are always bounded to a common pattern, otherwise there is no benefit in using them. In reality I'm sometimes forced to compromise
    these patterns in order to gain performance (think of complex SQL statements). There a two ways to counter such situations: First, I keep silent until the next framework change forces me to make some night shifts. Second, (and this should be the preferred way) I talk with the architecture team about framework modifications/extensions.
    The framework may support this, but the modeler/designer has now to consider (code specific) performance issues. This is a shooting offense to division of work.

    You may argue, that optimization can be abstracted in some way (e. g. put a tagged value "sql-generation=no"), but you'll loose the benefit of code generation, if you open the door for individual optimizations.

    This is really horrible, because the last statement is the opposite to the statement about "culture". You are always prisoned between flexibility and productivity!?! ;-)

    To avoid misunderstandings: Code generators are ok for me, but they are not the silver bullet as you depicted.

    Cheers,
    JW


  11. While I agree with Jacks points on abstraction and separation of responsibilities (these are good things), I find it quite a large inductive leap to conclude that model-driven development tools (read: large-scale code generation) are the answer. Certainly none of the tools I have seen are in any way usable for real-world applications of any complexity.

    Some points:

    ++ Comparing software development to electronics or automobile manufacturing is fundamentally wrong. The "Soft" in the word "Software" is a significant hint. Software is easily changed - that is the value of software. It is adaptable to changing requirements - and the requirements for a given piece of software always change - ie they are "soft". "Hardware" items, on the other hand, are "hard" to change. They represent physical things that are difficult to modify - they are not suitable for implementing requirements that change. For example, you dont have a manager in Ford coming to the *manufacturing team* to tell them "Oh, did I say 2-wheel drive, I meant 4WD... can we make it 4WD? And although its only a 2-seater now, will we be able to make it carry 24 people next year?". However, these sorts of things are normal in software (they are normal in business).
    Software should not be compared to other engineering disciplines. Software is different. We have constantly tried to treat software like hardware and this is why a lot of software methodologies have failed.

    ++ We use a programming language to bridge the gap between what we understand and what a computer understands. However, this semantec gap is relatively small and is well defined. To say that modelling/development tools will bridge the gap between a business process and a programming language seriously underestimates the size of this gap. Building distributed enterprise applications is a complex task - there is a limit to the generality that can be abstracted away.
    In the end, to get something to actually work you have to either leave the confines of the tool, OR, you have to put so much detail into the "model" that you actually find yourself trying to program at the model level.
    I would also argue that this gap will always be a constant. As programming languages and frameworks like J2EE raise the abstraction level, so too the complexity level of the business problems at hand will rise. It is natural that when people realise that more is possible, they will desire to achieve more.

    ++ Building distributed enterprise applications that are performant and scalable is a very complex task. The devil is always in the details. These "join-the-dots" development methodologies, tools or frameworks may appeal to non-technical people who are unfamiliar the implementation details (I think that vendors bank on these people being the purchasing decision makers). However, a brief look at most of these tools is all that is required to see that they are very flawed.

    Compuware tried (very hard) to sell us their OptimalJ tool - which is based on this Model-Driven-Architecture approach (built on top of NetBeans). Everything sounds great when development is portrayed as a waterfall (ie little change). However, try to make a change in direction during development and you suddenly have lots of problems on your hands. During their presentation, I asked them to deviate from their pre-cooked demo (a *simple* change in structure). Instantly, we hit problems. Some of these were admittedly bugs in OptimalJ which can be fixed (its very new) - but more importantly, it was immediately obvious that we had a problem, and no idea where to start looking to solve it (not even the "expert" knew). While there is a wealth of information (books, specs etc) on Java and J2EE, there was zero outside help that we could use to find the cause of the problem with the tool.
    If you use these tools as "code factories" (to borrow from Jack's comparison to an assembly line), then you have a non standard, proprietary machine (that you dont understand) trying to manufacture code that is already standardised and that lots of people already understand.
    The capability to "debug" at the model level is certainly missing from tools I have seen. Also the ability to develop outside the tool (interoperability with other tools) is also missing.

    In the end, I dont think that you can build a *useful* machine that will manufacture an enterprise system from a few diagrams. You always have to get your hands dirty - you have to deal with the details at some point. There is a limit to the level of abstraction you can successfully achieve - we already have people who feel that they dont have the flexibility they require in EJB...


  12. Nick,
    Thanks for putting things straight. The intreviewee's talk about manufacturing and assembly is frightening!!!
  13. thanks for give the text view[ Go to top ]

    the video can not pass the firewall of our company