Slashdot Mirror

The same thing that happens when you want to leave any other development platform in existence.

Wow. You really don't understand this?

If the platform is based on a standard (rather than just parts of it), then you can leave without much penalty to anyone else who implements the same standard.

I have very little desire or need to be migrating.

Trust me, it happens.

Perfect example. We use a Java servlet container. One day we discover it has a bug. We go to the vendor. The vendor refusese to fix the bug. We switch to another container. Presto. The bug is gone.

Imagine, too, that if there is only one vendor and you are locked into them, they no longer care so much about fixing bugs or keeping you happy at all, because they have a monopoly, and they act like it. And I've had exactly this problem with MS. I catch IIS blowing up? I debug it with MS support, who actually talk to me because the client is fortune 50, and what do they say when we catch them red-handed? "Sorry, we know about that bug. It's marked WONTFIX."

Imagine never having to hear that kind of thing again, because now you have a market instead of a monopoly. That's what standards do. That's what scares MS to death.

accept the miniscule risk that we *may* have to rewrite some code should we choose to migrate.

As you get more experience, you realize this no longer sounds so good when you have 400,000 lines to worry about.

In time, I'd say it's pretty reasonable there will be equal demand sometime in the near future.

Man just listen to yourself. That's a pretty contrived way of admitting that there is greater demand for Java than C#.

And by the way, if you really think C# will equal Java for job demand in the near future, I would take that bet, depending on when you think that is. Within 5 years? 10?

If you are in need of that much performance,

In the enterprise the term is "scalability."

I don't think it would make a significant difference what language you did use -- It would depend on the compiler.

Unfortunately this isn't actually true. The topic has been covered extensively.

You know, I don't actually see a lot of what you like in .NET that isn't also in Java. Form editors for GUI work? Java has them. Attributes? Java. Reflection? Java. ADO? Java's Hibernate is a great persistence mechanism... Remoting? Java has it. In fact I did some Java to .NET remoting the other day with glue. It took about 5 minutes to get going.

I find Java development tools like Intellij Idea significantly superior to anything available for C#/.NET. I would go so far as to say it basically defines the state of the art in development tools. I've never seen code-as-structured-DB, effortless search and refactoring integrated so completely in anything before. You should seriously check it out. (As it happens the Jetbrains guys have ported some of their refactoring tools to C# - I think the product is called Resharper, worth checking out out as well...)

The vastly greater number of people doing Java development, and its many-year lead in the space have resulted in a rich ecosystem of vendors, open source, and free software projects that are totally unmatched in the .NET world. The result is that there is a lot of great code out there to use (even BSD licensed) and a lot of interesting research going on in the space...

Congrats! Looks like the boss sees dynamism in you - give it your best effort, but be realistic and don't be afraid to ask money to implement an effective solution.

EDI can be mind-numbing. You'll need attention to detail, clear headed thinking, very good and very tightly controlled documentation, and a well thought out and documented processes for new EDI-partner implementation and existing-partner transitions.

For software, try getting something that simplifies life as much as possible. If your company is willing to spend a fair bit consider buying an off-the-shelf solutions.

webmethods: http://www.webmethods.com/ is a good solution. I've been using it for 5 years at work. It's got a good name since lots of people have had success with implementing EDI with it. The best open-to-the-public webMethods user website is http://wmusers.com/ - even if you don't use webMethods, searching that site for terms like "X.12" and "EDIFACT" will give you a sense of how others implement EDI. Here's an article by a friend of mine: "Create Positional Flat File Templates for the WmEDI Parser"
http://www.wmusers.com/ezine/2003apr_rmoser_1.shtm l
Note, this article is for ver 4.6 - I understand the current version of webMethods (ver 6.5) has a different, graphical, EDI parsing engine. Other articles:
http://www.wmusers.com/ezine/archives.shtml

The good thing about webMethods is it's got a visual-progamming IDE that simplifies life a great deal, and that it's really a webservices/XML-centric solution that also handles EDI - so in future, you can move forward to cXML, xCBL, ebXML, etc, which are XML-centric standards. (For the respective websites just append .org to these names). They also have support for stuff like RosettaNet and RFID, but I'm not familiar with the specifics.

The one thing webMethods does not do well is FTP file spooling for pickup - it does built-in FTP clients and an FTP server (can only submit documents to it), plus VAN and SFTP support. For FTP spooling, you'll need to run a separate FTP server.

webMethods competitors include TIBCO, Commerceone (conductor), Microsoft (with Biztalk), IBM and BEA (not sure what). There are also the old distinguished EDI translators like GenTran.

Google shows up a couple of open-source solutions as well:
http://edi4j.sourceforge.net/
http://mec-eagle.sourceforge.net/

Hm, maybe I should do a sourceforge search. Aha, quite a few matches:
http://sourceforge.net/search/?type_of_search=soft &words=edi&imageField.x=0&imageField.y=0
Don't know how good these are though. If you evaluate them, try posting back here if you can.

Whatever solution you choose, when you do build a solution, try making a 3-layer
solution, with a middle layer of canonical data structures isolating the B2B/EDI standard from your backend-system standard. For eg: as mentioned in my article here:
http://www.wmusers.com/ezine/2002jul15_schauhan_1. shtml

Also, no matter how well you implement a standard, you'll always come across situations where you need to customize a B2B/EDI implementation because your trading partner sees the standard differently than you do - try building an architecture that enables easy customizations. Also it's important to implement automated integration and system testing (most people only try and automate unit testing) - as you build functionality, keep adding tests to your test suite.

Enterprise Web Services

-brian

Of course, everyone who adopts Seibel's software does this.

Wow, I gotta get me some of that!

There's a chapter or two written by Charles Allen about WIDL in the XML Handbook (Goldfarb, et al).

But it's a technology that is dated now -- webMethods has moved on to B2B, and anyone who is jumping up and down about screen scraping in 2000 is just a little bit behind the times.

--brian

Hmm, let me think. "tits up"... Pretty sure that's not the case. I mean, recent financial data doesn't seem to support it : webMethods breaks even a year ahead of schedule.

In the darwinian environment of the web, the real growth in XML has been using very simple schemas. Why conform to a huge spec. when a ten line DTD will generate an output that I can pull into my database with a five line Perl LWP script. Where is all the ICE syndicated traffic or XML-based EDI? It simply hasn't happened because it has been too complicated.

I've been following XML-EDI for a couple of years now since working on EDML and the tendancy to re-invent the wheel has slowed development enormously, and yet XML-EDI really should be the killer app. We could all forget having to fill in horrible paper forms without having to spend huge ammounts on Legacy EDI systems.

90% of all paper transactions are Invoices and Purchase Orders, wouldn't it be great if someone concentrated on this and developed the killer XML based system that allowed us to issue these electronically.

Yes, Webmethods does look useful. I'd have more confidence in it if their web pages were not moronized.

this sounds like its competitive to webmethods which is a type of integration/screen scraping crawler that is being used to web-enable sap, etc. essentially you can write a script to extract content from html then turn it into xml then use xsl to transform it to your target dtd. so: you write a script to extract teh data then you go ahead and write xsl stylesheets for your client types.