Brandon Werner

Archive for the ‘Eclipse Modeling Framework’ Category

Service Data Objects Architecture: Business Objects with Smarts Presentation

Thursday, April 17th, 2008

This is a presentation I created to describe how SDOs can be used in the Insurance enterprise space to provide sanity in the large and diverse messages. These are increasingly being passed around as Business Objects in a Domain architecture as companies move their old object patterns to a service based approach (I refer to it as servitized business objects).

If you are looking for my particular experience on how SDOs and the IBM EMF framework that contains them works against the large ACORD schema, you can find my critique of Websphere Process Server and ACORD here and the SDO design pattern plugin I wrote for Rational Software Architect here.

You can download the slideshow here.

Apache Is SOA Ready

Monday, September 10th, 2007

You have to be impressed with Apache’s strategy and execution. Although many enterprise companies have stumbled or confused customers with their numerous SOA offerings in the marketplace, Apache has, behind the scenes, been dutifully executing on the core standards (WS-BPEL 2.0, SDO specification 2.1, SCA specification 1.0) that make up a SOA and plugging them neatly in to an overall stack. All of this has been accomplished while also removing any hype or marketing and focusing squarely on the technology and it’s usefulness. It’s hard to imagine SOA would gain any great credibility beyond vendor brochures if it wasn’t for Apache’s volunteers showing that.. yes.. there is real technology underneath the rhetoric.

This stack can be viewed in Apache Tuscany, which brings the SDO and SCA specification to us in vendor neutral Java or C++ and Apache ODE (Orchestration Director Engine) which uses WS-BPEL to execute business processes in an SOA similar to IBM’s Websphere Process Server, which I’ve written about here and here. I’ve done work with the Tuscany, including implementing it and managing it’s deployment. Aside from some problems with Websphere (Tuscany uses the EMF libraries from IBM’s Eclipse and Websphere products, so some library version clashes occur in deployment) I can say that it works as advertised and can handle a decent load.

If you couple this with Eclipse’s community contribution on the visual side, with a graphical BPEL editor and the SOA Tools Project, and you have a stack that rivals millions of dollars in IBM license fees for Websphere Process Server and Websphere Integration Developer IDE. Of course, all of these tools don’t come with support and are sure to need some hacking. Regardless, the future is bright for any size company wanting to leverage the best enterprise technology in an open and free development environment.

PHP On Rails?

Friday, August 24th, 2007

One of the new technologies I’ve been playing around with has been Project Zero from IBM. Before everyone gets too excited this software is not free; at least not in any way normally understood by the development community. Although the source code is available, IBM takes some time to explain what it’s use of the term “Community Driven Development” means, but it boils down to this: “this is something we’re going to charge for and we’d just like you to help out for free, please.”

From the About Project Zero page:

We are still building commercial software here, as the licensing makes clear, but we are doing it in a more transparent fashion. This transparency provides a way for you to influence the project much earlier in its lifecycle. It also serves a role in our notions of radical simplicity. Every discussion, every technology decision, the full history of this technology will be accessible, searchable, preserved on this site. That means that finding answers to your questions will never be more than a search away. Development means that this community is about the technology and how it is developed and evolves. This is not a product community. It is not the place for the finished item, but rather the lab where it will grow.

You could be angry with that, and it certainly leaves a bad taste in my mouth. IBM has had a lot of success moving technologies to the open source community, and they have received nothing but benefit as a result. IBM would not have the mindshare of enterprise developers it does today if it had not allowed Eclipse to grow openly and organically.

It has also had success including “torjan horse” frameworks in to Eclipse such as UML2 and EMF, which only see their real fruition in their pricey enterprise products for Rational, Websphere and to a lesser extent Lotus. If you want to see the true power and future of Eclipse as an IDE, you should look at what IBM is doing with their paid products. However, IBM has always been good at folding yesterday’s Rational release back in to Eclipse. For instance, Rational Application Developer 6’s amazing WSDL and Webservice editor tools has found it’s way in to Eclipse Europa as a direct copy, and you can find some XML editor features moving over as well. This is a win/win scenario that promises to keep both developers and IBM happy for a long time to come.

Yet it seems here that IBM has tried to redefine “community driven development” as giving software to developers to create buzz and get free development work from excited community members, and then shove them off like a birthing husk and sell it to large consumers for more than your yearly salary. If I found myself in a community like this, I’d move.

