I’m a little surprised - I’ve been banging out blogs at a rate of about one every couple of days or so, but after the blog I posted on January first, I needed to get some traction on the Firefox book, and I needed a bit of a breather. Blogging can get to be a little too intensive at times, eating into everything else that you do, and if you’re not very careful you can get to the point where your every waking moment is geared towards getting those numbers to edge up beyond the last spike … “Uurrggh, must have my reader fix!!”
M. David Peterson just turned me onto a very interesting blogging tool - w.blogger (at http://www.wblogger.com. It’s essentially a reasonably complete word processing tool that’s specifically designed for use with a whole host of blogs. I’m still getting a feel for it, but thus far I’m pretty impressed with the product - a standalone blog editor that doesn’t need to be online to work, that contains a full set of formatting tools, works with a fairly wide number of blogging servers and is open source to boot. We’ll see how well it works over the long term, but out of the gate I could see it being an invaluable addition to my set of tools.
Will AJAX replace enterprise level Java or .NET?
SOA
Web services are not SOA and SOA is not web services. Web services (try and define it) can be used in the implementation of SOA, but they are not necessary. SOA is an extension of component-based architectures. I first implemented them using Tuxedo in the 1990's. Tuxedo, was the first application server. If you look at Tuxedo and any JEE application server, you will see how similar they are.
It is also possible to implement web and other types of services and not be SOA. If you aren't component-based you don't have the flexibility and agility necessary to quickly compose new services from existing and new components. That is fundamental to SOA, because service reflect use cases, not objects. They are designed for efficiency, not for reuse. You don't want fine grained services because you will be making too many calls.
Components are objects (at a higher level) and are, if modeled correctly, inherently reusable. Although any well designed component can be made into a service, they are often too fine grained. Services are facades on one or more components designed to satisfy use cases.
So, enough with this nonsense about SOA being a PC version of web services, they have no direct relationship and SOA predates the web services technologies.
Ajax Projects
Ajax Projects (http://www.ajaxprojects.com) will help you to find all the resource to learn and know allabout Ajax technology, by providing you with the latest Ajax projects (http://www.ajaxprojects.com) ,latest Ajax tutorial, Ajax articles, Ajax Forum and Ajax news.
www.ajaxprojects.com (http://www.ajaxprojects.com)
Biggest Problem with AJAX
Two words: code protection. If my back-end services are essentially just XML data renderers and all of my code is in Javascript on the client, security is much harder to maintain, not to mention the fact that most of my code is visible to anybody who wants to see and/or steal it.
Don't get me wrong - I love AJAX, but unless you are putting your project out as open source you can't truly embrace it.
SOA
I absolutely agree with you - SOA predates web services by a significant amount. The problem has come in that this is a distinction that is not necessarily made by many web services companies that jumped on the SOA bandwagon after the web services bandwagon began to lose steam. By their reasoning,
Web Services = SOAP/WSDL = SOA
However, personally I'm inclined to believe that SOA as a term holds less and less meaning every day - its useful to convey a vague idea, but getting a clear and consistent definition is almost impossible.
SOA
One additional comment - I'm not sure I agree with the statement "if you are not component based - you lack the flexibility and agility necessary to quickly compose new services from existing and new components". What does that do for something like an XForms front end, which is not a component in any formal sense, yet is something that I see as being a very useful tool within the SOA lexicon. What about JIT code bases where not just the data, but the business logic, presentation structure and even underlying application shell are instantiated on an as needed basis which have comparatively little to do with formalized components.
My point here is that we're entering a new realm where many of the terms, such as components, will need to be redefined or new terminology will need to come to the fore. Whether SOA is part of this is hard to say, though I sense that this is the case.
-- Kurt
SOA
XForms - the plug-ins and frameworks do qualify as components and conceptually XForms is a component, but that is beside the point. XForms are part of the Services facade. A service is a facade in front of one or more components. The service facade handles works with the transport and protocol implementations, the message data binding and the delegation of operations to the component(s) methods/functions/procedures.
Components are not some GUI or Microsoftie thing, its more than that. Components in the software sense (not the new UML/MDA conceptual sense) are modules with formal interfaces and contracts more coarse than an API and intended to perform high value services relative to their ease of use. Their implementations are encapsulated and they are composable. Their definitions are (or should be) derived from object models. They are the higher level objects in the architecture and may be implemented with or without an OO language.
In the 1980's it was common for we OO developers to model and even prototype in an OO language, but implement in a 3GL like C for performance reasons. In Windows in the 1990's this was still true because C++ was too slow if you used objects all the way down to the fields.
The following link is a good one: http://cs.ua.edu/components/papers/position.pdf.
The point of SOA is not services by themselves. you can slap services on anything, but that doesn't make it SOA or give you its benefits. What makes it SOA is the component architecture the services are built on. The component architecture makes it easy to compose new services or enhance new ones when and where ever you need them. It gives you a basis for defining services around domains that will insure your services and the components underneath are useful for a long time.
Offline AJAX
You may be interested in an experiment of mine, a wiki with transparent support for disconnected operations: http://blog.monstuff.com/archives/000272.html
Regarding the code protection issue, there are two things to consider: you can obfuscate javascript code and you can de-compile Java bytecode and .Net IL. So the situation isn't that different between javascript, Java and .Net in terms of code security.
YES! of course, sort of....
Java and JSP is a perfect platform to build Ajax applications cheaper and better. For example look at a recent announcement from a startup, which demonstrated reusable Ajax GUI Components for JSP.
http://cbsdf.com/misc_docs/why-gui-api.htm
http://cbsdf.com/misc_docs/gui-api-brief.htm
Using the simple process outlined in the web site any programmer can create better reusable Java GUI Classes for Ajax components. The GUI Classes can be more flexible and easy to integrate, than the Classes in GUI API for Windows/VB. The Java GUI Classes can be used in JSP to generate graphics intensive applications (web sites).
What will stop any one from building the great Ajax applications? The process out lined in the web site is simple even to doubt if it works. Try it out and build your own Reusable Ajax Widget.
This is just the beginning and every one knows that there are many others hard at work and still in stealth mode. It is still too early to know, since Ajax became popular only in the past few months. It takes time even for real innovations to mature.
sgs