It was an innocent enough motivation – find a blog client that would liberate me, at least a little, from the web based blog interface that I use on one of three blogs that I post to. Truth be told, I was not very savvy about the blog client landscape, I just wanted a little convenience, like spell checking, formating, and generally not having to fire up MS Word every time I had to post a lengthy article.

What started as a simple endeavour to install the ‘Performancing’ Firefox blogging extension. When the attempt to install this extension went awry, crashing the browser, eating up days of fiddling – I spoke to a consulting client of mine who makes a Super-Server platform that includes, amongst its many web services and database functions, an installable Blog system. The conversation took many twists and turns, and resulted in a ‘quest-to-test’ as many blog clients as possible. I resolved to form some opinion of how interoperable, usable, and generally, productive, these blog clients are compared to the native web-based interfaces we usually use for our daily blogging.

I tend to write rather longer articles (compared to typical blog fare) for this client’s internal blog, some of which gets into the wild, and I almost always use MS Word for its ability to footnote, spell check, format, etc. After an article is finished, I cut and paste into this client’s blog hosting platform using the Web based interface. Nothing wrong with all that except to open or change the browser view, cut paste, add tags, etc. This particular blog and server system accurately captures all of the MS Word formating and hyper links, and the system generally works.

Still, I thought, maybe there is a dedicated blog client that pulls this all together? Maybe include podcasts and in-line images, rapid grabbing of RSS feeds or web content to quote in my articles? Well, the odyssey was enlightening,frustrating, and poignant in the extreme.

The blogosphere is a nascent precursor to the readable, shareable, write-able web – and we are going straight downhill if the lack of stability and standards in blog clientware is any indication of the state of the art. The following opinions are simply that – mere impressions of one person’s collected thoughts on using this potentially useful technology as an adjunct to blogging productivity.

Rather than single out particular blog client software for scrutiny, I am going to draw a set of general conclusions; it would not be fair to the programmers and  publishers to post categorical remarks based on my experience alone – and some of these conclusions may be rendered moot by updates and such in the fullness of time. The overriding impression is one of lack of stability and difficulty in configuration. Certain well known blog clientware offers preset options for free and paid blog hosting services, and it seems these may have fewer problems. But woe unto him who tries to configure for other hosting platforms that support well know blogging APIs!

Here is a list of struggles that I engaged with in my ‘quest for blogging productivity’:

1. Setup issues – if your blog client supports a well known paid or even free service, then you will have less trouble determining the actual URL used for account access, which may be different from the URL used for reading or even posting to your blog from a web based interface. The same goes for configuration of the infamous RPC endpoint – handled differently by each blog client.
   
   
2. To make things interesting, for those configuring for custom hosting platforms. some hosts use /RPC2 (case sensitive), some use /backdoor-xmlrpc – hold it…some clients have a separate field for the endpoint using no slash – some need the slash – some want the whole thing one big, ugly URL. Care to find the proper way without tearing your hair out – browse the FAQS (as if you have nothing better to do), send a support email – and wait. Expect to possibly get incorrect information.
   
   The only positive thing I can say is that once you get the hang of it, most blog hosts of the same family (Word Press, MT, Typo) tend to be alike – but not always.
   
   
3. Beware of on-line docs for setup – they are often outmoded.
   
   
4. Multiple choices for blog API’s in your client software? Tough luck! Try them all and see what works. You will notice that some of the client’s features will work with one API setup, and not with others. Oh, and yes, you will be pleased to note that sometimes when you change an API, strange behaviour may result, errors may be reported back to you, and you may crash in various ways. I found that with some clients, it is best to terminate and restart the client software after an API change – sometimes this will not be enough; you may have to delete the blog account info, re-enroll your account info, restart the software and try again.
   
   Oh, and I found sometimes that a restart of the OS is sometimes a good thing.
   
   
5. Media Objects: A real sore spot. I was hoping that a good blog client would make posting images and other media files a more seamless process – wrong! If my experience is any indication, native files on your local file system are going nowhere unless your blog client and host are in agreement. This may entail FTP account setup (puhhhhleeeze), or a special URL, which may be relative to your blog account URL, or another totally unrelated URL or directory pointer – I think you get the point.
   
   Some of the pre configured services work fairly well here, and some subset of the clientware out there supports this, but it is not easy and is not universal. I swear, if you heard some of the setup instructions to create an /images directory for my blog accounts – you would surely laugh.
   
   Note: it is very interesting to me that the clients that did support Flickr made it easier to insert photos into my blogs than did the native uploading of files from my local OS.
   
   