If you choose not to move any farther in to IBM’s work here, it would be understandable, but you’d be missing out on some incredible work. Why not just take a peak?

Project Zero: PHP with REST/AJAX

Project Zero is essentially a Groovy/PHP/Restlet/AJAX framework that tries the “batteries included” approach that Ruby on Rails has with it’s application framework. To be sure, there is a lot that a Ruby or SpringMVC developer will be familiar with when playing with Project Zero, especially it’s Restlet/MVC patterns and it’s scaffolding separated in to an /app, /config and /public directories. You can use Project Zero from the command line, but the real productivity gains are found in using the Eclipse plug-ins. You can program in either Java or PHP as nicely illustrated in the downloads page.

Comparison Between Ruby and Project Zero File Layouts

There are a lot of Restlet/MVC frameworks for Java, which is why I choose to focus on the inclusion of PHP. Simply put, it’s the fastest way for a PHP developer who feels the AJAX/Restlet/Ruby world has pulled away from them to get back in the game building quick and powerful AJAX/Restlet applications. This is all accomplished by the use of the Eclipse PDT project, currently in incubation, which allows for PHP development inside the Eclipse IDE. Project Zero uses this framework to give users right-mouse click control over their entire application.

It also uses Dojo as the JavaScript framework for AJAX. Why this was chosen over others I have no idea other than it’s robust support of file IO and other nice things DHTML doesn’t give you. Dojo has a pretty good following and shouldn’t cause any restrictions on what you can do within your application, although the version included with Project Zero is 0.4.3, which means you won’t get any of the goodness Dojo 0.9 gives you as demonstrated by the cool Mac OSX inspired Fish Eye demo.

Dependency Selection in Project Zero

There are many other libraries that you can use with Project Zero to build a robust application, assuming you’re using Apache Derby, that is. Sadly, although the software libraries in the repository are still in development, there isn’t a lot of juice in the batteries. Further, you can only deploy your PHP / AJAX applications if you have Project Zero installed on your remote environment and running. This means that those host providers who provide simple PHP and php.ini support will not run Project Zero applications you develop.

PHP being RESTful easily

Just like with Ruby on Rails, Project Zero maps RESTful resources to controllers based on names to speed development and reduce resource mapping. Therefore, the RESTful URL: /resources/people calls a people.php file in /app/resources/ that contain the following methods:


People:onList()
People::onCreate()
People::onPutCollection()
People::onDeleteCollection()

and individual resources can be specified as /resources/people/001 (e.g. id= 001 of a person in a people database) which have these methods in the same people.php file:


People::onRetrieve()
People::onUpdate()
People::onPostMember()
People::onDelete()

This makes programming in a RESTful way in PHP as easy as it is in Ruby, but without the language barrier.

JSON in PHP

Much in the same way that the SpringMVC framework uses HttpServlet to pass information back and forth to the calling application, Project Zero prefers to use JSON. This approach is nice since JSON has got a lot of traction lately from AJAX users who don’t want to wait for large XML documents to be sent across the wire. Project Zero exposes an API for PHP that maps roughly to the same HTTPServletRequest/HTTPServletResponse that SpringMVC and Struts uses, called json_encode and json_decode.

Getting data from the POST through JSON is easy enough:

$employee = json_decode($HTTP_RAW_POST_DATA);
$sql = "SELECT * FROM employees WHERE employeeid = ".$employee['id'];

and writing data in JSON is easy as well:

indexedArray = array("a", "b", "c");
$result = json_encode($indexedArray);
echo "Indexed array = " . $result . "
“;

Yet, this method of writing data leaves a lot to be desired. It would be nice if we could forward JSON data and then redirect to a RESTful view, the same way many other frameworks (Ruby on Rails, SpringMVC) does. It turns out you can do this using what Project Zero calls Response Rendering, which is a pattern of APIs to do just that.

In PHP this would be:

$customer = array('name' => 'John Smith');
put('/request/view', 'JSON');
put('/request/json/output', $customer);
render_view();

Wrap-Up

