News: Cape Clear: You don't need an appserver to build web services

  1. In a recent interview, Cape Clear CEO Annrai O'Toole criticizes appserver vendors for convincing people you need fancy orchestration and transaction mangement services (of an appplication server) to build service oriented architectures/web services. He also claims that javascript is all you need to maintaining workflow and transactional integrity.

    Read Could application servers be overkill?.

    Threaded Messages (27)

  2. Doesn't apply[ Go to top ]

    Annrai's comments apply to companies who are very small and will not need to consider a robust architecture.
    Cape Clear is a product for the little guy. The Big Boys in the Fortune 1000 are not going to buy this product.
    Cape Clear likes the idea of a small, unscalable app server that can handle the buzzword "Web Services". This is because Cape Clear is an offshoot of IONA and realizes that they better not make the same mistake that IONA did, dumping their equity into a market that had no room for it.
    So it's understandable why Annrai is saying the things he is, but it doesn't fly unless your business is making less than $1 Million/year and you don't care about scalability, transaction management, etc
  3. Doesn't apply[ Go to top ]

    Well... I think people that already have App Servers will use their chosen App Server to deliver Web Services.

    But there's no need to buy an App Server simply to run Web Services. This enterprise stuff has been handled for a LONG time *without* J2EE app servers (hell, still more web sites use Apache and Perl scripts with CGI than use Java Servlets -- BY A LONG SHOT, not to mention it's still below 20% of J2EE implementations that use EJBs), so having a way for J2EE to call into back ends (C++, Java, anything else non-EJB) makes sense for these people... there's no need to fork over $3M to BEA to Web Service enable your existing infrastructure. It's highly likely all the scalability/fault tolerance/load balancing existed long before J2EE was even conceieved (heck, it may well be Web Services to a proxy for a mainframe).
  4. Completely flawed[ Go to top ]

    So what happens when I turn Javascript off, perhaps without any malicious intent? Even when you have a full-featured, controlled client, perhaps a Swing client, you're still leaving a lot to chance if you base your approach on client-side validation and controls. Change this to an environment where your foundational assumption can be disabled with the click of a button, and you're asking for trouble. I certainly hope they're not pushing this approach for anyone developing an app for anything other than in-house use. It's like saying you don't need traffic lights in a small to mid-size cities because everyone already has brake lights and turn signals on their cars.
  5. to supply a city with electricity.

    In a sense, you do. How else will the linesman safely drive to your house to install a meter? Just because a browser has javascript doesn't mean anything using javascript has to run in your browser. I can imagine your thought process when you buy a book from Amazon.com now...

    Amazon loads their inventory database into your pc, then selects the item and sends an order their warehouse. Then their web service connector to the credit card processor loads on your pc. It's a little slower because it then has to fetch the banking transactional database. If only you could crack that mod 10 script you see when you click 'view source', you know you could have access to all the electronic transfers happening simultaneously. Not that you would, I'm not accusing you of dishonesty. The picture gets a little fuzzy imagining how, when the warehouse ships your big fat J2EE book, the fulfillment software is transferred by email to notify you of your order (My email client, at least, doesn't run scripts by default), but then it clears up again when its back to web services to track deliver via FedEx. Then you wake up and realize, wait a minute, all web services don't use javascript, that would be silly...

    But just out of curiosity you fire up the computer, type in: Amazon.com, and on the billing page, click 'view source'. There, on the screen, is that ominous mod 10 formula from your dream. Thank God for one click shopping, you never see it again.
  6. I think in a lot of cases, this statement (you don't need an app server to build Web services) is very true. If you Web service-enable existing applications that are not J2EE based, using an application server, e.g. with session beans on top of JCA, is likely to be complete overkill. And overly expensive, as well.

    There other products out there, BTW, e.g. Systinet WASP and TME Glue, that allow you to build Java and (in the case of WASP) C++ based Web services without an app server and are a lot more advanced than what the J2EE vendors have to offer.

  7. <O'Toole>
    O'Toole claimed that complicated protocols like the Business Process Execution Language for Web services (BPEL4WS) or the Web services Choreography Interface (WSCI) are extra baggage and that any functionality that those specifications are designed to handle is easily covered by something found in virtually every system: JavaScript

    Consider the concept of congruence, i.e. finding an appropriate abstraction for implementing logic for a given problem. Example: presentation logic for Web apps enjoys the effective use of JSP for its implementation. Now, what would be an appropriate abstraction for implementing orchestration logic? BPEL4WS or JavaScript? The latter may possess a simpler syntax, but can it effectively capture and model the flow in real-world applications when compared with BPEL4WS?

  8. BPM (Business Process Modelling) technology and products have been around for a long time, but still not every developer on every project is using them - even in circumstances where they arguable could / should.

    Why is that, do you think?

    Personally, I believe it is largely because most BPM products are just too hard to use, and require a totally process-centric view of the world with a single controller (the BPM engine) which is rather foreign to many developers.
    Better tools may partly address the former over time, but we have been promised that since BPM products were released, haven't we? Using scripting language like JavaScript or Perl is likely to be another way.

    An interesting analogy is why don't all programmers use flowchart diagrams when writing code? This flowchart vs code-hacking comparison is exactly the same question in my mind as the graphical process definition vs procedural / action-oriented scripting approach using Perl or JavaScript or VB or whatever.

    Will everyone write "process control statements" in JavaScript?
    No, of course not!
    But there are definetly some people who will, just as there are people writing apps in Perl, VB, Python as well as good old Java right now. Freedom to choose your implementation language of choice is just as important, and BPEL could easily be described as a "process-oriented programming language" (as well as its many other facets too, of course).

    The real question then is how do process composition and control functionality become more appealing, accessible and usable to the 95% of developers in the world who are not "enterprise developers".
    By definition, readers of TSS are in the other group who won't need "simpler development approaches", but that doesn't reduce the need for someone doing something for the other 95% of the world!
    To quote the famous Perl motto - TMTOWTDI - "There's more than one way to do it".

    - Jorgen

    Disclosure: I work for Cape Clear, so naturally share many of Annrai O'Toole's views.
  9. Fallacy[ Go to top ]


       Just because something is difficult to use, that is no excuse to ask for people to willings downgrade their abilities.
       There used to be a time in the IT industry where whatever a company needed, it would buy a product that solved that need --- without consideration of integration or flexibility. The last 5 years have shown us that this approach was wrong, hence the ability of the big companies like IBM, HP, ORACLE, and MicroSoft to become a fixed part of a business's landscape.
       The big companies got to be in that position because they offered Enterprise Solutions.
       CapeClear's solution is so narrowly focused and impractical that I can't see any CIO worth his salt buying this product.
       CapeClear should "reinvent" itself once again and try to become a product that works with the big boys instead of waving a white flag and shouting conspiracy theories.
       We're not stupid, and the more that I hear people defend CapeClear's stance, the more offending it gets.
  10. Fallacy[ Go to top ]


    >The last 5 years have shown us that this approach was wrong, hence the ability of the big companies like IBM, HP, ORACLE, and MicroSoft to become a fixed part of a business's landscape.

    So in your opinion software became in the last five years a comodity?
    As a matter of fact I'd really like to see some opinions about "comoditization" of software.
  11. <Jorgen>
    BPM (Business Process Modelling) technology and products have been around for a long time, but still not every developer on every project is using them - even in circumstances where they arguable could / should.

    BPM tools have been indeed too difficult to use and commanded their own application model (i.e. everything is a process). The emerging BPEL4WS standard may be changing the basic dynamics - authoring orchestration logic using a universally accepted specification which can fit into mainstream application development.

    Can JavaScript match the effective level of abstraction achieved by BPEL? Is it better to let a (J2EE-based) BPEL container provide the infrastructure facilities for orchestration (allowing developers to focus on authoring orchestration logic) or let JavaScript developers do that in custom code?

  12. Duh. I just don't buy this talk about "everything have to be a web service", it doesn't make sense at all. Web Services are just about integrating systems of different technologies: Java, .Net, C, Perl. Of course you don't need a full app server to do this, because you have to do it in mainframes running cobol, or web servers running CGI scripts, no app servers available.

    But, JavaScript? Javascript is intended to validate user input before it going to the server, saving time, but the validation is made again in the server, because it is too much a security risk to trust an Internet client. Or use it to make some little visual tricks, or something like that. Coding an entire application in Javascript is just plain stupid.
  13. Yes, it's not good[ Go to top ]

    Yes, this is just another example of a desperate company trying to "reinvent" itself.

    CapeClear understands that they cannot engineer a good app server. They also see that there is not point doing so even if they could. So they are trying to sell what they have as this "revolutionary" idea that app servers, after all, are not even necessary!

    Hey what a coincedence!! CapeClear doesn't have an app server to compete with Weblogic and WebSphere, but guess what? Annrai says we don't even need one! Perfect! Now they can make money!

    This is the first time that I've ever seen a company trying to move back the clock in order to justify their product. That's like Ford and GM trying to sell everybody a horse and buggy instead of car because the CEO of the company says that we don't really need cars after all.

    It's just plain silliness. CapeClear should do itself a favor and try to get hired back by IONA. Maybe they could work it out so that they could work in one of the many IT divisions there, in a REAL solutions company.
  14. not good at all[ Go to top ]

    But Magee's biggest criticism of Cape Clear concerned the cost issue. With Cape Clear's cost of $10,000 per CPU

    Why not get Tomcat and SUN JWSDK/Apache AXIS for free, instead of buying
    JavaScript for 10k. C'mon we can get WEBLogic with full set of options for that price ! I dont think that Cape Clear has more to offer than WL.

    BTW I looked at WL 8.1, It's noticable faster than 7.1.

  15. Clueless!!!!![ Go to top ]

    asked O'Toole if he expected Cape Clear's customers to proceed blindly with developing Web services that are devoid of any notion of orchestration or transactional state. O'Toole claimed that complicated protocols like the Business Process Execution Language for Web services (BPEL4WS) or the Web services Choreography Interface (WSCI) are extra baggage and that any functionality that those specifications are designed to handle is easily covered by something found in virtually every system: JavaScript (also known as ECMAScript).

    Excuse me the arrogance but this guy is completely clueless! What does he think: that we are completely stupid therefore we can buy his statement regarding converting BPEL in Javascript because his product only support Javascript?!!? BPEL is about flow coordination, asynchronous message exchange and in some advanced use case, compensationg business transactions.

    Annrai! Could you please enlighten us on how you would implement a purchase order flow in Javascript! If not, please stop considering developers as idiots!

  16. Yah it's insulting[ Go to top ]

    We're all insulted... why, all this time we've been agonizing over the complexity of enterprise computing, and all we had to do was use JavaScript!

    Annrai, you moron.
  17. appservers overkill?[ Go to top ]

    Isn't most software overkill? I mean, to please 90% of the people who each want something slightly different, don't you have to do 10x as much as the average bear is actually looking for? Let me go looking through my Windows "Start" menu and count how many items I actually use. Hmm. Not many. Is Windows overkill? Hardly.

    Most projects will use app servers for the purpose of standardization. If a company has 5000 developers, they certainly don't want to have 5000 different ways of building applications and putting them into production. It's bad enough to have 50 different ways. So what if 90% of the app server isn't getting used? The app server is typically free (Tomcat, JBoss, Jonas, Jetty, Jumping Jehosophat) or relativley inexpensive (where "relatively" has a different meaning in a large organization, since most of their IT costs are those 5000 developers at $100k each.)

    So unless that "big" app server somehow makes it harder or significantly more expensive to build and deploy and manage web services (which is what these guys should be pushing, if they can show a better way), then I don't see how this appeals to the general use case for web services.


    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  18. appservers overkill?[ Go to top ]

    Couldnt agree more.
  19. appservers overkill?[ Go to top ]

    Annrai, your solution is already dead :-)
  20. appservers overkill?[ Go to top ]

    I believe it's very important that Web services is not so much about building new applications, but rather about opening up existing ones for new uses. And to use a full-fledged application server for a simple integration task is just overkill - similar to using WebSphere for just serving JSPs. Which of course lots of companies do, anyway ;-)

  21. appservers overkill?[ Go to top ]

    I don't entirely see this. Say I have a java class or EJB(or whatever) that I simply want to add a service layer into for integration reaons. Throw AXIS/GLUE, whaterver on top and Voila! If you're already running something like a Servlet app, then dropping a web-service into the app-server and "wrapping" existing business logic into a web service isn't overkill or underkill. It is pretty easy thoguh.

    For my current project we're integrating a number of different systems around the country, and SOAP/XML-RPC/web services makes sense. However, we have to have robustness because the data is critical: load-balance, failover, distributed-cache with optimistic locking to the DB. App-servers provide a great deal of that functionality. Someone please explain how I might do that with JavaScript. I know those aren't web-services "functions," but they are an important part of the requirements for our overall web-services architecture and functionality. I don't think I'd use JavaScript for that.

    I guess it really drills down to what your trying to do, what your requirements are, and how you're going to do it. In my case, we probably need to app-server for "requirements" reasons. In many cases maybe not. The JavaScript thing seems odd to me though.

    Does anyone know how the JS stuff works in Cape Clear?

    By the way, from the article, it looks like Cape Clear runs on Jetty, which is an app-server (I know there are plenty out there who don't think a servlet engine is an app-server, but let's not split hairs here...).

    Jason McKerr
    Northwest Alliance for Computational Science and Engineering
  22. JavaScript[ Go to top ]

    I think Annrai's next public presentation will be about bringing back the Commodore 64, because we don't really need our workstations, do we?
  23. Retro[ Go to top ]

    I think Annrai's next public presentation will be

    > about bringing back the Commodore 64, because we don't
    > really need our workstations, do we?

    Nah, I suspect Annrai is more an Atari man! ;-)

    An interestring thought though is that "retro" Atari games are making a big comeback on both PCs and cellphones - without replacing either.
    Simple (sometimes boring) technology being applied through new channels to reach a previously un-reached audience.
  24. What a wicked person. I he going to take away from them the "big App Server" - their whole reason to live? – the reason they can look people straight in the eye? - doesn't he have a heart in his body?

    "the longing, the yearning for the lost and unattainable"

    Rolf Tollerud
  25. Pauvre Rolf[ Go to top ]


        I know you are missing your soap operas because it's Sunday, but you must try to keep in mind that not everybody waxes so eloquently as you.
        I should have known that you would support such a product as this. Anything to wreck J2EE is good for you --- oh Rolf, you're so obvious! At least throw a bit of grandeur or pure evil into your assessments. You're starting to sound French, always complaining over anything and making people angry.
  26. Pauvre Rolf[ Go to top ]

    You're starting to sound French

    That was under the belt, really.
  27. No[ Go to top ]

    All's fair in love and war.
  28. And BTW xDocs - aka InfoPath - is not limited to Office Documents!


    Rolf Tollerud