6. Although not specifically related to clientware – what is the deal with blog templates? YeG-ds. I have never seen such a messed up situation in my life. Hurry up AJAX.
   
   
7. Podcasting – none of the clients I tested offered easy, universal, support for podcasting. I hear that Apple has a great universal tool set for this that includes blogging and much other stuff that works like it should. But I'm clueless about Apple – that  may have to change.
   
   
8. Error handling – some clients crash, some report an error and send the post through without telling you, some report a cryptic error and don't post.
   
   
9. Support for Technorati, Del.icio.us,  – sometimes this is a function for the hosting platform, but coverage is spotty and what is with this ‘keyword’ thing in the Movable Type settings?

My intent thus far was really to avoid a laundry list of failures and issues – but rather to give an overall user impression. What we have here is a dynamic of diverging and immature standards, clients, and hosting engines. In this era of Web Services, REST, SOAP, WSDL (especially WSDL), we should be at a point of functionality where a Word processor, blog client, or anything..can reach out and touch a hosting platform and know what its capabilities are and compensate for the supported features and API omissions.

However, the best blog hosting platforms are web editing centric, and most clients are produced by independent programmers and small shops – more like utility programs. I applaud these efforts, and this article in no way casts blame on those actually trying to make useful software for the active blogger. I think this is an issue of immature industry, and fast moving conventions and standards.

There are a growing number of blogging and social / semantic web technology platforms sprouting up around the way. Likewise, there are a great number of blog clients. If we could just use the best of the latest (easy for me to say), in order to improve interoperability and configurability between clientware and blog hosting platforms, then the work of the W3C will have not been in vain.
 

This post was written using the BlogJet client, and was posted to OpenLink Software’s Virtuoso Universal Server’s ODS semantic data space blog application – wish me luck before I hit “upload”.

The Year of the Web Application Framework and Java Defections

One doesn’t need to be a Java Expert to blogwhine about bloated frameworks and Java induced headaches – Let  Bruce Tate say it more eloquently than I ever could ever hope to [1] . I’m a writer and client facing person, I put the spit on heavy technical articles so upper level folks can get their points digested. Sometimes, this type of lively ‘analyst type’ writing helps others. Hey, it’s a living.

And I’ve been out of the coding loop for a while – my old days as a topnotch firmware/AT BIOS/FORTH man are well behind me, but I’m back baby! Thanks to a fortuitous oblique reference I found Ruby, and why, and hey…how can one argue with this stuff, really?

But I’ve ‘out the game’ so long, that I’m even having a hard time asking the right questions, which never was problem for me before, because I have a very good grounding in traditional programming. So when reading all things Rails, and to a lesser extent Ruby, I don’t get it all, and have to dig. Sometimes the formally presented information, such as in Dave Thomas’ excellent, “Agile Web Development with Rails”, leaves me a little….huh?

But this is just rust – it does not cause me undue stress (I lie, I feel I will never catch up).

Round about two years ago, I thought, I should know more about Java. So I purchased Eckle’s, ‘Thinking in Java’, with the CD-ROM. Hmmm…am I just slow or stupid….I must be stupid, it’s not jelling. Maybe a class sitting with live humans.

Now, I know that there is a certain momentum in all things crafty and intellectual; if you stop working in something for say, twenty years, you have to play catch up. But I felt that this Java problem I was having was going deeper. It seemed very painful to do small, satisfying things – the things that entry level folks need to get positive feedback, good vibes, and a willingness to go further. I wasn’t getting it or having fun learning it.

Now, I’m not stupid (really!), I just think differently and more broadly than I did back then. Ruby, Rails, understanding the interplay with the web infrastructure and the separate issues of delivery configuration is just the cost of doing business. And, as a older returnee to the programming fold, I was not up for the Java Fight. Six weeks into the Java class, and still fighting with my home machine’s development classpath, I got up, and without undertaking a soliloquy (something I might have done in high school), I left, thinking, ‘there has to be an easier way’.

