From the Canadian Real Estate Blog, MoveSmartly, They have a post titled “The Future of the Online Real Estate Search in Canada“.

In the USA, people interested in real estate have a ton of different websites they can use to search for houses. Pop the term into google sometime. In Canada, things are completely different. There is a single website mls.ca which holds all the MLS data and does not allow any form of third party interactions.

Housing 123 was downloading MLS information to their site allowing their users to search and browse homes on a Google map interface. MLS.ca, the real estate search site operated by CREA, does not have any mapping functionality making it difficult for users to search for homes in a particular area.

The Canadian Real Estate Association is threatening Housing123 with a lawsuit because they are syndicating the real estate market data. The interesting issue is that the mls.ca is pretty old, outdated and can’t even display houses in a map view. You still choose to look at houses based on internal region codes (how very non SOA but that’s another story).

Anyway, this opens up a very interesting issue. Why is MLS data so restricted and who is the one benefiting from this relationship?

Is it the consumers? I don’t think so, we’re being denied a better user experience. Entrepreneurial Innovations and new business models are stifled when you can’t get access to core data for an industry.

Is it the real estate companies? I don’t think so, they’d be more than happy to display all the listings and become buyers agents for the home buyer.

Is it the owners of mls.ca? Bingo. They control the data, they ensure that their site is the only one that can be used. They ensure their continued relevancy even though they can’t keep up with consumer demands on what is wanted in an online home shopping experience.

I’m a large proponent of ‘information likes to be free’. It sure does seem in this case that information about the houses on the market in canada is something that should be free to anyone to use in any way. Shame on the Canadian Real Estate Association for being so close-minded and behind the times.

Why is this relevant to the readers of this blog? Well these are the kinds of situations that are going to occur more and more as mashups and web 2.0 take off. Companies are going to have information twisted into ways they never imagined and the course of action they choose will shape both the web and the integrations of tomorrow.

Related Posts

• ROFLCon2008: Random Musings About Social Web And Community Building
• Oracle SOA Suite 11g - Hello Competition!
• Legacy System DTDs over the wire
• Enabling SCA-MQ integration via MQ bindings
• WebSphere Process Server v6.1 API

I have to admit that I was very impressed with DataPower Course WB552. The content of the course covered everything that on would need to know about how to use the box along with security. It also provided a lot of opportunity to go off the beaten path and try modifications on your own. I felt like I got a good feel for debugging on the box as you would almost always miss a step (by default a rule is bi-directional which will throw an error when you only have security on one side).

When you are in this debugging mode, the box provides a pretty good view of exactly what was going on with the ability to see the complete trace log for a single transaction, even though sometimes the errors themselves are cryptic. Luckily, I have more than enough experience translating developer exceptions into English from WebSphere Process Server.

The time allocated for the labs is quite large and you get the opportunity to leverage the skill of your teacher to explain certain dialog boxes and determine the datapower programming model. An example of this was when I was trying to set two URL’s in a match rule, thinking that the operation between multiple rows in the list was an ‘OR’. It’s actually an ‘AND’ meaning that my match would have to satisfy both URL rules.

Given that I had previous datapower experience both writing the certification test and reading the course beforehand, my view may be a little skewed but I noticed that the entire class was able to keep up and usually worked ahead of the lecture::lab relationship.

I was told that there is a follow-on course for WB552, I’m not exactly sure which one it is, or what they start to get into.

I totally recommend this course to anyone who wants a better understanding on the hands-on use of the datapower box.

Curiously, I was also informed that the IBM Business Partner Virtual Innovation Center does not currently provide a DataPower box. This makes it difficult for partners to get the hands-on skill or be able to rerun the labs on their own time. Hopefully this will be addressed soon by IBM.

Related Posts

• DataPower Course WB552: Accelerate and Secure XML and Web Services with IBM DataPower SOA Appliances
• WB552: Random DataPower Thoughts Part 6
• WB552: Random DataPower Thoughts Part 4
• WB552: “Is there an IDE for DataPower?”
• DataPower: Can A Match Action Accept Multiple URLs?

Seeing how I’m not at Impact 2008, my impressions are going to be more geared towards what I see being said in the blogs, the twitter stream and the participation in the SOA Jam.

