Discussions

News: Opinion: Preparing for a Career in Web Services

  1. Computerworld hosts an article that discusses the need for us J2EE guys to be learning Web Services too. They talk to various IT managers (and monster.com) about what they are looking for: "Five years from now, it's definitely something that developers will want on their resume."

    They claim that knowing Web Services is a good move for a developers career, but you are much better off knowing the building blocks of J2EE.

    "Many Web services components will be legacy applications wrapped in Web services interfaces. Programmers still need a firm grounding in established programming languages like C++, Cobol, Visual Basic and widely used business applications like Oracle Forms and IBM's CICS."

    Do we get a higher salary if we know Web Services?

    The European market, says Grutter, won't necessarily pay bonuses to applicants who list Web services project experience on their resumes, because unemployment has brought down salaries about 10% overall.

    But in the U.S., Falk places a 10% premium on hires with Web services experience. However, he says he wouldn't offer any more than that because he places more weight on developers' core application programming skills than on knowledge of Web services.

    Read the article: Preparing for a Career in Web Services

    Do you agree with this form of Web Services hype? Are you seeing more $$$ for those skills, or more jobs that require them?

    Threaded Messages (37)

  2. I was on a web services project for the past 18 months, and I just went through a round of interviews, and my experience has been that most "IT managers" don't really know what web services actually are. Developers' reactions range from "web services, sure, okay, I guess they're neat" to "they're stupid". But among managers, it seems that "web services" is a buzzword that you better be using. At my last project, I had this hunch that managers used the term as a way to impress one another. Plus, most of them thought that using a web service involved using Internet Explorer. And there was the theory that web services would be replacing web portals (I kid you not, this idea was even presented as fact to the customer). So I'm not sure which magazines the managers are reading to get their "knowledge" about web services, but my experience has made me a bit suspicious when I hear a manager say they want to use web services on their next project.

    Rob
  3. Except that this article is sillier than normal.

    By the end of it, I seem to need:

    -SOAP
    -XML
    - C++
    - Java
    - C#
    - VB.NET, VB
    -CICS
    -J2EE
    -Oracle Forms
    -Cobol

    Oh yeah, and Webservices too ...

    Seems like the author threw in everything she'd heard of as skills to have in 5 years time. 5 years is a long time in this business ... another useless jobs article.
  4. By the end of it, I seem to need:

    >
    > -SOAP
    > -XML
    > - C++
    > - Java
    > - C#
    > - VB.NET, VB
    > -CICS
    > -J2EE
    > -Oracle Forms
    > -Cobol

    No. The benefit of webservice is you only need to learn Swing client and Axis server. Little else. The list you mention isn't webservice, but rather EAI. Different game.
  5. Yawn, more skills I need in 2008[ Go to top ]

    Why do I need web services between Swing client and axis server? Can't I use RMI or JNDI/EJB since they are both built on the Java platform? Or did you mean making Swing client talk to .NET server (a rarity), or VBA client talk to J2EE server (very common)?
  6. <eric>
    Why do I need web services between Swing client and axis server? Can't I use RMI or JNDI/EJB since they are both built on the Java platform?
    </eric>

    Nice point, Eric. Using web services for communication between different tiers within enterprise is a definite overkill. Web services carry unnecessary plumbing and performance overhead that is generally unacceptable for communication between application internals. The intent is to use web services whenever interoperability between enterprise endpoints is required and performance is generally not a factor, for example a bank sending credit inquiry to a loan agency before approving a loan (in this case a user would not mind waiting additional 20-30 seconds).

    <eric>
    Or did you mean making Swing client talk to .NET server (a rarity), or VBA client talk to J2EE server (very common)?
    </eric>

    I don’t think a VB client talking to J2EE/Java server is such a rarity. I believe it's a very well justified choice for many projects using thick clients. For instance, it is often known in advance that end users will only use windows desktops, and since VB or C# clients generally offer better performance on windows and natural windows look-n-feel, using .NET for thick client in this scenario is a better option than Swing. However, due to performance overhead, web services would provide little value in this case. Interoperability difficulties of this sort are better solved using more efficient protocols and services that can comfortably coexist within both runtimes. For example, in our product xNova™, metadata service allows to efficiently pass objects between Java and .NET (about 40-50 times faster than native serialization routines), and caching service allows effective distributed caching of objects within any number of Java and/or .NET nodes in the cluster.

    Hope this helps,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Architecture for Java and .NET
  7. <Dimitriy>
    I don’t think a VB client talking to J2EE/Java server is such a rarity.
    </Dimitriy>

    You mis-read my post. I said VBA calling J2EE server is very common, and precisely because of the scenarios you laid out in your response.

    As for using a binary protocol to bridge Java and the MSFT worlds vs. using XML-based web services, I can only say that Java/COM bridge was popular 2 to 3 years ago, but one hears less and less about it today because of web services is has become a much more compelling and standard-based alternative.
  8. By the end of it, I seem to need:

    > >
    > > -SOAP
    > > -XML
    > > - C++
    > > - Java
    > > - C#
    > > - VB.NET, VB
    > > -CICS
    > > -J2EE
    > > -Oracle Forms
    > > -Cobol
    >
    > No. The benefit of webservice is you only need to learn Swing client and
    > Axis server. Little else. The list you mention isn't webservice, but rather > EAI. Different game.

    I'm quoting the skills what the rather lightweight article says will be needed in 5 years. And IMO EAI and Webservices are rather closely related. If we aren't integrating different applications, using Webservices is pretty pointless - just overkill as another poster pointed out.

    The times I've used SOAP (two projects so far) have been to communciate with external systems not under my developmental control.

    bruce
    -----
    Free Java/C# FTP client library
    http://www.enterprisedt.com/downloads.html
  9. WebServices the basic skillset[ Go to top ]

    I guess web services are going to stay for long time, there are number of reason we should go for this thing.

    1. Web will be there and hence distributed components are accessible.
    2. EJB is going to rule the world, and few legacy systems (mainframe, old vax/vms, Cobol apps, old vb, vc++ apps, and by that time existing .NET applications) will need some sort of connectivity with EJB components.

    3. The way we thought CORBA will pickup has not happened, and the other good option is web services with some reduced functionality.

    I guess all guys who are in EJB should start roping in web services skills, may be for initial 2 year you might demand more salaries but later its going to be a mandatory requirement.

    Regards
    Chetan
  10. WebServices the basic skillset[ Go to top ]

    "The way we thought CORBA will pickup has not happened..."

    Too hard to tunnel IIOP over port 80. Some firewalls don't allow HTTP streaming, a common ORB trick. WSDL get through strictest firewalls where leading ORBs choke. WSDL has greater reach than CORBA.
  11. WebServices the basic skillset[ Go to top ]

    "The way we thought CORBA will pickup has not happened..."

    >
    > Too hard to tunnel IIOP over port 80. Some firewalls don't allow HTTP streaming, a common ORB trick. WSDL get through strictest firewalls where leading ORBs choke. WSDL has greater reach than CORBA.

    Again, define an XML based version of IIOP. Expand the definition of the IOR so that you can do:

    CORBA::Object obj = CORBA::StringToObject("http://www.jboss.org/myorb/myobj");
  12. Web services is not a silver bullet, but the technology does solve a lot of nasty problems associated with EAI and B2B systems with regard to interoperability.

    The negative reaction that you see some developers having toward Web services is just natural. When Java came out I spent most of my day trying to convince people that Java was in fact a viable platform for production development (1995 - 1996). The same is true of Servlets, EJB, and J2EE.

    The truth is Web services is very important for a particular set of problems. If I have a homogenous systems than I don't see a point in using it, but how often does that happen? I've rarely worked on a system that uses a single operation system and application framework. It's fairly simple to implement SOAP/WSDL based Web services compared to CORBA. The performance is not as good as some protocols, but the interoperability you get with Web services - especially when the WS-I Basic Profile is finalized - outweighs the performance penalties. EAI and B2B is less about performance than it is about interoperability.

    Admittedly I'm biased, but I believe it's a good idea for developers to learn as much as they can about Web services. In a year from now I believe the market for these skills will be at a premium.

    Richard Monson-Haefel
    Author of J2EE Web Services (Addison-Wesley 2003)
    Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2002)
    Co-author of Java Message Service (O'Reilly 2000)
    http://www.monson-haefel.com
  13. I Agree with Richard, Web services are here to solve problems in specific areas. But it's a good technology to solve the problem, which otherwise gets really complicated.

    Still emerging, the knowledge/experience of webservices going forward would be a top cut
  14. I am not sure I really agree. It is not Web Services that solve this problem - it is SOAP. This is some standard that tends to create a lot of problems that it is supposed to solve. It has a very complex (whilst extremely flexible) binding model that is even more complicated than plain old Corba. The "standard" still lacks viable, cross device, common functionality, like security, session handling and the like. Even if the standard caters for it, hooking say a MIDP phone on a secure web service is far from trivial. The same goes for transfering custom data structures - not a problem of the standard but of the tools, of course. Just take the Java WSDK - a toolkit that does not even provide a mechanism for the implementation of custom serializers.

    At the same time I agree that Webservice are a great tool for integration. But given the amount of information hiding and little kingdoms that you find in large corporations, I also wonder whether this is really something that is going to happen.
  15. I have been working on a couple a J2EE-based projects for the financial services sector. The real pain in the neck has always been the integration issues with "legacy" components such as portfolio management systems hosted on an AS400 and written in cobol... or connectivity to real-time datafeeds, etc... Actualy, from my own experience, a relatively big part of the costs of a J2EE project as well as critical issues such as performance and scalability are due to integration with legacy systems. The "pure J2EE" part of the project progresses rather smoothly throughout the development phases. Using SOAP/Web Services for systems integration is actualy quite easy and provides an enormous amount of flexibility. I have taken that path on a couple of projects and the overall system performance is quite acceptable (ie, the system is not less scalable because I am using SOAP for integration). Also, the development tools are becoming quite mature, so basically you don't need to "learn" web services as such (is anyone still dealing with SOAP messages or WSDL directly?). A tool such as WebLogic Workshop is already pretty cool and you can do amazing things with it. Perhaps the "hard" part about web services will be about how to use the concept correctly. I guess that over time some "Web Services Patterns" will emerge and provide best practices.
    Finally there is still one point I am not still very clear about using Web services for EAI is the advantages/disadvantages over MOMs and technologies such as JMS, which are also a very elegant and scalable solution to EAI.

    cheers,
    anwar
  16. I have been working on a couple a J2EE-based projects for the financial services sector. The real pain in the neck has always been the integration issues with "legacy" components such as portfolio management systems hosted on an AS400 and written in cobol... or connectivity to real-time datafeeds, etc... Actualy, from my own experience, a relatively big part of the costs of a J2EE project as well as critical issues such as performance and scalability are due to integration with legacy systems. The "pure J2EE" part of the project progresses rather smoothly throughout the development phases. Using SOAP/Web Services for systems integration is actualy quite easy and provides an enormous amount of flexibility. I have taken that path on a couple of projects and the overall system performance is quite acceptable (ie, the system is not less scalable because I am using SOAP for integration). Also, the development tools are becoming quite mature, so basically you don't need to "learn" web services as such (is anyone still dealing with SOAP messages or WSDL directly?). A tool such as WebLogic Workshop is already pretty cool and you can do amazing things with it. Perhaps the "hard" part about web services will be about how to use the concept correctly. I guess that over time some "Web Services Patterns" will emerge and provide best practices.



    This great to see an actual usecase of Web Services. Being an ex-CORBA guy, I'm wondering why CORBA has failed so miserably? I mean, why not just write an XML format for IIOP, then be done with it? CORBA has already visited and solved all the inter-language, inter-platform issues such as transaction and security propagation. So far I see Web Services as nothing more than CORBA Reloaded. IIOP ~ SOAP, WSDL ~ IDL, UDDI ~ Naming, transformations can be done using Portable Interceptors. Anwar, you said it best yourself: "so basically you don't need to 'learn' web services...." Its really nothing revolutionary like CORBA and J2EE were as standards. This is why the article says "Five years from now, it's definitely something that developers will want on their resume." All hype, nothing new.

    You want a real skill on your resume? Try looking into Aspect Oriented Programming. AOP is positioned to have as powerful an impact on software development as OOP did 10-15 years ago. Distributed frameworks written on top of AOP will finally achieve a clean separation of system architect and business programmer that DCE, CORBA, J2EE, and Web Services have been working towards over the past 10 years. This clean separation will finally allow the business developer to think about solving business problems instead of worrying about learning complex API's, definition languages, transport protocol DTD's or XML Schemas, or paying thousands of dollars for a buggy tool with limited functionality. Tools just hide the true problem: The architecture needs to change. We need to rethink how systems are built before things get simpler and the industry can move forward. AOP is the path.

    Regards,

    Bill Burke
    Chief Architect
    JBossGroup, LLC.
  17. I'll agree with you on part of the AOP argument. If you want to be an uber-developer, AOP is the path. But if AOP can create a container where I can program POJOs and add some XML to get my services, an end-user of that container doesn't necessarily need to be able to do AOP themselves.

    It seems much more likely that there will be tons more developers using AOP-centric containers with no knowledge of AOP needing some amount of web services. Maybe the question I'm curious about is how is AOP going to affect the typical application developer who doesn't have an understanding of system-level/container-level internals?

    Steve
  18. I'll agree with you on part of the AOP argument. If you want to be an uber-developer, AOP is the path. But if AOP can create a container where I can program POJOs and add some XML to get my services, an end-user of that container doesn't necessarily need to be able to do AOP themselves.

    >

    If you want to earn more money, AOP is the path. I really see AOP providng the ability to have a clean separation between the system-level architect and the typical application programmer. As a software engineer, these roles are currently very blurred because the developer must understand some of these container-level constructs to write a line of code.

    > It seems much more likely that there will be tons more developers using AOP-centric containers with no knowledge of AOP needing some amount of web services. Maybe the question I'm curious about is how is AOP going to affect the typical application developer who doesn't have an understanding of system-level/container-level internals?
    >

    How will AOP affect the typical application developer? They won't have to know about system-level/container-level internals or constructs. They won't even need an ultra expensive GUI tool to mask the complexity of J2EE.

    Again, I reiterate. Tools are not the answer. We need to fundamentally change how software is developed and designed before the complexity of developing these applications goes down. Microsoft has partially figured this out with their attribute-based programming in C#. JSR 175 is addressing this in Java in the future, XDoclet and similar technologies are addressing this now. Attribute-based programming is not enough though. We need the rest of AOP.

    Bill
  19. Again, I reiterate. Tools are not the answer. We need to fundamentally change how software is developed and designed before the complexity of developing these applications goes down.

    Technologies like AOP help address some areas of complexity in programming, but complexity will persist. Instead of tools masking complexity, they should do a much better job of helping us visualize what we create so that we can achieve simpler, more coherent designs. They must also keep relevant information at our fingertips that has been culled from the collective experience of ourselves and others. Unfortunately, there isn't a single tool out there that even comes close to achieving this (especially at the design level), and I am convinced that most of the leaders in our space are heading in the wrong direction.

    AOP is a nice breath of fresh air, and I hope it continues to gain in popularity. I personally hope to see pattern-driven tools and technologies that instead of masking complexity, unmask it and help us achieve better results. We shouldn't discard the usefulness of tools when applied properly, because even technologies like AOP will benefit greatly from their assistance.

    Best regards,
    Bill Willis
    Director of PatternsCentral
    "Where Patterns and People Meet"
  20. And what *is* AOP?[ Go to top ]

    We need to rethink how systems are built before things get simpler and the

    > industry can move forward. AOP is the path.

    I think this is a bit of a weird statement. There is no definition about what AOP actually is. Sure there are a couple of tools out there, claiming to be "AOP" - most prominently AspectJ - but there is still *no* textbook about AOP, only a couple of conference proceedings. These tools usually provide a very complex and powerful interception framework with add on things like aspect scoping etc. I find it pretty strange that a technology that has basically been available for years (or is it decades) in languages like clisp or even c++ is supposed to be the next cool thing in programming. Given that AspectJ for example adds about 30 Keywords and three main artefact (aspect, join point and pointcut) to Java it can probably be considered the next big thing in *complexity*.

    That said, it can be utilized to create extremely powerful plumbing frameworks. Yet it is quite easy to show that AOP often fails miserably if the aspect developer doesn't know the internal structure of the advised code (changes in internals of advised methods break aspects quite easily). This is pretty much the opposite from encapsulation. So the basic question about AOP is not "Is it powerful?" (It is!). The main questions are "What is it?" and "What do you want?".
  21. AOP again[ Go to top ]

    Distributed frameworks written on top of AOP will finally achieve a clean

    > separation of system architect and business programmer that DCE, CORBA,
    > J2EE, and Web Services have been working towards over the past 10 years

    Now, that is some statement. I am always wondering what this separation is going to be any if it is at all feasible. Basically, say with EJBs, you get a lot of this. Sure you need to learn a bit deployment description but with AOP frameworks like AspectWerkz you need to learn Aspect Description instead. Do you gain much? Doubtful. Is the framework itself easier to build and to change. You bet! Is this of any relevance to those using the framework. No! Also, with AOP, technical functionality tends to get merged into the business code _after_ it is written, whereas traditional frameworks are programmed against a given "plumbing" framework. Which one is better - hard to tell, but since the framework part is the *hard* part, even with AOP, I would tend to solve the hard things first, which means to employ a "proven platform". Also, it is a bit naive to think that even then, you can completely decouple "business logic" from "system archicture". The whole way data is persistently stored, the way transaction boundaries are drawn, the decision of when to use optimistic or pessimistic locking, lazy vs. early data loading and storing, access control etc. is at the very heart of business logic. Still of course, AOP is cool and powerful and this should be reason enough to look into it for any programmer. Whether it is good for large organizations, whether it is manageable and what it actually comes down - IMHO - to remains to be seen.
  22. This great to see an actual usecase of Web Services. Being an ex-CORBA guy, I'm wondering why CORBA has failed so miserably?


    Because Microsoft didn't market it maybe? That's the difference between CORBA and WebServices: marketing.
  23. Because Microsoft didn't market it maybe? That's the difference between CORBA and WebServices: marketing.<

    In CORBA, IDL/IIOP. in Web Service, XML/HTTP. which way you wanna go? I guess the answer is obvious.
  24. Because Microsoft didn't market it maybe? That's the difference between CORBA and WebServices: marketing.

    Uh, no. It's because CORBA has a slow community. CORBA's firewall standard was proposed in 1997 but not finalized until 2003. Why 6 years to figure out how to tunnel?! Still no mention of port 80 in the firewall spec. Little ORB vendor support for sharing port 80 modularly from within a web server. HTTP pluggability comes standard on WSDL engines.

    Then there's the message matters of queing and pipelining. When document oriented, SOAP is easily stored, queued, cached, broadcast, syndicated, visually inspected, programaticly inspected, transformed by stylesheet, etc. CORBA ain't any of this. Eg, a web brower can produce a meaningful display given nothing more than a SOAP message and a stylesheet. Also, CORBA is RPC oriented. SOAP can be either RPC or document oriented. CORBA predates the Web.
  25. "Finally there is still one point I am not still very clear about using Web services for EAI is the advantages/disadvantages over MOMs and technologies such as JMS, which are also a very elegant and scalable solution to EAI."

    Exactly. MOM or JMS for EAI. WSDL for B2B.
  26. |
    |"Finally there is still one point I am not still very clear about using Web
    |services for EAI is the advantages/disadvantages over MOMs and technologies such
    |as JMS, which are also a very elegant and scalable solution to EAI."
    |
    |Exactly. MOM or JMS for EAI. WSDL for B2B.
    |

    Not sure I understand the distinction.

    There is no reason why you cannot use Soap, etc over JMS. (?)

    -Nick
  27. |

    > |"Finally there is still one point I am not still very clear about using Web
    > |services for EAI is the advantages/disadvantages over MOMs and technologies such
    > |as JMS, which are also a very elegant and scalable solution to EAI."
    > |
    > |Exactly. MOM or JMS for EAI. WSDL for B2B.
    > |
    >
    > Not sure I understand the distinction.
    >
    > There is no reason why you cannot use Soap, etc over JMS. (?)
    >
    > -Nick

    Hello Nick,

    I think it is more a question of architectural design. There are some things such as asynchronous processing and notification that are easily done using a technology such as JMS (which is actualy ment for that!). I am not saying you can't do it with SOAP/Web services, the solution is simply elegant with JMS (ie requires less coding :)). The big advantage of asynchronous processing is the ability to build very loosely-coupled systems. So for example let's say you would like to update a client account on a mainframe system from a Session Bean, all you would need to do is publish the "update account" message from the bean and then basically forget about what else is happening. The mainframe-side would then do all of the required processing (lets say the whole process takes a few seconds). Once the process is finished, another message could be published from the mainframe-side and "intercepted" by an MDB in the J2EE business tier providing information such as the success or failure of the operation, etc... In such a way, your overall architecture would be much more responsive.

    Regards,
    Anwar.
  28. Hi,

    Web services are about a service-oriented view to computing. The exact protocol used for communication (usually SOAP) is of less importance.

    The problem is that of integrating applications built using widely differing technologies - java stuff (EJBs and the like), MOM, older backend stuff (CICS etc.) and so on. Viewing them as services that advertise their functionality in a normalised fashion, using WSDL, enables integration. WSIF (http://wws.apache.org/wsif) is an Apache project that offers software supporting this approach.

    The arguments against web services (poor performance, unsuitability for EAI etc.) mostly relate to SOAP. The fact is that WSDL's extensibility allows for alternative protocols, making it a great hub for all kinds of integration.

    Nirmal.
  29. The fact is that WSDL's extensibility allows for alternative protocols, making it a great hub for all kinds of integration.

    Can WSDL describe a JXTA web service?
  30. Hi,

    WSDL bindings are extensible - basically a binding is a bucket that says "put your protocol-specific vocabulary in here" and you can put in any XML you like that describes how the abstract service description (port types, messages and so on) are mapped to your specific protocol.

    So you can define a JXTA binding that maps WSDL messages, operations and so on to whatever JXTA uses to communicate information and use the functionality supported by some endpoint. You could also wrap your JXTA with SOAP and offer a SOAP binding so thet clients who don't know JXTA or can't use that protocol (maybe it is only for internal apps) can use SOAP.

    Nirmal.
  31. I would second Richard’s comment. It is especially important to understand the area of applicability for WS to really understand their value. By design, WS are specifically tailored to EAI or B2B type of enterprise systems, the areas where (as Richard mentioned) performance is less critical than overall interoperability.

    Way too often I come across the “silver bullet” discussions on WS that brings more confusion than clarity to those who starting up in WS area...

    Thanks,
    Nikita.
    Fitech Labs, Inc.
  32. Absolutely, and j2ee needs to do more on web service arena; though AXIS and GLUE are good, but we need a coherent set of libraries and tools to do the job.

    every public/beta uddi that i know is being dominated by .Net, ex: xmethods.net (uddi provided by mindelectric the-GLUE-guys). since '99 we are doing our document oriented web services in java, and it is a pain. that's why when AXIS came by, we are happy! but when vs.net came by, we are stunned how easy it is to create and deploy web services.
  33. Way out yonder[ Go to top ]

    "Life Time Fitness Inc., a health and nutrition services company in Eden Prairie, Minn." doesn't exactly sound like the vortex of the Information Age.
  34. Aren't they trivial?[ Go to top ]

    Well, I know that 2-3 years ago web services were the "big new thing", tools were still new and clunky. But, with todays tools I'd say that putting together a couple of services is matter of days, if you start from scratch. So, what's the big deal?
  35. Aren't they trivial?[ Go to top ]

    Totally agree.

    The 'standards' seem to be in perprtual limbo. whilst rolling your own solutions is fairly quick and easy.

    Personally I'm very wary of a standard that is jointly patented my MS & IBM. If something like this is to become common place then I think their patents should be reliquished to the W3C.

    my 2.5 cents,
    -m
  36. A very important point is raised toward the end of the article, but I think it should have been presented in 24-point font at the top:

    But in the U.S., Falk places a 10% premium on hires with Web services experience. However, he says he wouldn't offer any more than that because he places more weight on developers' core application programming skills than on knowledge of Web services.

    The problem is that most companies are more interested in buzz words than a developer's core skills. The plain fact of the matter is that there are very few "classically" trained (those who are schooled or self-learned in the fundamentals of computer science) software developers out there.

    Here is my advice for those developers out there who are wondering whether or not they need to know about this Web services stuff:

    If you don't know at least the basics of computer science and object-oriented programming languages like Java (please, no religious responses), get that knowledge as soon as possible. Dabble in Web services if you must to get it on your resume, but don't waste any more time on it until you get the fundamentals under your belt. Those fundamentals will serve you much better and will help you digest new technologies and trends more quickly.

    Here is my advice to those companies out there who think they need to hire people well versed in the latest Web services standards:

    Only hire developers with good fundamental skills or those eager to aqcuire them (initiative); otherwise, they will fail you almost immediately. Also understand that Web services standards are still evolving, so proceed very carefully. Having architects and developers with solid fundamental skills will help you adapt to the changes in Web services (and just about every other technology) that will certainly occur in the short term. They will also help you understand if you need Web services in the first place and when they are appropriate. In short (sorry for the long rant), focus on fundamentals and pay those people the premiums - you will look great and may even get promoted to executive VP ;-).

    Regards,
    Bill Willis
    Director of PatternsCentral
    "Where Patterns and People Meet"
  37. I could not agree more.

    There are so many people outside that don't get the basic principles of the OO paradigm (especially those that hava a host background) or that don't know what a transaction monitor is and why you need one.
    I had endless discussions with many clients why they would need an application server in their host integration projects. It's always the same questions.
  38. Hmm... it seems to me that there is enough skills, but not enough jobs.

    As we get more productive in developing sofware, we need less and less people to do the same thing.

    .V