I was a commercial FORTH/x86 assembler programmer specializing in Real Time systems back when I was in my 20’s – now I’m a Java failure at 47. Is Ruby going to save me? Probably not, but I’ll have more fun flunking out and telling about it. Furthermore, it’s uncertain whether or not the Ruby Hook would have been planted without Amy Hoy, who correctly identified the “middle documentation problem”; you know, when the geniuses post 15 minute videos of web app creation, and you buy the books, and still don’t’ know the story behind the story? Amy’s articles really helped. Thank you Amy Hoy, looking forward to your new Rails book!! [2]

There has been a tremendous amount of commentary on Java defections to Ruby, Python, and frameworks (obviously Rails, Django). The upshot seems to be that you don’t have to be totally out of practice or slow to appreciate that dynamic languages and web application frameworks are providing a way to achieve that certain something that web application programmers are looking for. For the entrenched world of Java, for those that thrive in it, or for those that must work within a business climate where there is little or no choice, I see the far horizon, and if you read the Bloggosphere as I do with my morning coffee – there is a bright tomorrow rising,

With that sunrise will come even better integration of web application frameworks with their hosting components, making deployment less of a specialist’s game – no disrespect to Swtchtower.

Service Oriented Angst Comes of Age

Alan Wilensky, Analyst

Encompass, LLC.

Industry Overview

Service Oriented Architecture (SOA) is moving surely along the further end of the adoption parabola. The Web Services vendor community, once considered an exotic species within the mainstream IT cohort, is at last providing solid tools for application creation and reengineering via services composition.  This soft milestone is verified by the fact that one is generally no longer required to be completely conversant in the W3C specifications when employing the latest generation of Web Services tools. - this indicates progress.

The SOA grail-quest is a old as computing itself, and indeed mimics our life’s desire to simplify and understand relationships, causes and effects of our actions.  Certainly, if one could travel back in time to read the mind of Alan Turing and Company, toiling away at Colossus in 1943, the first digital computer used to break the WWII German Enigma Cipher, you would detect an innate psychic murmuring, ‘bollix, I wish we could just invoke some well defined service, without all this fuss and bother “.

The computing industry has listened, as reusable code libraries and dynamic programming models have multiplied like genetically engineered rabbits.  Great innovators of computing architecture led the industry through iconic changes; from the centralized Iron giants of yore, to the minis and super minis, on to the PC and the catalyzing influence of the Internet and the World Wide Web. Each revolution in computing hardware and connectivity begat a concomitant revolution in system’s programming methods.

And here we are, newly arrived as beneficiaries of years of struggle in the data format wars (a.k.a. XML), and in an era where the world’s computing infrastructure is decidedly enmeshed.  Though it took a while for the academic and vendor communities to settle down, we are now seeing post-early-adopter uses of SOA.

Tracking SOA Adoption

Presently, capital line-of-business applications and custom programming may be invoked as network based services with well defined functions. Perhaps as important, the spreading of database management systems is becoming far more manageable in the guise of component services presenting a unified data model.  This synergy hastens the promise of SOA,  as this seamless unification of application functionality and data cohesion allows for the composition of new applications, and creates an agile growth environment for existing systems to evolve. Our new service components may be composed of both new and older cloth;  we will build a new generation of applications with minimal disruption to current processes, preserve existing system emplacements, and orchestrate the consumption of these network-available resources in a ballet of Service Oriented Architecture.

For those of us tracking the Web Services Rodeo from the outset, the relief etched in the faces of ‘real users’ is apparent. The progression of inscrutable terms such as “executable end-point’, resulting in the blankest of stares, is being replaced with a relaxed comprehension and an increasing grasp of the substantive subject matter. Naturally, larger, resource rich companies took up the SOA gauntlet first, adapting legacy infrastructures using the principle of composition.

Another promising hallmark of the SOA adoption curve is capital line-of-business software vendors, like SAP and Peoplesoft. Vendors who have long offered voluminous platform specific API integration libraries have warmed to the Web Service siren call. The benefits are manifest, as callers and service providers become increasingly platform agnostic using the lingua franca of web services : 1) XML for data/metadata, 2)SOAP –XML-RPC for messaging envelopes, and 3) WSDL for self-documenting service parameters. These basic building blocks of the SOA fabrique provide a foundation for further enhancements and services for security and reliability.

The advent of XML’s ubiquity is a study in the chaos of convergence.  Mirroring the renaissance of the Web, which the Internet proper preceded by years, the wonderful-horrible marriage of HTML and Web Browser created a democratizing influence over on-line business and personal publishing.  An increasing set of ever more accessible tools is making SOA the latest chapter in a fairy-tale of web services convergence. The delivery of XML-based services crossing boundaries of OS specific silos of functionality is but one of our IT era’s latest success stories.
.

