The industry's best kept secret?

From Ganesh's blog:

WSO2 Mashup Server seems to be the industry's best-kept secret for now.

The last release of the year

As I hinted yesterday, here is the WSO2 Registry 0.1 release. We know we have plenty to do, but we think this release is enough for you to take a look, start commenting, give us some feedback on the approach, and generally kick some early tyres.

Merry Christmas!

----------------------------------------------------------------------

The WSO2 Registry team is pleased to announce the 0.1 release of the
WSO2 Registry.

The release artifacts can be downloaded from:
http://wso2.org/downloads/registry

WSO2 Registry 0.1 - Release Note - 21st December 2007
======================================================================

WSO2 Registry enables you to store, catalog, index and manage your
enterprise meta data
in a simple, scalable and easy-to-use model. It is designed around
community concepts
such as tags, comments, ratings, users and roles. Think of the registry
as a structured wiki
designed to help you manage your meta-data in a simple business-friendly
system.

In addition, the registry allows you to store more unstructured data
such as Word documents,
Excel spreadsheets and text formats. Using these approaches, you can
build a catalog
of enterprise information ranging from services, service descriptions to
employee data and on going projects.

WSO2 Registry can be deployed in Application Servers and access using
the Web UI or the APP interface.
It can also be used as a Java library inside other Java programs as a
resource store with all
community features and versioning.

Christmas presents from WSO2

Its a busy time of year for everyone, getting ready for Christmas, and here at WSO2 its even busier as we roll out new releases of software just in time for the holidays!

We just released the Identity Server 1.0, and keep your eyes peeled for a Registry release, but what I think you might really want to unwrap this Christmas is the Mashup Server 1.0 beta.

So what is the Mashup Server? Basically its a simple and easy to use system for pulling together feeds, web pages, Web Services (both SOAP and REST), and whatever other data you have out there into re-usable Mashups. How do you do it? You simply have to pull together a little JavaScript and deploy it.

The mashups can expose themselves as Atom feeds, or send IMs or emails. You can build simple Ajax UIs too. And the whole thing has a dead-simple, beautiful, and productive Web UI.

We've got some great examples - for example TomatoTube which takes the top 10 movies from RottenTomatoes and mashes it up with YouTube to give you a feed of the trailers.

But don't take my word for it! You don't even need to download it - try it out live here.

And have a Merry Mashed-Up Christmas!

Stirring up the ESB honey pot

My article on ESB seems to have kicked off some discussion:

• Todd Biske pointing out he said much the same thing long ago (nice posts btw)
• Lorraine Lawson - Defining ESB - why it matters
• Joe McKendrick - To ESB or not to ESB that is the question
• and TheServerSide

I've also had some private mail saying I misrepresented JBI - I'm hoping that person will comment more publicly too - they made some interesting points that deserve a wider hearing.

Another great blog post from Ganesh

You've got to read this! http://wisdomofganesh.blogspot.com/2007/12/paying-restafarians-back-in-their-own.html

The "enthusiastic support and blistering pace of WSO2 development"

From Ganesh Prasad's blog entry:

Speaking of the WSO2 Mashup Server, those folk over at the community site virtually fall over each other to help newbies. I knew that Open Source communities were friendly, but these guys are something else. Thanks for all your help, Keith and Jonathan. I'm in shock and awe both at your enthusiastic support and the blistering pace of WSO2 development in general.

Extending the WSO2 ESB

Yesterday I presented a webinar on how to extend the WSO2 ESB. Because our ESB is so closely based on the Apache Synapse project most of the guidance also applies to that project. The slides are available here.

In addition, Upul has just published two excellent articles about writing Tasks and Mediators for the ESB and Synapse.

The next webinar is all about using WSO2 Data Services to extend databases into the SOA, increasing security and making data access more realtime.

SOA and Unix Pipelines

One of the most successful patterns of re-use in computer science is the Unix Pipeline. Invented by Douglas McIlroy it uses the simple idea of a set of operations where one feeds into the other. This is a huge inspiration to many of us, and we stole and re-used the idea heavily when we built the Apache Synapse mediation model.

In fact, SOA is a remarkably similar endeavor when looked at from a high-level. Some people would view BPEL as the equivalent of a shell-script. But the fact remains that Web services - even REST and HTTP models - remain largely separate from shell-scripting. Of course WGET does allow some integration and is a fantastic tool - but in my experience even this kind of integration is still used in a tiny proportion of scripts.

In his blog, Samisa talks about a new utility to do web services interactions from the command line. Its completely written in C and it supports calling REST-style services as well as SOAP and WS-*. Take a look - this is a smart new addition to the Unix pipeline toolkit.

Reclaiming the ESB

I've written an article that talks about how the term ESB has been waylaid, hijacked and generally misused. I think this is an important point, because there its causing a backlash against ESBs - and fundamentally I think its based on an incorrect assumption of what an ESB is and should be. So in my opinion its time to reclaim the ESB as what it should be!

Read more here.

Making SOA Groovy and Coding for Synapse

A while back I did a talk at the Grails Exchange entitled Making SOA Groovy - about using dynamic languages and Groovy in particular to enhance your SOA. The video is on TheServerSide homepage and the slides are here [choose Save As in your browser].

I'm also giving a free webinar on extending Apache Synapse and the WSO2 ESB next week - you can find out more here.

A new kind of (SOA) Registry

For a while I've been thinking that the SOA registry space has been a little overcomplicated. The first problem is the inheritance of the UDDI initiative. UDDI has a number of significant problems, but the biggest problem is that it has skewed the collective view of what a SOA registry and repository should look like.

The second problem is the lack of a really nice, simple, successful open source initiative in this space. When I talk to customers, even hardened Open Source supporters, they tell me they are looking at proprietary systems such as HP/Systinet and Software AGs Infravio.

So we thought, lets look at this again. Our view on OSS is to start with what is really needed and work from there, maybe adding some extras here and there. So what is essential in an SOA registry:

• You need to be able to store and retrieve stuff, both with a remote API and with a Web browser. Of course its also nice to have a local embeddable Java API.
• You need to be able to search, categorize and catalogue the stuff - and wouldn't it be nice if you could also tag and comment on that stuff.
• Its essential that there is security, access control and versioning on every bit of stuff you put in there, so you know that this is a robust and trusted source of information.
• The system should track dependencies between items, and should be able to manage those dependencies as items are versioned - this is really important for SOA governance.
• There needs to be ways of importing, exporting and copying stuff, as well as managing the lifecycle - from sandbox to test to staging to production to deprecation.

You notice I called the things you store and search and read from the registry/repository "stuff". In the SOA case they are mainly XML documents (WSDLs, WS-Policies, etc) but they might also be Word or Excel documents. And in fact, fundamentally they are just resources.

So now let's look at this problem from the Resource Oriented perspective instead. Let's think about UDDI and where it went wrong - why do I need a SOAP call to update a resource, when a POST or PUT can do? At least UDDIv3 allows me to read resources using HTTP, but is there any reason to have any SOAP call to read a resource? And why do I need unique identifiers to be TModels when the humble URI/URL makes a perfectly good unique identifier?

So fundamentally the approach we have taken is to build a registry/repository based on REST concepts. And as we looked at the REST space, we kept noticing how close the Atom Publishing Protocol (APP) is to our needs, so we've made that the public remote API to access the repository. Of course, if you are just browsing the registry, you only need a browser - APP is mainly there to support updating resources.

Of course, using Atom and APP gives some really nice benefits too - like being able to subscribe a feed of new resources that meet your search criteria.

If you want to join in, you can subscribe to registry-dev, or you can download the code, have a play around and submit some JIRAs. Join the fun!