Jan 09

Dreaming of Hiding the Complexity

Whilst the software products are geared towards making people executing things in a more effective way and allowing people to execute things that were not possible before (I agree, this is not always something good… we would live better without some of the software creatures…), I have always thought that the goal of the technology behind the software results (i.e. the technology that allows the production of software) would be to allow the artists (i.e. the developers) to do their job in the best possible conditions.

I remember how much I loved the VMS operating system (from Digital), the powerful CASE environment that was implemented on that operating systems (ah, Language Sensitive Editor…) and the Common Language Runtime.
I also remember how easy and natural it was, a life later, to develop distributed Service Oriented applications in the Forté environment (where Service Orientation and scalability was built inside the language framework itself). The motto from Forté was “Hiding the Complexity” and, indeed believe me, they couldn’t have been chosen a better motto!

Today I have read one of the “2008 predictions articles” and I was hit by the last item:

13. The next big thing. Software development will change to a wider use of code generators. Forget about heavy frameworks, regardless of what programming language you use.  In a simple case, use some XML style sheets combined with the metadata that describes your application objects to automatically generate the code for these objects. On a larger scale, the entire application may be described using metadata and XML, and an appropriate code generator will do the job. So programming will change from writing tedious code that requires lots of coders to describing the metadata and writing custom code generators.

I know, this will remain a dream: Rubik's Cube GameWhy steal the pleasure of fighting against the complexity of building a program that would let the author being proud of the many hours he spent in debugging it and in having a presentation that looks likee what he would have wanted ….?

 

Hiding the complexity and allowing the artist to express his creativity in addressing the solution to a problem (instead than in debugging, in challenging multithreading or fighting against the geometry manager) would be something nice to dream.

P.S.The Author has, also, some interesting observation on Java, AJAX and Flex/AIR.

Oct 26

Java on the desktop is already here!

I have been surprised when I read this article: James Gosling (Sun) : « Java sur le poste client n’est pas à la hauteur aujourd’hui ». It is in French, so I translate the title here:

James Gosling (Sun) : « Java is not ready today for the desktop »

Strange, isn’t it ? The “father of Java” who, 15 years after, makes such a big statement!Well, the reality is different, as we all know.
Eclipse is there and it is there since sometime now. Eclipse is no more only an “open development platform”, but has become ‘a platform for building and deploying rich client applications”: it is called Eclipse RCP. Many people are developing rich Java applications for the desktop (and for the mobile market also) based on Eclipse RCP:

And, not least, IBM is building the new generation of its products based on Eclipse RCP!

The Universal Managed Client for SOA, called Lotus Expeditor. A platform for building enterprise applications and enterprise mashups that bring the power of SOA towards the desktop and devices

The new Lotus Notes 8 client, which brings the possibility of building Composite Applications centered around the collaboration tools

Lotus Sametime, which provides a new frontier for Unified Collaboration and Communication

Sun may not be ready. But the world is not waiting in order to make Java evolving! And Java is bigger than a trade symbol.

Oct 15

Mashups, web2.0 and the SOA cake

I read a commentary around the recent Gartner 10 Strategic technologies to watch in 2008.
In this commentary, Evan Data Corp. Joe McKendrick and Software AG Miko Matsumura say, very high, that even in SOA is not explicitely spelled in the recent Gartner’s report, SOA itself is the basis for what we are building today and in the future. There are some interesting quotes from the commentary that I wanted to highlight here, as they have really a lot to do with what we do everyday.

  • The consumption patterns of Web 2.0 and Enterprise 2.0 are made possible by SOA in this view.
    “The architecture has no value until it’s expressed in consumptions patterns. …The underlying service is just a generic-kind of service, but it comes to life when you put an Ajax interface in front or some kind of cool mashup in front of it. Once you’ve got a platform of business services, you can make mashups or Web 2.0 or a ton of really cool things.

  • “Turning to another goodies metaphor, …SOA is invisible in the same way the recipe for a cake is invisible. Even the most proud baker wouldn’t stop people from eating his cake while he read them the recipe. The consumers of cake or Web 2.0 applications want to enjoy them not hear a dissertation on how they were made, he said.
  • The status of SOA today is similar to where e-commerce was in the late 1990s. At that time everybody was building e-commerce applications using e-commerce tools. “Now, we’re doing the same thing with SOA. We’re saying this is an SOA project or this is an SOA tool. Today, you still use content management and application servers and Java as a language and Web interfaces, but you no longer call it e-commerce because now it’s just apps. It’s just how we do it. We don’t really think of it as e-commerce any more, it’s just the typical pattern for applications these days. I think exactly the same thing will happen with SOA.”
  • “When you say SOA no longer matters, it’s everything that SOA enables that matters, I totally think that’s right because SOA is a way to achieve certain things from an architecture and an alignment and agility point of view,”