This is the Server Side revolution. Application frameworks have evolved with particular zest, keeping pace with the explosion of better performing, lower cost databases. Significantly less mental capital is being squandered agonizing over the application/data relationship. Core data relationships are still the subject of intense design scrutiny; yet the legacy of the last forty years of IT science is changing rapidly with the proliferation of object databases, object-relational mapping, dynamic languages, and web services. This domain of applications and the relationship to underlying data is now a much more flexible endeavor due to the foregoing innovations.

It’s a rosy picture, yet we still struggle with systems that are the progeny of monolithic schemas, vast ER diagramming, and massive joins and foreign key relations. For SOA, a real renaissance is just starting with dainty, yet increasingly confident steps. Data is becoming more universal, contained in smaller functional domains (or made to act like it), with wider accessibility, and with better tools for accessing monolithic and heterogeneous data storage systems. These tools and new Superplatforms are being innovated at a furious pace. Data is becoming smarter, with abstract object storage freeing programmers from the ‘tedium of where’.  

Programmers need to know less about the minutia of rows, columns and  foreign keys as advanced development frameworks become even more closely bound to modern middleware, Virtual Databases, and native object relational mapping. Each year brings us closer to an ideal of universal data objects that act with increasing intelligence.

In this pouring from the empty into the void, questions arise – these were my analyst-style questions in the dim, early days of Web Services and SOA:

·       How will services be created and broken out of their monolithic application stack?

·       How will new services access data from previously monolithic database schemas?

·       Does a services invocation approach obviate the need for old-time data modeling?

·       What am I going to do with all this SQL and stored procedures? Throw it all away?

·       How am I going to Query XML native objects in a new SOA world?

·       What about data in multiple DBMS systems (ours and our partners) that are not in XML?

Creating a Culture of SOA

The march of time has not changed the fact that applications still require data access and persistence; what has changed is the diversity of data storage platforms. It is not uncommon for application ‘A’ to access one DBMS, and applications ‘B,C,D, and E” to persist data in other platforms. The two-tier application revolution, now very mature, has created data and application silos that may use SQL, applications server session data, flat files, and industry specific messaging formats, like EDI, or ebXML.

To institute an effective SOA plan, we need to factor essential service functions by type and compose individual and composite services that make sense. Furthermore, an important key to this network accessible service model is data availability via a unified data model spanning our diverse storage platforms. A service factoring process therefore comprises an application service invocation construct, resulting in a set of URI end-points that deliver finite, well-defined services with concomitant access to data.

The foregoing is an enduring drama played on the stage of IT history; if anything has changed culturally, it’s the competitive concerns of delivering innovative services in an agile fashion.

The middleware era is alive and well, and universal data access for applications (ODBC,JDBC) is still a vibrant and profitable sector. Virtual databases are also carrying a substantial portion of enterprise integration workloads. A minor shortfall in this approach is the somewhat dated reliance upon explicit SQL wrangling. The Web Services renaissance,  based on XML protocols, makes this reliance on explicit table definitions messy. The world of SOA is striving for a more elegant medium in which to express data object relationships for applications invoking web services.

Data Services Construction

Evolving a new model of the data universe in light of SOA philosophy devolves upon functional isolation – liberation of discrete services by function. In the real world, we have applications that Create, Read, Update, Delete, and Calculate, etc., while database systems may be scattered all over the place with poorly documented schemas, and application bindings. For a fact, most two-tier applications, client/server or Web Based, rely upon services bound tightly to an application’s event loop. Such architectures do not readily lend themselves to reuse; even those with ample, bulging API binders.

SOA modifies the approach of classical database schema design in the grand tradition; working from what currently exists, we liberate data service classes as objects, and create new functions in order to transit these service classes upward towards network-based interoperability.

The concrete approach of service composition is at the core of data services architecture. Common, plainly understandable services are mapped to business objects - such as inventory and supplier service objects. These services abstract the data interaction layer of a typical enterprise application,  and provide an explicit implementation of a generic method. Like Oz behind his curtain, a service invocation may interact with any number of data resources through a unified data model spanning multiple DBMS systems locally or at far remove.  