When you think about it, it’s pretty amazing that PHP has been given this much functionality from a product out of IBM’s research. The question on my mind is if PHP even deserves it. Although many websites leverage PHP on the front end, it has always had a mixed history when it comes to separating presentation from the code itself, and is usually re-factored away as an application grows. Further, with Sun and others focusing so heavily on migrating Ruby to the JVM, it makes you wonder why IBM would choose to pick PHP as another language to do web 2.0 in. Remember, IBM made it clear from the above talk about “community development” that they plan on making this a commercial product, so it seems they have settled on Groovy and PHP to be their torch carriers with Project Zero. For PHP developers, they have been given a very powerful toolset. Shame they can’t use it until IBM decides to sell it to them.

My advice? Although large applications such as Wordpress and Facebook use it, for new development PHP’s time has passed. You are better off moving to a Ruby or Java web framework.

Eclipse Modeling Framework Examination and that mean Websphere Error.

Thursday, April 19th, 2007

The Eclipse Modeling Framework (EMF) is one of the least understood and most powerful frameworks ever handed down to us mortals by IBM. Often confused with providing UML modeling capability in Eclipse and the Rational toolset (that’s actually the UML2 Framework) EMF concerns models in the meta-data sense, and is, in essence, an abstraction engine for data and code. The fact that Service Data Objects (SDOs), one of the two frameworks of the holy SOA stack (SDO/SCA), is built on top of EMF points to it’s power.

Sadly, most of us often encounter EMF only as some tool failure where we get an .Ecore error or some other nasty issue, and we usually reverse tracks instead of digging in to the mysterious innards of Eclipse. It was in this scenario I discovered a problem with EMF and Websphere, and I’m certain from the message board posts it’s gonna get a whole lot worse before it gets better. Luckily, there is a simple way around it.

The EMF Error

If you do any deployment on Websphere 5.x and higher, particularly it seems now that version 7 of the IBM Rational Platform is out, and use EMF either in SDOs or other parsing technologies, you’re going to run in to this error:


java.lang.IllegalArgumentException: resolve against non-hierarchical or relative base
at org.eclipse.emf.common.util.URI.resolve(URI.java:1853)

This is all the information you get, and it can be maddening. I was forced to face this error recently when trying to load in a xsd file in to an SDO from a relative URL. You can duplicate this problem by running the code below:

public class Test1 {

private static final String PO_MODEL = "po.xsd";
private static final String PO_XML = "po.xml";

private static void definePOTypes() throws Exception {
FileInputStream fis = new FileInputStream(PO_MODEL);
XSDHelper.INSTANCE.define(fis, null); // In Websphere container this will fail
fis.close();
}
}

