I present the following exhibit:

The only difference between these two snippets is the string that I am setting in the commonName attribute.

But, let’s look at the java that was generated under the covers for the bottom snippet:

boolean __result__31 = (iFlag != null) && (iFlag.trim().equals("Y"));
 if (__result__31){
commonj.sdo.DataObject svcCharVal = __result__34;
java.lang.String __result__36 = "HIGH SPEED INTERNET";
svcCharVal.set("commonName", __result__36);
java.util.List __result__38 = svcChar.getDataObject(..).getList("...");
boolean __result__40;
{// add item to list
__result__40 = __result__38.add(svcCharVal);
}
}

Looks good. But check out what I have generated for the first snippet:

boolean __result__19 = (tvFlag != null) && (tvFlag.trim().equals("Y"));
 if (__result__19){
commonj.sdo.DataObject svcCharVal = __result__22;
java.lang.String __result__25 = "TV";
java.util.List __result__26 = svcChar.getDataObject(...).getList(...);
boolean __result__28;
{// add item to list
__result__28 = __result__26.add(svcCharVal);
}
}

If you look closely, you’ll notice that the

svcCharVal.set("commonName", __result__25);"

IS MISSING IN THE FIRST SNIPPET

This means that the snippet I see visually and the actual java generated for the snippet aren’t the same. It appears that not only is the visual snippet editor dependent on the visual information of your java, it’s also dependent on HOW YOU CREATED IT.

I’d love to hear an explanation for this one. You have the entire visual snippet artifact, why isn’t the backing java just built off of that on every save?

Related Posts

• Visual Snippet Editor: Forgets Java Syntax
• WebSphere Integration Developer: Struggling with the Business Object Mapper
• BOFactory: create(..) or createByElement(..) ?
• Avoid the WebSphere Integration Developer Debugger
• WebSphere Integration Developer & WebSphere Process Server v6.1.2 released

In the past, I’ve gone and de-constructed WebSphere Process Server stack traces in an example of problem determination. Now, I’ll talk about what I do when WebSphere Integration Developer goes crazy.

A typical WebSphere Integration Developer exception consists of either a builder error pop up dialog or an issue when trying to open an editor. You’ll see the standard eclipse error dialog with some cryptic message. When this happens to me, I try the following steps:

Regenerate the J2EE App, EJB and Web projects

Sometimes there is an error in these generated artifacts. What I first do is a clean build via the build menu, clean all. This is supposed to flush the internal state of the eclipse builders and force them to recreate all artifacts from scratch. As the versions have progressed, this has gotten better but it’s not perfect.

Should the problem continue, I will switch to the resources view and manually delete these generated projects. Once they’re gone, I will do a clean-build. Since the files are physically deleted, theres no worry about the builders maintaining internal state.

Restarting WID

Sometimes, all it takes is a simple restarting of the tool and builder errors can disappear.

New Workspace

In WID v6.0.2.3 I rarely do this anymore. I would export my current workspace as a Project Interchange file (IBM speak for a .zip file). Then I would start a new workspace and import the PI. This resolves issues with corrupted workspaces that ravaged the v6.0 GM version of the tool.

Usually, these two solutions will resolve random errors. Sometimes though, your tool is completely screwed up and you can’t even get the Business Integration Perspective to appear. This usually occurs after the first time the product is installed or when a fix pack (or add-on product like WebSphere Business Services Fabric) is installed. There are two methods of fixing these kinds of errors:

WID.EXE -clean

There is a command line option when you start WID called ‘clean’. To explain clean, we need to take a step back and understand how WID is package. WID is built on top of both eclipse and Rational Application Developer. It does this by providing a set of plug-ins that extend the eclipse platform. Eclipse then needs to index these plug-ins to determine dependencies and capabilities. Sometimes, the eclipse index is out of sync with the file system. Clean forces eclipse to rebuild this index. It will take about 5-10 minutes to start the tool as this work is performed but it will usually resolve missing editors.

WID.EXE -initialize

This is another internal eclipse command line option that tells the platform to rebuild that the plug-in caches. I normally do a clean followed by an initialize.

Finally, if neither of these solutions resolve your problem, you can take a look at the WID .log file and see the exception. The log file is contained at <workspace_location>/.metadata/.log . If you are very lucky, it may contain relevant data.

So you now know my WID secrets on fixing tooling time errors. I hope it will save you some time in the future.