This view of network accessible services is very different in terms of types of service containers or classes, rather than explicit functions calls:

·       Abstract data services rather than explicit SQL declarations

·       Services for application-centric functions which manipulate the abstract data objects.

·       Service container classes for inter-application, pardon me, inter-service messaging – a transit service for data that must be shared and combined

·       Service methods that cater to user interfaces and machine interfaces

Variations of the above are becoming standard constructs, some call this a “Design Pattern”, and there are many. The important point is that SOA methods embrace a notion of data abstraction through invocation of service methods,  which in turn expose functions of the underlying data management layer. This all should occur  with lower development overhead. This ‘thought bending’ spills over into application frameworks and IDE’s that encompass both light and heavyweight implementations of the Web Services and SOA paradigm.

In the Real World

A service abstraction consists of the application logic for servicing a function. A natural order of selection of functions arise from our legacy applications, and as composite functions that need to be invoked in tandem.

In our medium manufacturing example, we know that Supplier ERP and inventory records are interrelated by our legacy systems. Although one application is store bought (SAP), while the inventory systems is older, using an aging database system, we have in embryo an ideal test-case for an SOA approach to integration.

An add-record method exposure for the supplier/inventory service class may be proffered as a composite access invocation. Using an SOA framework providing a design time environment for the exposure of SQL stored procedures and application code, we may create a WSDL service, in the truest sense of the word, comprising one or more SOAP invocations to Create, Update, Delete, or Read the Supplier data in both  inventory and supplier ERP DBMS systems. This service mapping should not at all be disruptive of the ERP system’s primary user interface, as all the rules of the underlying data structure are kept intact.

Service container descriptions and ‘super service calls’ are one way to structure data access and application functions in the SOA world.. A modest implementation might be better served by a list of direct service invocations, listed in a UDDI directory. One may be limited by the type of tools adopted; as with all with new techniques, SOA applications are an expression of tools, talent, and persistence.

Many companies, not all of them gargantuan, are eager to offer web services for partners and clients. These companies also have a motivation to simplify an aging and increasingly diverse data infrastructure. In one swell foop,  we are witness to an increasing number of SOA pilot projects and internal (possibly covert) laboratories engaging and contributing to these worthy aspirations.

SOA Methodology in Practice   

Integration implies a certain amount of work; the scope of a project’s complexity depends on the underlying data access system’s type and the quality of application code held over from pre-SOA project days. There are nuances in the world of SOA; services may be called via traditional programming methods, or the latest declarative and graphical design tools may be employed.

Services managing information in our CRM/Inventory example provide two invocation calls for storing or retrieving supplier data. Each service invocation has an XML Schema describing record metadata (described by WSDL). Providing transparent access to the data residing in each system mandates the formation of a unified data model in order to normalize the calling mechanics to what were two distinct data management sources.

A Classic programmatic method of service invocation requires a code loop or script to retrieve information returned from aggregate data sources called from the service object. If this data is bound for a web based UI, Java Script or XHTML style sheets can do the job, while many new programming frameworks are pitching new-fangled AJAX. The downside is that this repetitive scripting must be duplicated for each service invocation.

Without the base-class empowerment of a robust framework, possibly Django, Struts,  or Ruby on Rails, the programmer must be resigned to a certain amount of vigilance. Any modification of schema or method handling will impact maintainability. While a framework’s ORM class handling can help with repetition and adaptation, ultimately, placing service invocation in a code or script loop can be bothersome. New techniques for modeling service objects are being innovated at a furious pace by framework vendors (and the Open Source Community); these advances will obviate some of the pain involved by dynamically propagating schema changes to view methods.

An alternate path uses declarative queries and process orchestration. XQuery and BPEL, shaken well, is a  hybrid methodology worth examining. Ultimately, any combination of scripting, frameworks, XQuery, and BPEL, will be completely interoperable as development environments mature.  

A declarative approach to SOA on Web Services might use XQuery to define super methods for marshaling data services. Executed with aplomb, we have created an ‘abstraction of an abstraction’, returning a unified dataset  within the WSDL invocation URI for ‘add supplier’. This declaration can be defined centrally, consolidating all potential changes to the data access methods in one location, freeing service consumers from yet another layer of integration details. A properly implemented XQuery processor leverages all the power of the underlying data virtualization layer, with its concomitant power to optimize query syntax and cost modeling.