I like all these quotes, because they really make the point!

Going back to what Gartner asserts, I obviously like the presence of the following 3 items in the top-ten list:

  1. Business Process Modelling
  2. Mashups and Composite Applications
  3. Web Platform and WOA

My readers know how much I consider “Business Process Modelling”, at the point that I did not hesitate to say that it is the glorification of any SOA, the way in which Services could become useful from a Business Point of view. I am not sure, though, that BPM will emerge (finally!!!). Not because it should not deserver a shining place, but because of the power implications it brings into a company’s organization (who owns the process owns the power….).

In this context, though, the emergence of the Mashups and Composite Applications, may slightly change the picture. “They allow you to rapidly tailor the functionality you want in one place, without having to re-create the original“  is the quote from Gartner. I still think what I wrote last year in “Composite Applications, Mashups and Portals: relay race or team spirit?” . Through Mashups and Composite Applications, the user will become an actor in the SOA. SOA will not stop anymore at the beginning of the HTTP pipe on the server…. it will continue, it will encompass the desktop.

The user will be allowed to integrate what the “portal” gives him with tools and content coming from elsewhere. The “portal” will provide the official company process and the mashup will provide the creativity, the differentiator by which a user would tailor the standard process and add his own touch !

Aug 30

Speculations on Google Browser (GBrowser) ?

I have read this morning an article speculating on the arrival of a new Browser on the market, a Browser labelled “Google” (or Gbrowser).
The few readers of my blog can immediately imagine that this is not the kind of news that I would have liked to hear. I personally do not like this invasion of things from Google which, under the cover of being “free for everybody”, tie us to a new monopoly (see my previous post “Internet Search should be property of no one“).
I state this even if I have no problem admitting that most of the technologies that Google, in its immense altruism, offers us are very cool and really innovative and really pushing for significant progress in the Web space.
The problem is not around how cool the presents from Google are… it is about the concept of “present” itself !

Anyway, in this specific case (GBrowser… yes, you can see that the domain name has already been registered by Google!) I think that, if the speculation actually reflects a reality, it may become something very significant, and perhaps not completely bad.

If really Google will put on the market its own branded Browser, I think that :

  1. Google will finally admit that some “footprint” is required in order to properly run today’s internet applications (this will have consequences on AJAX as we see it today, I think)
  2. Google will automatically transform what they published as “contribution” into a de-facto standard (because it will be working naturally with the new browser….)
  3. Google will create a platform onto which developers will build RIA applications

Yes, in the last bullet I wrote “RIA applications“. Because, if the Browser from Google will become true, it will obviously promote the use of Google Gears and of all the other G* things that invaded the web. A couple of months ago, I wrote my first reaction to Google Gears:

[with Google Gears] Google starts to install something else than the browser in order to keep the browser relevant”

The advent of Apollo AIR (paved by Flex) and the approaching of Vista (via Silverlight) may create serious alternatives for running applications delivered over the internet (see here and here and here for a summary of my opinion on this topic); the default mean to access to applications delivered over the net, will no more be the browser, at least when some significant experience and richness of functionality will be required.

Will Google redefine what we know today as “the browser”? Will Google remove the impedance that somehow forced the two main actors in this space (IE and Firefox) to comply (at least formally) to standards?

Again, if Google will indeed go into the Browser business, all what it gave away so far could be interpreted as a way to create “addiction, so that people will find it normal that Google will also revolutionize the browser space. After all, Google is not perceived as the “bad boys in the block“, so it is likely that this move will find only few opposers.

Despite these considerations, though, I initially wrote that this may not be a bad outcome for the web. My readers know that I consider that the browser needs a big evolution in order to support the new challenges and the execution of applications delivered over the internet. So, this move may represent a shock that will benefit the whole community.

I wished Firefox and XUL could have become this shock!!!! Perhaps they will anyway (why wouldn’t the GBrowser be based on Firefox after all?)

Of course, this is all speculation at this moment….

May 11

Firefox as a Phoenix