Related Posts

• Venting some WebSphere Integration Developer Steam
• Exploring The Contents of a WID Module Project
• WebSphere Integration Developer – Namespaces Cannot Span Projects
• Automatic Build Solution for WebSphere Integration Developer
• AlbeesOnline: The Road to Hell is Paved with Good Intentions

Previously, I talked about what steps I think IBM could take in order to foster an external WebSphere Community with the goal that one day it would become self-sufficient. In the previous posts in the series:

1. I talked about the benefits to IBM
2. I talked about the holding an external conference call for practitioners

I think that IBM should hold a weekly rotating chat between the developers and the users.

My reasoning for this request is that the developers hold the intimate knowledge of how pieces of the product work. They would be able to comment on design decisions and allow the end users to understand the reasons behind why the software works in the way it does. It would be a quick ’short-circuit’ of the lengthy PMR process where a developer could quickly resolve a potential PMR issue before it is opened. End users would be able to build relationships with the developers and put a ‘human face’ to the products. This personification would help reduce the general angst that exists towards the product stack.

It will also allow the developers to gain feedback over their piece of the product. This would allow the developer to better understand if the users are interacting with the software in the way that the developer envisioned. Many times in software, there is a disconnect between what the developer thinks the user wants and what the user actually wants. This should lower that division significantly. It can also be a point of encouragement for developers. A “good job” or “works great” from the people you wrote the software for is worth more than some IBM Thanks! award trinket. Most developers that I’ve spoken to enjoy dialogues with their users. Currently at IBM, they are sheltered by the rest of the organization too deeply. Let’s open it up.

My idea is that the chat would be held once a week at a specific time with a rotating cast of developers. It would last for about an hour and the transcripts would be made available. The rotation would be structured in a way that a developer would participate around once a quarter. DeveloperWorks has alrady held events that are similar to this as one-offs. I would like to see it the program expanded.

I think this idea would allow developers and practitioners to connect in order to raise quality and reduce support costs.

Related Posts

• Part 1: IBM and the self-sufficient WebSphere Community – IBMs Business Case
• Part 2: IBM and the self-sufficient WebSphere Community – An External Conference Call
• SOA Jam: Foster an External Practitioners Community
• Impact 2008: SOA Jam – “Foster an External Community for Practitioners”
• Impact 2008: Impressions of Day 2 – SOA Jam

The cousin to yesterday’s WSDL Anti-Pattern: The ‘Single XML String’ Service is the use of the XSD specification’s ‘any’.

‘Any’ literally means “any well-formed XML contained in this section is valid”. ‘anyType’ means “any valid XSD Type”. We can start to see the correlation between the Single XML String service and the use of these generic types. They are used to dilute the definition contained in the WSDL to attempt to account for unforeseen changes in the future.

The benefit is that the WSDL doesn’t need to change as the service evolves, even though the services themselves will have to be modified to support the new arbitrary types.

The drawbacks are numerous. Tooling support for xsd:any’s is also low. You lose message validation. You lose strong definitions of your service. All the points that were made in the previous post apply to this style as well.

This is not to say that there aren’t valid reasons to use ‘any’ and ‘anyType’. Say, for a service that dynamically routes messages based on header contents. It’s just that most of the times they are used, it’s for the wrong reasons. Yes, I’m talking about you Industry Standard Schema Definitions (easily the worst offenders).

Just in case you didn’t like any of my arguments, here is a very well written DeveloperWorks Tip on using generic types with WSDL and the pitfalls that can occur:

Summary

Although it may seem like a good idea to use xsd:any in your Web service’s XML schema, there are pitfalls to doing so: you are deviating from the intent of WSDL, and the language mapping of xsd:any may not be easy to use. Although I won’t go so far as to say using xsd:any is a bad practice, I do hope this tip has given you a better awareness of problems you may encounter before you encounter them.

Related Posts

• xsd:any, xsd:anyType, xsd:anySimpleType, xsd:anyAttribute in WebSphere Process Server
• WSDL Anti-Pattern: The ‘Single XML String’ Service
• Tip: Agree To Concrete WSDL Definitions before Development Begins
• MQ Import Anti-Pattern: Multiple MQ Imports connecting to single pair of physical request/response queues
• Handling unmodeled faults within WebSphere Process Server V6.1

