Tuesday, October 24, 2006

A long time ago Somewhere I have not been for a very long time is www.microsoft.com. I wonder what it is like there now? Is it still great? (The word that appears in more Microsoft sentences than any other). I was a Microsoft developer for many years (this feels like a confession - hi, my name is David and I'm a Microsoft-holic), then one day I just converted to Java, Eclipse & Co. Just like that, it was like flipping a switch. And I've never looked back. But now I'm wondering, while that company doesn't seem to be so important anymore, am I missing things I should not be? Have I closed my mind too much? Maybe its time to take a look at Visual Studio version whatever and do some comparisons with Eclipse. I never bothered learning C#, I already know it! :-) One thing Microsoft always did well were developer tools, and I'm hearing from a couple of friends who are still on the other side that they have some pretty slick stuff ... if you want to develop for the CLM (do they still call it that?) and .NOT, uh, I mean .NET. A long time ago Microsoft were a force to be reckoned with. Now you'd want to have your head examined to voluntarily choose the Microsoft platform for Enterprise development. Still, I wouldn't mind having a peak, if I can just free up enough space on my hard drive... 1:32:58 PM    comment []

Friday, September 22, 2006

Eclipse workbench in a browser? Has anyone ever thought about a hosted Eclipse concept, with the workbench being available in a browser? Would this be as simple as an implementation of SWT using AJAX techniques? Ok, its far from simple, but the AJAX front end would be firing events back to the SWT AJAX proxy and into the platform agnostic layer, and the UI changes would be sucked back out ... and hey, it would all just work! :-) 1:18:56 PM    comment []

Monday, September 11, 2006

A vote for IStorageEditorInput Now that Eclipse editors are reaching out beyond the confines of the workspace more and more (with pluggable file systems and files that can link to resources at remote locations e.g. HTTP accessible resources), editors that expect to be working with files should be coded to support IStorageEditorInput, and not just IFileEditorInput. All too often when developing editors the assumption is made that the editor is dealing with a local resource, and worse, often casts are made to IFileEditorInput. Remember that an editor is a viewer before it is anything else, a lot of the time the purpose of opening a file in its editor is purely to browse its contents. In fact, probably more than half of the time, when a file is opened in a editor, it is never updated, it is only read. IStorageEditorInput is the super interface of IFileEditorInput, and its API contract states: File-oriented editors should support this as a valid input type, and display its content for viewing (but not allow modification). So if you are not supporting IStorageEditorInput properly, you are potentially failing to support a large number of use cases. 3:41:21 PM    comment []

Friday, August 18, 2006

Refactoring SOA Artifacts - Part 1 One of the key features that first hooked me on Eclipse was its (Java) refactoring capabilities. Refactoring is an indispensable tool in the Java code jockeys toolbox, and Eclipse makes it easy. The Eclipse Language Toolkit (LTK) provides a framework within which to build refactorings. As we move into the realm of service-oriented programming, developing services that can be deployed on Enterprise Service Buses, I'd like to see the same level of refactoring available for SOA artifacts. By SOA artifacts I mean things like WSDL, BPEL, deployment descriptors, as well as Java classes and other language files. At the detail level, the relationships between these artifacts can be complex. With WSDL described services, when the WSDL changes some refactoring often happens automatically i.e. tooling can regenerate the proxy code for a service when the WSDL describing the service changes. But beyond this kind of thing, more sophisticated refactoring is required. In fact, whether this refactoring is done explicitly by the user, or implicitly by the tooling reacting to changes in WSDL and automatically altering other artifacts, much of what needs to be done is the same. The use case I'm starting with is a simple one. A BPEL script implements a service defined using WSDL. The BPEL script invokes another service also defined in WSDL. It should be possible to rename a portType operation by highlighting the operation in the WTP WSDL Editor in Eclipse, right clicking and choosing Refactor | Rename. I'm considering both the cases of the service implemented and the service invoked. It is worth noting that the WSDL editor in Eclipse 3.2 provides a basic rename refactoring feature, but to date I think its pretty limited. The LTK provides a high level framework for refactoring, within which I'm going to put the framework for SOA artifact refactoring. The basic steps are something like this: Identify the refactoring the user wishes to perform e.g. renaming a WSDL portType operation. Find all the projects and artifacts in the workspace that should be changed. Perform the initial sanity check. Ask the user for more information if necessary. Calculate the changes required to each artifact. Check that each artifact will still be valid after the changes. Present the changes to the user for acceptance or alteration. Commit the changes. Lets have a look at a snippet from a really simple WSDL file, HelloWorld.wsdl, that shows an operation called sayHello: <wsdl:portType name="HelloWorld">   <wsdl:operation name="sayHello">     <wsdl:input  message="tns:sayHelloRequest"/>     <wsdl:output message="tns:sayHelloResponse"/>   </wsdl:operation> </wsdl:portType> Lets suppose this WSDL operation has a SOAP binding. The operation name also appears in the binding and in the soapAction attribute in the binding: <wsdl:binding name="HelloWorldBinding" type="tns:HelloWorld">   <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>   <wsdl:operation name="sayHello">     <soap:operation soapAction="cc:HelloWorldService:HelloWorld#sayHello"/>     ...   </wsdl:operation> </wsdl:binding> As in the example, by convention message names often follow the form: Request, Response. It would be great if the user could choose to also rename these as an optional part of renaming the operation name. One of the Eclipse plugins I'm going to develop will house the framework core. The implementations of the various parts of the framework can be contributed via extension points. Lets consider the problem of finding all the relevant artifacts and the projects that house them across the Eclipse workspace. While this first use case considers just WSDL and BPEL, the search-for-artifacts step, at a high level, is general enough. The job of the Artifact Finders is to find projects and their artifacts that require changing in response to the operation rename. Consider the case where the HelloWorld.wsdl file lives in one project, some projects have a link to it and others have a copy of it. The projects with a link to it are easy enough to find. Any projects that contain a file called HelloWorld.wsdl are also candidates, but just because one WSDL file has the same name as another does not mean they represent the same service, or the same version of the service. A trickier case again is where the WSDL file is indirectly referenced e.g. it is imported by another WSDL file, or referenced in a descriptor file. For these latter cases we may require some deep searching, which could be time consuming, so we need to bear that in mind. Artifact Finders are one element of the framework. The Artifact Finder interface will look something like this: public interface IArtifactFinder { public RefactoringParticipant[] findArtifacts(SOAArtifactRefactoringArguments args); } And the extension point is defined like this: <extension point="org.codecurl.soa.refactor.finders">     <artifact-finder     id="foo.id"     name="Foo Refactor BPEL Artifact Finder"     class="org.codecurl.soa.refactor.finders.FooFinderImpl"/>   </extension> Lets look next at the changes required to the BPEL script, considering first the case where the BPEL service implements the interface defined by the HelloWorld.wsdl file. The variable definitions for the input and output messages may need be to changed (if the user has chosen to also rename the input and output message types): <bpws:variable name="sayHelloRequest" messageType="ns:sayHelloRequest"/> <bpws:variable name="sayHelloResponse" messageType="ns:sayHelloResponse"/> For consistency, we should allow the user to rename the variables too if the message type names are changing. The receive starts the process: <bpws:receive partnerLink="HelloWorld" portType="ns:HelloWorld"    operation="sayHello" variable="sayHelloRequest"    createInstance="yes"> </bpws:receive> So the operation name is changing and maybe also the variable name. And the process ends with a reply: <bpws:reply partnerLink="HelloWorld" portType="ns:HelloWorld"    operation="sayHello" variable="sayHelloResponse"> </bpws:reply> Again, the operation name and possibly the variable name will change. In the case where the BPEL process is invoking the HelloWorld service, we need to consider the invoke element. The operation name attribute value will change, and the inputVariable and outputVariable attribute values may change: <bpws:invoke partnerLink="HelloWorld" portType="ns:HelloWorld"    operation="sayHello" inputVariable="sayHelloRequest"    outputVariable="sayHelloResponse"> </bpws:invoke> We need to set up the invoke call by populating the sayHelloRequest message, so we should look for assign elements that use the variables: <bpws:assign>    <bpws:copy>      <bpws:from><xs:string>Bob</xs:string></bpws:from>      <bpws:to variable="sayHelloRequest"/>    </bpws:copy> </bpws:assign> Callbacks (onMessage) also need to be considered. One of things I want is APIs for refactoring the various models (WSDL, BPEL, whatever). I like to start with a "perfect" API for something like this, and then implement that with off the shelf components (like WSDL4J) and whatever additional code is required. Once I have the framework plugin working for this simple example, I will look at contributing to the appropriate Eclipse project/area. Maybe the SOA Tools Platform and/or the LTK. 8:29:26 AM    comment []

Sunday, June 11, 2006