I am starting to digest and sediment a series of articles that recently popped out on Mozilla. The one who hit me most was Chris Messina’s Thoughts on Mozilla, but also Alex Faaborg’s Web2.0 Expo presentation. I will certainly add more comments in the next few days.
For the moment I would like to comment on the Innovation aspect.

Imho, Firefox should not bet its future on “being the best browser”. In this way it will simply set its path, in one way or the other, “on respect to something else” (notably IE).
What the user interface of Linux already did (KDE or Gnome for that matter) in trying to, first “catch” and, then, “be better than” Windows… did not produce any significant result in terms of innovation (in fact if the price wouldn’t play a role, most of the people would choose a Mac because of its interface, certainly not Linux).

So, if from the phoenix (of Firefox as we know it) could raise something new, a platform where applications delivered through the web could be executed, then, I think, it will be great. Yes, certainly, this is the domain in which Adobe and Microsoft are also directing their efforts (I tend to agree with Scoble that JavaFX is more for the mobile-phones) .
But Mozilla could consolidate the effort from the Open Source community and this would be really a great advantage.

Let’s dream about XUL+SVG ….

May 11

Does JavaFX Spell The End Of ….?

Strange logic in this article titled Does JavaFX Spell The End Of AJAX? After reading it I would think that the title would better be Does JavaFX Spell The End of Swing?

Apr 26

Flex opensourced: the battle of the giants. Towards a new Rich Client?

So, just few days after Microsoft announced its SilverLight platform, Adobe answered making Flex an Open Source platform. I suggest you have a look at Scoble’s page “Adobe opensources Flex“, especially for the two videos he recorded with some of the Adobe thinking heads.

Wow! How things are changing fast!

There is one consideration that I want to make here. Now, both Adobe and Microsoft have the following approach to their flagship UI technology:

Microsoft Adobe
Express - Entry Point SilverLight Flex
Full Product Vista -
Windows Presentation
Foundation
Apollo
  • An “entry point” offer, freely available or even Open Sourced, which paves the road to the flagship product.
  • In both cases, the technology behind is the same (MXML/ActionScript for Adobe and XAML for Microsoft). In both cases, the technology behind is Declarative!
  • In both cases, the Entry Point offer is helping making more popular, especially with developers, the technology, so that it can be more used as the basis for building applications using the Full Product version.
  • in both cases, the Entry Point makes a tactical use of the Browser (at least, in the Full Product version the browser is not playing the important role that we are used to)
  • in both cases, AJAX is used as a programming approach instead than as the overarching foundation.
  • Apr 26

    SilverLight

    I have been reading about SilverLight, the new technology from Microsoft that has been labeled as the Flash-Killer.
    What I find interesting is that the positioning of SilverLight on respect to Windows Presentation Foundation (and Vista in general) from Microsoft seems, to me, very similar to the positioning of Flex with respect to Apollo from Adobe..

    It is very much another example of a client-side container that replaces the role played by the Browser so far. With this move, not only Microsoft provides container functuionalities inside the Operating System itself (WPF) but, also, provides an “express version” of it (SilverLight), which does not require Vista and that can work on the Mac.

    I am still unclear why Microsoft does not also target Linux. But, probably, there will be someone who will do on their behalf….

    Mar 08

    Are Mashups Web-based only offering?

    An interesting article “Barrelling Through The Web 2.0 World” highlights parts of a recent Gartner’s report on Web2.0. The article features my friend and IBM colleague Dan Gisolfi.

    I extrapolated the sentence

    Who is to say the mashup has to remain a Web-based offering ?

    because I think that it is very interesting… Not because of its “Web 2.0″ bias (as the article implies) but because of the implications that the mashup technology could have well outside pure browser-based technologies.

    Web-based technologies go well beyond their utilisation in browsers. I think that they have their place in Rich Client applications also.

    I am thinking here to technologies I know, such as Lotus Expeditor or Lotus SameTime. Where the Composite application model actually allows the integration of content and application delivered over the internet with content and application aggregated from the enterprise SOA.

    Mar 07

    BPM **is** a mashup

    Wow! I think this is an interesting quote from the BPM and Enterprise 2.0 panel:

    My favourite quote from the panel, from Phil Larson when speaking about mashing up BPM data: “BPM *is* a mashup”.

    I never thought in this way, but this is certainly very stimulating as a concept. It is the way in which I always thought to this topic (BPM) in my mind; taking services and visually composing them together in a network in order to create a Composite, Multi-Role and Multi-Step Application.

    Feb 21

    AJAX second’s birthday. What’s next ?

    Today is AJAX’s second birthday, as this article remembers us.

    I remember when I started blogging on this topic. And, in all honesty, I have to admit that I got in love with AJAX when it happened. I liked very much the idea of building web applications that “last longer”, that provide a fluid experience to the user and that do not require additional plugins. At that time, in my previous team, we were trying to understand how things like Flex, OpenLaszlo and other technologies would impact the way in which our customers think to Web applications.

    Today, after two years and some posts… I changed my mind. I start thinking that AJAX has been artifically keeping the browser alive:

    • regardless of the merits of some of the AJAX technologies that were developed so far
    • beyond the excellents things we see around (more or less everywhere on the web, today! even if one of my favorites is still Zimbra)
    • despite the fact that the emergence of the Web2.0 phenomenon is certainly due to the availability of the AJAX technology (which made people caring of Web2.0 because they could immediately see the advantages)

    well, today I am more prone to think that AJAX represents the swan song of the “browser as a mean to execute applications delivered over the web“. The arguments that make me thinking that way have been often posted in this blog.

    In the previously mentioned article on AJAX Birthday, I think I agree with what Richard Monson-Haefel wrote:

    • While AJAX has set the world on fire and caused a renaissance in user experience, it’s not the best Rich Internet Application (RIA) technology available today.The technology, or “approach” as some like to say, suffers from serious problems….
    • ….The fact that AJAX has ignited a renewed interest in making the Web a much better user experience is to be applauded, but don’t confuse the hype around the technology with the basic facts about the strengths and weakness of AJAX compared to its counterparts…
    • ….Another area where AJAX really needs to advance is in terms of tooling…
    • …the number of code-level AJAX frameworks and APIs available today is ridiculous. At my last count (August 2006) there were something like 160 AJAX frameworks….
    • …Here is another problem with AJAX, it’s not very deep

    Ditto !

    Now, I would like to take this opportunity, AJAX’s birthday, to comment on an excellent article, Web 2.0 Re-examined, from Coach Wei, the founder of NexaWeb.

    One of the interesting concepts introduced by Coach Wei is the one of “Architecture of Partition“.

    The truth of the matter is that neither server centric nor client centric architecture is always appropriate. Unfortunately developers never had the flexibility to deciding the right architectural partition for their applications. Web 2.0 brings architectural partition flexibility to developers for the first time in history. With web 2.0, developers can partition the application in a way that is best appropriate for the application, rather than trying to fit into a pre-determined architecture. Some applications are best served by leaving only user interface and some UI logic on the client side. Some applications require all UI logic on the client side to deliver optimal result. For even more sophisticated applications, there is requirement to have a certain business logic and data on the client side as well. Web 2.0 technologies enable developers to decide how much computation stays on the client side and how much stays on the server side, delivering optimal results.

    Somehow, if “Architecture of Participation” represents an Usage Paradigm Shift, the “Architecture of Partition” represents a Technology Paradigm Shift.

    This Architecture of Partition is, actually, realized by means of the 3 components drawn by Coach Wei in the picture on the left.

    The way in which Coach Wei describes  the Application Client Container (ACC) has many of the points that I try to push since few months:

    1. ACC is stateful. A web browser is designed to be stateless … …but Applications are inherently stateful.
    2. ACC supports asynchronous interactions by default while browsers require careful developer coding to do so
    3. ACC can support offline computing while web 1.0 applications are online only
    4. ACC supports mobile computing as a first class citizen
    5. ACC supports accessibility
    6. ACC supports rich user experience.

    We start seeing instances of ACC appearing. Not necessarily, hopefully, in standard browsers!

    As to the third component described by coach Wei, I personally think that the “Enterprise Mashup Server” is a component that is realized partly by a Portal (on the Server) and, partly, by some clver use of the ACC. See my post Composite Applications, Mashups and Portals: “relay race” or “team spirit” ? for more details.

    In any case, Coach Wei’s paper is the first one I read in which some architectural foundation for the new generation of Web-based applications is depicted.

    Today, AJAX’s second birthday, these concepts make a lot of sense to me. Perhaps, the future of AJAX may be in some ACC !

    Feb 20

    SOA + AJAX = The client layer ?

    The CBDi Forum feeds are always very valuable. Yesterday I was able to find an interesting post from David Sprott, titled SOA Plus AJAX. What hit me most was:

    1. David asserts very clearly that “it’s essential to avoid coding business logic into the client layer“.
      Why? What’s wrong with coding some business logic into the client layer?
      • What is wrong is, imho, trying to defeat the principles of physics by mixing and shortcutting layers in a multi-layer architecture.
      • What is wrong also is mixing the business logic and the presentation

      But this does not have much to do with coding business logic in the client.
      A statement like the one of David sounds, to me, one of the myths that populate our IT culture (such as “open source is great” or “Linux is better than Windows”)

    2. David also says “I have always been more than a little uncomfortable with composite applications because they are a kluge – to the extent that many refer to mash-ups and composite applications in the same breath“.
      That’s interesting.
      I have sent David a mail asking him to read my comments titled  Composite Applications, Mashups and Portals: “relay race” or “team spirit” ? and Two faces of the same coin.
      I hope this could be useful for triggering some more discussion.
    3. David also mentions, in his post, an article from John Crupi, AJAX + SOA: The Next Killer App. I have met John when we both worked for Sun.
      I do not agree with everything John wrote…. but I certainly agree when he makes a distinction between free-services and business-oriented services, for which a contract is required!


    Update from February 22.

    I have just read an interesting article from David Linthicum: Enterprise mashups meet SOA. I want to quote a couple of interesting sentences:

    • Mashups and SOA are part of the same continuum. By linking the new components of Web 2.0 with our own sets of information and services, mashups provide a quick and easy way to solve many of today’s simple business problems — and should scale nicely to solve more complex and far-reaching problems in the future. They make the value of an SOA much more visible over a much shorter term.

    • An enterprise that can’t see the new Web will have a huge strategic disadvantage in the years to come.

    Let’s see…

    Feb 19

    Will browsers ever deliver applications instead of documents?

    Finally I found it spelled the way I thought. Great article, Beyond HTTP; something that made me thinking again.

    Just yesterday evening, I received a mail from a colleague asking me what did I think about Windows Presentation Foundation and if I have seen the New York Times Reader application.
    I replied to him pointing to a series of internal posts I wrote on this subject, especially one in which I was quoting “The browser has a terminal illness and is dying” and another one in whihc I quoted “Death to the Browser“.

    What is needed is the Post Browser, the Next Browser, whatever name you want to give to it. Sure, it can still run HTML (the old stuff), in a container that is essentially the same as today’s browser. However it should be capable of complete look-and-feel customization via a standard markup language. It should provide a rich set of custom controls and be able to access the desktop (with appropriate security, of course). It should have a native, secure, bidirectional mechanism, and one that supports multiple connections so that we can access services from multiple sources in a composite application. It should also have extensible controls so that we can extend and improve the behavior of controls and applications as needed.

    Ajax is certainly great, but its reality is very much what the author of “Beyond HTTP” says:

    I find myself in a bizarre position. The fact that I’m an expert in this kind of thing and have the technical know-how and aptitude to design and pull off such a complex beast on time and as designed means that I got paid quite well for the six months it took to develop, and I’ll continue to get paid as and when upgrades are needed. If any old John Doe could have opened up Visual Studio and slapped it together then I probably wouldn’t find myself getting paid quite so much for my services….
    ….Compare the Visual Studio .NET Windows Datagrid with its Web-based counterpart. There’s no comparison: a confident user of the former wouldn’t immediately be able to even recognize the latter.

    But, even beyond the intricacies of AJAX programming, the real issue is the REST architecture laying behind “the Web as we use it today“:

    Finally we get to the rub: The document-based Web as we know it is not a platform for developing complex applications; sure it’s possible and there are plenty of bright people working at places like Google who are doing it as we speak and creating frameworks to make it easier. But is this really the way forward? A tree-based object model accessed by an interpreted scripting engine tacked onto a specification designed for static read-only documents?

    So we need to avoid any dogmatism. Again, the author of the article asserts:

    Now would be a really good time in history to stop, step back, and look at what we have and what could be done better. What we need is a Web browser that doesn’t just server up documents, but serves up applications: full screen native GUI, network-transparent and, most important, fast, lightweight, real-time applications. Ideally we’d want to start over, build a whole new spec running on an entirely new platform and set of protocols….

    it should have state, and that state should begin by initializing the application’s main source file on the server when the client first connects. The application would maintain state between calls, allowing the use of global variables and custom classes that persist…..a move away from the top-heavy and stateless HTTP protocol to a true lightweight binary client/server relationship between the user and the application…

    …All it takes is the will to step away from the Web browser and start something new.

    I subscribe! :-)

    • I subscribe because I am not against the browser, do not get me wrong! I am in favor of the browser for when it needs to support what it was born for: supporting the delivery of documents and supporting the REST (stateless) model.

    • I subscribe because an evolution of the browser is the only possibility to save it (or to save its central position in the Internet).
      Windows Presentation Foundation” (WPF) seems to be the way that MSFT is taking to make the browser irrelevant. WPF Applications can be delivered as Web Browser Applications : “…from the user’s point of view, no installation occurred, but rather an application was “ephemerally” loaded into the user’s browser in much the same way an HTML page is loaded. In a sense, it feels as though the user simply “visited” the application…

    • I subscribe even if I find that “AJAX is a cool thing“.
      But, somehow, AJAX (with which I got in love a couple of years ago), seems to me today the swan song of the “browser as it is today“.

    • I subscribe because I start suffering from the limitations of an AJAX model which forces me to open a new browser tab to cope with anything I need.
      Web2.0 and AJAX are different things!
      AJAX may not be always the best technology to support Web2.0

    • I subcribe because, as the New York Times reader example shows, the risk is that we will not compete on the AJAX battleground in the future:
      • Microsoft with Windows Presentation Foundation is pushing for a convergence between standard applications and internet applications
      • and Adobe with Project Apollo is freeing Flex from the constraints of the Browser

      The battleground is already shifting!

    • I subscribe because of the laws of evolution.
      I think that the only reason to keep the “browser as it is today” alive is that it took so much effort to arrive to an agreement! All that effort sorts of prevents people to recognize that the laws of evolution apply in this domain also… and that the glorious browser has made its time.

    Certainly, the “Browser as it is today” will stay, probably forever (after all, the reason for not driving all on the right side of the road is because of too much legacy ;-) ). A “cheap”, “ubiquitous” layer to access the information everywhere will always be required:

    • certainly to support the access to static, REST, stateless content.

    • Perhaps to support many of the pervasive Web2.0 things…

    But real-world application development leveraging the Internet that goes unnoticed by the photo-sharing, music-downloading, blogging masses” may really benefit from a quantum-leap in this area.

    Why not starting from XUL? It is declarative, it can be hosted in browsers….

    Oct 09

    Composite Applications, Mashups and Portals: “relay race” or “team spirit” ?

    I take the time to start posting some thoughts on Composite Applications and, more specifically, on Mashups. It is some time that I have this in mind but I have always been struggling with the lack of a coherent approach in writing this down. Not that today I found this coherence or I am ready to write properly what I think… but at least I found an excuse in an article that grabbed my attention.
    The article which gave me the trigger is, incidentally, AJAX Composite Apps - The Last Mile Between Your Users and Your SOA.
    The article starts with an interesting sentence:

    In the IT industry we also have our “last mile”: putting the right application in the hands of the end user. Composite applications address this “last mile”, combining a rich user interface with SOA-driven application integration technology.

    Yes, I think that the analogy is interesting. It continues saying:

    Composite applications are nothing new. Analysts have been talking about composite applications since the birth of the Internet and in more urgent tones during the Enterprise Application Integration (EAI) generation of integration technology

    and, towards the end, goes deeper:

    Portals were arguably the first generation of composite applications. Today composite applications can offer a much richer application development platform through service-based integration (instead of the kind of integration in the application server that runs the portal) and the highly interactive user environment offered by AJAX-enabled rich Internet applications. With this trend, some analysts have predicted that composite applications signal the beginning of the end for portal-based applications. In reality, the primary functions of portals and composite applications complement each other well. A portal can “wrap” and pass through users seamlessly to a composite application, containing it wholly. Conversely, a composite application can wrap a portal (or portlet more likely), as part of the application, perhaps even invoking it with parameters that tie it into the rest of the composite application.

    As I wrote in my post titled Two faces of the same coin, the integration space is huge. In order to do a job, in order to do a task in general (I would say), everybody needs to integrate information and tools coming from different directions.

    • Some of them are mandated.
      For instance, in a working context, some of these information and tools are mandated by the company’s business process; it is the view that the company has on the activity you have to do.
      Outside of a working context, mandated information and tools are the ones that derive from experience, from common wisdom or from convention.
  • Some others are specific to each individual.
    In a working context, for instance, two enginers may do things differently because of the personal taste and experience, the curiosity, the culture.
    And this is true also outside of the working context.
    I would say that this “part” is what distinguishes an artist from an other….. and this should be well known to software engineers, right?
  • So, these two sides are really important. They complement each other. Today is hardly possible (at least in the Western world) to think to a job where an individual is not asked to bring her/his own “approach, experience, information, tool“… This is why, I think, our governements are very attentive to the school system.

    So, how this matters in the context of the Portal and Composite Applications?

    I think that a Portal is the way in which the “mandated information and tools” are made available to an individual. A Portal actually aggregates the info and tools that the “owner of the business process” delivers to someone in a given role. These info and tools are part of the arsenal of the company, either directly (because they are physically owned by the company) or indirectly (because the company believes that this material found elsewhere is useful for you… and perhaps pays a fee for making it available to you).

    A Mashup is the equivalent, in my opinion, of the “personal knowledge” that an individual brings to the table in order to do her/his job in a personal way. I may be wrong but, if you allow me for one second to escape the technical limitation imposed by today’s browsers sandboxes, a Mashup is something that I bring into my workspace in order to do things better. There is a lot of accent on the user, on the way in which each individual plays herself/himself in the context of a given activity; it is her/his “engagement”, her/hos “flavor in doing the job”.

    At this point, a Composite Application describes the way in which these two sides are combined.

    I start thinking that my previous post (and the analogy with the hemisperes) is getting more clear now. The Portal is the way in which the “company side” (I would also say, the “server side”, at least in the mahjority of situations) of the picture is delivered to you (I call it the South Hemisphere). And the Mashups is the way in which the “personal side” (I would also say the “client side”…) of the picture is used by you (I call it the North Hemisphere).

    In both situations, of course (and the author of the article is right) SOA is important.

    And it is in this context that an architecture like the one of IBM’s Managed Client (see here) will make the most of sense. Even if it does not yet brings inside the picture the concept of Mashups, i.e. the concept of components that the final user can aggregate in an autonomous way to complement what the “server” brings to her/him.

    I am not bashing AJAX here, of course. But AJAX is not always the right answer.

    Aug 27

    Two faces of the same coin

    A series of articles trigger this post. Among them, two above all:

    I could summarize the ideas behind them in the following way.

    Enterprise Mashups represent, on the desktop, what SOA represents on the server. And that what matters, on the client as well as on the server, is how these technologies allow the execution of Business Processes.

    This is great!
    In my presentation “Thoughts for a Rich Client”, I sort of developed the concept of 360 degrees integration.
    See Explanation.  Clicking on the picture will download  the highest resolution version available.Let’s represent the integration space with our Globe: we have a Southern and a Northern hemisphere.

    The Southern hemisphere represents the kind of integration that happens on th server. This integration is made possible by an architectural pattern (SOA) and conveyed to us by a Portal. Ismael’s article describes so well how this is all about Business Process, because the reason to adopt an SOA is indeed the one to automate an existing Business Process (or to implement a new one).
    By the way, I have written a little comment to Ismael’s article in which I try to explain my position.

    The Northern hemisphere is a new territory. Until recently, the desktop has been considered simply as a projection of something that was happening on the server. Infact, a Portal is aggregating content that is simply displayed inside a browser. In the Web world, the Presentation Layer of an application has normally been executed on the server, leaving to the desktops the simple task to display something happening elsewhere.
    The advent of AJAX (and of other rich client technologies, including Lotus Expeditor) and the evolution of the technologies in the browser space made it possible to actually consider the client as a first-class citizen in the SOA world; for the first time in the web era, the Presentation Layer (or a part of it) could be implemented outside of the server, “after the web server”, on the other side of the pipe….
    This makes it possible to perform aggregation also on the client. call this aggregation “enterprise mashup” or “rich portal”…. at the end, what these technologies allow, is the implementation of the client side of Business Processes.

    The Business Process can now be described and properly automated in its more natural way: a rich set of cooperating tools, information and applications allow users, from their desktop, to properly use orchestrated services. The formal, top-down processes described and executed on the servers are made available to users who can recompose them in ways that exploit the innovation and foster the flexibility required by new enterprises.

    So, BPM on one side and Enterprise Mashups on the other, can actually represent two faces of the same coin. The coin of the “enteprise business processes”.

    P.S. Other articles that contributed to this where: