Can anyone give me an estimate on the amount of Java development required for a given integration project using wM (IS, EB, etc.)

Of course it depends on what you’re doing. And general estimates such as this are always a bit dangerous but I’ll offer a swag anyway.

For IS, I would estimate less than 10% of any solution will use Java services or custom Java code. This depends, of course, on one’s comfort level with Flow. Many IS developers seem to want to drop down into Java services for even simple processes. Many, many things can be done in Flow directly but doing so requires familiarity with the Flow control structures and the built-in services. And despite what wM says, using Flow is programming (it’s got branches, loops and everything!)!

For ES (I assume EB = Enterprise Broker; we’ll need to come up with a new abbreviation for webMethods Broker, since that’s the latest name; how about wMB?) you’ll be exposed more to Java. Using Visual Integrator, you’ll generate Java code with the GUI and then possibly make tweaks in the code here and there. If you use the ATC, you’ll be writing Java code. I’d venture that for ES a developer might need to do 20-30% of the work in Java, but that’s just a pure swag.

Anyone else have thoughts?

Joe,

The programming we do - and we guide our clients into learning to do - is modest for each integration. Some percentage require none. The Flow, Business Integrator, Blueprint, and Integration Component designs can be done without dropping directly into Java. In some cases.

For other cases you might see a few lines, or 10’s of lines. A Java Service (instead of Flow Service) or an ATC Workunit (instead of ATC Blueprint) can easily go over 100 lines … scale by logic branching and special code; scale by size of data objects being processed.

If you have a lot and you are not having to go direct to the low level APIs, you might use an average of 50-100 LOC per integration for estimation. These are programs that, once you have the specification nailed, can take hours by folk who know a little Java.

In context the Java programming tends to be very simple as Java programming goes. Frameworks are already defined. Good examples available from webMethyods.

This assumes you have all the adapters you need. Adapter development is a different ballgame.

Mark

I think that Rob Eamon is on the money when he said that it depends on the comfort level of the developer with respect to the amount of flow objects that are used.

My comments address B2B only.

My experience has been that many companies retrain their existing people to use webMethods (that’s how I started) and people naturally gravitate to what they know and are comfortable with. This seems to generate a lot of java coding. I’m not a java coder to begin with, so I rely heavily on FLOW to provide what I need. If I can’t get flow to do what I want (write files for example), then I extend features with Java.

I have seen shops that have heavily leveraged java and when developers cycle through, the java is scrapped in favor of built-in services. I have worked on one deployment recently like this.

I am a proponent of using built-in (i.e., supported) functionality as well because if issues arise, webMethods is quicker to find a solution (I have found at least.)

I would concur that many integrations can be accomplished with little or no coding. From my experience, it’s generally harder to decide what it is you’re doing than it is to do it! There are a few exceptions however.

One is the occasional time when the data transformation needed between the source and target systems is structural (as opposed to just one data type to another) in nature. This sometimes can require a deep understanding of what is really going on inside the code that is generated by EI - inner classes and what not.

The other thing to consider is how much responsibility the end points are willing or able to assume. It is generally harder to integrate to a “closed” system - one that isn’t available for modification at the code level.

Finally, if there’s any hint that there may be performance issues, time should be allocated early on to accomplish some timing and performance tests - these may flush out issues that can be helped with strategic custom coding.

For example, one project I worked on had extensive work being done inside of an Oracle adapter IC, the throughput was a fraction of what was needed but it couldn’t be scaled due to ordering constraints between the messages. Consolidating as many of the steps in the IC as possible improved the performance by about 40% (the reason for this is another discussion - it has to do with all the inner classes that get instantiated and mapped everytime a step is invoked). In spite of this increase, it wasn’t enough, we ended up writing a custom jdbc adapter that would perform batch updates to the database.

I’ve often thought that the webMethods marketing cry of “no code, no code” is a little misleading. It’s been my personal experience that every project needs at least a couple of really good java programmers to take on the 10% of the work that requires 40-50% of the total effort.

Hope this helps,
Tara

How much Java development in a typical webMethods integration? Easy – it depends on the experience of your developers.

Without sounding melodramatic, Java developers can significant increase a project’s time-to-market and ruin your ROI. The primary strength of the webMethods Platform is its Built-In Services (Integration Server) and Configured Operations (Enterprise Server).