My first impression comes from the SOA Jam, where I think I’ve posted two pretty good ideas. The first being that we desperately need IBM to foster an external community. The other that the ESB products overlap too much, reducing the pool of skilled applicants. IBM says that 6000 people are in attendance for this conference, yet the total number of entries after day one of the Jam is 22 with 70 comments. That means that we’re jamming with 0.3% idea generation and 1.1% commenting participation rates (assuming no duplicates). I find this to be very low for a Jam that ends Thursday morning. It will be interesting to see what happens the rest of the week with the numbers. I’m not sure if there is any actual active promotion of the jam going on, or participants just don’t care.

As for my contributions, they seem to be progressing at an acceptable rate. I’ve got five comments about the external community where most are in agreement and three on the ESB. The external community is the one that I hope sinks in and takes hold. It’s low hanging fruit that IBM can leverage, whereas modifying the architecture for various products is more of a dream that I’m hoping finds roost in the head of someone who matters.

On the ESB side, I’m getting kind of what I expected: some agreement some disagreement. The disagreements usually come when someone makes the point that they are all targeted to different users. I say that at a high level, they all do the same thing. I accept that the runtimes are unique and will likely never change. That doesn’t preclude changing the tooling to be uniform.

I’m a developer, I’m already implementing systems (in WID) in an abstract way with boxes that represent functionality and lines that represent relationship. Why can’t what runtime I choose to deploy my solution to be abstracted as well?

Related Posts

• Impact 2008: Impressions of Day 2 - SOA Jam
• Impact 2008: SOA Jam Day 3
• Impact 2008: My impressions of Day One - Blogs & Twitter
• My Contributions To The IBM External Community - The 24/7 Answer Man
• Impact 2008: SOA Jam - “Foster an External Community for Practitioners”

In the blog Albees Online, Albin Joseph expresses his frustration that he’s stuck using the buggiest IDE in the World (WebSphere Integration Developer). I’m going to include my thoughts below:

Most of the times the server wouldn’t change the status to started even if the server is actually started

Agreed. There’s something wrong with the communication between WID and WPS over the RMI protocol where the tool either ignores or doesn’t receive the “Started” message. The stupid part is that this problem has existed in the tool since v6.0 with no real resolution in sight. The workaround? Open your WID Server configuration (double click the server in the Servers view), and change the RMI setting to SOAP or SOAP to RMI. Save the editor and your server will now be started.

publishing would not work, not able to add a project to the server,

I’ve also had this problem where either the publishing would fail randomly or a builder would generate an error. Theres two workarounds that I use. The first would be to re-build the generated ear files but deleting the EJB/WEB/APP projects in the resources view and then initiating a clean build. If that didn’t work, I would remove the ear from the server and restart the server. This usually ‘fixes’ the problem. In the extreme cases, I would export my workspace into a Project Interchange file, create a new workspace and re-import.

the changes made in a project will not be reflected in the server and so on.

Again, this is a legitimate problem between the interactions of WID and WPS. Process server seems to hate iterative development. It caches and optimizes based on every app-install on the assumption that the server will be untouched for long periods of time. This directly conflicts with the usage pattern of most developers. In the more recent ifixes of the tool, I’ve used the task view warning to re-deploy the ear as needed and have greatly reduced the instances of changes not being reflected.

If all these things worked, then we will get a series of exception with some stupid ids. If we search the error code in IBM infocenter we will get an explanation that is no way matches with the problem we are facing.

Agreed, problem determination in this stack is very difficult. You either know the solution because you’ve seen the exception hundreds of times, or you spin your wheels debugging ‘ghosts’. I think this is a reflection of the architecture of products being built on products being built on products. It’s a great way to design a system, leveraging domain experts to solve common problems. I think the issue comes when the developer who uses a dependency doesn’t take ownership of the problem, but rather points a finger at the lower level and shrugs. As it stands now, by being a developer on WID, you also have to be an expert on Rational Application Developer, WebSphere Process Server, WebSphere Application Server, Eclipse, WSDL, EMF etc.

If someone from IBM reads this post, please please test your products before you release it to the end user and please give some proper explanations and how to solve these issues in your infocenter.

They do get tested, the problem is that WebSphere Integration Developer is built off of so many products and includes such a wide variety of usage patterns, that it’s impossible to test them all. That has led to the documentation of ‘Best Practices’ as a guide to attempt to keep developers along the ‘most traveled and tested’ path.

Related Posts

• Problem Determination and WebSphere Integration Developer
• WebSphere Integration Developer & WebSphere Process Server v6.1.2 released
• Automatic Build Solution for WebSphere Integration Developer
• Taking component testing to the next level in WebSphere Integration Developer
• Tip: Redeploying your modules from WID

From the IBM Innov8 game. Premonition of the future? (Both sides??)

Damn, she stole my gimmick should I ever be back on the job market. I’m not sure if a panhandler should be dressed better than the people she’s begging from though. The collared shirt probably has to go.

Related Posts

• Online Real Estate Search in Canada: Example of Integration Bottlenecking And Innvocation Stifling
• DataPower - Proxy & Co-Processing
• DataPower Course WB552 Overall Impressions
• Rational Performance Tester provides refreshing honesty
• WebSphere Business Services Fabric, Part 2: Extending the ontology models

From IBM Redbooks, IBM WebSphere DataPower SOA Appliances Part III: XML Security Guide

Redpaper, published: Tue, 1 Apr 2008

- Secure and improve your XML and Web Services setup and deployment
- Integrate DataPower appliances with WebSphere Message Broker
- Provide XML threat protection in DataPower

IBM® WebSphere® DataPower® SOA Appliances represent an important element in the holistic approach of IBM to service-oriented architecture (SOA).

Part 3 of 4 in the DataPower series.

Related Posts

• IBM WebSphere DataPower SOA Appliances Part IV: Management and Governance
• IBM WebSphere DataPower SOA Appliances Part II: Authentication and Authorization
• IBM WebSphere DataPower SOA Appliances Part I: Overview and Getting Started
• Make SOA real with IBM WebSphere Enterprise Service Bus and IBM WebSphere DataPower SOA Appliances
• WebSphere DataPower SOA Appliance: The XML Management Interface

From IBM Redbooks, IBM WebSphere DataPower SOA Appliances Part II: Authentication and Authorization

Redpaper, published: Tue, 1 Apr 2008

• Integrate IBM Tivoli Access Manager with your DataPower appliance
• Implement enterprise security and identity management
• Configure authentication and authorization using LDAP

IBM® WebSphere® DataPower® SOA Appliances represent an important element in the holistic approach of IBM to service-oriented architecture (SOA).

This is the second of four Redbooks available about DataPower. This one focuses on Authentication and Authorization which are amongst the top reasons for purchasing the box.

Related Posts

• IBM WebSphere DataPower SOA Appliances Part III: XML Security Guide
• IBM WebSphere DataPower SOA Appliances Part IV: Management and Governance
• IBM WebSphere DataPower SOA Appliances Part I: Overview and Getting Started
• Make SOA real with IBM WebSphere Enterprise Service Bus and IBM WebSphere DataPower SOA Appliances
• WebSphere DataPower SOA Appliance: The XML Management Interface

From DeveloperWorks, Developing integration solutions with WebSphere Process Server relationships

The Relationship Service in IBM WebSphere Process Server is an infrastructure service that is well integrated with other transformation components. It includes a comprehensive administrative interface that you can use to easily implement complex integration scenarios without custom development of cross-referencing logic mixed in with your business logic. This article introduces the capabilities of the WebSphere Process Server Relationship Service, including those new in V6.1, and explains when and how to use these capabilities. (IBM WebSphere Developer Technical Journal)

To be honest, I've never used the relationship runtime and I haven't encountered a client who has either. I just get the feeling that is has a lot of 'moving parts' so little use that recommending it would result in more problem reports than the functionality is worth.

Related Posts

• Automatic Build Solution for WebSphere Integration Developer
• WebSphere Integration Developer & WebSphere Process Server v6.1.2 released
• What’s new in WebSphere Process Server V6.1.2
• IBM Redbooks: WebSphere Process Server and WebSphere Integration Developer
• DataPower - Proxy & Co-Processing

Go figure,

I was googling for “WebSphere Process Server” and came across an AlphaWorks project:
SCA Component for Ruby with IBM WebSphere Process Server. Unlike the article that ‘integrated’ the two via Web Services, this project will give you the ability to run Ruby from inside a component.

Related Posts

• How to misrepresent your article
• Web services with SOAP/JMS in IBM WebSphere Process Server
• Use ARM to monitor SCA invocations in IBM WebSphere Process Server
• Developing integration solutions with WebSphere Process Server relationships
• Enabling SCA-MQ integration via MQ bindings