CodeGrabbit Plugin There are a lot of blogs out there with a lot of useful stuff - code snippets, hints and tips, mini-tutorials and howtos on this open source component and that tool. Wouldn't it be great if, having come across a useful code snippet or component related howto, there was a way to insert the necessary bits directly into the Eclipse project you're working on. These bits might include Java classes, the latest jars for a component etc. I'm imagining a plugin that could set all these artifacts up in the selected project, including making appropriate changes to the build properties and whatever, and some sort of server side descriptor that describes the artifacts in question and where to get them. So the blog entry would have a link to the descriptor. The only issue I see with this might be security, I guess some bad folks might put malicious components out there and create tempting blog entries to entice hapless programmers to download, build and run the latest whatever, but then steal their credit card details or something. This could probably be overcome with the usual trust/signing mechanisms - but that might be a bit too expensive/inconvenient for publishers. Not sure what the answer to this is, but I reckon this would be a great help for folks. So I suppose this is kind of a distributed, expert exchange, remote assist, write my code for me stylie thing :) If you think this is a good idea, let me know, and maybe we can start a project to build this. 10:54:28 AM    comment []

Sunday, April 23, 2006

Farewell PaceMetrics In a few days time I'm finishing up at PaceMetrics, the company I've been with for the last three years. Leaving Pace was a tough enough decision for me. I joined on an up curve just as the company was starting to build its fourth generation BAM (Business Activity Monitor), and winning a huge deal with a tier one investment bank. To deliver that project and productise it, I was lucky enough to quickly assemble one of the best software development teams I've ever had. This team was world class, all experienced, seasoned, innovative, agile engineers. We had a really stellar project manager and business architect in Colm Toolan, and a super professional services team, and the result was PaceMaker 4: - fully Java, J2EE (POJOs of course!) and JMS based, leveraging best-of-breed open source components and tools - loosely coupled components communicating asynchronously using XML-based messagess - a simple maven based build - a super-scalable, fully reliable, and architecturally innovative BAM engine - thanks James :-) - a scalable web front end built on some pretty cool caching technology - enterprise ready monitoring and management through JMX from our own custom web based admin console - Eclipse based tooling (courtesy of yours truely) Its been a great few years, but in the end I've been tempted away by the shimmering lights of SOA and ESBs. I'll post more on that in a couple of days. 5:43:52 PM    comment []

Friday, September 23, 2005

Mylar and the Way of the Task If you're an Eclipse jockey and you have lots of different tasks on the go at the same time like me, especially if they span multiple projects, you may well need some special mylar care and attention. Mylar is a cool new Eclipse project that monitors your interaction with Eclipse creating a context specific to the current task. Switching from task A to task B closes everything for A and reopens all the stuff you were using for B. There are a bunch of other features like color coordinated task items. Mylar is a work in progress right now - the current 0.4 release seems to have made my rename refactoring very slow and broken a few other things, so its probably a bit early for most people. Could be great though. 11:01:50 AM    comment []

Monday, September 19, 2005

Seeing the light behind Eclipse Tools are a vital part of our lives. One of the tenants of good bush craft is build the tool first, then use it to do the work. Most outstanding enterprise software products feature outstanding tools. I'm a big fan of good tooling, and a particular fan of Eclipse. If you are considering developing tools for the enterprise space look first at Eclipse. You would really need to have a very strong reason not to build on Eclipse - leveraging the various sub-projects and the tooling that is already out there should enable you to build functionally impressive and slick looking enterprise tools fast. Unless you are doing "end user" style browser based tools, Eclipse is the business. I find it astonishing that it took Borland so long to drop their own IDE platform in favour of Eclipse - as a Java developer I dropped JBuilder years ago, Swing was (and despite its advances really still is) too clunky on the Windows desktop. And look at BEA and BEA Workshop, they put a lot of effort into their own IDE framework, and it blew up in their faces. When Weblogic 8.0 launched the Eclipse juggernaut was already unstoppable. BEA had to rethink and back Eclipse. Just recently they bought M7 of NitroX studio fame. It is a pity those good folks over at JetBrains keep putting effort into their tooling platform - if they could just take the best out of IntelliJ IDEA, marry it with Eclipse, and switch all that talent to higher level value add, now that would be something. What can I say about Sun and NetBeans? If only Sun could get past that name, and do a little embrace and extend. Actually, I think Sun is a great company and you don't need me to tell you there is engineering talent to burn there, but sometimes that talent is misguided. But who knows, if NetBeans is the only competition left for Eclipse, then maybe its a good thing. Competition breeds innovation, and Eclipsers need to keep innovating. Thankfully the healthy development community involved with Eclipse, its subprojects etc., are showing every sign of doing so. One of the things I love about Eclipse - apart from all the (growing list of) tooling goodies you can reuse and extend - is SWT. In fact I'm a total convert to SWT - I would rarely now choose Swing over it for rich client applications. Eclipse is one of those things - like Java, JavaEE (well, in some form anyway) and XML - that will most probably span many computing generations. 7:52:46 PM    comment []

© Copyright 2006 David Black. Last update: 10/24/2006; 1:33:00 PM. This theme is based on the SoundWaves (blue) Manila theme.