Lost in the hype around Service Orientated Architecture (SOA) is the fact that the idea is really really simple. It’s all based on the idea that most applications (and that includes websites) are built either to be used by people , or used by computers. The pictures below (a free preview from the Enterprise Java Briefing) show what I mean.

In a ‘normal’ application, such as a online banking website, we need to remember what the user did last (are they logged in, what account are they looking at, are they in the middle of making a payment). If we didn’t , the user would get annoyed about having to repeat themselves every step of the way. It would also make for pretty complicated screens, to allow the user to enter all the information in one go. Instead , we allow the user to enter information in several steps, and remember where there are each time.

In an application designed to be used by computers, we don’t have to worry about this. We can force the computer to give us all the information required all in one go - username , password, bank account to take money from , bank account to give money to, date to execute transaction. For a computer , this is actually easier ; we make one call to our banking service and we are told it has succeeded or failed. It’s also easier for us to build our service:

• Each service (transfer money, book flight , execute share trade) only does one thing.
• Because each service ‘forgets’ after each call, we don’t need to worry about trying to remember what we were doing before.
• Because we have no memory, services are very scalable; we can make several copies of the same service and put them in a pool. Any client can talk to any service - no waiting for a particular server to become available.

So that’s Service Orientated Architecture (SOA) : programs that do one thing (a bit like a function call to a method) exposed that other computers can call. So what’s the big deal? Like all good ideas , a simple concept goes a long way.

Take a look at the picture below. It’s like a Visio diagram, but in fact it’s drawn by the Eclipse Based JBoss IDE. It shows a workflow for an online commerce store - pretty easy to understand. This example uses JBoss Java Business Process Managment (jBPM), but companies such  Tibco, Cape clear and Oracle BPEL have similar products.

Here’s the clever bit; each of these steps is executed by one of the services that we talked about earlier. This means that if the business process changes (and it will), then all you have to do is re-arrange the diagram ; little or no coding changes should be required.

This abilility to mix , match, combine and remix services leads us to a lot of other good things (and we’re only scratching the surface here).

• Because our services don’t have to run on the same machine, we can use SOA to create a distributed application. This is the concept behind the BPEL (Business PRocess Engineering Language)
• Services tie well to Ajax and Web 2: Our Ajax web page or portlet can call as many services as it requires to get the job done (it’s one of the reasons Tibcom is sponsoring the open source DWR project)
• We can call many services at once. If these this service calls are xml based ,or we send these calls as a message then we can filter, duplicate, pass and other distribute these calls as we set. These are the ideas behind Apache Synapse, Apache Servicemix and the  Enterprise Service bus (ESB) in general.

What do you think? Is SOA useful , or over hyped?

related posts

Most people building systems run into the following problems again and again:

• How to capture Business rules , in a way that both the Business users and the computer can understand.
• How to capture the flow of actions in a system, in a way that both Business users and the computer can understand. This flow is across multiple users, and may extend over days or weeks.
• How to deliver a system to the user (e.g. Via the Web), but to give the user a rich interface , similar to what they are used to on the desktop.
• How to maintain and enhance older systems , now that Java has been mainstream for more than years.
• How to take advantage of the new Features afforded by Java 5 and EJB 3, and what business problems to the solve.
• How to build components for reuse in all environments (Web , Enterprise, Command Line and Desktop).
• How to map information in a Java System to and from a Database (Persistent Storage or Legacy System).
• How to deliver value to the business at every point in the project.
• How to use the many resources and solutions already available in the Java community.

It’s to address problems like these , that I’ve been asked to put together a Advanced Java training. It’s early days yet, but I’d like to get your input as to what you’d like to see on such a course.

Full details of the Advanced Java course are available on the knowledgebase / Wiki. Leave your comments here.

Update: I posted a similar question on the (technical) O’Reilly Books Java blog. If you’re interested in seeing the responses , click here.

The best thing about doing presentations is the questions you get asked at the end. Apart from the stomach churning moment of ‘will I be able to answer this one?’ they give you a new angle on things that you may have always assumed, but force you to think of in a different way.

Take one of the questions after yesterday’s Enterprise java presentation at DCU. One of the topics mentioned in the final ‘putting it all together’ was the Agile and RUP (or other upfront design) methodologies. The question , coming from an attendee that was keen on using Agile , was ‘How do you do Architecture in an Agile project?’

