Brian O'Neill's Blog: Programming Archives

Software development techniques and processes are changing at ever faster rates as open collaboration development spreads globally (thanks to the adoption and promotion of open source software). As the systems we architect and implement become increasingly complex, the mechanisms, infrastructure and patterns with which we build the complex systems constantly improve to keep the problems tractable.

The Java Business Integration (JBI) specification and Service Component Architecture (SCA) are the latest additions to our tool set. Now, I'm a simple man, a caveman really. And for the last three years, I've been working to construct a multi-channel service oriented architecture for the federal government, with pluggable enterprise services (pub/sub, security/encryption, messaging, VoIP, etc.)

As you can imagine, this is a hard problem for a caveman to solve, especially when you layer in a complicated political landscape filled with software infrastructure vendors, and their professional services divisions. We needed an industry standard on which to hang our hat.

Now, most people would hang their hats on "Web Services". Those same people would probably define web services as WSDL + SOAP + HTTP + (UDDI). They would then proceed to convert all RMI, RPC, and potentially database communication into web services: then call that a SOA. Unfortunately, that only results in a rat's nest of invocations and derived dependencies that can bring down an entire enterprise. (we have the battle scars to prove it)

So, we evolved.

We realized that we needed a common communications backbone to unravel the mess. Enter Enterprise Service Bus (ESB) concepts, but again we were disappointed. We looked around for one of these new fangled ESBs, but all we found were re-applied messaging systems that required proprietary extensions to achieve a services layer. (and we knew enough to stay away from those, and the vendor lock-in that came with them)

SO, we looked long and hard at the writing on the (cave) wall; and found a promising acronym: JBI. We set about downloading JBI implementations. Immediately, we were hooked. JBI provided a standard interface through which we could deliver our enterprise service "lollipops". Literally, we could drop our lollipops into existing JBI containers, rewire the connections and provide service consumers and producers with security, compression, discovery and other capabilities. Wow, nirvana.

In fact, as cavemen - we were more productive than ever. We could develop applications without writing a single line of code. Applications development became a matter of drawing pretty pictures. Using a palette of components, and drawing lines between them, in minutes we could create new convergent capabilities - e.g. take messages from XMPP, and post them to RSS feeds.

But alas, nothing gold can stay. The political landscape shifted, and SCA came down from the heavens like a meteor crashing into the earth. We ran for cover, trying to figure out how SCA fit into our new world view. What we had heard about SCA was promising, but we had trouble putting our fingers on it. SCA seemed like a great language with which to communicate with other cave people, a common way to describe what we were building, and compose larger services from smaller, recursively. This was much needed, and completely complimentary to our new found love - JBI. As cavemen, we couldn't see where SCA dictated a run-time, but we didn't need it to. We had JBI already.

Us cavemen proceeded forward with a new world understanding - determined to build a bridge demonstrating an SCA composite application, running in a JBI runtime.

You can follow along at jBIZint .

Source Equity: Making Open Technology Development Profitable

Posted by boneill42 on December 13, 2006 at 02:49 AM | Permalink | Comments (2)

Increasingly companies are incorporating open communities into their software development strategy. This allows companies to capitalize on expertise and innovation beyond their enterprise boundaries.

This works well for markets that can easily attract development communities with cutting edge technology or a sexy problem domain. People are willing to donate time just to get exposure or to learn something new, but how do we expand open technology development into other markets?

Additionally, in a world where software development is becoming a commodity, how do we ensure that the contributors delivering the value are rewarded appropriately? In an open development model where enterprises are leveraging external "free labor" forces, it is in the enterprise's best interests to maintain a stable community and to motivate that community in a direction that aligns with their corporate goals.

Thus,
What if we began treating software development projects like traditional enterprise ventures? Using standard agile methodologies, equity could be assigned to user stories based on relative customer value. As contributors complete user stories, new shares are authorized and granted to those contributors. Then, revenue could be shared with the development community. Contributors would receive a share of the revenue based on their equity holdings.

A model like this would allow non-traditional markets to avail themselves of the open-technology and open-source development communities. Also, since equity distribution is based only on the delivery of customer value (vice vesting periods), the model provides a low-risk open development model for startups, Startups that couldn't otherwise fund staff, can leverage a much broader community that could share the risk (and consequently the reward) of the venture.
I've been working this concept for a few years now, trying to evolve the specifics. You can check out the fruits of my labor here: Source Equity

Although they are more focused on the "idea farming" phase, a similar concept is being worked by http://www.cambrianhouse.com/.

I believe this model has other interesting characteristics when you consider the "right to fork", corporate teaming arrangements and work-share, and even applications of the model within enterprises (bonuses based on contributions, etc.); But i'll leave those comments for later blogs. =)

If you are interested in getting involved, please drop me a note:
bone@alumni.brown.edu

All comments are welcome.

A Communications Services Framework to fuel IP telephony deployment?

Posted by boneill42 on November 12, 2003 at 06:58 AM | Permalink | Comments (10)

I've started the snowball rolling for a Communications Services Framework. (CSF)

IP telephony deployment has been slowed by some major hurdles, and we have yet to see the "enhanced services" that will really drive the market. I think a web services environment, hosted on Java.Net, through which enhanced communication capabilities could be delivered, combined with a client side API that allows developers to take advantage of these capabilities could solve the problems found in current IP telephony deployments and provide impetus for migration.

One of the first problems I'd like to tackle with the CSF is that of identity. Currently, there is no way to automagically discover a persons contact addresses given one of the set; SIP address, phone numbers, email address, AOL screenname, etc.

This causes many problems. If I am on a SIP phone, dialing a phone number, it will go out through a gateway to the publicly switched telephone network (PSTN). If the person I was dialing happened to be available via SIP as well, the phone call will still travel out to the PSTN, and back in through another gateway because there is no way to discover that the person I was trying to call is available via IP. There is no way to keep from traversing the PSTN. How inefficient? This needs to be remedied.

What if there were a web service, an Aggregate Directory Service (ADS), that given a users contact address, phone number for example, would return the set of contact addresses via which that user is available? It would solve the problem. A SIP Proxy Server could then utilize this web service to determine if it can keep the call on the IP network, before blindly passing it to the gateway. How beautiful? Lets build it.

Because this is not the only such service required by these next-generation communications networks, it makes sense to house the ADS in a larger more general framework. This is the Communications Services Framework.

Bingo. we have a plan. I just started working on the complete specification for the CSF and the Aggregate Directory Service. If you would ike to get involved PLEASE contact me.

Powered by
Movable Type 3.01D

java.net RSS Feeds