public static void main(String[] args) throws Exception {
definePOTypes();


FileInputStream fis = new FileOutputStream(PO_XML);
XMLDocumentImpl xmlDoc = XMLHelper.INSTANCE.load(fis);
DataObject purchaseOrder = xmlDoc.getRootObject();

Of particular interest is this line here:


XSDHelper.INSTANCE.define(fis, null); // In Websphere container this will fail

Explanation Of Error And How EMF Determines Runtime Hierarchies

This XSDHelper simply takes an XSD (either String or stream) and prepares the SDO. In essence, the XSD gets parsed so that the SDO can apply the XML or any other data it gets to the XSD for Type validation. This XSDHelper is just a wrapper around EMF, which takes the XSD and begins to fit it in to a meta-model that Java can deal with. What is interesting is what EMF does under the covers, and for this we need to know about the URI class in EMF, and in particular the resolve method.

Recall the class we got the error from:


at org.eclipse.emf.common.util.URI.resolve(URI.java:1853)

The URI class in EMF is simply a representation of a Uniform Resource Identifier (URI), as specified by RFC 2396, with certain enhancements. Like String, URI is an immutable class; a URI instance offers several by-value methods that return a new URI object based on its current state. Most useful, a relative URI can be resolved (that’s the resolve() method in the error we got) against a base absolute URI — the latter typically identifies the document in which the former appears.

It’s finding this absolute base URI that EMF is having the problem with when it says “resolve against non-hierarchical or relative base”. Why does it always want to resolve a base absolute URI? Think of the situation poor EMF is in when it gets a relative URI. What if your XSD refers to other XSDs (po-folk.xsd)? What if it specifies other relative links in relation to it’s own place in an heirarchy(../po-folk.xsd)? EMF can’t deal with that unless it knows exacly where it is in your filesystem or URI landscape.

EMF And Websphere

So, now we know how that works, but what’s wrong with getting the absolute base URI in Websphere?

Well, let’s talk about those “certain enhancements” IBM mentions when talking about the URI class. Even though you probably don’t think about it, almost everything you access in a Java runtime is some kind of archive, no matter if it’s Jar or Zip. Even if you don’t think your working inside a JAR, if you’re running an IDE chances are you are. One enhancement in the URI class of EMF provides support for the hierarchical form used for files within archives, such as the JAR scheme. By default, this support is enabled for absolute URIs with scheme equal to “jar”, “zip”, or “archive” (ignoring case), and is implemented by a hierarchical URI, whose authority includes the entire URI of the archive, up to and including the ! character.

If we would ask EMF for the absolute base URI of the po.xml file in a typical Java application, we would see this:


jar:file:/C:/workspace/test/xsd.resources.jar!/org/eclipse/xsd/po.xsd

This is the URI, with the absolute base URI being “jar:file:/C:”. EMF would be confident all things could be found in relation to this root location.

Now, what happens if we do the same thing in Websphere?


wsjar:file:/C:/workspace/test/xsd.resources.jar!/org/eclipse/xsd/po.xsd

What’s that? A non-standard archive scheme called “wsjar”?. It would appear that IBM, never content with being standard, has an archive scheme that is completely different from one if you were to access a Jar file from outside the container.

What happens when EMF tries to get an absolute base URI when it doesn’t know the archive scheme of the file it’s looking it up for?


java.lang.IllegalArgumentException: resolve against non-hierarchical or relative base
at org.eclipse.emf.common.util.URI.resolve(URI.java:1853)

How To Fix It

Now we know what we’re dealing with. How do we fix it?

Well, all we need to do is let EMF know there is another archive scheme it needs to keep an eye out for, and you can do that two ways.

At the command line:


-Dorg.eclipse.emf.common.util.URI.archiveSchemes="wsjar wszip jar zip"

Or set it up in your WAS configuration as a JVM property.

I hope you learned something interesting about absolute base URIs and stumbled upon this article before you shed too many tears. I don’t know why more people are experiencing this problem with WAS and Rational Application Developer / Rational Software Architect 7, but hopefully IBM will see it fit to provide an EMF in Eclipse that has these new archive schemas built in. Lots of headaches could be solved.

The Service Data Object (SDO) Pattern For Rational Software Architect

Wednesday, June 14th, 2006

As I was architecting some software lately, I noticed that the DeveloperWorks Reusable Asset directory had all the Enterprise and Security patterns, but the SDO pattern was sadly missing.

The Service Data Object is one of the most powerful tools in abstracting any data from it’s datasource, and is used heavily by enterprise architects and developers in Service Oriented Architectures (SOA) and in DAO patterns where you may have different data sources and abstraction is key. The SDO gives you built-in ChangeSummary ability, so that you can automatically update your datasource or XML with new data after you’ve finished using the SDO! Also, the SDO itself is serializable.

I am currently finishing an article about SDO and how to create a poor-man’s SOA from existing Business Objects using the SDO. Look for that somewhere soon.

In Rational Software Architect, having patterns in your Pattern Repository that you can drag and drop in to your Analysis or Design diagrams is essential to ensuring you’ve designed your own products correctly, and that you have the best representation of the pattern in your environment. With that in mind, I have recreated in complete detail the Service Data Object pattern here so that many SOA and DAO developers and architects can simply import it in to their RSA through Import –> RAS Asset and use it.

About The Pattern

I have included documentation from the ServiceDataObject specification Version 2.0 and have relied on several IBM and EMF document sources from DeveloperWorks and the SDO specification itself to create one pattern that seems to take in all the various text based and UML based examples of this pattern.

The completeness of this pattern is very important, so if you find anything wrong or would like to make suggestions either edit the included java file and send it along or comment to this thread.

This is an example of how it should look in your design document after you have filled out the pattern template completely and dragged the classes on to your design.

SDO Pattern in RSA

Click for larger view above.

Because of my current project name, the pattern will appear under Maestro -> Core Patterns, but you are free to copy / paste it where you like after import.

Download Files

Here is the Java file and the RAS file if you would like to do your own patterns or see how I made the associations I did above. To use the RAS file, simply do an Import... RAS Asset in your Rational Software Architect product.

  1. ServiceDataObject.java
  2. Service Data Object RAS File