WSDL is a very useful technology. It allows service providers and consumers to agree on namespaces, operation names, the data to be transmitted in a request and the data to expect in a response. All very good things to know, all in a platform neutral way.

Now, WSDL tells us what all the elements and attributes are for a service invocation. What can we do at the WSDL level to account for future changes to the service? This is where some implementations get it wrong.

When you are creating a service, you can only account for the changes that are expected. Maybe a new product will be added or a field may become depreciated. These are easy changes to account for via the way you structure your XSD definitions. In this case, I would say that the service takes a List of Products thats unbounded.

If the change that is being requested created a structurally different message (via additional fields), then you just have to suck it up and modify the WSDL (either marking the old fields as optional if you want compatibility with current clients) or just making all your clients upgrade. To make my point, I’m going to ignore multiple version service offerings or use of WebSphere Service Registry and Repository.

What I’ve seen though, are services where the providers attempt to reduce ANY potential modification to the WSDL interface. This usually results in a service where the operation takes a single string parameter called ‘xml’. The client is expected to serialize the message itself and include it as a string payload in the request.

What this anti-pattern does is remove the entire point of WSDL and XSD. The ability to know what data to send to a service call and what data to expect back in a response. This is no longer captured at the level it should be. If I am a consumer of this service, how do I know what the XML to be transmitted should look like? I have to go through alternative social channels to get this information. That’s the very problem that WSDL was created to solve!

Other problems with”services as strings” deal with the added complexity that the service implementor and consumer need to perform themselves. Today, you can generate a SOAP/HTTP client for a wsdl automatically. The client will serialize your platform specific objects into SOAP and transmit them. In the anti-pattern, the developers themselves need to call the code to serialize the real content and then pass it on to the generate proxy which serializes it again.

What do you gain through this anti-pattern? Well you are no longer bound to making WSDL changes as the service matures. If a new product is created then the service provider and service consumer’s implementations must be updated, but the WSDL is left alone. This pattern is normally used to allow for ‘dynamicity, to account for changes in the data sent between the two services. The gotcha is that you are probably going to have to modify the implementation code anyway to handle the new data. You didn’t really gain anything, but you gave up strict typing and validation.

I’ve found that when the anti-pattern is used, it’s with good intentions but you are far better off just specifying the data explicitly in the WSDL and dealing with changes through your regular change management process for both WSDL and implementation.

Related Posts

• WSDL Anti-Pattern: xsd:Any and xsd:AnyType To Encapsulate Future Changes
• MQ Import Anti-Pattern: Multiple MQ Imports connecting to single pair of physical request/response queues
• Tip: Agree To Concrete WSDL Definitions before Development Begins
• Business Object Maps and ‘Required’ Attributes
• Visual Snippet Editor: Forgets Java Syntax

Yesterday, I had a non-descriptive NullPointerException occur within a visual snippet sub-map in WebSphere Integration Developer. The only message written to the log was something that identified which transformation in the sub-map failed. There was nothing about what line was bad. Rather than filling my code full of “Got Here” and “Did this Runs”, I thought I would use the debugging capabilities of the tool.

I thought I would get the ability to move from one snippet to the next to identify the issue. It would have been even sweeter to get hot-code replace, but I don’t mind rerunning my testcase.

What I got was an exercise in bugs, pain and non-intuitiveness. I set my breakpoint at the first point in my visual snippet. The breakpoint popped. I then tried to step into the next line of the snippet and the debugger interpreted that as ‘Run to completion’ so I missed the point of failure.

I realized that I had to just keep manually setting breakpoints for any point where I wanted to stop. My snippet is quite large and finding a NPE is hard. It also took about 6-10 seconds to hit the next breakpoint in the chain. The editors would go crazy resizing and flipping between editors while this was happening.

I decided that the best approach was to use my breakpoints to divide my visual snippet in halfs, identifying which half was failing and then breaking it down even more. Of course, each re-iteration was a completely new invocation which took time.

I also experienced a few times where the breakpoint graphic was created (hello little dot) but it never popped anyway. Another invocation please.
Everything was just so painful and slow to run, that it took about an hour of running tests to figure out that the visual snippet editor didn’t initialize a value.

Next time? I’ll just put in the extraneous system.out’s and forget about even running the debugger again. For all my defenses of the tool and runtime, even I can’t defend how crummy the debugger is.

Related Posts