The developerWorks article titled “Create a Web service with Ruby on Rails for integration with WebSphere Process Server makes it sound like it’s some cool new functionality that would allow a Ruby Component inside of process server.

Alas, the “Integration” between Ruby and Process Server is done via a yawn-inducing boring old web service. I’d suggest re-titling the article: “How to invoke a Web Service using Ruby on Rails” and drop the whole Process Server buzzword.

Related Posts

• Article about how to write Articles for WebSphere DeveloperWorks
• SCA Component for Ruby with WebSphere Process Server
• Web services with SOAP/JMS in IBM WebSphere Process Server
• My Integration Test Client DeveloperWorks Article
• DataPower - Proxy & Co-Processing

From Developerworks, a little piece of self-promotion called Writing articles for developerWorks WebSphere

Everything you’d ever want to know about getting an article published on developerWorks.

One caveat, the article approval process is very long. My submission for the Test Client article took around 3 months to get approval. By then, I wasn’t all that interested in the topic as I had moved on to other exciting things. My suggestion is to just write the article anyway without official approval. Worst-case scenario you can self-host it.

Related Posts

• My Integration Test Client DeveloperWorks Article
• How to misrepresent your article
• Taking component testing to the next level in WebSphere Integration Developer
• Whats new in WID/WPS v6.1
• DataPower - Proxy & Co-Processing

From DeveloperWorks, Configuring SCA HTTP binding to enable real-life scenarios

You can use HTTP bindings supported by IBM® WebSphere® Integration Developer Version 6.1 in many common real-life integration scenarios involving Service Component Architecture (SCA) applications. For example, by properly configuring the HTTP bindings you can expose SCA applications as a simple HTTP URL using HTTP export binding; enable SCA applications to consume third party XML Web services using HTTP import binding; and use HTTP bindings to integrate multiple SCA applications.

Using a downloadable, hands-on, sophisticated example SCA application, you see how to configure the key HTTP binding attributes to enable these scenarios. It is intended for WebSphere business integration consultants and developers who want to integrate SCA applications using HTTP infrastructure.

The HTTP binding is new in WebSphere Process Server v6.1. It appears to support REST and includes an example of mashing-up Atom feeds. Enjoy.

Related Posts

• Integrating Oracle BPEL with an HTTP (REST) Service
• Enabling SCA-MQ integration via MQ bindings
• JMS Function Selectors & Method Bindings
• Web services with SOAP/JMS in IBM WebSphere Process Server
• Asynchronous SCA One-Way Operations And How To Recover

From Developerworks, BPEL or ESB: Which should you use?

When designing an SOA solution, it's not always clear whether you should use a Web services BPEL process or an ESB mediation flow. This article describes considerations that will help you decide which is right for you.

In v6.0.x, this is an easy question to answer: BPEL always. WebSphere ESB is only simple and straightforward when involving a transformation from a single source to a single target. Anything more than that and you'll create a Frankenstein that will puzzle support people for years. It uses a non-intuitive XSLT editor and the mittens are tight enough that you'll land up putting custom java code everywhere. In v6.1, as we saw in the 'Whats new' articles for both products there a lot of flow related constructs that have been 'pushed down' into WebSphere ESB. I do have a few issues with this article though. Under the section about ESB strengths is the following statement:

Another strength of an ESB is performance. An ESB is designed to be able to handle large volumes of messages. If, for example, the requirements say that there will be 200,000 messages per day, the ESB would clearly be the better choice.

Now. A WPS Module and a WESB Mediation Module are very similar constructs. Both of them use the SCA runtime to execute their code, they both get packaged as utility ears on generated EJB projects, they both leverage the underlying abilities of WAS (SIBus, Transactionality etc). The only real difference between them is the usage of a Mediation Flow component vs a BPEL Flow and I don't think the performance differential between the two is significantly large. They share so much code in common and must spend so much time performing common tasks, yet there's always this implication that Mediation Flows are magically faster. With the introduction of these flow-like constructs to mediation flows, the performance benefit of Mediation Flows must be closer to the performance of BPEL. They are both pretty much doing the same workload. I would severely discount performance as a reason for choosing one over the other. I guess the other thing I don't like about the article is that it kind of cops out on WESB entirely by lumping Message Broker in the same category. Message broker is severely expensive and does its job extremely well and has been for years but when someone talks about 'BPEL vs ESB', they are usually referring to WESB. The bullet points that make the ESB case sound so great are actually message broker features. So whats my point? I guess that even in the v6.1 product my point of view on deciding which to use will still be: "Lets do it in a Process Server Module." unless my use case is ultra-trivial (or the customer simply doesn't have Process Server). As a customer, why would I want to learn two different runtime components when they are probably pretty equivalent in performance? Build the skill the in process server, the superset.