On the face of it this seems a contradiction. Agile in it’s most extreme form is ‘make up just enough design as you go along’, with automated tests to make sure changing things later is a relatively low cost and pain free process. In real life most projects are a balance between Agile and need some element of a more formal process (often trying to answer the question ‘how mucn is this going to cost?)’

So , how do you merge Agile with an upfront design process? It’s easier than you think.

Most systems built the ‘traditional way’ do not get all their design done in one go. They might start out with the best of intentions for phase 1 with a clean sheet but over the months / years people come and go, business requirements change and different phases try to deliver different things. Over time the original clean design twists and turns and you work hard to try and make it work out ok. Some of features you thought were key may end up getting thrown out as too complicated.
Now Agile architecture is a similar situation. Each weekly / monthly iteration is like phases on the larger project , with twists and turns that may be unexpected. The difference now is that you have a safety net comprised of your (J)Unit tests, to allow you to make radical changes if your blueprint ends up in a cul-de sac.

Yes, it is ok to have an idea the bigger picture and where you like to go with the design. Yes, a good architect will find reasons in the current release to build towards that design. And yes, a good architect may admit that some of the design features he / she thought were required weren’t actually needed. The difference between Agile and Upfront architecture is in when you find your ‘Don’t really need it’ point. With Agile , you find it just before you build it. With upfront design / architecture you find it when it’s already too late.

It’s all been very quiet over here , too quiet. And not just because of the hosting issues (the people at Netbunch, you know that I’m talking about you)

It’s been very quiet , because I’ve been very busy. On top of all this , we’re coming to the end of the year for the (part time) Masters at UCD in Dublin, so we’ve also got exams coming up. Thankfully it’s the last year, the downside being I have a dissertation to write.

Being a blogger , I’m not happy putting together a weighty tome that will sit gathering dust on a shelf. Instead , I want something that will solve some business problems , and that I can use as interesting content. So after much thought , the proposed title of my dissertation will be …… cue drum roll ….. ta-da!

Enterprise Web 2.0

Now, if you’ve talked to me , you know I spend a lot of my working day as an Enterprise Java Consultant , working for various banks. The idea is to take some of the Web 2.0 ideas (and you don’t need me to repeat them) and apply them to the sort of problems large companies have. Or , if you want the catchy subtitle , ” it’s all about sucking the knowledge out of people’s brains and putting it onto (ugly) websites”.

So an obvious topic to cover is the use of Ajax , which while big on the web at the moment , is going to be huge once companies realise what it can bring to their internal applications. The rest of the topics cover knowledge management (what is web 2.0 if it’s not about sharing knowledge), but also some tools and techniques that will all Enterprise Java (with all it’s robustness and scalability) compete with the nimbleness and tricks of Ruby.

Business Problem 1: How to present this information to people in a easy to deploy, but powerful way.
Solution: Update to Sun Java article - this one on how to do Web 2.0 / Ajax ‘right’ in Enterprise Java (i.e. not worrying about legacy code)

Business Problem 2: Where you have documentation, but don’t know how to find it.
Solution: Write up of the Red-Piranha Adaptive Search engine that ‘learns’ what the team wants , and finds more of it.

Business Problem 3: Where you have information in Excel sheets, but can’t do much with it.
Solution: Update to previous O’Reilly Articles on JBoss Rules - this one on JBoss’ ability to ‘run’ Excel Spreadsheets.

Business Problem 4: Where you have information that people ‘know’ , but that a machine finds it hard to ‘learn’
Solution: Simple Neural Networks using Joone, applied to a ‘real life’ business problem.

Business Problem 5: Where several people have to work together on a set of information , following a strict set of steps.
Solution: JBoss workflow, with a simple online example

If you’re very observant , you might notice that this post is about a week late. Still , here are my notes on the slides / nodes from the final day of the Agile course.

Previous Posts from the training course are:

• Day 4
• Day 3
• Day 2
• Day 1

Junit Introduction

• Junit
  Framework for writing automated unit tests (don’t need to use Junit
  to write the tests , but it helps)

• All Junit
  tests extend TestCase

• Individual
  test methods (pre Junit 4.0) : public void testSomething() method
  signature

• Use
  assertEquals assertTrue assertFalse assertNull assertNotNull
  assertSame and fail methods for testing.

• SetUp() and
  tearDown() methods called before and after each test method.