• Visual Snippet Editor: Forgets Java Syntax
• WebSphere Integration Developer: Visual Snippet Java Code Generation Is Non-Deterministic
• Updates required for WebSphere Integration Developer debugger to work when security is enabled
• WebSphere Integration Developer: Struggling with the Business Object Mapper
• Problem Determination and WebSphere Integration Developer

If you are a provider or a consumer about to enter development on a web service, you should have an understanding with your counterpart of the WSDL that defines the service. It should be very well ‘baked’ and changes once development begins should be minimial.

Major things like name spaces and object names should rarely change once development begins. Name spaces and object names are treated as a key by mapping tools. If either of them change, expect to waste time refactoring your development artifacts to use the new definitions.

Your WSDL file is a contract. A contract that describes what data I can expect from an invocation. How can you expect to perform a development exercise without a strongly defined contract?

Also, the runtime that you are going to use to implement your service is irrelevant. I received three WSDLS that were completely different because the developer was switching between runtimes and I assume just autogenerating the WSDL from the tooling.

Good anti-pattern and a solid reason why these kinds of projects miss deadlines.

Related Posts

• WSDL Anti-Pattern: The ‘Single XML String’ Service
• WSDL Anti-Pattern: xsd:Any and xsd:AnyType To Encapsulate Future Changes
• Avoid the WebSphere Integration Developer Debugger
• BOFactory: create(..) or createByElement(..) ?
• WebSphere Enterprise Service Bus – Mediation Flow Component: No Refactoring for WSDL Faults

Previously, I talked about what steps I think IBM could take in order to foster an external WebSphere Community with the goal that one day it would become self-sufficient. In that first post, I outlined what I thought were the benefits for IBM to make it happen.

In these next series of posts, I’m going to give my thoughts on concrete items that I believe IBM could implement to grow the community. There’s a lot of talk about the possible future, dynamic communities, social networks etc. They all sound great until you realize that it will take a long time for them to grow. I’m going to try to keep my focus on practical solutions that are implementable today and could generate immediate returns on investment.

My first solution is for IBM to hold a weekly conference call for the practitioners in the field. The idea being that we are in need a place to hold an interactive conversation. Currently, the only tools available are search engines, forums or the Problem Reporting process. None of these can give me direction in a timely fashion. The call would be formatted primarily as a Question and Answer with questions ranging the gamut from beginner to advanced. Like any mechanism, there’s no requirement placed on IBM to give definite resolutions. Even so, there is a ton of value in dialogue that is as simple as “Have you ever seen this before?” “Nope, Sorry”. I can then use that information to judge that I really am in a unique PMR situation and not just missing the obvious. If I get a resolution, thats a major success. My customer is happy with both myself and IBM for getting the problem solved quickly and efficiently. IBM saved a PMR and potential angry customer escalation situation. Win-Win.

IBM needs to begin to understand that articles, info centers and education courses are insufficient to properly skilling the external community. Those formats of information delivery are only good when I am in the exact same scenario. If I stray from the ‘best practice’ due to a business requirement, I have to lean on my personal social network which does not include IBM. Again, IBM has all the information. When they aren’t involved, it makes my problem resolution extremely difficult.

Conference calls are very non-web 2.0 but they are also very effective if moderated well and transcribed. The long term goal is not to require IBM to moderate these calls forever but eventually rotate the job around the community that has been built. But as it stands right now, we need IBM to provide that spark that will enable us to succeed.

Providing a few resources in a call once a week would be a nice step in the right direction.

Related Posts

• Part 1: IBM and the self-sufficient WebSphere Community – IBMs Business Case
• Impact 2008: SOA Jam – “Foster an External Community for Practitioners”
• My Contributions To The IBM External Community – The 24/7 Answer Man
• SOA Jam: Foster an External Practitioners Community
• Impact 2008: Web 2.0 Social Networking Missing In Action

Over a twitter yesterday, James Governor lamented about the lack of official web 2.0 happenings a conference where we’re all talking about mash-ups, integrating communities and mass enablement. IBM’s youTube Channel has a single 1 minute video from day one, theres a twitter account created of the name “Impact2008“* which has no activity. Heck, even IBM’s official blog hasn’t been updated past day one.

(*unknown who it was created by, but as far as I know there is no official twitter).

