ESB-Oriented Architecture: The Wrong Approach to Integration

Discussions

News: ESB-Oriented Architecture: The Wrong Approach to Integration

  1. Bobby Woolf describes an all too common integration conundrum: IT and businesses may view the deployment of an ESB (Enterprise Service Bus) as an objective rather than as a means of achieving business process integration. The IT folks focus on deploying the ESB because it gives them a tangible, deterministic result: if you connect application endpoints A and B over protocol P, you'll get your applications to talk. SOAs, in contrast, are determined by business requirements, where the connections between systems are driven by arbitrary, non-deterministic business decisions; such connections are heuristic at best. An ESB can help in providing those connections, but should not become an architectural paradigm in itself. Bobby writes:
    An increasingly common request from clients is to complete a project that does not use service-oriented architecture (SOA) as a whole, but instead implements only an enterprise service bus (ESB) architecture. Such an ESB-oriented architecture is easy to envision, but its success is difficult to measure. What clients requesting such projects do not understand is this: An ESB-oriented architecture does not produce business value. A project based on ESB-oriented architecture needs to be made into one based on SOA-oriented architecture to help ensure that it successfully delivers business value.
    Is your organization adopting a technology like ESB and turning it into an answer to every problem? Are you building connectivity and functionality with your ESB that the business may not need or ever use? Are you building technology that creates business value? Bobby Woolf is the co-author of Enterprise Integration Patterns and The Design Patterns Smalltalk Companion, and a member of the IBM Software Services for Websphere consulting organization.

    Threaded Messages (80)

  2. Is your organization adopting a technology like ESB and turning it into an answer to every problem?
    Yes.
    Are you building connectivity and functionality with your ESB that the business may not need or ever use?
    No.
    Are you building technology that creates business value?
    Yes/No.
  3. so wrong!!!!![ Go to top ]

    This article's axis wrong. the usecase is of someone who need not have used ESB. but it does not say ESB in general is a "wrong architecture".
  4. SOA is...[ Go to top ]

    It seems like some IT organizations equate ESB with SOA the same way some equated "SOA is just web services" until recently.
    A bit off topic, but in my opinion, SOA really is more or less just a grouping of web services. I've yet to really see anything defining to the contrary. ESB though, I've seen "buses" come and go. They never really deliver on the plan for one reason or another. It'll be interesting to see if this one survives.
  5. ESB[ Go to top ]

    IBM have a Websphere ESB product, and this guy works for IBM Websphere consulting group. I wonder how he is going to sell Websphere ESB to customer. May be he told customers, "ESB is more a problem then a solution" so don't buy Websphere ESB.
  6. Re: ESB[ Go to top ]

    IBM have a Websphere ESB product, and this guy works for IBM Websphere consulting group. I wonder how he is going to sell Websphere ESB to customer. May be he told customers, "ESB is more a problem then a solution" so don't buy Websphere ESB.
    NO, he'll be saying Websphere ESB focuses more on SOA than competitors do.
  7. Re: ESB[ Go to top ]

    As far as i remember an ESB was originally more an architectonical pattern, than a concrete product. And as a pattern it obviously can/should be implemented with any MOM solution you'd like. So one must make the difference between the pattern and a product like Websphere ESB, that is one possible implementation of it. And as a pattern, it can be used to solve the integration in a SOA.
  8. Re: SOA is...[ Go to top ]

    A bit off topic, but in my opinion, SOA really is more or less just a grouping of web services. I've yet to really see anything defining to the contrary.
    There is no 'W' in SOA. So no that's not really correct. Services can exist with out the web. SOA and service orientation is a philosophy and an approach. It's not a technology in the common sense of the word.
  9. Re: SOA is...[ Go to top ]

    There is no 'W' in SOA.
    Gee, thanks.
  10. Re: SOA is...[ Go to top ]

    There is no 'W' in SOA.


    Gee, thanks.
    Maybe that was a little too trite. People thinking SOA equals web services is problem. You can have service orientation without a single web service. For most internal services, I think MOM is a better approach. You could also use existing EDI services. The point is that SOA is an approach borne of many decades of attempts at distributed architecture. I think there's this idea that it's just an offshoot of web services. Personally, I think web services as we know them are really a minor technology in comparison. The word 'web' should not enter a discussion about service orientation until you are talking about implementation details.
  11. I'll tell my MOM![ Go to top ]

    The word 'web' should not enter a discussion about service orientation until you are talking about implementation details.
    That's true at the start, but past the requirements def, you have to discuss implementation options. MOM would be a pretty good solution. However when you start looking at tools like IBM Websphere MQ and how it uses channels, what should have been a simple and elegant solution instantly turns into muck. (if this doesn't qualify as a MOM tool, then nevermind :) When you start looking at service orientation and technologies to support them, things need to be simplified. It just seems like a lot of design approaches and architectures are overly complicated. 2 cents
  12. Web services are complicated[ Go to top ]

    Personally I think web services is too complicated. Why deal with soap and security for internal services? It is much simpler to send an xml message via JMS. Security (access to publishing and subscribing) can be handled by the middleware. Not too mention the fact that get you reliable messaging (participants need not be online at the same time) with no added complexity and you can handle complicated scenarios such as partial success. I think an ESB is a great tool if you are trying to build a SOA environment.
  13. Personally I think web services is too complicated. Why deal with soap and security for internal services? It is much simpler to send an xml message via JMS. Security (access to publishing and subscribing) can be handled by the middleware. Not too mention the fact that get you reliable messaging (participants need not be online at the same time) with no added complexity and you can handle complicated scenarios such as partial success.

    I think an ESB is a great tool if you are trying to build a SOA environment.
    I don't think that anyone uses Webservice for internal communication in a SOA. I'd guess that most real life SOA use a high performance MOM, RMI, JMS or another protocoll. Webservices are only good for the inclusion of external high-level services. Or for providing high-level services to external partners.
  14. I don't think that anyone uses Webservice for internal communication in a SOA. I'd guess that most real life SOA use a high performance MOM, RMI, JMS or another protocoll.
    Tell that to CrapClear..ahem.. Cape Clear
  15. Re: Web services are complicated[ Go to top ]

    I don't think that anyone uses Webservice for internal communication in a SOA. I'd guess that most real life SOA use a high performance MOM, RMI, JMS or another protocoll.
    Web services (meaning XML with SOAP/REST in this context) is also used for internal communication in some cases. But of course this is should be questioned. What protocol should we use in each scenario? Web services only for external communication? RMI/JMS for internal systems? When talking about SOA best practices, we usually describe combination of BPEL, rule engine, service directory, ESB etc. I think SOA best practices should also include choosing the right technology to implement SOA in each scenario. That might mean plain EJB or JMS calls with simple customised service locator implementation. I think this technical decision the most important task of an architect in current SOAish environment.
  16. Re: Web services are complicated[ Go to top ]

    I don't think that anyone uses Webservice for internal communication in a SOA. I'd guess that most real life SOA use a high performance MOM, RMI, JMS or another protocoll.


    Tell that to CrapClear..ahem.. Cape Clear
    Oh, I have a better example. I heard someone suggesting to have a webservice to issue invoices implemented with an invocation of a WS to get the ordered items, an invocation of a WS to get the discount, an invocation of a WS the get the taxes.......... But, OK, no WS the perform the total calculation. Guido.
  17. Re: Web services are complicated[ Go to top ]

    I think an ESB is a great tool if you are trying to build a SOA environment.
    What I got from the article was not that ESBs are bad but that you should focus on building services first and foremost. If you are focusing on the ESB and not on the services it's like building a highway to nowhere.
  18. ESB is not a WLS, or WEBSPHERE application server with X additional functionalities. It is a pattern being used in SOA enablement of IT. A valid ESB should be a framework implemented in some technology which allow us to add the following features incrementally as we move to higher SOA maturity level as part of SOA adoption 1) Message brokering between heterogeneous environments 2) Supports asynchronous, synchronous, publish and subscribe messaging 3) Supports synchronous and asynchronous bridging 4) Supports message formats of SOAP 5) Support for message format of SOAP with attachments 6) Support for xml message 7) Support for structured non-XML data 8) Support for raw data message 9) Support for text data message 10) Sport for e-mail with attachment message 11) Heterogeneous transports between service end points 12) Supports for FILE protocols 13) Supports for FTP protocols 14) Supports for HTTP protocols 15) Supports for HTTPS protocols 16) Supports for Multiple JMS providers 17) Supports for RMI protocols 18) Supports for web service protocols 19) Supports for CORBA protocols 20) Supports for DCOM protocols 21) Supports for E-mail (POP, SMTP, IMAP) protocols 22) Support for advanced transformation engine 23) Support for configuration-driven routing 24) Message routing based policies 25) Support for call-outs to external services to support complex routing 26) Support for point-to-point routing 27) Support for one-to-many routing scenarios 28) Support for request response model 29) Support for publish-subscribe models 30) Service monitoring 31) Service logging 32) Service auditing with search capabilities. 33) Support for capture of key statistics for message and transport attributes including message invocations, errors, and performance, volume, and SLA violations. 34) Supports clusters and gathers statistics across the cluster to review SLA violations 35) Support for service provisioning 36) Support deployment of new versions of services dynamically through configuration 37) Migrates configured services and resources between design, staging and production 38) Supports multiple versions of message resources that are incrementally deployed with selective service access through flexible routing 39) Configurable policy-driven security 40) Supports the latest security standards for authentication, encryption-decryption, and digital signatures 41) Supports SSL for HTTP and JMS transports 42) Supports multiple authentication models 43) Policy-driven SLA enforcement 44) Establishes SLAs on a variety of attributes including a. Throughput times b. Processing volumes c. Success/failure ratios of message processes d. Number of errors e. Security violations f. Schema validation issues 45) Initiates automated alerts or enables operator-initiated responses to rule violations using flexible mechanisms including a. E-mail notifications b. Triggered JMS messages c. Triggered integration processes with a JMS message d. Web services invocations with a JMS message e. Administration console alerts. 46) Support for having multiple LOBs manage their own service bus based on their policies, and a service bus at an enterprise level that could act as a broker for sharing services across the various business units. 47) Support for agent plug-in to support following features 48) External provider’s service access for security 49) External provider’s service management 50) External provider’s transaction container a. External provider’s business orchestration (BPEL Engine) and business work flow service container 51) Transaction support on message level 52) IDE Integration 53) Open standards
  19. ESB is not a WLS, or WEBSPHERE application server with X additional functionalities. It is a pattern being used in SOA enablement of IT.

    A valid ESB should be a framework implemented in some technology which allow us to add the following features incrementally as we move to higher SOA maturity level as part of SOA adoption

    1) Message brokering between heterogeneous environments
    2) Supports asynchronous, synchronous, publish and subscribe messaging
    3) Supports synchronous and asynchronous bridging
    4) Supports message formats of SOAP
    5) Support for message format of SOAP with attachments
    6) Support for xml message
    7) Support for structured non-XML data
    8) Support for raw data message
    9) Support for text data message
    10) Sport for e-mail with attachment message
    11) Heterogeneous transports between service end points
    12) Supports for FILE protocols
    13) Supports for FTP protocols
    14) Supports for HTTP protocols
    15) Supports for HTTPS protocols
    16) Supports for Multiple JMS providers
    17) Supports for RMI protocols
    18) Supports for web service protocols
    19) Supports for CORBA protocols
    20) Supports for DCOM protocols
    21) Supports for E-mail (POP, SMTP, IMAP) protocols
    22) Support for advanced transformation engine
    23) Support for configuration-driven routing
    24) Message routing based policies
    25) Support for call-outs to external services to support complex routing
    26) Support for point-to-point routing
    27) Support for one-to-many routing scenarios
    28) Support for request response model
    29) Support for publish-subscribe models
    30) Service monitoring
    31) Service logging
    32) Service auditing with search capabilities.
    33) Support for capture of key statistics for message and transport attributes including message invocations, errors, and performance, volume, and SLA violations.
    34) Supports clusters and gathers statistics across the cluster to review SLA violations
    35) Support for service provisioning
    36) Support deployment of new versions of services dynamically through configuration
    37) Migrates configured services and resources between design, staging and production
    38) Supports multiple versions of message resources that are incrementally deployed with selective service access through flexible routing
    39) Configurable policy-driven security
    40) Supports the latest security standards for authentication, encryption-decryption, and digital signatures
    41) Supports SSL for HTTP and JMS transports
    42) Supports multiple authentication models
    43) Policy-driven SLA enforcement
    44) Establishes SLAs on a variety of attributes including
    a. Throughput times
    b. Processing volumes
    c. Success/failure ratios of message processes
    d. Number of errors
    e. Security violations
    f. Schema validation issues
    45) Initiates automated alerts or enables operator-initiated responses to rule violations using flexible mechanisms including
    a. E-mail notifications
    b. Triggered JMS messages
    c. Triggered integration processes with a JMS message
    d. Web services invocations with a JMS message
    e. Administration console alerts.
    46) Support for having multiple LOBs manage their own service bus based on their policies, and a service bus at an enterprise level that could act as a broker for sharing services across the various business units.
    47) Support for agent plug-in to support following features
    48) External provider’s service access for security
    49) External provider’s service management
    50) External provider’s transaction container
    a. External provider’s business orchestration (BPEL Engine) and business work flow service container
    51) Transaction support on message level
    52) IDE Integration
    53) Open standards
    LOL :^). This is the funniest thing I've seen on TSS for a while. Well done Shaji.. People just don't get it. It's just one big rip-off, and it's been like that for a while. No wonder industry commentators like Paul Graham think that the average Java programmer is dumb! How long will it take us to wise up?
  20. LOL :^). This is the funniest thing I've seen on TSS for a while. Well done Shaji.. People just don't get it. It's just one big rip-off, and it' been like that for a while.
    Why are you laughing? That's the best feature list I have ever seen.
    No wonder industry commentators like Paul Graham think that the average Java programmer is dumb! How long will it take us to wise up?
    Please stop bashing Java.
  21. LOL :^). This is the funniest thing I've seen on TSS for a while. Well done Shaji.. People just don't get it. It's just one big rip-off, and it' been like that for a while.
    Why are you laughing? That's the best feature list I have ever seen.
    No wonder industry commentators like Paul Graham think that the average Java programmer is dumb! How long will it take us to wise up?
    Please stop bashing Java.
    Hi Guido, I wasn't bashing Java. Java as been very good to me actually. No I was bashing a certain mentality. In away Java is victim of it's own success. Being the market leader means that you attract a lot of sheep. BTW when you mentioned that this was a great feature list, were you joking or are you serious? Paul.
  22. BTW when you mentioned that this was a great feature list, were you joking or are you serious?
    Seriously, no joking this time. I doubt there is a product, that offers all of this features (except Websphere ;-), but it's definitely a great road map. But listen to Boob Wolfy: if it's not required, don't use it.
    I wasn't bashing Java. Java as been very good to me actually. No I was bashing a certain mentality. In away Java is victim of it's own success. Being the market leader means that you attract a lot of sheep.
    We shouldn't judge people by the language they use (but for sure Smalltalkers are the smartest).
  23. OMG!!!.... Have you ever spoken to a PHP programmer about OO? Try and he'll ask "What's OO?". Java is attracting too many people that that are essentially BOX'ed in thinking. And because it's a market leader. No offense to Indians as a nation, but they provide the most monkey coders currently, to any language. I guess thats because thats the easiest way to get a descent salary in India. But you know... the more developers they produce the lower the median quality of individuals
  24. Re: Everything but ESB or SOA[ Go to top ]

    OMG!!!.... Have you ever spoken to a PHP programmer about OO?
    Yes.
    Try and he'll ask "What's OO?".
    No, he was a smart guy.
    Java is attracting too many people that that are essentially BOX'ed in thinking. And because it's a market leader. No offense to USA as a nation, but they provide the most monkey coders currently, to any language. I guess thats because thats the easiest way to get a descent salary in USA. But you know... the more developers they produce the lower the median quality of individuals
    I don't agree.
  25. Re: Everything but ESB or SOA[ Go to top ]

    OMG!!!....
    Have you ever spoken to a PHP programmer about OO?
    Yes.
    Try and he'll ask "What's OO?".
    No, he was a smart guy.
    Java is attracting too many people that that are essentially BOX'ed in thinking. And because it's a market leader.
    No offense to USA as a nation, but they provide the most monkey coders currently, to any language. I guess thats because thats the easiest way to get a descent salary in USA.
    But you know... the more developers they produce the lower the median quality of individuals
    I don't agree.
    I agree, I don't believe it has anything to do with nationality or race. The real issue IMO is that we need to raise the quality of software developers. This is and always will be the only solution to the software crisis. NO TOOL WILL SOLVE ALL YOUR PROBLEMS FOR YOU!!!!! Sorry for shouting, but this simple message seems never to get through. Fred Brooks told us long ago that there is no silver bullet, yet there is still a thriving industry of vendors who readily invent techno-marketing labels like ESB that supposedly will solve all our problems. Buy their product, use their wizard and bang, a solution to all your problems. This is what Shaji illustrated so well and what I found so funny. In a sense it has nothing to do with programming language, but the Java community seem to epitomize this mentality more then most. Who to blame? Management who think that by buying WebLogicSphere AquaMQBus that they can skimp on developer salaries and hire a bunch of second rate monkeys? Or developers themselves than run like a pack of sheep to learn every buzz word gimmick the vendors choose to bestow upon them? No tool (or language) will solve your problem. You need to solve your problem. The thing that counts most is the skill and the ingenuity of the developers themselves. Paul.
  26. Re: Everything but ESB or SOA[ Go to top ]

    NO TOOL WILL SOLVE ALL YOUR PROBLEMS FOR YOU!!!!! Sorry for shouting, but this simple message seems never to get through.
    I guess that's what Bobby Wolf told us (maybe he told us the opposite, I'm not sure). Don't be ashamed, shout it even louder.
    Fred Brooks told us long ago that there is no silver bullet, yet there is still a thriving industry of vendors who readily invent techno-marketing labels like ESB that supposedly will solve all our problems. Buy their product, use their wizard and bang, a solution to all your problems.
    I'm also an ESB doubter, but that doesn't stop me from having an open mind.
    Who to blame? Management who think that by buying WebLogicSphere AquaMQBus that they can skimp on developer salaries and hire a bunch of second rate monkeys? Or developers themselves than run like a pack of sheep to learn every buzz word gimmick the vendors choose to bestow upon them?
    Don't package your criticism into questions. People could think it's FUD.
    This is what Shaji illustrated so well and what I found so funny. In a sense it has nothing to do with programming language, but the Java community seem to epitomize this mentality more then most.
    Still don't see many features in his list, that are not reasonable.
    No tool (or language) will solve your problem. You need to solve your problem. The thing that counts most is the skill and the ingenuity of the developers themselves.
    Well, at least sometimes you may reuse some piece of software from outer space?
  27. Re: Everything but ESB or SOA[ Go to top ]

    NO TOOL WILL SOLVE ALL YOUR PROBLEMS FOR YOU!!!!!

    Sorry for shouting, but this simple message seems never to get through.
    I guess that's what Bobby Wolf told us (maybe he told us the opposite, I'm not sure).

    Don't be ashamed, shout it even louder.
    Fred Brooks told us long ago that there is no silver bullet, yet there is still a thriving industry of vendors who readily invent techno-marketing labels like ESB that supposedly will solve all our problems. Buy their product, use their wizard and bang, a solution to all your problems.
    I'm also an ESB doubter, but that doesn't stop me from having an open mind.
    Who to blame? Management who think that by buying WebLogicSphere AquaMQBus that they can skimp on developer salaries and hire a bunch of second rate monkeys? Or developers themselves than run like a pack of sheep to learn every buzz word gimmick the vendors choose to bestow upon them?
    Don't package your criticism into questions. People could think it's FUD.
    This is what Shaji illustrated so well and what I found so funny. In a sense it has nothing to do with programming language, but the Java community seem to epitomize this mentality more then most.
    Still don't see many features in his list, that are not reasonable.
    No tool (or language) will solve your problem. You need to solve your problem. The thing that counts most is the skill and the ingenuity of the developers themselves.
    Well, at least sometimes you may reuse some piece of software from outer space?
    Hi Rex, Not sure if you got it, but a tool that claims to do everything is what most people call a general purpose programming language. That's the joke. P.
  28. Re: Everything but ESB or SOA[ Go to top ]

    Not sure if you got it, but a tool that claims to do everything is what most people call a general purpose programming language. That's the joke.
    Maybe you're right and we should all switch to Ruby. It could solve all our problems (includuding the 53 features above)...
    P.
    LOL :-) PS: last post for this weekend...
  29. Re: Everything but ESB or SOA[ Go to top ]

    My last comment on this subject. The fact that Bob Woolf needs to write this article is indicative of a deeper problem. We have managed to get ourselves into a situation where the tools are seen as more important then the people. Good people who understand business and how to exploit technology in a business environment have no need for Bob Woolf's warning (or Shajis' wish list). These people will use what they need when they need it. This isn't the "enterprise environment" we live in today. Mostly tools are seen as an ends in themselves with no connection to business needs. Developers spend their time learning specific tools in the minutest detail, void of the ability to understand business need and translate that need into an appropriate solution that will evolve and adapt with the business over time. How many times do you see the IT department dictating terms to the business? I see it all the time. What percentage of IT systems address real business needs? Beyond payroll most tend to miss the mark. What I am trying to say is that we focus on the wrong things. If we chose to focus on people and skills then appropriate technologies would follow. We should be discussing the problems we face and the values, principles and skills that we need to address those problems - not tools. The best tool we've got is our brains, yet it seems as though we don't want to use our brains. We want to use an off the shelf tool instead, almost mindlessly. It's as if we want to outsource thought itself. End of rant - over and out. Paul
  30. hear hear[ Go to top ]

    My last comment on this subject.

    The fact that Bob Woolf needs to write this article is indicative of a deeper problem. We have managed to get ourselves into a situation where the tools are seen as more important then the people.

    Good people who understand business and how to exploit technology in a business environment have no need for Bob Woolf's warning (or Shajis' wish list). These people will use what they need when they need it.

    This isn't the "enterprise environment" we live in today. Mostly tools are seen as an ends in themselves with no connection to business needs. Developers spend their time learning specific tools in the minutest detail, void of the ability to understand business need and translate that need into an appropriate solution that will evolve and adapt with the business over time.

    How many times do you see the IT department dictating terms to the business? I see it all the time. What percentage of IT systems address real business needs? Beyond payroll most tend to miss the mark.

    What I am trying to say is that we focus on the wrong things. If we chose to focus on people and skills then appropriate technologies would follow. We should be discussing the problems we face and the values, principles and skills that we need to address those problems - not tools.

    The best tool we've got is our brains, yet it seems as though we don't want to use our brains. We want to use an off the shelf tool instead, almost mindlessly. It's as if we want to outsource thought itself.

    End of rant - over and out.

    Paul
    I'm glad someone is saying it. What happened to all those books and articles on good design? You only seem to find them in academic journals nowadays.
  31. Re: hear hear[ Go to top ]

    I'm glad someone is saying it. What happened to all those books and articles on good design? You only seem to find them in academic journals nowadays.
    I guess you're right: Gof4 patterns are the solution!
  32. Re: Everything but ESB or SOA[ Go to top ]

    Or developers themselves than run like a pack of sheep to learn every buzz word gimmick the vendors choose to bestow upon them?
    You mean like JSF, EBJ3, Seam, and Ajax? John Murray Sobetech
  33. PAUL, YOU LAUGH ON MY LIST KEEP IT UP. DO you know one thing I came back to serverside posting after a while cuz people like you still wander somewhere in USA with the support of the ignorant CTOs with over budgeted IT projects to screw tax paying average consumer of the applications. What ever you touch every day in this world from Banks, Investments, Insurance, public services, Consumer business, Supply Chain etc and if it belongs to one fortune 300 company, I have worked on it. Also I was a full time employee of BEA and IBM, so you keep you F***ing software programmer assumption towards me in your ***. Grow up and write software for making human being's life simple instead of screwing the client and their consumer. A nation where 300 millions people consume 25% of these universe assets like Dinosaurs will not care about people like you and the ignorance in SOFTWARE computing. Go and work in Asia and some extend some European countries or Russia and try to sell your BEA and IBM SOA models, they will laugh on you like as you are the biggest ignorance cuz they care about the investment in software computing.
  34. PAUL,
    YOU LAUGH ON MY LIST KEEP IT UP. DO you know one thing I came back to serverside posting after a while cuz people like you still wander somewhere in USA with the support of the ignorant CTOs with over budgeted IT projects to screw tax paying average consumer of the applications.

    What ever you touch every day in this world from Banks, Investments, Insurance, public services, Consumer business, Supply Chain etc and if it belongs to one fortune 300 company, I have worked on it.

    Also I was a full time employee of BEA and IBM, so you keep you F***ing software programmer assumption towards me in your ***.

    Grow up and write software for making human being's life simple instead of screwing the client and their consumer.
    A nation where 300 millions people consume 25% of these universe assets like Dinosaurs will not care about people like you and the ignorance in SOFTWARE computing.

    .
    Which nation consumed the Dinosaurs? Pangea?
  35. PAUL,
    YOU LAUGH ON MY LIST KEEP IT UP. DO you know one thing I came back to serverside posting after a while cuz people like you still wander somewhere in USA with the support of the ignorant CTOs with over budgeted IT projects to screw tax paying average consumer of the applications.

    What ever you touch every day in this world from Banks, Investments, Insurance, public services, Consumer business, Supply Chain etc and if it belongs to one fortune 300 company, I have worked on it.

    Also I was a full time employee of BEA and IBM, so you keep you F***ing software programmer assumption towards me in your ***.

    Grow up and write software for making human being's life simple instead of screwing the client and their consumer.
    A nation where 300 millions people consume 25% of these universe assets like Dinosaurs will not care about people like you and the ignorance in SOFTWARE computing.

    .


    Which nation consumed the Dinosaurs? Pangea?
    Sure, blame the poor Pangeans. Typical American response ;) . And they were the first to use Ruby on Rails. So Shaji, since you were an employee of IBM and BEA, do you feel responsible for all the vendor evils you list here -- twice?
  36. Dinsoaurs in Pangea?[ Go to top ]

    Which nation consumed the Dinosaurs? Pangea?
    Not true. Pangea was disintegrating into continental masses along the subduction zones in the late cretaceous period just before the Permean extinction during which 90% of biomass on the planet was destroyed - so there was nothing much left to consume. Also there werent enough consumers left alive after the Permean extinction. Max biomass cosumption was limited to mid Jurassic period - at which time all the continents were already formed. Ok.. enough for today.. Back to work :-)
  37. Also I was a full time employee of BEA and IBM, so you keep you F***ing software programmer assumption towards me in your ***.
    No doubt you were fired because of your attitude :-).
  38. I am a person believe in Technology than luck. I have worked with your brother TRUCK driver who went to training in Chicago with his HS diploma and joined in Software Consulting. I choose my profession due to the fact that I know what exactly I am qualified for. You can go and check my employment history in BEA. They are the fool cuz some of your stupid brother works there in Decision making roles. I can screw their PS and Sales man at any client place cuz of the fact I am a qualified architect to provide a solution for their client by knowing in and out of their products. So keep doing your imaginary software consulting job with your brothers. Finally if you ever check my federal tax return statement you will know what I am qualified for through my profession. Why don’t you go back to school and figure out what exactly you are qualified for!!!
  39. As I said, from your comments, your language and your general attitude: You will get fired in any decent organization. Your comments here would be sufficient in a lot of countries to "sue your ass off", as they say where I live. Let me have a look at your publications on the area of software architecture in general and SOA in particular then we can have a "chat" about your "qualifications".
  40. peace[ Go to top ]

    As I said, from your comments, your language and your general attitude: You will get fired in any decent organization. Your comments here would be sufficient in a lot of countries to "sue your ass off", as they say where I live.

    Let me have a look at your publications on the area of software architecture in general and SOA in particular then we can have a "chat" about your "qualifications".
    Lets evualate ESB and SOA , not Shaji :)
  41. I hate those decision makers and all those smoke-sellers too, but I think that a little bromide may help sometime. Guido
  42. Also I was a full time employee of BEA and IBM, so you keep you F***ing software programmer assumption towards me in your ***.

    Assuming for a moment that you're telling the truth, this only proves that you were fired at least twice. So, a far as I´m concerned, those "F***ing software programmer assumption" (sigh) about you still hold.
  43. ESB or no ESB[ Go to top ]

    I think an ESB is a great tool if you are trying to build a SOA environment.


    What I got from the article was not that ESBs are bad but that you should focus on building services first and foremost. If you are focusing on the ESB and not on the services it's like building a highway to nowhere.
    But isn't using ESB product, say like Mule, allow you to focus on building services first and not worrying about the rest of plumbing. For those have implemented services base on SOA architecture style, what does it look like in the end if you don't use ESB?
  44. Re: I'll tell my MOM![ Go to top ]

    The word 'web' should not enter a discussion about service orientation until you are talking about implementation details.


    That's true at the start, but past the requirements def, you have to discuss implementation options. MOM would be a pretty good solution. However when you start looking at tools like IBM Websphere MQ and how it uses channels, what should have been a simple and elegant solution instantly turns into muck. (if this doesn't qualify as a MOM tool, then nevermind :)
    We actually have MQ and I agree it's vastly overcomplicated for most purposes but once you get everything set up, this stuff isn't relevant from a high-level design. You really need a dedicated infrastructure team to manage it, though.
    When you start looking at service orientation and technologies to support them, things need to be simplified. It just seems like a lot of design approaches and architectures are overly complicated.

    2 cents
    In complete agreement but you could say that about almost anything technological. Being able to break a problem down into it's most basic form is not a common skill. One of the reasons I don't like to talk about SOA and prefer the term service orientation is that it's not completely clear what qualifies as SOA and what does not. Service orientation is easy to understand and probably more crucial. It's actually surprising to see someone from IBM writing the above. IBM tends to over-complicate everything. I always thought it was to get more consulting and support dollars.
  45. Re: SOA is...[ Go to top ]

    There is no 'W' in SOA
    I dunno.. I hear one.. "so-wa"
  46. Re: SOA is...[ Go to top ]

    Cool. Because I was starting to think I was crazy when I was saying that there is a W in SOA(so-wa). WS-* is a hack, and generally NOT a good solution.
  47. True-ish[ Go to top ]

    There is no 'W' in SOA. So no that's not really correct. Services can exist with out the web. SOA and service orientation is a philosophy and an approach. It's not a technology in the common sense of the word.
    Yea I know, and I understand that it doesn't have to be web services. However it usually is implmented that way. Still this wasn't my point per se. What I really meant is that I agree is't a philosophy and not a technology. So how and why do companies like IBM and their clones try to sell SOA implementations? That would be like hiring the Dalai Lama to change your philosphies to improve system communications. Sometimes you need a an enterprise solution, but other times purchasing a semi truck to pick up a toner cartridge from Office Max is overkill. I think this is why technologies like Spring are used far more than EJB solutions. Back to SOA and ESB... why not just toss out web services with a locater/documentation?
  48. SOA IS NOT WEB SERVICE[ Go to top ]

    "A bit off topic, but in my opinion, SOA really is more or less just a grouping of web services. I've yet to really see anything defining to the contrary. ESB though, I've seen "buses" come and go. They never really deliver on the plan for one reason or another. It'll be interesting to see if this one survives. " PLEASE DO NOT SAY SOA IS GROUPING OF WEB SERVICES IN 21ST CENTURY. IT IS MOST IGNORANT THING AND BUT IN REALITY A BUNCH OF COMPANIES SELLING OUT ACROSS USA. SOA is an Architecture approach, Web service is a technology following some extends SOA architecture approach. SERVICE means some reusable functionalities exposed through an interface approach with proper governance and management support. Web Service is a technology implementation of a SERVICE concept using common language XML and common protocol between SERVICE consumer and provider IBM, BEA, they are still killing an architecture concept by wrapping it around their preparatory products lines. All IBM products are now SOA enabled for marketing. All BEA products are now SOA enabled for marketing; however there is not much change except they are still using SOA as a weapon for using ignorant CTOS to sell their product. They even started talking like MY SOA is better than YOUR SOA. SOA is not a technology or tool, it is a concept applied to IT architecture domain to achieve a maturity to measure better agility to IT enablement of business model same as CMM levels in Quality. Thanks Shaji Nair
  49. Re: SOA is...[ Go to top ]

    This is funny. The fact that no 2 posters even on this thread can agree on what SOA is or is not shows: a) Most Java developers are ignorant (Paul Beckford's point) b) SOA is a bullsh*t acronym that people think is a golden hammer like "ESB." Again Paul's point that most developers/techonologists are ignorant. I agree with the essential thrust that good developers don't need this article (i.e. aren't the target of it) just like we don't need to be debating what SOA is or isn't. Dhanji.
  50. Re: SOA is...[ Go to top ]

    The fact that no 2 posters even on this thread can agree on what SOA is or is not shows
    You have to read more carefully.
  51. @ Shaji[ Go to top ]

    Hi Shaji, I agree that its a good list of features. But honestly speaking, in real world not even 1% of the community needs the full set of features you have given. Some examples.. 1. How many of them really use service logging in production scenario? 2. How many of them really monitor the process alerts and are able to drill down to the detail?. By the time the alert is sms-ed and action is taken, the average time frame of that process goes for a toss in real world. 3. How many of them really use email transport and smtp transport. In fact, it has the potential to bring down the performance of the system by hogging certain number of application-server threads under peak load.. :) 4. Not all the SOA customers may not need ebxml or any specific standard you have listed. I don't deny the fact that its a good collection of features. But hardly I would say any product would support it. ~Rajesh.B
  52. Features I have listed is for a reference model on which you build implementation guidelines for a given level of SOA maturity. SOA is an architecture views applied across business and IT so it touches the enterprise level of your organization. You have to adopt SOA in an incremental fashion not in one step. A maturity level is achieved through different incremental steps. You have to adopt the features as you move from one maturity level to next level.
  53. Re: SOA is...[ Go to top ]

    Most Java developers are ignorant (Paul Beckford's point)
    Most developers are ignorant. So what is your point?
  54. Would A Unix Approach Be Better ?[ Go to top ]

    I first have to admit that I do not have any experience with WebSphere or WebLogic, but I once worked for an EAI vendor in the late 90s and early 2000s. I also have used Unix quite often and I have to use a Windoze box here at work. Shouldn't the approach to SOA implementation be a toolbox methodology ? First identify what you *really* need: things like RPC protocol (RMI, CORBA, DCOM, Web Services,...), message queues (like MQSeries,JMS), transactions (?), directory services (LDAP, JNDI,...), databases (MySQL, Oracle,...). Use all those things as orthogonal tools, each addressing a certain *key* need. If you do not *really* need a certain functionality, keep it out of your architecture. This will allow you to focus on business needs and thoroughly understand your architecture. Unix is pretty much like that: you have a bag of tools each doing a certain thing very well. You can then combine those tools to do exactly what you want; all tools are (more or less) orthogonal. Shouldn't we strive for the same orthogonality in SOA tools ? Only a few people need this 35 item laundry list....
  55. RPC in less than 100K[ Go to top ]

    I final note: these tools can be pretty small. I have implemented an RPC mechanism in less then 100K of code. And that is C++,C#,Java and Smalltalk implementations combined. It does not have IDL (nor does it need one), just a portable serialization library. And it is 10 times faster than WS; as fast as RMI or CORBA. I did the same with a pretty basic Message Queue system. Shouldn't the SOA implementation be a set of small, but efficient tools you combine to deliver a well-understood solution ? I just hated reading reams of CORBA documentation and WS-* seems to be a remake of that.....
  56. Should read: A Final Note[ Go to top ]

    Should read: A Final Note
  57. Re: RPC in less than 100K[ Go to top ]

    A final note: these tools can be pretty small. I have implemented an RPC mechanism in less then 100K of code. And that is C++,C#,Java and Smalltalk implementations combined. It does not have IDL (nor does it need one), just a portable serialization library. And it is 10 times faster than WS; as fast as RMI or CORBA. I did the same with a pretty basic Message Queue system. Shouldn't the SOA implementation be a set of small, but efficient tools you combine to deliver a well-understood solution ? I just hated reading reams of CORBA documentation and WS-* seems to be a remake of that.....
    Sorry Paul, you are right ;-)
  58. Pretty on the inside makes[ Go to top ]

    ...makes it easier to be prettier on the outside. I hate big vendid stacks of complicated goop, when in a lot of cases, getting the dev teams to really see the solution and problem and make things prettier on the inside of the code with the right abstractions often makes it a ton easier to wire up the interfaces that are exposed via whatever you choose. I totally agree with the approach posting, it's an approach, or should be. What often ends up happening, is that after a couple of months of razzle m-tazzle in a POC, a few million dollars, and a long term contract, you are hosed by big vendors with complicated stacks, all the while you don't have your *@#$! together on the inside of the applications. Kind of like being forced into an arranged marriage (your higher up execs are the matchmakers) with a lot of promise, a ton of make up, a big spending habit, and the inability to hold polite conversation.
  59. SOA Product future[ Go to top ]

    People tend to buy products not architectures and the SOA marketplaces seems really fragmented and not very successfully. So it is really hard for people to decide on the best approach hence lots of confusion and hype. Maybe some open source approach will appear in a few years time that will standardize things until then there is lots of hype and heaps of products. I cannot believe the complex software being layered on top of websphere and weblogic will be the right approach in the long run. Maybe companies current applications have to move on some more so a simple approach to SOA will be possible.
  60. Re: SOA Product future[ Go to top ]

    People tend to buy products not architectures and the SOA marketplaces seems really fragmented and not very successfully.
    I don't believe you can buy an architecture in a box, and even if you could it would probably be the wrong one. Enterprise architectures should emerge over time through the gradual integration and refactoring of front line business applications in response to real business needs. A more of a bottom up then a top down approach.
    So it is really hard for people to decide on the best approach hence lots of confusion and hype.
    Yes. This gradual emergent approach requires listening to the business teams and the application development teams. These people know the business challenges and the integration needs. This bottom up view of the world doesn't gel with a top down strategy where technology decisions are made at the top and imposed top down. Most middleware technology is sold to the people at the top.
    Maybe some open source approach will appear in a few years time that will standardize things until then there is lots of hype and heaps of products
    Open source works well, when people are scratching their own itch. When it comes to something like SOA every organisations itch will be different. I think we need to be willing to roll our own, using simple enabling tools to allow us to do so. I've used Tuxedo in the past, and although it is over 20 years old and based on Unix/C it did allow us to develop our own enterprise messaging backbone and integrate to legacy systems.

    I cannot believe the complex software being layered on top of websphere and weblogic will be the right approach in the long run.
    It's the right approach for BEA and IBM. They need something new to sell. It is amazing the number of projects I come across where they have no idea of the business requirements, but they know for sure that they will be using Webshpere or Weblogic :^). Over complex technology for its own sake makes no sense, and I agree people should use the simplest thing they can to solve their immediate needs, then be willing to refactor that solution when driven to do so by more demanding business needs.
    Maybe companies current applications have to move on some more so a simple approach to SOA will be possible.
    Like I say in earlier posts, I don't think the problem is with the applications, but rather with the mindset of their creators (strategists, architects, developers etc). Everyone is looking for a golden hammer, when the simple truth is there isn't one. We just need to get better at building and integrating systems. Paul.
  61. Re: SOA Product future[ Go to top ]

    Like I say in earlier posts, I don't think the problem is with the applications, but rather with the mindset of their creators (strategists, architects, developers etc). Everyone is looking for a golden hammer, when the simple truth is there isn't one. We just need to get better at building and integrating systems.

    Paul.
    With my limited experience I can say that rather than looking for a golden hammer those who decide technologies before understanding business/project needs are looking for a wall where to lay their back. So, when the things go wrong they could always say that stupid developers were unable to use the latest perfect technology they selected. Without considering "relations" with the vendors. There is a wonderful C++ Report editorial from Douglas Schmidt about technical inepts.... Guido.
  62. There is nothing as universal concepts or pure golden concepts when it comes to Technology from a Vendor. Three months ago, I was with a client at Midwest to analysis a deep performance issue on a 24/7 E-commerce application builds on BEA platform by Accenture. Accenture is the consulting firm represent from big five list for BEA products and they sold all the BEA tools to this new client in Kansas City and their cheap imported labor units which they claim that work like the precision of accuracy and consistency of Tiger Wood’s Golf game ability build A SINGLE SYNCHRONOUS web services using BEA controls in BEA WLI platform and cut and pasted that 128 times to create same technology into different business needs, same cut and past approach applied at Aqualogic and Portal side. Client paid them millions of dollar for cut and past service and the entire application is down. When I went to the client place all people call this new system as their SOA system and they believe this is what is SOA mean. When a BEA self claimed Architect from WLI team came to a conference call to discuss the mess, he claimed his company and their partner what ever they did is 110% correct. However in front of people such as VP roles, I pulled out certain steps and methods supposed to applied with the common sense of SOA work with reference to their product documentation available at their own web site and mentioned to his what ever he is preaching with respect to the current situation and whatever his company preaching in Edocs are contradictory he started changing his arguments. “Synchronous message exchange is the new name of point to point integration and if he wanted to do that for 128 business use cases why should somebody have to buy millions dollar software license from a vendor” As long as a client do not have proper investment in right talented IT people. Vendor will screw them for anything and get away. They even sell cow shit and banner it as SOA. It is all about how much they make using their product lines at the end of the day. It has nothing do with Architectural concepts However irrespective of whatever the technology or product we use to establish an SOA enabled IT platform, I believe ESB, Repository and Registry play a big roles to apply governance, reusability, implementation independent collaboration between services and a run time mediation. Service enablement of a component oriented architecture should be an extension of the current architecture framework by introducing the service layer and necessary governance and management model to handle the further complexity introduced by SOA service layer in IT architecture. I hope one-day Vendor’s game will be stopped and people realize as always they are making client fool in this world. Those who interested in Registry and Repository features, see them below Registry Features 1) Replication of registry instances across the network 2) Data store support for persisting the registry information 3) Enforcement of security at metadata access level based on access control on predefined roles and predefined policies. 4) User-defined, fined-grained access control policies based on user-defined roles/groups 5) Federated identity management and SSO 6) Audit enabled. 7) Data validation during publication 8) SOA security mappings 9) Advanced classification of published services 10) Ability to relate any two objects in registry using any relationship type 11) Support for user-defined packages 12) Ability to access business data 13) Ability to support service approval process in service lifecycle. 14) Ability to support service change management in service lifecycle 15) Service change notification during services lifecycle 16) Business service discovery during service life cycle 17) Service quality management during service lifecycle 18) Web-based business service console for configuration 19) Platform-independent open architecture that interfaces with leading enablement, management and security products. 20) Grouping any number of objects in same package with the context of a service repository 21) Group an object in multiple packages with the context of a service repository 22) Digital signature based authentication 23) SOAP and HTTP binding support 24) Published content based event notification 25) Delivery of notification to registered services 26) API and SDK support for customization Repository Features 1) Ability to publish and discover metadata a. Service b. business process c. User interaction d. Reusable assets 2) Sophisticated metadata search by a. Category b. Composite application name c. Service description d. Scope (such as division or department) e. Any other metadata type tracked within the repository 3) Service dependency mapping to track both which assets a service depends on and which assets depend on the service 4) Notification of changes in metadata 5) Extensible metadata taxonomies, so that businesses can customize taxonomies based on their own requirements 6) Authorization procedures to control who can create and manipulate metadata contained within the repository 7) Maintenance of version information for all assets 8) Impact analysis for proactively measuring the impact of a change prior to making the change 9) Open, extensible interfaces for synchronizing with development environments 10) Synchronization with other external stores, such as a registry or other repository 11) Design-time semantic validation of the metadata based on the design-time policies 12) Approval workflows for promoting or rejecting metadata 13) Federation and partitioning for multiple synchronized repositories. Service Management Features 1) Visual process modeling to modify views and business process models 2) Open standards compliance, preferably BPEL 3) Business process orchestration and automation between private processes, public processes, human tasks, and error handling 4) Support for nested and concurrent processes for advanced modeling and custom logic as required to enable rapid customization. 5) Optimized process performance to provide flexibility of configuration for state-full (long-running) and stateless (short-running) process design patterns as well as synchronous and asynchronous process execution. 6) Status monitoring to show users end-to-end processes graphically and measure performance against service level agreements. 7) Process instance monitoring to provide statistics on running processes, drill into individual details, and terminate, delete, or suspend problematic process instances. 8) Enable task creators, workers, and administrators to interact with running business processes for handling process exceptions, approvals, and status tracking. 9) User and group management to centralize the assigning of roles, users, and groups working on integration projects. 10) B2B protocol support for rapid, secure online connection with suppliers and customers using leading standard protocols such as RosettaNet, ebXML, and EDI, with secure messaging, digital signatures and encryption, recoverable and traceable messages, and dynamic configuration updating 1) Manage and maintain the service at enterprise-wide 2) Map and maintain service hierarchy across the enterprise and provide dependency matrix to operations 3) Detect and manage exception conditions 4) Review and monitor business transactions, and provide the capability to review in-flight transactions 5) Manage service lifecycle and validate before deployment 6) Provide non-intrusive service discovery across multiple systems 7) Manage and integrate with multiple service bus and service registry infrastructures 8) Leverage the existing monitoring infrastructure. 1) Visual process modeling to modify views and business process models 2) Open standards compliance, preferably BPEL 3) Business process orchestration and automation between private processes, public processes, human tasks, and error handling 4) Support for nested and concurrent processes for advanced modeling and custom logic as required to enable rapid customization. 5) Optimized process performance to provide flexibility of configuration for state-full (long-running) and stateless (short-running) process design patterns as well as synchronous and asynchronous process execution. 6) Status monitoring to show users end-to-end processes graphically and measure performance against service level agreements. 7) Process instance monitoring to provide statistics on running processes, drill into individual details, and terminate, delete, or suspend problematic process instances. 8) Enable task creators, workers, and administrators to interact with running business processes for handling process exceptions, approvals, and status tracking. 9) User and group management to centralize the assigning of roles, users, and groups working on integration projects. 10) B2B protocol support for rapid, secure online connection with suppliers and customers using leading standard protocols such as RosettaNet, ebXML, and EDI, with secure messaging, digital signatures and encryption, recoverable and traceable messages, and dynamic configuration updating
  63. Feature list No. 2
    You spent too much time with Accenture.
  64. Accentures[ Go to top ]

    They are 21st centuries ITIV. It will not show the symptoms as it hit but slowly they kill the IT investment of an organization just like HIV kill a human being. Unfortunately they can buy any big firms in USA
  65. A Few Points[ Go to top ]

    A few points * Why do we often see the service so tightly coupled to transport HUH? * Why use SOAP/WSDL? - Tool support, you know, automation, the key to our industry. * MOM doesnt mean no SOAP, Standards require SOAP over JMS * Developers often dismiss the importance of monitoring/logging, try some time in a Test/Production Support env sometime. * In an ideal world, Good People would be preferable, but we dont live in that world, we need Standards driven tools that minimise the impact of 'Less than Good' people. * Dont forget certificate management, everyone forgets certificate management :-)
  66. Re: A Few Points[ Go to top ]

    A few points
    ...
    * In an ideal world, Good People would be preferable, but we dont live in that world, we need Standards driven tools that minimise the impact of 'Less than Good' people.
    This is where the whole Java/J2EE experiment went wrong! The whole EJB idea back in 1997 was intended to make programming easy so that we could accommodate "Less than Good" people. It failed. Who remembers Bruce Tates EJB Anti-patterns book? This is where the first cracks in the facade showed. Bruce illustrated that you can't program buy numbers, just blindly applying patterns. Bruce has given up on the Java crowd now and is now making his money with Ruby. Rod Johnson, then went on to illustrate that the language Java was more important then the tools (J2EE, EJB etc, although you wouldn't think it if you heard him speak about Spring today :^)). So we know that the assumption behind your assertion is false. I work as a Coach and I'm yet to meet a developer who hasn't got the potential to be good. Most developers spend there careers working in isolation, basically in fear that they'll get caught out, and someone will realise one day that they are 'less than' brilliant and don't have all the answers. We work in pairs where we all help and learn from each other. No one needs to be afraid - because guess what? None of use have all the answers! We also regularly discuss design as a team in an open and honest way, where everyone feels safe to say that they don't know. I'm not saying that it is easy to build skill, but it is possible, and a lot more preferable then relying on tools and so called standards/patterns. Programming is an intellectual exercise, and all attempts at dumbing it down have failed. EJB's etc led to class loader hell, where you needed a PhD to debug your Application Server :^). In the end we always end up relying on good programmers. Some believe that eventually we'll all end up like Paul Graham programming in Lisp, who knows :^). Most professions do not tolerate mediocrity. Would you allow a Surgeon who was 'less than good' to operate on you just because the Hospital had standard tools and procedures in place? You would expect the hospital to mentor junior doctors and ensure that they're competent. You would also expect all doctors to be supervised by their peers. A failure to ensure competence and adequate supervision is a failure in leadership. Paul.
  67. Re: A Few Points[ Go to top ]

    In an ideal world, Good People would be preferable, but we dont live in that world, we need Standards driven tools that minimise the impact of 'Less than Good' people.
    Good Luck!!!
  68. Re: A Few Points[ Go to top ]

    ... whole EJB idea back in 1997 ...
    You live in the past (but you're not the only one).
    I work as a Coach ...
    Ruby or Java?
  69. Re: A Few Points[ Go to top ]

    ... whole EJB idea back in 1997 ...
    You live in the past (but you're not the only one).
    I work as a Coach ...
    Ruby or Java?
    Both!
  70. Re: A Few Points[ Go to top ]

    Both!
    Hope so.
  71. Re: A Few Points[ Go to top ]

    ... whole EJB idea back in 1997 ...
    You live in the past (but you're not the only one)
    I wish it was the past. All JEE5 compliant application servers must be EJB 2.1 compliant too. Which means that most EJB3 implementations encapsulate the same old EJB2.1 under the covers. Also this idea of dumbing down doesn't only apply to App Servers. It was one of Gosling's design goals to limit the features in the Java language so that it could be readily understood by 'mainstream' programmers. Since 1995 he as admitted that perhaps this was a mistake, and we are now faced with trying to retrofit the language with all those power features that we now know we need like closures. My point is that we need to learn the lessons of the past, and not continually repeat the same mistakes. Paul.
  72. Re: A Few Points[ Go to top ]

    ... same old EJB2.1 under the covers ... Since 1995 he as admitted that perhaps this was a mistake ... that we now know we need like closures.
    You focus too much on implementation details (and in the wrong way). There are so many great and experienced Java developers are out there. That's what makes the success. Btw, I learned Ruby in 2002 and it was a great experience, but it was never more fun to be a Java developer than nowadays.
    My point is that we need to learn the lessons of the past, and not continually repeat the same mistakes.
    I guess that's what a coach is good for.
  73. Re: A Few Points[ Go to top ]

    There are so many great and experienced Java developers are out there. That's what makes the success.
    Really... Now if you had said:
    There are so many great and experienced developers are out there. That's what makes the success.
    I would agree whole heartedly :^) Paul.
  74. Re: A Few Points[ Go to top ]

    Now if you had said: There are so many great and experienced developers are out there. That's what makes the success. I would agree whole heartedly :^)
    Agreed and peace. Must work now...
  75. Re: A Few Points[ Go to top ]

    All JEE5 compliant application servers must be EJB 2.1 compliant too. Which means that most EJB3 implementations encapsulate the same old EJB2.1 under the covers.
    Why are there so many EJB3 fans out there pretending that they don't see this simple plain truth?
  76. I don't need a golden hammer...[ Go to top ]

    All JEE5 compliant application servers must be EJB 2.1 compliant too. Which means that most EJB3 implementations encapsulate the same old EJB2.1 under the covers.
    Why are there so many EJB3 fans out there pretending that they don't see this simple plain truth?
    ... I just need a baseball bat.
  77. Re: A Few Points[ Go to top ]

    All JEE5 compliant application servers must be EJB 2.1 compliant too. Which means that most EJB3 implementations encapsulate the same old EJB2.1 under the covers.


    Why are there so many EJB3 fans out there pretending that they don't see this simple plain truth?
    I don't think that EJB 3.0 fans are pretending about anything. This is a simple backward-compatible requirement. It doesn't mean that the whole thing is just a wrapper for EJB 2.1. JPA is EJB 3.0, and has nothing to do with EJB 2.1.
  78. Re: A Few Points[ Go to top ]

    It was one of Gosling's design goals to limit the features in the Java language so that it could be readily understood by 'mainstream' programmers. Since 1995 he as admitted that perhaps this was a mistake, and we are now faced with trying to retrofit the language with all those power features that we now know we need like closures.
    When Gosling was wrong then, why should he be right this time :-). I know about as many people who think that closures are a good thing than the other way round and much the same with most of the "new language features". In my opinion, there is a lot of evidence that "simple yet powerful" is still better than "complicated and more powerful". The vast majority of programmers has problems to grasp what J2SE 1.4 supplies (like polymorphism!).
  79. Re: A Few Points[ Go to top ]

    Most professions do not tolerate mediocrity. Would you allow a Surgeon who was 'less than good' to operate on you just because the Hospital had standard tools and procedures in place?

    You would expect the hospital to mentor junior doctors and ensure that they're competent. You would also expect all doctors to be supervised by their peers. A failure to ensure competence and adequate supervision is a failure in leadership.

    Paul.
    I understand your point in general, but to nitpick a bit, I do not agree that most professions do not tolerate mediocrity. Mediocrity is (unfortunately) everywhere, and in particular an intrinsic part of Parkinson´s Law and at the heart of the hiring process (Comitology - "An official wants to multiply subordinates, not rivals").
  80. Conclusion: Take care ...[ Go to top ]

    ... SOA killed the dinosaurs!
  81. From more then a year I am hearing the SOA buzz word so much that now I have earache. What are this guys trying to sell? The enterprise systems are more or less service oriented. You have remote components (sharable services), local components (non-sharable services), integration b/w system (EAI, ETL etc), discovery (non-automated), grouping (portal) and lots of other feature. The integration with partners also takes place in similar line with well-defined protocol and SOA (terms coined by marketing guys) will not change anything And I will tell you companies are smart and they use of all this more or less efficiently. Is SOA bundle more then this? Thanks, Shabbir