• TestSuites
  (groups of TestCases) replaced by Ant and (Eclipse) IDE
  functionality

• Run tests via
  built in Text / Swing test running , or more likely use IDE / Ant
  integration.

• Organise via
  same or paralell folders

• TestMyClass
  or MyClassTest

Mock and Stubs

• Problem: some
  classes (Collaborating Objects) can be tightly bound to system
  resources (e.g. File or Database) or to a hard to test API. Another
  example is the observer pattern. How do we unit test these?

• Solution: use
  fake object , pass it to class under test , allows testing of the
  class at a unit level.

• Stub : fake
  object that uses hard-coded data , often following an API. Many
  ready made stubs available (e.g. For the JDBC libraries).

  • Replace
    expensive to create objects

  • Have to
    create all objects that production code interacts with.

  • Start in
    middle and develop outwards

  • One failure
    can ripple out / appear elsewhere.

• Crash Test
  Dummy: type of stub that deliberately fails in order to test
  exception handling – simulate database crash or I/O full.

• Self Shunt is
  where the unit test itself implements the interface (doesn’t work
  for classes) and gets callbacks from the class under test.

• Mock Objects
  like stubs, except that they are intelligent enought to self-verify.

  • Mock
    Secondary objects (normally ones that we build) instead of API (as
    Stub does)

  • Outside in
    development style

  • What if mock
    implementation is incorrect?

• Interaction vs. State: In
  state-based testing you check the tests by examining the state after
  the stimulus. In interaction based testing you check the right
  interactions were triggered by the stimulus - Martijn
  Fowler, http://martinfowler.com/articles/mocksArentStubs.html
  

• Mock objects
  tend to test more the interaction between objects rather than a unit
  test of the object itself.

• Stub rather
  than mock external API’s

Smells and refactoring.

• Code smells
  are bad or suspect design decisions in code.

• Not always
  bad , but should be looked at (often will involve a trade off)

• Smells are
  often hard to understand , hard to change code.

  • Samples :
    duplication / long methods / poor naming / tightly coupled classes
    / switch statements /

• Refactoring :
  Small , controlled changes to codebase , so that it continues to
  compile / tests run to improve the design. The behaviour remains
  exactly the same.

• Seperate
  refactoring and adding additional functionality.

• Easier with
  automated tools and Unit tests to confirm that nothing has broken.

• Refactoring
  != Rewrite. Codebase is evolved , not thrown away.

User Stories

• In some ways
  , equivalent to Use Case from Predictive methods (but with subtle
  differences).

• Represent
  chunk of functionality that makes sense to the customer.

• Can be
  represented as card / conversation / paper based documents (more
  predictive approach).

• In Agile (as
  opposed to predictive) , shift the focus from writing to talking
  i.e. Get a true understanding of what the customer wants , even if
  they haven’t expressed it very well.

• Lessen the
  importance of requirements

• Support
  iterative development and participatory design.