It would have been cool to say, allow participants to ask questions in keynote Q&A over twitter as well as the microphone. Maybe presenters could offer informal times to talk to eager listeners once the session is over. How about if IBM aggregated the Impact ‘blogosphere’ and gave us a single place to look for what people are saying about the conference? What if I’d like to try and track down Steve Mills for a two minute interview. Where is he? There’s six thousand people walking around. If I want any of those things, it’s completely dependent on my own social network to make it happen. If I don’t happen to have a person in my list then it’s left to fate and circumstance if we’ll ever meet. Once again, we need IBM to take the first steps to make this happen. It’s great that I now follow the guys from RedMonk and various people who tagged #impact2008, but it’s still just the voices of the people ‘in the dark’ (non-IBM). Without IBM, we can talk all we want about changes that are needed but there’s no buy in from the sole required enabler. The idea that IBM can show up at predetermined times on the calendar, fire-hose the community with information and then disappear are long dead.

It seems like the conference itself is actually an accurate reflection of the state of the SOA community as a whole. You’ve got a large mass of people who would do a great job collaborating with each other and networking, but no catalyst to make it happen. Instead of being energized as part of a broader community, you get isolated and bored. I think I see that effect in how the number of articles/twitters/blogs about Impact 2008 has dropped off significantly from the first day to the third. Even the #impact2008 tag has one message on it over the last 13 hours.

In the SOA Jam, about 80% of the ideas relate to social networks and how to build communities but we’re already failing on a very small scale with people in the same physical location! How can we expect to snap our fingers and create a vibrant self-sustaining community on the large if we can’t do it on the small?

Related Posts

• IBM Impact 2008 – Two Weeks Away
• Twitter Objectives with the ‘danZrobok’ Account
• Impact 2008: My impressions of Day One – Blogs & Twitter
• Impact 2008: Dana Gardner and Michael Coté Blogging the Conference
• Impact 2008: SOA Jam – “Foster an External Community for Practitioners”

The marketing says that it’s WebSphere’s 10th birthday on Tuesday. To celebrate, IBM is asking for revised lyrics to the well-known Birthday song. Never being one to pass up on a free chance at bizarre creativity, I’ve shilled-out and submitted:

WebSphere *IS* big blue
What Can it not Do?
We praise you, Dear WebSphere
Ten more years for you!

Thats the clean submitted one, I give you the tongue-in-cheek one:

WebSphere makes me blue
Ten years of stack spew
Fix my PMR, Please WebSphere?
"It will be in version 9.2"

Related Posts

• Happy Halloween – WebSphere Integration Developer Costume
• IBM Impact 2008 Attendance
• Impact 2008: SOA Jam – “Foster an External Community for Practitioners”
• IBM Impact comes to you: Toronto
• Problem Determination and WebSphere Integration Developer

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

Previously, I lamented about the lack of a non-IBM community dedicated to WebSphere. In this series, I’m going to put myself in IBM shoes and describe what I would do to encourage the formation of an external community. Before I get into that, I’d like to reflect on the benefits it would bring to IBM directly (incase some high profile IBMers need a business case).

Currently, if I’m a customer and I have a serious problem I have very few avenues of non-IBM resolution. I can attempt to google in the hopes of finding other wayward souls. I can browse the infocenter included with the product. I can attempt to toggle random check boxes that I don’t understand (which may result in a more-mangled system that I started with).

Once I’ve exhausted these paths, usually on the order of an hour or three, my only choice is to open a Problem Report (PMR). A PMR is very costly to IBM. Depending on the severity and the visibility of the customer, you could have tens of people on a conference bridge talking about your issue. Eventually, X days go by and you get an answer to the problem. You’ve spent hours of your own time on the phone and hours*attendees of time from the people on the phone. Thats a significant amount of dollars.

The worst part is that you are usually told that the problem is resolved in a fix-pack you haven’t upgraded to yet. Wouldn’t it be nice to have been able to ask a practitioner directly your problem and maybe gotten the answer within 5 minutes because they just ran into it?

You can’t do that today because IBM keeps tight grips on information. DeveloperWorks is a fantastic technical resource. It’s problem is that it’s a massive one-directional fire-hose. You get the technical infomation based on what IBM has determined is important, not based on your own problems and experiences.

What IBM fails to leverage is that most developers are natural problem solvers and would prefer to spend hours resolving an issue on their own in order to move their projects along. Currently, IBM asks you to solve a puzzle (exception trace) without providing the pieces nor the box (for good measure, they spin you around a few times and turn the lights off too ).