Related Posts

• Adding JMS or MQ/JMS Custom Header Attributes
• Whats new in WID/WPS v6.1
• BPEL: Beware the use of nested loops in a short running process
• What’s new in IBM WebSphere Enterprise Service Bus V6.1
• WebSphere Enterprise Service Bus does not support Event Sequencing

I’ve started reading up on DataPower in anticipation of writing the certification test in May (At the WebSphere Services Technical Conference 2008). Two of the usage scenarios that have caught my interest are ‘Proxy’ and ‘Co-processor’.

In Proxy, DataPower acts as proxy to your web service . The scenario given is a website that uses Cascading Style Sheets to create a website. In the non-DataPower scenario, your application server creates the XML, applies the style sheet to it and then sends it back to the client. Apparently, this is a very CPU-intensive task. When the box is introduced, the application server sends the XML content back to DataPower, and it applies the style sheet and sends the response to the client. The article described that DataPower was able to perform the transform seven times faster (7s to 1s) than the application server. The application server’s CPU usage already decreased substantially. Seems like a shoe-in product for style sheet heavy web sites. You decrease the load on the app server, making it able to do more business work and the load on the datapower box is also negligible. You could send transforms at it at ‘wire-speed’ (100Mb/s in and 100Mb/s out). Wow.

In the second scenario, the DataPower box is called by the application server to perform transformations on demand. Say a business process requires the invocation and transformation of three web service calls. Without the box, the app server does the conversion from Generic Business Object (GBO) to Application Specific Business Object (ASBO). It then invokes the endpoints, gets the resultant data and applies more transformations to create the final composed output. Depending on the size of the objects, your server could be spending a ton of time transforming data. With the DataPower box, you make WebServices calls to it to convert from GBO to ASBO, invoke the service and convert the ASBO response into the GBO response.

The very neat part of the co-processing solution is that your integration developer never needs to leave the ‘GBO’ view of the data. This makes the actual integration solution much easier to understand, and keeps the data at a generic level that most people in the company could understand.

The DataPower core business case is that they view data transformations as a commodity. It’s a commodity that shouldn’t be running on your expensive application server, mixing business logic with transformation logic. They think that your application server should spend it’s time providing business services and less time compiling stylesheets. It makes sense to me. You buy a single datapower box and it will probably be able to serve all your transformations from all your systems. You lower the cost of ownership and server maintenance (less servers) while increasing your transaction throughput (via the CPU time not spent transforming) and overall response times (DataPower is just faster than an app server).

Win-Win. Cool product.

We have a box that I can access in Perficient, so I should be able to provide some hands-on numbers once I get to that stage.

Related Posts

• WebSphere DataPower vs WebSphere Enterprise Service Bus
• WB552: Random DataPower Thoughts Part 12
• Make SOA real with IBM WebSphere Enterprise Service Bus and IBM WebSphere DataPower SOA Appliances
• IBM WebSphere DataPower SOA Appliances Part I: Overview and Getting Started
• WB552: Random DataPower Thoughts Part 9

From DeveloperWorks: Demystifying WebSphere Business Services Fabric End Point Selection:

Learn how the WebSphere Business Services Fabric Dynamic Assembler uses content, context and contract to dynamically select service endpoints. You'll learn how policies are used to select candidate endpoints, and how the Dynamic Assembler handles policy conflicts and policy resolution.

On the heels of my opening discussion about Fabric and how its a product ahead of it's time, comes an article from developerWorks that delves into the "how" of the product. This article provides an introduction to the terms that the fabric team likes to toss around: "Policies", "Assertions", "Dynamic Assembler" etc.

Related Posts

• WebSphere Business Services Fabric, Part 2: Extending the ontology models
• WebSphere Business Services Fabric
• Getting Started with IBM WebSphere Business Services Fabric V6.1
• Adding custom roles in WebSphere Business Services Fabric
• WebSphere Business Services Fabric 6.1 Content Packs