• Even a simple
  requirement has many possible permutations (that lessen the odds of
  getting it right.

• Not just a
  generic user – but more user roles – groups of users that do
  different things with the system , depending on their experience ,
  task at hand etc

• User Stories
  should be Invest:

  • Independent

  • Negotiable

  • Valuable

  • Estimatable

  • Small

  • Testable

• Templace
  (FlashCard , as used by Xplanner)

• Be careful of
  size

  • too big and
    cannot be used for estimated (break these down into smaller
    stories). Easy for Compound , but for complex stories might need to
    do some research and then break out.

  • Too small ,
    and it is not worth the admin of estimating each. Bundle them up
    into higher level task like UI improvements or bug fixes.

• User Story
  should give us the acceptance tests

We’re giving a talk about ‘how to talk to your boss about agile‘ for the Irish .Net Developers Association next Tuesday in Buswells hotel Dublin.

More details (including the slides themselves, as a preview of what you are missing) are available here in powerpoint, openoffice, pdf and flash formats. The slides explain how 4 pictures of bridges can explain the difference between Ad-Hoc , Predictive, Agile and XP projects. No , really , you do want to check this out.

Links to a lot of the sites / articles / tools used in the presentation are here on Del.icio.us. More posts on this blog about using agile techniques on projects are here.

The Bridges are:

• Old Drogheda Bridge from the 1200’s - Quick and Dirty or Ad-Hoc project. Got the job done , and fast . Was patched a load of times, but eventually fell down under the weight of the traffic.
• New Drogheda Motorway Bridge - Predictive Projects. Very easy to specify what you want (I want a bridge going from A-B to carry a motorway) and very easy to know when you are finished.
• Drogheda Railway Brigde - Agile. Once the longest Iron Girder bridge in the world.Built in the 1850’s and the spec has kept on changing since. This included a complete rebuild in 1925 without losing a single days traffic. How’s that for unit testing?
• Bungee Jumping off bridge in Queenstown - Extreme Programming (XP). Great fun if you’re doing it (and can be pretty effective), but scary for anybody watching.

As a sample of some of the pictures (which include lego people showing everything that can go wrong on a team), check out the image below.

.
Image from
TheBrickTestament.

A while back I wrote an article for an O’Reilly sister site, Java.net , on Sprinkle Some Ajax Magic into your Struts Web Application. I’m going to repeat one thing I said in this article: while coding Ajax is cool, you really want to use a framework if you have the choice. If you don’t believe me , check out some of the podcasts on Ajaxian.com. When you listen to the problems that the frameworks have overcome (What if the ActiveX XmlHttpRequest Object is turned off? What if you want to do local storage? What if the user hits the back button?), you’ll be a convert to the ‘Frameworks are better’ approach. So which Ajax enabled framework should you use as an Enterprise Java developer?

Pre Ajax, the answer to ‘which Java presentation framework should I use?’ would have been Apache Struts. Not because it was technically better than any of the other frameworks (although feel free to leave your comment!) but because everybody else is using it. This meant
(a) using Struts is good for your client, as they can replace you if you get run over by a bus and
(b) using Struts is good for you, as you can take your Struts skills to your next piece of work.

However , in this strange new Ajax and Web 2.0 world, things are beginning to change. Javascript gone from ‘has been kiddie scripting language’ to ‘coolest thing on the planet’. User expectations about what Enterprise Web applications can are going through the roof as Web 2.0 enters the mainstream. What Java framework are you going to use to deliver these expectations?

With this in mind, I did some research on the Ajax Enabled Java frameworks that are currently (Feb 06) available. I tried to pick out the best ones (best for your career, and hopefully technically best) based on the following criteria:

• Java - Web development frameworks with Ajax capability.
• Rating based on technical capabilites, and which is most likely to be the ‘next Struts’ (i.e. become the defacto standard for Java-Web Development).
• Rating is based partly on downloading and running the projects and partly on evaluation of what the websites / other people say.
• Products must be available (at least partly) in open source form with a recognised open source licence - as these are most likely to get community traction.

Before we get into the list, there a couple of items that you may think are missing:

• Whatever you may think of non-Java frameworks (e.g. Ruby on Rails, PHP with Ajax), these are not included here. The notion of Java being replaced by Language / Framework ‘X’ is an entirely different article.
• The list also does not include several excellent ’server neutral’ frameworks such as BackBase, Dojo, Prototype, or JSON. While these frameworks are included with some of the toolsets listed below, we’re aiming to get an ‘out of the box’ toolkit for the Web tier of Enterprise Java applications.
• You’ll also probably note that there are 3 implementations of the Java Server Faces (JSF) standard on this list - MyFaces , Ajax JSF and Struts (Shale).

Think we got the evaluation wrong? Leave your comments at the bottom of this post.

Ajax Java Web Presentation Frameworks

Conclusion
The New Struts is …. Struts. Some other framework may overtake Struts to become the new standard, but I would recommend the following Struts-related frameworks based on the following scenarios

Scenario 1: Adding Ajax to existing Struts Applications. Use AjaxAnywhere - closest to the approach taken in the article Sprinkle Some Ajax Magic into your Struts Web Application. Despite writing this article , I see the frameworks evolving rapidly to the point where you would only take such an approach for adding Ajax to ‘Legacy’ applications.

Scenario 2: Need Ajax Now for a new Java Application. Use Appfuse as it gives Struts, Ajax (with DWR) and the possiblity of JSF integration now, all ‘out of the box’. This fits in well with …

Scenario 3: Medium Term. Use an implementation of JSF (either MyFaces or whatever Appfuse promotes - probably Struts Shale). Struts Shale (JSF) has so far released only ‘overnight’ builds. Apache MyFaces (JSF) tool support and Ajax capabilities are likely to improve over time. Both Struts-Shale and MyFaces are likely to play well with AppFuse , making it a safe bet for investing your time checking it out.

Link to Enterprise Java Workshop, to be led by Dr. Bruce Martin in Dublin on the 6th - 9th March.

Is anybody going? Is it worth $1995 USD for 4 days? (and I’m not going to get sniffy about us using Euro over here ) Who is this course aimed at? In some ways this course is like Corba: very relevant to the very small niche that use these technologies, but the broader line of ‘best practice’ has moved on.

An extract from the Agenda is below. It seem to broadly match what Sun looks for in it’s Enterprise Java Architect Certification. As such it shares the plus and minus of this approach : You get the Orthodox Entreprise Java Approach, or at least the approach being plugged by Sun about 3 years ago.

The trouble with this approach is that the Enterprise Java world has moved on. Hibernate has pushed aside Entity Beans , so much so that Enterprise Java Beans 3.0 is a complete turnaround it it’s direction. Spring has got a lot of traction as an EJB-Lite (and I mean that with the most positive connotations). Enterprise Java Patterns are much better understood (just search the IBM site), if not more widely understood.

Where’s the Ajax and the impact of multiple, small , web requests on application scalability? The JSON (as part of the Web Services)? Does it cover Java Server Faces and the emerging Ajax enabled Java Presentation Frameworks? What about workflow and rule engines and Java Messaging Services (JMS)? How about the tool integration to make your teams life easier when building the designs that you , as an Architect , have come up with? I don’t see Security in there , nor any of the other JSR (Java Specification Requests) that have come out of the broader Java community in the last 3 years.

And that’s before I go on about the only ‘technology alternative’ being offered is .Net - the PHP , Ruby and Oracle guys will have something to say about that! All have strong cases to make on a project by project basis. What about off the shelf products (both open source and commercial) that could , depending on the project, give you most of the functionality you need and you just have to customise the remaining 20%?

Maybe I’m being unfair, and the above is not the aim of the course.

For info, it’s on in the Gresham hotel on Dublin’s O’Connell Street from the 6th to the 9th of March. If you want a good solid foundation in Enterprise Java, and if somebody else is paying for it then it’s probably to be recommended. It might even help you get certified as a ‘Sun Enterprise Java Architect’. But unless you’re in an outstanding group, don’t expect it to be cutting edge.

Are you going - prove me wrong and leave a comment!

Project Module

• Introduction
• The Value Propositions of J2EE and EJB
• J2EE vs..NET
• Requirements of the Auction Application
• Group Discusssion: J2EE or not, EJB or not
• Activity: Identify the Auction Objects
• Vertical Slices
• Activity: Identify Vertical Slice
• Communicating Architectures

Persistence Module

• Pros and cons of JDBC
• Object Relational Mapping
• Java Data Objects (JDO)
• EJB 2.x CMP Model and Relationships
• EJB 3
• Other O-R mapping solutions
• Group Discussion: Persistence Matrix
• Activity: Persistence Strategy for the
  Auction
• Advanced Transaction and Concurrency
  Control topics
• Activity: Identify the Transactions

Scalability Module

• Principles of Scalability and Fault
  Tolerance
• Application Server Clustering solutions
• Activity: Scaling the Auction

Integration Module

• Messaging
• Activity: Messaging in the Auction
• Connectors
• XML, Web Services and SOA
• Activity: Enterprise Application
  Integration
• Activity: B2B Integration

Application Design Module

• Top Ten J2EE Design Patterns
• Activity: Design patterns or not
• Activity: Complete the design
• Group Discussion: Custom Consulting

It now seems obvious that the Healthcare Payroll system was destined to fail. If you were working on the project, I’m sure it felt very differently at the time. How can your projects avoid a similar fate? While IT may sometimes seem disconnected from reality, the following guidelines show that ‘Real World’ lessons still apply.

1. Know what you want and stick to it. If you’re building a house and change the plans several times the builder is going to fleece you, no matter how low the initial quote was. The same goes for IT Projects - if you change your mind after the price is agreed, you’re going to pay more.
2. If you don’t know what you’re doing , find a friend who does. I know very little about houses, so when I was buying my own I got a friendly surveyor to check it out. With IT projects, this ‘friend’ should be genuinely on your side, and have something to lose (e.g. financial or reputation) if things go wrong.
3. Little and often is better. Like exercise, smaller projects that deliver results little but early are best. If the results are good, try a second (and third) round to add more functionality based on the feedback from users.
4. It’s been all done before. Tailored suits cost a lot more than ready-made ones - and most people are happy with a ‘Good enough’ instead of ‘Perfect fit’. There are literally thousands of ‘off-the-peg’ computer systems out there ready for final alteration to what you need.
5. If you don’t understand the answer, ask more questions. Thankfully the days we sat and nodded at the Doctor’s Latin words are long gone. IT Consultants may sometimes speak a different language, but if they can’t explain what they’re talking about in English that you understand, the chances are they’re trying to hide something.
6. Don’t build on sand. Like houses , projects need good foundations. For IT Projects , the good foundations are sound knowledge of the Business Processes being coded into the system. Changing processes and changing IT systems at the same time is like building on sand.
7. Sometimes the tortoise wins the race. Unless your entire business model is built around being the very first to market, then being a tortoise and letting others race ahead has very big advantages. Not only can you learn from other people’s mistakes, but the chances are you’ll get it at a much reduced cost - For example websites now cost a fraction of what they did during the dot.com boom.
8. Use a safety net. When building houses, often the first thing to go up is scaffolding, for safety reasons. The equivalent safety net in IT is called ‘Unit Tests’. Not only do they help you get there faster, but they let you know if you’ve broken something you’ve already built.
9. Be a good poker player. Good poker players never give away valuable cards. For IT projects, owning all cards mean just that - make sure that you have full rights to the solution so that you can still move tables and use a different supplier. Even if you never make the move, knowing that you can is an effective bargaining chip.

And finally …

When you are in a hole, stop digging. The decision to call a halt to the projects was no doubt a difficult one, and is to be applauded. Too often, the temptation is to keep on going and hope things will turn out right. Recognising problems at an early stage means there is more chance of being able to fix them.

Our Technical Knowledge base has just been launched.

We found that over the last 5 years , 80% of the solutions we were building were the same. How many ways are there to take information from the web, apply some business rules or logic to it, and then save it into a database?

Currently the knowledge repository contains information on Enterprise Java , XML , Eclipse, Oracle, Architecture, Project Management as well as a lot of useful links for Dublin, Ireland and Technical specific areas.

The public area to the site can be found here. All information is generic, non-client specific, and can probably already be found on the web, although it is much easier to read it here!

The UK based IT Architect site is running a series of articles on why IT Projects fail.

(Part 1) suggests what is obvious (that there are different types of projects), but more usefully classifies them into two types. Type 1 are those that deliver concrete goods (like roads, bridges and office blocks). Type 2 are fuzzier projects aiming to change things, such as a process or organisational culture. It’s much harder to determine success in this second set, as they tend to deliver intangible results (i.e. you can’t drop them on your foot) . They also tend to suffer greater rates of failure. IT projects tend to be Type 2.

Some depressing statistics that if you’re lucky have only read about , or if you’re unlucky, know from personal experience. According to the Standish group, 31% of IT projects are cancelled outright, and over half have such serious performance issues that they were fortunate to escape the same fate. In contrast, a 3% overrun on a construction project is often the trigger for a public enquiry.

While there are many ‘excuses’ given for project failure, the author suggests that often the root cause is over-optimism and ‘biting off more than you can chew’. Symptoms of this over-optimism include projects started without any tolerances set, no change control and without proper reporting structures in place.

The 2nd Part of the article , is a bit more optimisitc, in that starts to tell you what you can do to improve the rates of project success. Broadly speaking , there are two areas suggested for this:

For more details , here are links to part 1 and part 2 of the article.
http://www.itarchitect.co.uk/articles/display.asp?id=203
http://www.itarchitect.co.uk/articles/display.asp?id=224

When SAP announced that they were migrating their solution to a full J2EE server stack, I was initially sceptical. While it makes good business sense (after all Enterprise Java server’s are now effectively free), and complemented their decision to open source the SAP DB (now known as Max DB), there was still a niggling feeling at the back of my mind.

Why? Well over the years we’ve learnt a lot of lessons of how to build Scalable Java applications. Even then, some people can’t seem to get it right (No names , but you know who you are). How would SAP people (who I have a lot of respect for as you don’t get to the position SAP is within the industry without getting at least something right) react to this strange new Java world. Would they shed all past baggage and dive in with the enthusiasm of College Graduates? Or would they take a ‘not invented here’ attitude and hack together something in Java along the lines of what they were used to