Ok, so that helps support. How can open access to information help development?

Developers in IBM are like the inner most section of an onion, they’re so deeply buried in the onion they wouldn’t know a carrot when they saw one, but they could tell you things you never knew about onions. Most developers would love to hear about the exploits of the user, both good and bad. Increased exposure to the front lines would help developers when they are left with behavioral decisions. What may make sense from a developers point of view, may not work to the customer. Therefore, I would expect an increase in product quality.

What about IBM’s Consulting division (ISSW)?

ISSW’s typical business is to provide implementations of IBM products to customers. Pretty much assume the role of customer to IBM while still being IBM. Increased information helps them be more effective and be able to leverage yet another pool of resource (the external) for assistance.

Therefore, my theme in the forthcoming suggestions are all about opening the public to the vault of knowledge contained in the corporation. Lets empower the consultants to be able to serve themselves to the buffet.

Easier access to information will reduce support calls, improve product quality and improve consulting quality. This will create a self-sufficient vibrant community that will benefit everyone involved.

A colleague of mine liked the quote “If you and I exchange a dollar, each of us would still have a dollar – BUT – if you and I exchange an idea, each of us would have two ideas.”

Lets start sharing those ideas.

Related Posts

• Part 3: IBM and the self-sufficient WebSphere Community – Developer Chats
• SOA Jam: Foster an External Practitioners Community
• Part 2: IBM and the self-sufficient WebSphere Community – An External Conference Call
• Impact 2008: SOA Jam – “Foster an External Community for Practitioners”
• The lack of a non-IBM WebSphere Community

In Johannes Brodwall’s Blog, he asks “Why does so much enterprise commercial software suck?”. In it, he mentions that his project migrated off of WebSphere and onto Jetty and regrets that his project didn’t migrate soon. The money quote:

But WebSphere is just the most blatant example of software that gives you nothing, gets in the way of a lean process stream, yet costs a lot of dough.

I can hardly agree with this statement. Is WebSphere Application Server expensive? Sure. Does it have a steep learning curve? Yup.

But,

Does it do the job competently and reliably? Yes. Does it actually do everything listed in its marketing slides? Yup. Does it perform? In 6.1 IBM seems to think so. Can you automate the entire deployment process? Yes.

Bad software hurts you in an insidious way: It eats up the time of every developer a little at a time

Agreed. And I believe that the general clunkiness of the Integrated Development Environments that IBM provides is likely what Johannes is referring to. WID/RAD builds still take far too much time than they should, random errors appear and disappear and the UI does freeze needlessly, leading to death by ‘…a thousand pinpricks’. What I don’t quite understand is why his project didn’t evaluate using a better IDE for J2EE development. The WAS server is a reliable workhorse, why throw the baby out with the bath water?

Bad software hurts you in an insidious way: It eats up the time of every developer a little at a time. Instead of testing your changes with a one second unit test, you test your changes with a five minute deployment cycle. Instead of rolling out a new version to a controlled environment with a command in 30 seconds, you schedule a deploy task that the product expert will perform in a few hours.

This experience with a long deployment cycle isn’t really valid. You can script all of this stuff through ant tasks and JUnit cases. There’s no reason (other than the assumed process of the company in question) why an admin would be required to spend hours installing an EAR.

So when managers ask why a project is late, developers feel personally guilty. And it’s a poor craftsman who blames his tool, no?

I’d have to say its the smart craftsman who understands his tool and the time it takes to actually accomplish the task. It’s also the smart developer who comes clean and lets his project manager know when the plan may slip. This seems like more of a process/estimation problem that something caused explicitly by the software. If this was the first project on the WebSphere platform, I would assume a good project manager would build in contingencies for skilling up and learning.

And from the comments:

Hi, Space Monkey.

We either discontinued or replaced all features not included in a web server. Briefly: EJBs we stopped using (thank god for that!); for connection pooling we first used the pool that came with Oracle, and then switched to c3p0; for failover and loadbalancing, we use our expensive switches which already has this build in; for transaction monitoring, we use Spring; we also rolled our own message service implementation (much simpler than JMS, but a drop-in replacement for our use).