A small but growing number of contemporary super application serving platforms provide this highly flexible layering of core database services, data access virtualization layer, and in-line query transformation. Such platforms are all about application composition via Web Services, i.e., the creation of SOAP objects hosted in HTTPS accessible virtual servers, automatic generation of WSDL, with integrated BPEL to tie all service invocations together at a highest level of abstraction within an integrated application hierarchy.

Conclusion

The adoption of a Service Oriented Architecture in no way implies a single methodology for accomplishing an integration task. Services invocation may be packaged and executed via programmatic and declarative methods, or a hybrid of these techniques may be desired. The future basks bright in the sun of convergence, where a golden lasso ties together the best of Web Services platforms, Web Application Frameworks, and data unifying architectures.

Data services are a basic building block of SOA. The explosion of middleware components and super application servers help us get SOA designs off the ground in a unified, data-agnostic fashion. New Application Frameworks for creating Web Applications provide even more leverage for the programmatic consumption of these services.

The layered power of Data Virtualization, declarative abstraction for querying data supersets (XQuery), and Web Services in the form of SOAP, WSDL, and BPEL, create a rich environment for the creation of Service Oriented Architectures with less angst.   

By Tom Bradford,

12/13/05 Forward and explanatory prologue emendations by:

Alan D. Wilensky, Analyst, Encompass Consulting

The Soul of a New Web

‘Social Networking’; at once an inscrutable term, is  redefining the future of the World Wide Web.  We are all destined to be bent to the will of innovation as the Web inexorably transitions from islands of content to a fully-meshed fabric. Web 1.0’s  model of agglomerations of sites we shared with friends or use at work, are constructs of a mental hierarchy, but not of a concrete fabric. This is changing as we speak.

The next web is currently under construction. The hyped Web 2.0 is a mystery in embryo, for any concept that cannot be clearly defined in a few short paragraphs must be suspect. However, we are living vividly in the crossover of Web2.0 times. Social bookmarks, tagging, and blogs are the mere infancy of this semantic web. Even words used to describe the revolution are obscure, for outside of academia, where is the vocabulary of semiotics so bandied about?. The definition of semantic is, ‘relating to meaning or the differences between meanings of words or symbols’. So far so good. Web 2.0 will be content with meanings (tags) attached, and an architecture to liberate this semantic content into cyberspace (via RSS and other XML systems) so that it may be shared, marshaled, syndicated, and subscribed to.

Some great thinkers have coined this the ‘executable web’; Kingsley Idehen, OpenLinks CEO, a thinker if ever there was one, endeavoring to clear my Web 2.0 fogginess, said, “Web 2.0 is a system of ‘points of presence’ on the executable web – the web is the new operating system.”  Taking my usual three months to digest Kingsley’s thoughts, I became dimly aware of the potential for this ‘meshed fabric’ of active content.

Web 2.0 is Delicious and More

”delicious-delicious”, Kingsley echoed to me during many conversations, but I thought he meant the vegan cupcakes I had brought the OpenLink staff. It did not occur to me that Kingsley meant del.icio.us, a social book marking and tagging site that has changed the way I organize my incisive web-based research materials. Mr. Idehen did not lead me by the hand to del.icio.us – he suggested that I submit my conference research reports via the company blog and configure for ‘tagging’ services.

I was so lost; the immaturity of Web 2.0 shows in the strangeness of the tools and settings – but guiding me in a Zen-like way, Kingsley had me dutifully obtain an account on del.icio.us, configure my OpenLink Virtuoso blog, and add tags to my Virtuoso blogger profile. Viola, my blog article was now on del.icio.us, classified according to the tags I had added to my original post. Huh!

As I latter learned there are a great many social book marking services and content collecting engines in the Web 2.0 cloud. The Virtuoso blog engine has account settings for configuring specific upstream targets for your blog – but I also discovered that Virtuoso pings (notifies) well known blog aggregation engines, like Technorati, Moreover, and others, without the need for specific upstream setting other than the addition of tags to the blog account holder’s settings. So be careful what you write in your blog – the isolated ranting of luminary or lunatic may be instantly broadcast into the Bloggosphere.

Virtuoso Syndication is Bloggolicious

