Discussions

News: BEA exec claims developers need to look past APIs

  1. BEA's exec say its "Liquid Computing" view of SOA should signal the end of an era for J2EE developers. The time has passed where knowing Java APIs will be marketable, BEA execs told IDN. See BEA's 'Do's and Don't" for J2EE devs, and why they need to focus on life outside-the-container, including business rules, schemas and even integration and sharing with NET and Open Source.

    Read the full story:
    BEA: J2EE Career Devs Need To Look Past APIs

    Threaded Messages (44)

  2. BEA's exec say its "Liquid Computing" view of SOA should signal the end of an era for J2EE developers. The time has passed where knowing Java APIs will be marketable, BEA execs told IDN. See BEA's 'Do's and Don't" for J2EE devs, and why they need to focus on life outside-the-container, including business rules, schemas and even integration and sharing with NET and Open Source.Read the full story:BEA: J2EE Career Devs Need To Look Past APIs
    Hmmm. Is this really news to anyone? I think it is more news to management than a [well informed] developer (or whatever you might want to be called) - someone who has been in the trenches and realizes that some that something is wrong (things like "Just because I am building a webapp doesn't mean I should build it only to be a webapp". Not that I am in line with everything he side.
  3. "Hmmm. Is this really news to anyone? I think it is more news to management"

    Exactly, this really troubles me to see BEA totally in the dark. My interest with BEA is because of the early adoption with the J2EE specs. But, then the push with their proprietary Workshop was just not consistent with WebLogic's vision. This goes to prove again, BEA is really a marketing company that didn't managed the development of any product. Weblogic, Tuxedo and Workshop were all purchased. This explains the "Dilbert" like comments from the BEA exec.

    Of course, my comments are no way reflective of the Weblogic team, the team that paved the way for J2EE excellence! Imagine if we had to wait for IBM and Oracle to provide J2EE capabilities. Did you hear that Cedric?

    Now what software technology company actually provides freedom of choice with their products - Borland!

    I'm not an employee of Borland, but this company is the only one with real R&D spending on Linux, Windows, .NET and Java(J2SE/J2EE/J2ME) in its past. Thus, I was building SOA, before this "Marketecture" craze, 5 years ago - on any platform of my customers choice with Borland products.

    Anyone remembers developing native Windows clients interfacing with Java application servers via CORBA?
  4. Finale[ Go to top ]

    "I'm not an employee of Borland, but this company is the only one with real R&D spending on Linux, Windows, .NET and Java(J2SE/J2EE/J2ME) in its past"

    Yes, George "in its past", as the present is very different at the moment at Borland. There has been substantial firing and exiting of staff at Borland if the news items are anything to go by I suspect Borland under its current daleightful CEO has finally fullfilled the prophecy that has hung from its neck for too long.

    Borland had its moment to turn back history but unfortunately once again it blew it and this time I do not think it has the loyalty of the Java developers to save it. .NET developers are not interested and Delphi developers ( I was one for 4 years a long time ago) are a dying breed who refuse to accept that the world has moved on from VCL DB Controls.

    BEA is doing a much better job at providing a higher programming abstraction than what has come from the JBU which is zero. I am looking forward to when JetBrains release Visual Fabrique.

    Borland is trying very hard to act like it is moving up the food chain but its 'can we call it JBuilder and charge ridiculous amounts for stuff that does not work' mentality will always thwart any slim chance they have.

    By the way are you using Borland OpCenter? Do you know anybody using it? Have you even heard about it?

    Regards,

    William
  5. Borland OpCenter[ Go to top ]

    By the way are you using Borland OpCenter? Do you know anybody using it? Have you even heard about it?Regards,William
    My company has been using AppCenter, OpCenter's predecessor for 2 years. Appcenter was a very good product. OpCenter is the next generation and as far as we can tell, Borland has really screwed it up. I don't know if the folks who originally did AppCenter worked on OpCenter at all, but they left out some important items like Timers and a Web Interface. After using AppCenter for two years, we have decided not to deploy OpCenter and we are looking for something else.
  6. 'side' should be 'said'. Wish my brain would stay connected to my fingers.
  7. What fun is IT marketting[ Go to top ]

    Oh yes, 5th generation, 6th generation hyper engineering.
    The future won't require thought. No longer will you code with code. You will use components, which self configure, communicate assynchronously and handle all error conditions through continous negotiation.

    OurCo can provide these components cheaper than any other software vendor. We call these components 'people'(tm), and have specialist versions such as 'secretaries', 'project sponsors', 'financial controllers'.

    To facilitate our component model you may need some small amount of bespoke software, which we suggest the client develope in house - so that our components will be working to YourCo's business model, rather than a generic one which gives no competitive edge. Several of our clients have not taken the bespoke approach and have found themselves unable to compete using the simple typewriter technology which we ship.

    Or have I missed something?

    Jonathan
  8. What fun is IT marketting[ Go to top ]

    .Or have I missed something?Jonathan
    I think so.
     With the exception of some nice-to-have features such as OnStar and Hybrid engines, Automobile technology has not changed much. So "marketing's" job is to "artificially enhance " the value of new models and features.

    Software companies are not nearly so desparate -there are many problems yet to solve and a continuous stream of innovation (and change) that can be "applied" to those problems. 10 years ago the Internet was not a consideration in enterprise architectures because it didn't exist. 10 years from now it will not be a consideration in enterprise architectures because it will be "taken for granted".

    ....and yes software will eventually be self-tuning, self-healing, and self-architecting....unless, of course, your enterprise has standardized on typewriter technology.

    Matt
  9. What fun is IT marketting[ Go to top ]

    What's a typewriter?
  10. What fun is IT marketting[ Go to top ]

    What's a typewriter?

    I'm guessing (based on naming conventions) that it is a TypeWriter, probably java.io.TypeWriter. It implements the Writer interface, and probably extends a class such as StringWriter or FileWriter. My guess is that it is used to write class information ("types") out to an underlying Writer that sits on top of a file or stream.

    It's just a guess, of course.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  11. What fun is IT marketting[ Go to top ]

    <blockquote....unless, of course, your enterprise has standardized on typewriter technology.MattBut don't you think that any vendor product/distributed async comms will indeed be typewriter technology 2.5 years after you change your corporate architecture to use it?
    e.g. dce. e.g. Corba. e.g. rmi. e.g. com. e.g. EJB. e.g. Soap?

    Jonathan
  12. I think BEA understands that JBoss takes over, and wants to rather push for this SOA nonsense.
    I think that EJB3.0 will change the way we develop things.
    Looking past Java API ? This is to say:"Use our in house apis, rather than java easy to use api". Weblogic is a good app server - they should improve it not jumping into 'look past APIs' :)
  13. I think BEA understands that JBoss takes over, and wants to rather push for this SOA nonsense.
    That’s just silly! About JBoss and SOA. SOA isn’t nonsense, it is, and has been a reality for quite some time. Although the landscape and names and technologies have, and continue to change, the ideal is still the same and still fundamentally sound. BEA is moving higher into the solution stack offering solutions to complex enterprise problems recurring in corporations and not relying solely on an application server to carry them. That’s one of the things that make them such an innovative company.
    I think that EJB3.0 will change the way we develop things.
    How can you depend on a single specification to change the way we develop things? I do not understand this.
    Looking past Java API ? This is to say:"Use our in house apis, rather than java easy to use api". Weblogic is a good app server - they should improve it not jumping into 'look past APIs' :)
    The point is complexity abounds within enterprise solutions, I would argue that anyone who says “J2EE is easy” either hasn’t developed a large-scale complete end-to-end enterprise solution with it, or has only analyzed a fraction of the simpler APIs or is just running off, self-aggrandizing their knowledge and skill. Vendors like BEA are trying to address this complexity and increase productivity across the board for corporate developers; developers responsible for not only J2EE solutions but others as well. That’s the existing and continuing face of large corporations with real and complex enterprise computing needs.
  14. Once BEA understood their workshop theory to teach how to make J2ee easy for dummy managers, they are freaking with another idea SOA. I think they should concentrate on what they are good instead being a foolish boss
  15. Ryan,
    I meant that jdk1.5 and ejb3.0 would make our lifes easy to develop/build real stuff.
    Look at Spring ,Hibernate and Jboss - these are so simple to use and if you use these you will build really good stuff.
    If BEA is trying to push up the stack all their in house builds , this does not mean they try to make complex things easy.
    But anyhow, if you use the real stuff mentioned above, you will not thing that building enterprise apps is a complex thing.
    Look at workshop - I have tried and 5 mins later I felt again the same nightmare back when using MS tools - scary thing.
  16. Ryan,I meant that jdk1.5 and ejb3.0 would make our lifes easy to develop/build real stuff. Look at Spring ,Hibernate and Jboss
    Thanks for the clarification beton.
     - these are so simple to use and if you use these you will build really good stuff.If BEA is trying to push up the stack all their in house builds , this does not mean they try to make complex things easy.
    If you look at their long-term vision and listen to what their leaders say that is very much what they're trying to do. Whether or not they've succeeded is a different story ;-) I'm not being a BEA fan boy here even though I love their enterprise products I just think we need to look at the full breadth and depth of the solution context to understand what they mean when they say the things that started this thread.
    But anyhow, if you use the real stuff mentioned above, you will not thing that building enterprise apps is a complex thing.
    I might be misunderstanding you again here (correct me please if I am) but building enterprise applications is and will continue to be a complex thing. Maybe if business models and enterprise architectures were static we would eventually understand all there is to understand and reach a point where we can say creating solutions is easy. But that's not true and the complexities will always be there regardless of the tool or technology you use to solve them. That's why the tools IMO should abstract most of the inherent difficulty so you can spend the bulk of your time implementing a solution to the business problem and not worry about caching, accessibility, implementing the most optimal locking strategy, etc., etc. Not to say the tools should abstract that to a level where you can't access or tweak the code when needed, but abstracted non-the-less.
  17. beton beton,

    if you had used Hibernate and Jboss like I did, you would know they are not that simpler than other stuff.

    The big problem is application complexity, and Jboss and Hybernate are not a solution for that.

    They might even be the coolest pieces of software in the J2EE arena, but they do not change the paradigm (and costs) of development in any way.
  18. Roberto,
    As a developer I would rather use java objects and think in terms of objects when I code - in my opinion this is a simple solution.
    AS far as BEA workshop and their aproach to SOA - I think they just want to re-create a sollution that was there for a long time. They try to push their tools out to the world so they can market their sollutions.
    From my experience with Hibernate - when starting to use it in conjuction with Spring it gave me the total power to concentrate in designing/coding towords a requirements not towards a spec (EJB). This is easy.
    If we talk about how to expose services then I would say that even Sun's implementation is good enough.
    Application complexity comes from those who think not towards the application but to the spec(EJB). I don't know how you feel , but myself since I started to code with EJBs the app object model looked like a database model - which always is ugly.
  19. SOA isn’t nonsense, it is, and has been a reality for quite some time.
    Yeah. It is CORBA. IMO it is only technology that is based on healthy ideology. And it does RPC, Remote-Object-Invocation, and all those buzzwords.
  20. I think BEA understands that JBoss takes over, and wants to rather push for this SOA nonsense. I think that EJB3.0 will change the way we develop things. Looking past Java API ? This is to say:"Use our in house apis, rather than java easy to use api". Weblogic is a good app server - they should improve it not jumping into 'look past APIs' :)
    I agree with what BEA executive is saying, but he is not saying something new. Yes, you should look past APIs. Businesses interested in making business they dont care about your APIs. Simple.

    JBoss takes over? oh yeah, with their zillion developers, they can take over the world,why just BEA?

    I just dont understand why JBoss comes into picture when we are talking about an architectural changes.
  21. Looks like the guy lived under the rock for a few past years. Everyone in sight has been doing it for ages. I guess, corporate walls just too thick there...
  22. ""Being an expert in APIs and subsets of APIs is going to be increasingly less marketable," ""

    My resume is going to have to be totally rewritten now again, I've got way too much expertise to get hired. I've got to come up with more tweaking and configuring projects to balance out all of that code that I've written ...
  23. Pre-packaged architect[ Go to top ]

    I just love the part where he says there will be little need for architecture skills as these will come pre-packaged in the tool anyway. Do they also expect our support to de-skill our jobs ?
  24. Pre-packaged architect[ Go to top ]

    I just love the part where he says there will be little need for architecture skills as these will come pre-packaged in the tool anyway. Do they also expect our support to de-skill our jobs ?
    Yeah, I think that comment is just a wee bit out there :-) Architecture is one area where I really disagree with a vendor or tool driving or defining.
  25. Pre-packaged architect[ Go to top ]

    I just love the part where he says there will be little need for architecture skills as these will come pre-packaged in the tool anyway. Do they also expect our support to de-skill our jobs ?
    Yeah, I think that comment is just a wee bit out there :-) Architecture is one area where I really disagree with a vendor or tool driving or defining.
    That was one that got me too.
  26. Pre-packaged architect[ Go to top ]

    Just look what happened to Wakesoft as an "architecture vendor" ...
  27. I just love the part where he says there will be little need for architecture skills as these will come pre-packaged in the tool anyway.
    No kidding. I guess they expect the framework to analyze and model the objects, decide on the proper schema normalization given the anticipated frequency of events in the system, decide what info should be present in each message given the performance requirements, adaptively select caching, replication, and deployment configurations to match, and make changes on the fly if things aren't shaping up right.

    This paper is short on useful advice and long on trying to get people to abandon standard APIs in favor of concepts, technologies, and tools. Especially proprietary ones that add value to open standards, like BEAs SOA stuff. Which in some circumstances of course makes sense.

    But even there, I think the architect will play a bigger role than ever. You need someone to analyze the problem; pick a fitting framework from the wealth of standard APIs, Open Source offerings, and proprietary middleware add-ons; educate the developers as to how the framework properly matches the problem at hand; educate the deployers as to how the problem solution makes use of its hardware, and so on.

    My advice is to learn base concepts and the basic operation of many of the middleware and frameworks out there. Combined with a solid understanding of your industry and problem you should be able to choose technologies that are right, from whatever source. Take any advice from BEA that you should sit on the edge of your seat and await OASIS specs with a grain of salt, unless they specifically apply to you.
  28. Pre-packaged architect -- Hah![ Go to top ]

    Not really sure what Cornelius meant here. I think that Architects will become more important in the future, for many of the trends pointed at by Cornelius (In fact, my impression was that he thought that as well (from other conversations I've had with him)).

    One of the selling points of SOA is the re-use of services. You not only need to write an object once and re-use it, but you also only need to deploy it once. This opens the market up for more applications being built using integration and portal products that take advatages of these services to build interesting composite applications.

    As the percentage of applications that are being built on top of services, (rather than directly on J2EE) grows, it will be more important for there to be people that have a broader view of all the services in a company, and to be able to be able to understand these services and combine them in ways to address business needs faster.

    This means the skill set of an architect will be to be able to know the many services around the company and understand how to orchestrate them to build better composite applications. They will also have an important job of understanding how to build new services that can be re-used effectively and are able to be versioned for future use. The term "Architect" is a bit of a fuzzy term. I would exect for some Architects this would mean changing what they see their role as, and for others it would simply look like doing the same role, but with different technology.


    Will Pugh
    Principal Technologist, BEA Systems
  29. Service ?[ Go to top ]

    I have a trick question: what is a service and what makes it more reusable than, say, a plain old EJB component ?

    thanks

    A.
  30. Service ?[ Go to top ]

    I have a trick question: what is a service and what makes it more reusable than, say, a plain old EJB component ?thanksA.
    The main differentiators for a service are that they are loosely-coupled and coarsely-grained. They are often also built with the idea of being platform independant as well as versionable.

    With EJBs, it is harder to re-use when building a .Net application, or C/C++ apps, etc. Also, you need to get the deployment information correct in addition to just the calling conventions.
  31. Loosely coupled ?[ Go to top ]

    I have a trick question: what is a service and what makes it more reusable than, say, a plain old EJB component ?thanksA.
    The main differentiators for a service are that they are loosely-coupled and coarsely-grained. They are often also built with the idea of being platform independant as well as versionable. With EJBs, it is harder to re-use when building a .Net application, or C/C++ apps, etc. Also, you need to get the deployment information correct in addition to just the calling conventions.
    I knew you were going to say this - that's why I said it was a trick question. But frankly, that's a weak definition. A service is just a bunch of code that happens to have an interface defined in WSDL and is invoked through SOAP messages ? And somehow that would make it "loosely coupled" and "coarse grained" ? Is that all there is to it ? That won't suffice to transform solid computing into liquid, I'm afraid. Gaseous, possibly :-)

    A.
  32. Loosely coupled ?[ Go to top ]

    I have a trick question: what is a service and what makes it more reusable than, say, a plain old EJB component ?thanksA.
    The main differentiators for a service are that they are loosely-coupled and coarsely-grained. They are often also built with the idea of being platform independant as well as versionable. With EJBs, it is harder to re-use when building a .Net application, or C/C++ apps, etc. Also, you need to get the deployment information correct in addition to just the calling conventions.
    I knew you were going to say this - that's why I said it was a trick question. But frankly, that's a weak definition. A service is just a bunch of code that happens to have an interface defined in WSDL and is invoked through SOAP messages ? And somehow that would make it "loosely coupled" and "coarse grained" ? Is that all there is to it ? That won't suffice to transform solid computing into liquid, I'm afraid. Gaseous, possibly :-)A.
    Let me take a stab at answering the question. I would say that EJBs are a programming model with distributed access capabilities while services should be focused exclusively on interfaces for distributed access. I say "should be" because their are still many definitions of service architecture and enabling technologies, some of which are more pure than others in their focus on interfaces. Web Services standards are obviously aligned with this goal.

    Given this definition, you could potentially create a services architecture based on EJBs. However, current EJB tools are too programming-oriented to make this easy.

    The holy grail of the OO world has always been to be able to define the proverbial customer once within an organization as an object (e.g. CustomerEJB), then package that object in a repository and let all the other development teams reuse it. I've never seen this work even once. Obviously, with EJBs we could also deploy our CustomerEJB on a server and let all the other applications call it remotely. The problem is that in this typical example a Customer represents an entity, not an action.

    So, to make a service architecture using EJBs, you would need to define the Session Façades that encapsulate the business processes to be executed (e.g. addNewUser, deleteUser, subscribeToService, etc.). Then, somehow, you would need to document these interfaces, publish the interfaces, stubs, docs, etc. in some type of repository so that users could download the EJB interfaces and compile their clients that call EJBs.

    Now you begin to run into the limitations of using a technology-specific model. What if you want to access these "services" from .Net? from VB? from SAP? Now each client technology has to come up with a technology-dependent solution for connecting with our EJBs.

    For services to be easily reusable, apart from needing this basic connectivity, they also require tools and technologies that allow them to be easily embedded in different applications. Funcionality like dynamic routing of async service requests, service assembly into business processes, configurable data transformation to deal with application-specific data formats, etc.

    So, the short answer is that EJBs should be publishable as services and should be able to participate in service implementations with the reuse that that implies. However, a service architecture adds a lot more to enable reuse than EJBs alone can provide.
  33. stovepipes[ Go to top ]

    But what you typically see is that people build stovepipe J2EE applications where they define their Customer entity EJB and their CustomerManager session EJB everytime... In that case, just adding a CustomerService WSDL/SOAP wrapper won't give you a great SOA I'm afraid. My original point was that we need more intellectual substance than a bunch of "loose coupling" and "coarse grained" mantras to actually achieve any progress, and the pre-packaged architects in the tools won't really solve much of that for us. The article I pointed at on the IBM Developer web site provides some very useful insights about these issues.

    A.
  34. stovepipes[ Go to top ]

    But what you typically see is that people build stovepipe J2EE applications where they define their Customer entity EJB and their CustomerManager session EJB everytime... In that case, just adding a CustomerService WSDL/SOAP wrapper won't give you a great SOA I'm afraid. My original point was that we need more intellectual substance than a bunch of "loose coupling" and "coarse grained" mantras to actually achieve any progress, and the pre-packaged architects in the tools won't really solve much of that for us. The article I pointed at on the IBM Developer web site provides some very useful insights about these issues.A.
    Totally agree with you on the IBM article. To get to a reusable, service-based world, you will need architects that can facilitate the top-down and bottom-up drivers for interoperability and reuse. I believe the biggest barrier to SOA is organizational, not technical. Someone has to guide an organization to make this happen.

    That being said, you will also need tools that make the services visible to developers with different skill sets and that help implement all the "loose coupling" and "coarse grained" stuff. As you said, you can't just put a WSDL wrapper on an EJB and say you're now working in a SOA.
  35. Will,

    Here's a link to an article that discusses these issues from a (gasp) "beyond the buzzwords" perspective. Sorry, it's IBM stuff... It sounds like we architects will still have some hard thinking on our plate for the coming years with all this service stuff. It will take a while before it's all pre-packaged, and then something else will come along and obsolete it all anyway.

    http://www-106.ibm.com/developerworks/library/ws-soad1/

    A.
  36. One of the selling points of SOA is the re-use of services. You not only need to write an object once and re-use it, but you also only need to deploy it once. This opens the market up for more applications being built using integration and portal products that take advatages of these services to build interesting composite applications.As the percentage of applications that are being built on top of services, (rather than directly on J2EE) grows, it will be more important for there to be people that have a broader view of all the services in a company, and to be able to be able to understand these services and combine them in ways to address business needs faster.
    Now, this is a valid point if there is a saturation of core service implementations, and ONLY intergation and "orchestrations" is the IT spend. Which is not the case today. While SOA and orchestration et al has its utility, it only extends J2EE (and .NET) rather than "replace" them! For every two servcies talking to each other, someone has to implement each of the two services (..more..).

    Also, reuse of service is is not exactly an alien concept for J2EE. From the word go the technology professed and imbibed components and reuse (from the earlier EJBs, then IIOP for CORBA and in J2EE 1.4- Web Servcies for .NET & legacy). So SOA is not exactly path breaking trail-blazer. As someone else said on TSS (even if in a different context)- "evolutionary, not revolutionary"!

    Cheers,
    Ramesh
  37. I would second Ramesh’s comment. As he also pointed, SOA is for systems’ integration – not for system implementation! It doesn’t get any clearer than that… It looks to me as if it is a case of collective amnesia where many SOA pushers are forgetting that in order to integrate two systems you first need to build them and that takes a lot more than WS-* stack.

    There is another erroneous generalization that is sprawling right now: any .NET and/or J2EE development is SOA by definition. We are facing this confusion every time we talk to a customer. It’s just too hard to swallow for many ISVs that SOA is nothing more than a niche WS-* based technique…

    Regards,
    Nikita Ivanov
  38. the old reuse issue[ Go to top ]

    "One of the selling points of SOA is the re-use of services. You not only need to write an object once and re-use it, but you also only need to deploy it once."

    The technology isnt the limiting factor here. Its a fundamental design granularity problem that has shot down every technology to date promising "universal reusable components".

    The problem is with reusable components and services is that you have either shoot for the lowest common denominator functionality, or go for a huge amount of configurability and parameterisation that most clients dont need most of the time. So you end up with something that in the former case adds too little value to make the reuse worthwhile or, in the latter case is so complex to use that that it takes less time to specify and implement exactly whats needed for the job in hand than it does to figure out someone elseses "all things to all men" component or service.

    IMO we have already had the reuse "big win" in the form of the sort of libraries and tools that we use everyday. Large scale reuse at the business service level is just gold at the end of the rainbow: no business Ive ever seen is capable of the holistic thinking needed to make it work and ever if they were I seriously doubt that they would remain agile enough to be compeditive. They would suddenly be constrained to having to create new services from combinations of existing ones and doing all the domain analysis and factoring that entails, rather than using an agile stylee "just-in-time"/"just-good-enough" build-precisely-what-we-need-now approach.

    Paul C.
  39. Bea is saying that we should forgot all that we've learned in the past, and read their literature because they master and they are the future.

    something more?
  40. Just wanted to note that it is quite troubling to see two upper level managers from BEA contradicting each other on such rather simple message just days after eWorld conference. Further more, putting up the paid article (that is official advertising) claiming that the role of software architect “will become less and less widespread, because the best practices will be in the framework” will result in predictable laughter from the audience such as TSS much the same as similar recent “thoughtful” comments from Novell person on SOA.

    I do believe that WLS is de-facto best app server on the market yet coming out of missed quarter, disappointing results and deafening silence from Workshop “community” does not justify this sales/marketing rant that every developer will shrug off in disbelief that it came from the company that still has a lot of respect in dev community.

    Regards,
    Nikita Ivanov.
  41. I wonder actually why BEA only mentioned XML Schemas? In the world of so many XML Schemas, I think this is the right time to use MOF (instead of directly interacting with XML Schema), just like what David S. Frankel and Timothy J. Grose, et. al. in their corresponding books: Applying MDA to Enterprise Computing and Mastering XMI said.

    IMO, the future lies in MOF and MDA. SOA, EAI and Enterprise Application Development are only a part of them. Why not go one abstraction higher instead of depending yourself in those technology buzz words. Just take a look on how IBM uses MOF in their products and you will wonder ;-)

    Cheers,
    Lofi Dewanto.
    http://www.openuss.org
  42. MOF ? slightly Offtopic[ Go to top ]

    Just take a look on how IBM uses MOF in their products and you will wonder ;-) </a>
    I've also been reading about the way IBM is using MOF "deep" inside Websphere etc. ?
    A bit curious about the purpose. Where is it exactly used ? Where are you reading about this ?
  43. You can read all about this in the books I mentioned before in my thread.

    They (IBM) use MOF to define every single metadata they have in their products. But not only IBM uses MOF, Sun also uses it. So if you check Eclipse (EMF) and NetBeans (MDR), you can find how they use MOF in their products.

    This whitepaper from NetBeans can help to show how NetBeans uses MOF to define all their metadata:
    http://mdr.netbeans.org/MDR-whitepaper.pdf

    "Thanks to these features, MDR fits perfectly into architecture of modular IDEs such as NetBeans, enabling support for plugging in new kinds of metadata (such as new language models). For some languages the metamodels already exist – UML being the most important example. MDR is even more important for supporting languages like UML, as UML has no official textual syntax besides UML models stored in XML files conforming to XMI specification. MDR can automatically store/import all the metadata using XMI, so having MDR built into a tool enables interoperability with existing UML tools and other MOF or XMI-compliant software. Also having language metadata persistently stored in MDR makes it possible to easily implement modules for refactoring, code analysis, design patterns and so forth."

    So, again IMO, MOF is the way to go (instead of building your own schemas, just like what BEA tells us with those "self-made" schemas ;-)).

    Hope this helps!

    Cheers,
    Lofi.
    http://ejosa.sourceforge.net
    http://openuss.sourceforge.net
  44. WLS/J2EE requirement[ Go to top ]

    J2EE/WLS Infrastructure Admin:

    Must haves:
    - Overall 5-6+ yrs. experience
    - Good experience of BEA weblogic Administration, versions 6.1 to 7.0 to 8.1....2-3 years desirable....Clustering knowledge will be helpful
    -Hands on experience of Solaris platform
    -Good understanding of J2EE space...servlets/JSP/EJBs/JDBC/JMS etc.
    -Good understanding of oracle database and JDBC communication.
    -Good client handling, communication and troubleshooting skills

    Differentiators:
    Performance tuning tools like Jprobe/optimizeit
    General J2EE application performance tuning.
    Load Testing experience with tools as Loadrunner etc.

    Nice-to-Haves:
    Some experience in monitoring tools as sitescope, topaz etc.
    Shell scripting
    Java/J2EE Development.

    It's a great opportunity for a fortune company in CT area and is a very stable consulting contract which goes until end of Dec 2004 and has a great chance for going through the next whole year.This opening is for my group.

    People who are willing to switch employers need only apply. will process H1 visa, if required. Please email your resumes ASAP to wlsjobs@yahoo.com
  45. SOA is not a replacement for OO and component-based development but is another level of abstraction. Consider OO, it can be difficult to appreciate the benefits of classes when learning Java. However the benefits of OO constructs readily become apparent when considering design.
    Likewise with SOA, we are analogous to a bunch of C programmers wondering why we would want to bloat our code and get carpal tunnel syndrome moving to Java or C++. The benefits of SOA will make more sense when viewed from the perspective of analysis. See.
    Consider OO, it is simple in principal and devised to facilitate design. In reality, good OO requires skilled, talented and experienced people.
    Likewise and even more so the SOA. SOA sounds simple but people with the ability to create Services based architectures will be highly sought after.