Yowza, it looks to me like a ton of work went into reproducing the capabilities that WebSphere provided ‘for free’. Rolling your own message service implementation? Thats not a path I’d want to go down any time soon. Also, what happens to this system two three years down the road? All these multiple components, multiple vendors. They are all going to point the finger at each other when production goes down and Johannes is left holding the ball. I can appreciate the technical marvel that went into replacing WebSphere, but there’s also large questions of support, documentation and skillset that have to be answered.

So. Does Enterprise software suck? I believe like anything in life, its about costs versus benefits. What is most important to the project? Reliability that the vendor will be in business 5 years down the road? Exploiting the latest in Web 2.0 functionality? Fast development cycles? Documentation? Throw-away or 25+ year expected life? Companies need to try to look down the pipeline and find something that will support what they want to do.

Enterprise software tries to be all things to everyone, so it can come up short. Does it necessarily suck? No.

Related Posts

• Response to ‘Does Commercial Enterprise Software Suck’
• Automatic Build Solution for WebSphere Integration Developer
• Getting Started with WebSphere Process Server and WebSphere Enterprise Service Bus Parts 1 & 2
• WebSphere Enterprise Service Bus does not support Event Sequencing
• Securing JMS connections to WebSphere Enterprise Service Bus V6.1

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

• “Top Best Practices for Implementing WPS Solutions”
• 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
• WebSphere Enterprise Service Bus does not support Event Sequencing

You are a developer in WID, you play around in your candy UI all day creating integrations. One day, you switch into the Resource Perspective and you are exposed to files and extensions that you’ve never seen before. What are they? How does it all hang together? Read on!

In the root of your module project, you are likely going to see:

1. 1 sca.module
2. 1 sca.modulex
3. N *.component files representing the components in the assembly diagram
4. N *.import files representing the import components in the assembly diagram
5. N *.export files representing the export components in the assembly diagram
6. 1 .classpath
7. 1 .project
8. 1 .runtime
9. a ‘gen’ directory
10. a ’settings’ directory containing N*.prefs files.

In the following sections, I’ll attempt to describe what these files do.

sca.module

This file identifies the module to theWPS runtime as being a SCDL v6.0.0 defined module. This is a hardcoded filename that the process server SCA runtime looks for.

sca.modulex

Is an IBM extension on the ‘SCA standard’ sca.module file that provides information such as where the component resides on the assemblu diagram and the type of the component.

N *.component files

These files physically back the component abstraction from the assembly diagram. They contain the information such as: Interface type, Interface portType, reference type, reference portType, the target of any wire from a reference, the implementation type and the implementation backing file. In addition, any transaction qualifiers set in the UI reside in this file. You can open component files with a text editor (everything is XML) and see for yourself.

Jeff Brent and Roland Barcia provide a good explanation of a component file in their article: Building SOA solutions with the Service Component Architecture — Part 1.

N *.import files

Imports are cousins to component files except they represent the import components. They too define the interface and port type, but they also define the binding that should be used for communication (JMS, SCA, MQ etc).

N *.export files

Exports like imports define an interface. They also define the binding used including any information required by the runtime to use the export.

.classpath

Used by WebSphere Integration Developer builders to resolve dependencies. Please note that updating the .classpath will allow WID to resolve projects/libraries but it has no effect on resolutions from Process Server. You need to use the module dependency editor in order to have process server resolve dependent projects.

.project

This file contains the information related to the project from an eclipse point of view. Project dependencies, internal builders (things that run when you save a file or editor) and project natures (how does eclipse know that a project is a Module project? Natures).

‘gen’ directory

Depending on the component implementations in your module, you may find a gen directory containing java classes. These are usually generated by the mapping runtime.

.settings directory

This is another eclipse construct that can be used by plugins to set project specific information. This gets used internally be eclipse. The Integration Test Client uses the .settings directory to store the server that a test should be run against if the dialog box is set to not prompt.

Like any good abstraction, theres no real need for you to ever be digging around the physical representations of your modules, but it’s good to know whats being created behind the scenes if anything ever goes wrong.

Related Posts

• WebSphere Integration Developer – Namespaces Cannot Span Projects
• SCA, BPEL, Websphere Adapter for JDBC and Transactionality
• Adding JMS or MQ/JMS Custom Header Attributes
• Tip: Redeploying your modules from WID
• IBM TechNote: Content and maintenance of the wstemp directory for WebSphere Process Server V6