What do people have to say, really now? The blog is today’s best example of Social Networking on the Web.  Blogging is PERSONAL publishing as a series with the addition of syndication. Blogs are composed of public diaries, articles, commentary, and reporting on a variety of subjects.  Diversity of subject matter is what makes this a thriving, popular medium, while free and low cost Blogging accounts are as easy to obtain. Why the fuss? Haven’t personal web sites been available for years? What’s the difference between Web Content and Blogging content? In a nutshell – simplicity, syndication, semantics, and aggregation.

Simplicity of enrollment, posting, and commentary management. These attributes have not been a   solution set in the personal web services space.

Syndication is the magic of RSS, Real Simple Syndication, and other XML protocols that are largely transparent to the blog user. There may be subtle differences as to how these strange settings and attributes affect availability of future ‘social networking’ functions and publishing options. It must be underlined that XML protocols used in Blogging are easily transmutable into almost any other type of  syndication protocol – for this is magic of XML – separation of content from presentation and structure.

Semantics is the ability to add ‘tags’ to your blog posts. Tags are words that confer meaning to you or your social network. Sites like del.icio.us or Technorati will use these tags to aggregate your blog and help others find it. Clouds of tags and semantically tagged content is automatically built by an increasing number of Web 2.0 sites; not all of these are blog related, some are business oriented.

Aggregation is the act of blog engines pushing to popular collection points, or the reverse, content pulled from your blog to the aggregator. An upstream is an explicit destination that the blog account user configures with credentials, but many blog engines automatically ping popular aggregation sites. There is almost always a way to enable posts to be marked as private., and excluded from entering the Bloggosphere.

Blog systems provide a simple publication interface, for push-button publishing capabilities.  Blog posts are usually retained for archival purposes, affording readers the opportunity to digest content entries dating back to the beginning of that particular blog. Blogs often allow the readers to contribute to the content entries via commenting systems, and allow author’s to have administrative control of the comment stream.

Traditional web sites required authors to publish content using web authoring tools and the use of presentation markup, making sites hard to maintain, difficult to extend, and requiring the author to manually manage the article publishing in series format. There were, and still are I’m sure, on-line Web authoring tools that allow Newsletter publishing, comment management, and even email notification of new postings – but these systems have been supplanted by a maelstrom of blog tools, and the furor that has engulfed the Blogging phenomenon.

Blog Support in Virtuoso

</br></br>

Now that you understand the value of Web Logs, you may ask yourself, why Virtuoso? The answer is simple, but deserves a bit of explanation. After all, Virtuoso is a Super Server, an integration platform, and a content services powerhouse; what’s the deal, baby? We shall see how this article’s original author, the eminent Tom Bradford, sets the scene:

“Virtuoso facilitates effective flow of enterprise information. All is information within the global InfoBase.  A mere fraction of enterprise information is stored in the database proper, while the majority remains untapped and ‘in the wilds of the file system’.  A compelling argument if ever there was one for Virtuoso's mission of leveraging disparate information in a source independent fashion.
 

Information stored as blog content may be important to an organization, particularly if subscriptions or publications contain information vital to the business.  Blogs become a knowledge base for organizing content and an atomic representation of that knowledge."

Conclusion

The most basic, yet perhaps important and enduring aspect of Web 2.0’s social networking face is and will be the Web Log, or Blog, for quite some time. The democratizing influences of the Bloggosphere have already changed our society, launched scandals, and toppled once mighty news organs from their Apollonian perch. We have not seen the end of the blog; not by a long shot.

Virtuoso provides a powerful Social Networking foundation, a full-featured Blogging engine as an integral part of your organization's ability to leverage its entire breadth of information. From this point of departure, we have no idea where Virtuoso, with its vast panoply of content syndicating features, will take us.

One man’s impression on the new model of an emerging class of entrepreneurs.

Overview

I attended the Boston Web Innovators conference in a noisy, Cambridge bar. I arrived early, because I knew that the presenters would be setting up projectors and such. I spoke to several of the young men and women (there were many), and got to know a little about their thoughts on the technical aspects of development, tools, trends, and business models.

I also met the event host, David Beisel. He is an Associate at Masthead Venture Partners. David is a good man, trying his best to cultivate very early stage Web 2.0 ventures – these such as we saw at the Innovators Conference are far too small and at far too early a stage for his VenCap firm to fund. However, he is visionary looking down the long road of his portfolio, and the willingness he professes via these events (out of his pocket, although I paid for an $11.00 Bailey’s) is testament to his faith in Web 2.0.

There are several aspects to my analysis

