On Trojan Source...

Like me, Gord's product is also on the eve of its release. Oh, what a feeling! What a rush! The last time I felt like this wasn't all that long ago, actually. At the time, Ed blogged about how it felt like the end was nigh. Well, that end has since come and gone, and now everybody knows what Ed was really talking about. Personally, I think he should have entitled his farewell blog entry "So long, and thanks for all the FOSS".

Or is that FLOSS? The product I'm about to release is based on an open source platform that, believe it or not, isn't Eclipse (gasp). Their approach to open source, dubbed "professional open source", is somewhat... different from that of Eclipse. It seems ironic (at least to me) that a platform which boasts freedom from closed, proprietary software would switch to a more restrictive license mid-stream... it's almost like it was part of the grand plan all along.

So what does 'open source' really mean, then? According to the Open Source Initiative (OSI), which officially owns the definition, the distribution terms of open source software must comply with ten criteria. The OSI maintains a list of the open source licenses which have successfully gone through their approval process and comply with these criteria; both EPL and that other license are on it, as are many others. So what's the big deal? Just ask one of the customers or OEM partners who, if they want to adopt the next major version of said platform, may be forced to decide between releasing some of their software under the new open source license and purchasing a commercial license for the platform...

On Search Providers...

I mentioned that I spent a lot of my time recently on a deep dive into one of Embarcadero's products that's about to release in the coming weeks. I had planned on giving a "sneak peak" as to what it's all about, but it turns out that Greg beat me to it (thanks, Greg!).

Rather than repeat everything that Greg said, I'll focus on a lesser known aspect of one of the portal's main features. Despite the incredible value of its shared reports, explore dashboard, ad hoc query interface, and administration console, perhaps the most popular (and most scrutinized!) feature of the portal thus far has been its search capability.

One of the cool things (at least in my mind) about the search capability of the ER/Studio Enterprise Portal is that, like other Web-based search interfaces, it can be integrated into the search bar of your favorite browser. I'll walk through the steps to do this for Internet Explorer as an example.

1. Select the 'Find More Providers...' item from the search bar's drop-down menu.



This will take you to a Web page where can choose from among several exiting providers or create your own.

2. From a different browser window, type 'TEST' into the search box of the ER/Studio Enterprise Portal and hit .

This will take you to the Search Results page.



3. Copy and paste the URL from the Search Results page (the "&x=8&y=6" portion at the end isn't necessary), specify a name for the new search provider, and press the 'Install' button.



This will open a dialog asking you to confirm that you want to add the search provider (click 'Add Provider').



4. Choose the new search provider from the search bar's drop-down menu, type in your text, and away you go!



To avoid having to log into the portal each time you want to search, you can also add your user name and password to the URL before pressing the 'Install' button in step 3 above by appending, for example, the string "&userid=MyUserID&password=MyPassword".

On Status Quo...

What the heck is Blaugust, anyway? Well, it's what James has been calling the month of August lately in light of a little challenge we have going within the program management team here at Embarcadero (yes, another fest). blaugustFEST is a contest to see who can reach out to the community by blogging or commenting on a blog entry a minimum of twenty times during the month of August. So, keep your eyes peeled for some creative blogging by James, Gord, Wassim, and others... it could prove to be quite entertaining.

I don't mention Ian above because, alas, Ian has decided to move on to another pasture (I don't say greener since, as Ed often says, the grass on the other side only looks greener because you're looking at it from an angle). So, things aren't exactly status quo around here, for various reasons.

I'm glad. Not about Ian leaving, because we'll really miss him, but about things not being status quo. The problem with status quo is that it tends to stifle innovation. I get frustrated (and did just recently, in fact) when faced with a situation where "our users have come to expect that it works this way, and if we change it, we'll never hear the end of it". I'm sure many of you have been in the same boat. There's no doubt we'll be facing scenarios like that with e4.

There's this old story about a woman who always cut the ends off a roast before putting it into the oven. When asked why by one of her kids, she realized she didn't really know - her mother had always done it that way. The next time she saw her mother, she asked the same question, and her mother explained that she had to because she didn't have a large enough pan to fit a whole roast.

The real challenge, IMHO, is to face opposition in the name of progress. Sometimes we need to consider new, potentially better, ways of doing things. That's what innovation is all about, after all...

On Blaugust...

Not unlike John, it seems as though I dropped off the face of the planet(s) nearly three months ago. James has a great expression for this kind of phenomenon - "going dark". Well, I can assure you that while I have been dark in the blogosphere of late, I've been bright in other spheres.

So where have I been? So much has happened since my last entry, it's hard to remember it all...

• I participated in the e4 Summit in Ottawa. I know, old news, but now there's an actual proposal for the e4 project. What area will you be contributing to?

• I had a chance to meet with my CodeGear brethren in Scotts Valley for the first time, and I'm very excited about what we'll be able to accomplish now as a combined company. Stay tuned!

• I co-hosted the second of two Eclipse/OMG Symposia in Ottawa, and I'd venture to say that it was even more fruitful than the first!

• I played a part (as lead of the MDT project) in ensuring that Ganymede, in all its glory, was successfully released. w00t!

• I took a much needed vacation (they're never long enough!) - one week camping in New Brunswick and a second week at a chalet in Charlevoix. Oh, the stories...

• I helped orchestrate a summit for Embarcadero's Software Consultants in Toronto. What a great team!

• I did a deep-dive on one of my products that is about to release in the coming weeks.

I'll be taking time to blog about each of these activities (and others) in more detail over the next month because, as of today, it is Blaugust after all!

On Navigable Owned Ends...

OK, it’s time for me to get a little bit technical (and to try out JBuilder 2008) for a change. While working on the E/R metamodel as a member of the IMM submission team, I ran into an “interesting” scenario recently involving associations with one end type. Consider the class diagram below (the names have been changed to protect the innocent).


Can you see what’s wrong with this picture? The intent of the modeler was to express the fact that a bicycle has two wheels, one of which is the ‘front’ wheel (from the perspective of the rear) and one of which is the ‘rear’ wheel (from the perspective of the front). If you think about what an instance of this model might look like if it were mapped directly to classes and fields in a programming language like Java (using EMF, for example), you’ll realize that each instance of the 'BicycleWheel' class would need a reference to the bicycle’s other wheel, but also to itself – in order to satisfy the multiplicities (both association ends are required, i.e. they have a lower bound of 1), each wheel must reference both the front wheel and the rear wheel of the bicycle; obviously not a desirable result. In fact, it’s currently impossible to create a valid instance of this model using Java code generated by EMF, since an attempt to set a reference from the front wheel to itself (to satisfy the multiplicity) would result in its reference to the rear wheel being discarded.


What’s interesting (at least to a modeling geek like me) is that this redundancy could, in theory, be eliminated simply by making the association ends (the 'frontWheel' and 'rearWheel' properties) navigable owned ends. What does that mean? Well, in UML 2.x, it’s possible to designate a navigable association end as being owned either by the end type (as in the diagram above) or by the association itself. In the latter case, a mapping to Java would require a class to represent the association; now, in addition to there being an instance of the 'Bicycle' class and two instances of the 'BicycleWheel' class, there would be (at a minimum) an instance of the class representing the association which, in turn, would only need to reference each of the wheels once to satisfy the multiplicities. Ed and I have been giving some thought as to how owned association ends might be mapped to Java using EMF, but this special case makes me think that we still don’t have it quite right – see below.


I think there would still be an issue here with respect to navigability, because given a bicycle wheel, it's supposed to be possible to navigate to both the front wheel and the rear wheel (according to the model). Would this require redundant entries in the maps? What if a front wheel is passed as an argument to the 'getFrontWheel(BicycleWheel)' method? What if the owner of the bicycle rotates its wheels every season? I’m starting to wonder whether it should be considered valid at all to model a bidirectional association with required member ends and one end type. In the absence of an answer to that question and/or EMF support for mapping navigable owned ends to Java, there are a number of ways the model could be changed and still (or better) express the original intent. The model we ended up going with (or, rather, a reasonable facsimile thereof) is below. What might you have done differently?

On Change...

Embarcadero. It ain't just about databases anymore...

On the Efforts of the Few...

Dave has blogged a couple of times recently about his thoughts on standards development. As someone who is actively participating in the submission and revision of several specifications (some of which are standards) at the OMG, these comments certainly hit home. I agree that it’s typically 10% of the contributors that tend to do 90% of the work, and too often it seems that I’m among the “lucky” few...

One of the challenges of developing an OMG specification is the lack of tooling support for CMOF (Complete Meta Object Facility) models. This was one of the many topics that were discussed during the “Mega Modeling Mania” BoF (and again during the Eclipse/OMG Symposium) at EclipseCon in March. Based on those discussions, there does appear to be some demand for tooling that will make it easy to create, serialize (in CMOF-compliant XMI), and document metamodels that form the basis for open specifications. In response, I agreed to coordinate a proposal for a new component in the MDT project (tentatively dubbed “Metamodel Specification Tools”, or MST) to provide this kind of tooling at Eclipse.

The idea would be for the MST component to customize and/or extend the existing (or forthcoming) UML editors (primarily for class and package/profile diagrams) to expose CMOF concepts which are missing in UML (like identifiers, namespace URIs, and XMI tags), leverage the CMOF (de)serialization support that was introduced in the UML2 component as part of the Ganymede release, and provide a mechanism for generating a specification (or at least a decent boiler plate for one) directly from the metamodel using BIRT. Of course, it might also be desirable for the component to automate the mapping between a metamodel and its profile representation (if there is one) and possibly to make use of the Eclipse Process Framework (EPF) to document and coordinate the specification development process. If you’d be interested in contributing to such a component, I’d like to hear from you!