Just like the Java API, it takes time for a developer to learn and be comfortable with the webMethods “API” which is actually a combination of a traditional Java API and Flow/Operation Templates. As Ray mentioned, a Java developer with little webMethods experience will gravitate towards what he know – Java code. I have seen this concept manifested as an Oracle database integration which relied almost entirely on Stored Procedures because the developer was comfortable working with databases.

webMethods provides a long list of pre-tested, pre-certified, pre-configured and ready-to-deploy services out of the box. Literally. These are called Built-In Services but if your Java developers want to think of them as public methods, then fine.

It is my belief that a Java developer will never excel with the webMethods Platform until he can let go of the Java mentality. There is a greater “personal growth” factor in spending a full day wrestling with the webMethods Built-In Services than writing the service in Java in an hour. The sooner a developer becomes comfortable using the product, the sooner he will produce creative solutions that will increase reusability and, therefore, ROI.

That said, there are definitely cases where Java code is required. The more experienced developer will recognize these cases upon reviewing technical requirements; a newbie will not. The newly-trained developer should not take a “Java First” mentality at any cost. It may produce immediate results but it will slow testing cycles and future enhancement cycles.

Because Integration Server has a larger set of Built-In Services than Enterprise Server has Operation Templates, there is significantly less Java coding required for IS projects. The range is usually between 15-20%, in my experience. It should be noted that Trading Hubs will require less Java because of the strength of the Trading Networks product – probably 5-10% and maybe even less.

Enterprise Server is not so kind (relatively!). My experience says 20-25% Java code in an absolute worst case scenario. What’s more important with ES projects is to recognize the limitations of the product. Equally important is to recognize the strengths and to exploit them. Again, this comes from experience.

I would guarantee that if you ask a Java developer to look back at the Flow/Components built for his first ever webMethods project, he would blush and ask for a do-over. Too much Java code, they’ll say. Guaranteed. And this is completely natural because there is a measurable skill set growth from project-to-project for all webMethods developers – just like with anything else in life.

Tara nailed it – small percentage of the code, large percentage of the effort. Therefore, minimize your Java code to minimize your effort (and dollars).

Hello everyone. I finally have to chip in my two cents on the subject. I’ve been biting my tongue for a while as I usually don’t like to rain on wMs parade. My comments will be more in regards to wMES or wMB as it might be called today.

My main gripe with wMB and the GUI development that wM is pushing is the lack of support for version control and component based breakdown. The only component you can version is the entire ADL export.

I am personally a big fan of separating the business logic in their own adapters a la ATC. When java is used to build the logic for ATC adapters, then development with multiple team members can be supported by development tools that have been tried and tested over time. This means having java developers that have worked in a team environment. This could even support iterative development and builds. I think a lot of us knows how difficult it is to merge the work of multiple developers when all the work is stored in the broker. There is a thread right now discussing a migration that takes 13 hours. This is unheard of in a development environment where java is used. I am rebuilding an entire J2EE project using ant in about 43 seconds. The wMB tools are great for smaller projects (in size and number of developers), but leaves a lot to be desired when it comes to supporting a structured development effort and process.

I need to add a small disclaimer, I have not used the latest GUI tools. However, I doubt the latest solves these problems as gracefully as IS. wMB has to solve the problem of distributed processing whereas IS resides on a single box.

I really liked the broker and the communication it supports. I would love for a java/C++/whatever framework to be developed to be used in conjunction with it.

Comments? Please!

Andreas

> My main gripe with wMB and the GUI development that wM is
> pushing is the lack of support for version control and component
> based breakdown.
…
> There is a thread right now discussing a migration that takes 13 > hours. This is unheard of in a development environment where
…
> I doubt the latest solves these problems as gracefully as IS.

IS change management isn’t much better. Packages management is useful, but changes made to Trading Networks (Profiles, Processing Rules, Doctypes, etc) have to be copied over manually to the deployment machine very very carefully and then tested. I’d love to hear if anyone has automated this.

IS Deployment is the part of WM “development” process that I dread the most. Many times, I’ve manually “deployed” a processing rule, just to find it screw up things because of a tiny setting I missed.

Hi Sonam,

Just curious…

I assume you referred to WM4.6’s change management facilities. Have you had the opportunity to check them out in version 6? If yes, are you more impressed now? Anybody else perhaps?

Cheers,
Jonathan