–        The tenor of the event and personalities

–        The hype over Ruby on Rails development environment (I may need deprogramming)

–        The attitude, enough and to spare, of these very young, very smart developers, of existing tools, infrastructure, application hosting, and what makes their clock tick

–        Why are these inventors, and a new class of their investors, so displeased over the words ‘enterprise anything’, and so negative on any tool or product that needs to be paid for or licensed? The venom was palpable,

–        Is there an opening for Open Link? In short, like anything, and with and OpenMind, and an agile spirit – yes, there is an approach strategy.

The Event

As I said, I arrived early as I knew the presenters would be setting up. I spoke to the founder of Blognicient – he didn’t have a card, but did have an MIT class ring(Put a pin in that thought). I spoke with the Kiko founders, and many others.

They were young, each one younger than the next – a range of 19-27 years tops. The room was filling fast, it resembled a frat party with geeks. There were many female technoratti. My former experience of these Vencap  events are more formal and everyone wants a deal – but David was not besieged. In spite of the noise, he was having relaxed conversations with the attendees.

The overall feel of the event was an after work party, and these young folks were into what they were doing – if they were hot for equity, they didn’t show their cards at all. May thought that they could get their lightweight web applications up, get advertising, and self finance without dilution. More on this soon; it all ties to Rails and the founder of ROR’s success in making a success from Rails and the subsequent applications that made it big – Base Camp –Tada-Backpack.

The Ruby on Rails Hype, Religion, Saturation

Every last one of the presenters had an MIT class ring. Every Presentation had something to say about Ruby on Rails. One of the more pointed and cogent questions of the event was to Blogniscient’s [1] founder, Ben Ruedlinger: “….is the ranking engine also done in Rails?”, answer, “no, we have a custom process that is proprietary.” “psssss….said the Crowd.

So, why is Rails so important to these folks? I cannot answer this. There is some evidence that the creator of Rails (Ruby is not a part of Rails per se, but happens to be the ‘chosen’ language for it’s early development), made good in delivering the type of lightweight applications that made a commercial splash, and quickly. These attendees have tremendous respect for David Heinemeier Hansson of 37Signals.com. He has put back into the community by continually improving, evangelizing, and nurturing the Rails ethos.

So we start with respect for a visionary. One of the attendees grabbed me by the collar and sat me down at a Power book and then there was no stopping him and his girl friend from showing what Rails can do for my life. I was transfixed – but I’m easy to impress.

Am I the best person to give a technical lowdown on Rails? No. But I had to take a day, digest and re-read what I had seen at the event, which was impressive. Several of the attendees were stone cold C++ and C#/Java experts, and they were converted. One chap led me through an exercise that created a file sharing system and download service, with account management  - in 20 minutes, with explanations. That’s an agile environment.

As to what it actually is, well, let better minds decide. As to the impact, participation, and feel of a wider community – I can tell you without a shadow of doubt, that there is movement afoot here. www.slash7.com/articles/2005/01/24/really-getting-started-in-rails

“Rails means the end of XML files telling a story that has already been told in code. It means no compilation phase: Make a change, see it work. Meta-data is an implementation detail left for the framework to handle.” According to the gaggle, Rails came from the Design Patterns school of programming thought.

Rails is an MVC (Mode-View-Controller) framework that forces separation of presentation layer code from logic and metadata. That’s all I’m going to say about the technical side of Rails for now, but I intend to learn more about it and try and get a working knowledge of it in time.

Currently the important thing to bring home (or take away) is that the LAMPS community, the MySQL folks, are sold on ROR’s ability to completely abstract the SQL generation and need for repetitive code driven queries that they have been dealing with for years – and have become quite good at.

Ruby on Rails is becoming an industry with wide ranging participation from the LAMPs community. There is tremendous buy in from the book publishers, and a love for Rails that has even given birth to a full length illustrated comic book / tutorial (http://poignantguide.net/ruby/).

The Attitude

These were no punks and hackers – these were MIT CS grads and students late in the MSEE and MSCS Programs. There were also advanced amateurs, some were from Sloan School of Management, who were self-taught Rail Heads. They were also friendly, and went out of their way to ask me about my business and who I represented.

Now I’m just reporting as I heard it; it will do no good to correct or refute me on the following points.  While being very polite they pointed out that any product that pitched an Enterprise Integration POV was too heavy and expensive for the type of lightweight apps they