Discussions

News: Tibco Launches ActiveExchange 3.0 Integration Platform

  1. Messaging and Integration vendor Tibco today launched ActiveExchange 3.0, their latest version of their mature integration platform - now providing built-in support for Web-services specs including SOAP, WSDL, XML Signature, and ebXML Messaging 2.0. Unlike many of the new WS integration products, Tibco also supports RosettaNet, EDI, and more.

    Read Tibco Targets Web-Services Integration.

    Read today's press release.

    Threaded Messages (43)

  2. How does one get a copy of software like this, to play with and learn? Ain't a download button that I can see, as is the case with so many components with the "enterprise" tag.
  3. I think TIBCO is a company very closed and it's difficult to download his products and documentation. Specially, the products about EAI.

    Regards
  4. What other tools exist in the same space but are more accessible for learning and eval?

    Thanks,
    Mike.
  5. BEA Weblogic Integration, you can download all documentantion and an eval license.
  6. Other established EAI tools include:
      Vitria
      WebMethods
      SeeBeyond

    I do not think though these are easily available for dowload.
  7. You can download the IBM MQSeries family of products from the website. Unfortunately you may have difficulty in finding the proper product, particularly if you wish to use Java. It's a very poorly-designed web site.
  8. I'm also not sure if you can download anything beyond the basic MQ software -- like the MQ Integrator app (which is more of an EAI offering, vs. straight messaging). Also, it would be nice if they packaged up the base MQ product, the Java API's, and the Publish/Subscribe extensions, since you currently have to download them all separately.

    Mark
  9. There are other companies out there working with Web Services and BPM. I work for Versata, and we have been quite active in combining process and Web Service Technologies - as an introduction to this you can check out http://www.versata.com/versata.vjsp?pageid=399.

    We are particularly focused on standards and are active with the BPMI on the BPML standard for the representation of design time business processes (represented at a Board level through our chief architect Matthew Pryor) and our process engine currently uses Wf-XML for run time execution of processes. We have extended this with a web service interface to the Wf-XML message format to stop, start, query and update a process at run-time.

    Using this technology you are able to orchestrate web services and we believe that this is the way forward for enterprise web service arhictecture.
  10. EAI products are generally not available for download since they require special training using the tools and are not in particular friendly to Java-skilled developers. Adding Web Services support to EAI tools does not change that. It is highly unlikely that developers can be successful with an EAI tool they just downloaded from the web site without proper training. EAI vendors would not want to set themselves up for failure this way and undermine sales opportunities.

    Check out Web Service Orchestration (white paper on www.collaxa.com) where using a JSP-like abstraction for process orchestration can be learned within one day by Java developers. The product is downloadable, of course.
  11. Doron Sherman wrote:

    "EAI products are generally not available for download since they require special training using the tools and are not in particular friendly to Java-skilled developers."

    That view is largely bollocks. Tibco Rendevous is no more difficult than JMS is. Integration Manager and Object Broker are no great problem either.
  12. Having worked for Tibco previously, I can tell you that most of their products are avalable for evaluation download. Although not always in an obvious location. But certainly not all the products are available for download. Active enterprise is a suite of at leat four or five products, and each tool requires a seperate learning curve.

    Also all Tibco software is proprietary and not open source. It is mainly used in finance, energy, and telcomm integration and process automation initiatives. So unless you work in one of those environments, you probably won't have the luxury of testing out their products like you would an app server or ide. Another obstacle is a very small number of user groups and "greek" product documentation.
  13. I wonder if anyone can point to a single EAI product that ever achieved grassroots adoption by developers...???

    What is the point of making an EAI tool available for download if developers cannot master its use beyond the software install? I am not referring to basic messaging infrastructure that sports a standard Java interface like JMS.

    Programming process orchestration through Web Services should be as easy as using a JSP. If you are a Java developer, why would you need to learn a proprietary tool environment when a standard JSP-like abstraction exists?

    (Hint: check out ScenarioBeans at http://www.collaxa.com)
  14. "If you are a Java developer, why would you need to learn a proprietary tool environment when a standard JSP-like abstraction exists?"

    Probably because almost no system that you would actually integrate with has a web services interface ready to go. Instead, most of them are either custom systems or have their own proprietary API set.

    Mark
  15. "If you are a Java developer, why would you need to learn a proprietary tool environment when a standard JSP-like abstraction exists?"

    Because thats where the big bucks are! In a bad economy where it is even difficult for good java developers to get a gig, seperating yourself from the masses is paramount.
  16. Actually, putting a web services face in front of a legacy API is done relatively easily today. This is why the core
    benefit of EAI tools, i.e., the availability of custom adapters is slowly but surely fading.

    The bigger problem is publishing and especially consuming of enterprise (i.e. asynchronous) web services. The consumption side requires orchestration, which is the ability to coordinate, manage and monitor a collaborative
    application or a business process comprised of loosely-coupled components (like Web Services).

    If you could have a JSP-like abstraction for orchestrating web services, would it make more sense to use it as opposed to learning a proprietary tool environment? Taking a look at the history of application server technology is quite enlighting in that respect. JSP is what made publishing web pages so ubiquitous. In contrast, EAI tools are only used by the skilled few who can afford the learning curve and vast expense. What about the rest of the Java developer community and their ability to address integration problems?
  17. "In contrast, EAI tools are only used by the skilled few who can afford the learning curve and vast expense. What about the rest of the Java developer community and their ability to address integration problems?"

    Doing an integration using JMS is relatively easy and simple. Adapters at both ends. You may actually want to do this as a Web Service using SOAP to encapsulate the message, using JMS as the wire component. Tibco's Rendevous API and Java/C++ SDK products are no more conceptually difficult than using JMS, though getting decent examples and third-party documentation to supplement the lousy Tibco manuals is far more difficult for the Tibco API's than for JMS.

    Where Tibco has the functional advantage is in workflow products such as InConcert and Integration Manager and in message brokers like (drum roll please....) Message Broker! They also have a Repository product. All these are relatively difficult to work with out of the box.

    For a JMS-driven EAI system you must write your own workflow managers and messge brokers for the nonce, though I expect the market ot respond quickly with third-party products. Perhaps even a Tibco port of their products to the JMS format.

    Doing an automatic workflow manager should be relatively easy though not as flexible than the Intergration Manager product. Data conversion akin to what Message Broker does should be even easier if you don't insist upon complete flexibility. Something like the Repository ought to be even easier to do.

    Did I mention expense? Tibco charges a bomb for their products. I think using a simpler 'roll-your-own' approach has the potential to save a lot of cash for any enterprise.
  18. "Where Tibco has the functional advantage is in workflow products such as InConcert and Integration Manager and in message brokers like (drum roll please....) Message Broker! They also have a Repository product. All these are relatively difficult to work with out of the box."

    The reliable and scalable messaging layer is a must-have for delivering business processes and workflow automation and the emerging service-oriented collaborative applications. Indeed, the upper layer that deals with the application functionality is more interesting. The value provided by solutions at that upper layer, such as process or workflow monitoring, reporting, audit trail, etc is crucial.

    JMS is easy enough for handling messages but you get none of the features listed above. When developers roll their own solution, do they build monitoring, reporting and audit trail capabilities into each custom application? Not likely. But even at a more basic level, when you deal with JMS directly, you still need to worry about how the application will be able to scale (e.g. across multiple CPUs), how multiple messages sent on behalf of consumers will be correlated, how to recover upon failures (if the JMS call takes hours or days to complete, how do you save the context, e.g. in a database, to ensure you can recover), etc.

    Integration solutions, such as Tibco, provide these capabilities but there is a big problem with the learning curve, the proprietary products stack which requires special operations skills for deployment and maintenance and ultimately, a very high cost of ownership.

    What is needed is a new approach to the problem, called Web Service Orchestration. It's comprised of a JSP-like abstraction for programming orchestration logic (analogous to a JSP which is used for programming presentation logic) and an orchestration container which is the run-time environment for these orchestration components. The components should carry enough meta-data that will be reflected through the orchestration container during execution to provide monitoring, reporting, audit trail, etc.

    History may repeat itself. Back in 1995, Forte was the high-end proprietary toolset and claimed that they can easily address the broad market when application server startups popped all over the place. Today's EAI tool vendors claim that they can do the same with the advent of Web Services.

    The introduction of JMS and other Java interfaces to XML and Web Services prompt developers to first roll their own solutions (this would be equivalent to writing CGIs back then) only to realize that they reinvent the application infrastructure over and over again for each project in a sub-optimal manner. Subsequently, application servers took the helm as the dominant way of web application delivery.

    I believe we would see the emergence of a Web Service Orchestration Server as the dominant way of delivering process-centric applications sporting a programming model that is well-suited for assembly and coordination of loosely-coupled services over asynchronous communication protocols.

    Doron.
  19. "I believe we would see the emergence of a Web Service Orchestration Server as the dominant way of delivering process-centric applications sporting a programming model that is well-suited for assembly and coordination of loosely-coupled services over asynchronous communication protocols. "

    Somthing like a version of Integration Manager for Web Services? Hmmmm.

    What about piggy-backing SOAP over Tibco Rendevous messages rather using than HTTP for transport messages? I have this vision of universal adapters using SOAP and standard XML parsing tools which will serve out Web Services coming in from whatever transport. Http, JavaMail, Jini, JMS, Rendevous, whatever.....

  20. "What about piggy-backing SOAP over Tibco Rendevous messages rather using than HTTP for transport messages? I have this vision of universal adapters using SOAP and standard XML parsing tools which will serve out Web Services coming in from whatever transport. Http, JavaMail, Jini, JMS, Rendevous, whatever....."

    +1.
    There is indeed an opportunity with Web Services to hide the details of the transport from developers. The only case where the developer might want to know is when an exception occurs
  21. "Somthing like a version of Integration Manager for Web Services? Hmmmm."

    I think that orchestration is more about adopting a loosely-coupled architecture than a tool:

    * J2EE offers an architecture for building tighlty-coupled applications. J2EE includes component model, transaction model, security model, naming, etc...

    * Web Services will emerge into an architecture that allow enterprises to build process-centric loosely-coupled applications: XML, SOAP, WSDL are just a few steps...Transaction (BTP), security, etc... This is what we call orchestration.

    Once the infrastructure will be in place, tools will emerge to streamline and automate the production of loosely-coupled process-centric applications. J2EE will also probably evolve to embrace that emerging loosely-coupled architecture.

    Tibco is well positioned to be a key player of this emerging trend because as you mentioned reliable messaging is a fundamental requirements.

    Edwin
  22. "Tibco is well positioned to be a key player of this emerging trend because as you mentioned reliable messaging is a fundamental requirements."

    Yes, but Tibco is going to have to migrate many of it's programming tools from the current proprietary API and SDK into JMS. IBM has (apparently) made more progress in this area with MQSeries. IBM also has a major advantage in having a competitve App Server product which is being integrated with the MQSeries JMS products. Tibco's advatage are their suite of tools including Hawk, InConcert, Integration Manager, and Object Broker. But to my knowledge none of these tools are currently useful in the JMS space currently.

    Tibco mustr port their tools into the JMS space or run the risk of being swamped in the movement to a new standard. Tibco cannot afford to try to defend RV with the tools suite, because other vendors will be overjoyed to fill the vacuum. I've seen it happen before.

    Tibco will need to move more into the area traditionally covered by App Servers to make good in this market. I could see Tibco merging with a BEA or being bought by HP with this in mind.

  23. I think that your analysis is right on! The next 2-3 years are going to be interesting as we see large and small companies compete for building the infrastructure needed to deliver and manage loosely-coupled applications on top of JMS and Web Services! As Doron mentioned earlier in this thread, a similar battle was fought in 1995-1998 for the emergence of J2EE and the application server.

    -Edwin
  24. What worries me about Tibco is that I see little progress toward moving into JMS. They seem to have few plans apart from a single JMS product, which is not being pushed as far as I can determine.

    They are the market leader with their RV bus and suite of products. Technically IBM is ahead in number of sales, but a lot of that is old MQSeries. IBM moved swiftly into JMS and seems to believe that the future is with the JMS product.

    In contrast, Tibco seems to be sitting on it's hands, perhaps because JMS is much more of a direct competitor to RV than it is to MQSeries. IBM appears to regard JMS as an opportunity to carve into Tibco's niche while Tibco seems to regard JMS more as a threat than an opportunity, at least thus far. Tibco's response reminds me in a way of Sun's response to Motif during the early 90's. Let's hope that Tibco iss faster to quit fighting JMS and instead try to become the premier JMS vendor.

  25. The full blown EAI tool may seem expensive (in my guess $0.5-2 mil) but it surely beats cost of the development and maintenance of custom application based on simple messaging or even workflow engine. I've seen a project where the semi-custom solution based on "workflow-engine" from leading J2EE vendor costs almost 10 times more then what EAI would cost.

    The only situation where I think the custom solution would be cheaper is the simple integration of less then 4 apps.

    My point is that JMS based solutions are simply not there yet. Real EAI tools (Tibco, Vitria etc.) have been around for years. You get:

    - robust (=fast) messaging engine (usually written in C++ with Java and C APIs),

    - GUI, which can be efficiently used by Business Analyst rather then programmer,

    - GUI that helps with workflow mapping, design of message transformations, design of error handling, monitoring and even debugging on the fly,

    - moreover GUI actually works ;-),

    - tons of prebuild connectors to number of business applications (ERP, CRM, OSS),

    - database driven workflow engine,

    - web workflow integration for human-based tasks,

    - monitoring and reporting tools that can tell you where your business messages are

    So it is whole truck plus service station as opposed to just the engine. Most vendors take it this stack even further by selling preconfigured solutions for existing B2B echanges (like RosettaNet). For me it is a proof that applications really work.

    Regarding properitary skills - true but not as bad. My experience with Vitria was very positive. Yes, it requires some specific skills, but they are not so difficult to acquire for experienced developer (I can complement Vitria documentation as good to very-good). In return you get few times higher productivity. One experienced programmer is for sure cheaper then 4 unexperienced once churning out custom JMS solution ;-).

    My 5 cents,

    Michael
    http://ITSolv.ca

  26. Michael,
    Nothing beats real world implementation. Did you ever got a chance to play with the BEA Process Integrator? It seems to have all the features you are mentioning in your message except the long list of adapters. I was wondering how it compares with more established products such as Vitria.

    Also, based on your experience, do business analyst really build those complex applications you are referring to?

    In your opinion, what prevents Vitria from become a mainstream product? How come there is so much more momentum behind JMS?

    Best,

    Edwin
  27. "Also, based on your experience, do business analyst really build those complex applications you are referring to?"


    Forgive me for answering. There seems to be an intermediate level between pure business analysts and hard core programmers. They specialize in tools like Message Broker and Integration Manager in the Tibco suite. InConcert is a specialty all it's own.

    "In your opinion, what prevents Vitria from become a mainstream product? How come there is so much more momentum behind JMS? "

    Basically one thing. I've been over to the Vitria site (some time ago) and I couldn't find anything but marketing blurbs and 'white papers'. No downloads or anything. Not even downloadable documentation. There are plenty of products supporting JMS with free downloads.

    Even if I want to know Vitria (and I am curious) how ever am I going to learn anything about it?

  28. No I did not use the BEA project hands on, but I have seen the actuals (budget) of the project that used one and I am not impressed.

    I believe there is momentum behind JMS in the J2EE market, hence there is much momentum behind JMS on this site. Also BEA and IBM use their good and mature products to cross sell their messaging applications. It does make Process Integrator and MQSeries very popular but does not necessarily make them good. For example Oracle makes best database and uses it to very successfully promote rather shabby CRM and ERP.

    JMS is natural extension of the J2EE and similarly to J2EE has a very low level business API. I have not seen yet real and popular ERP application (or any other application of similar business complexity) based on J2EE, similarly I do not expect real EAI tools based on JMS soon. It just takes time. In my experience EAI complexity is 99% business complexity (message transformation, mapping, routing, error handling, flexibility to reconfigure without writing custom code ).

    For now tools with mature business interfaces may be better suited for the job. Once you get to this point the tool requires very little coding, and is no fun at all for typical programmer. Even if the software was easily downloadable I doubt many would get excited.

    Michael
  29. Michael,

    Sometimes I am a bit unsure when I read such well-expressed opinions as those you an Doron offer. It seems to me that there is pretty much one likely place where one could acquire such opinions. On the payroll of one of the major EAI tool vendors such as Vitria, SeeBeyond, Webmethods, or Tibco. Indeed I have seen a person openly identified as a representative of one of the major JMS vendors post a response to one of my questions before.

    Most people posting with such assurance are either a) EAI vendor employee, b) blowing smoke, or c) Longstanding EAI architects like David Linthicum. I'll readily admit the possibility of a d) None of the above category.

    Not to criticize, but since I cannot independently verify the facts in this case I would like to know where your expertise and assurance is coming from...
  30. Just to make things clear.

    I DO NOT:

    - work nor have I ever worked for EAI vendor (Vitria, Tibco, WebMethods, SeeBeyond, etc.)

    - I am independent consultant and I am not in competition with any companies that try to enter EAI market (BEA, IBM)

    - I did significant EAI work, I do not work on it anymore and it seems unlikely I will in the near future

    I DO:
    - like to complete the projects on budget, with maximum business value to the client.
  31. "For now tools with mature business interfaces may be better suited for the job. Once you get to this point the tool requires very little coding, and is no fun at all for typical programmer. Even if the software was easily downloadable I doubt many would get excited."

    You make a good point, Michael. JMS coding is far too low level to make it effective for solving the vast majority of applications that address business process integration. The trick is to avoid the 4GL syndrome, where you climb to a higher level of expression, usually tightly coupled with a graphical tool, but without losing the flexibility you get from a 3GL.

    In the presentation logic arena, JSP has proven that Java (3GL) can be elevated to an abstraction that is congruent with the problem domain (dynamic web pages). The equivalent approach would be a "JSP for orchestration logic", a Java-based abstraction that is easy to learn by Java developers (and preserving the fun of programming too...) and does not sacrifice flexibility, all that while sporting a semantical level which is congruent to the challenge of orchestration.

    Orchestration is essentially coordination, management and monitoring of asynchronous conversations with loosely-coupled services (i.e. XML and JMS Web Services). The idea is to provide a programmatic abstraction in conjunction with an orchestration container that takes the application fabric hassles away from developers. Creating the fabric yourself as a developer for each custom application is not cost effective (check out this white paper which outlines the challenges involved in implementing orchestration for a process-centric application: http://www.collaxa.com/pdf/tech_wp.pdf)

    It's a free country, orchestrate responsibly :)
  32. I read the white papers on the Collaxa website. Doron and Edward are two the the co-authors, BTW.

    It appears that the Collaxa product is a workflow manager for Web Services. In my experience it appears closer to InConcert than to Integration Manager in the Tibco scheme of things.

    One thing the white paper didn't seem to tell me is what Collaxa can do for me that I cannot program for myself. Any takers on that one?

    I'm still not sure where (and who) Michael is coming from. Specifically which company. It's nice to know. When someone writes that it's better to use purchased tools than write the software on your own, they may well be completely sincere, but they often also work for a tools vendor. And disclosure in that case is a good thing, so that I can weigh their opinions in the context that they come from.
  33. "It appears that the Collaxa product is a workflow manager for Web Services. In my experience it appears closer to InConcert than to Integration Manager in the Tibco scheme of things.

    One thing the white paper didn't seem to tell me is what Collaxa can do for me that I cannot program for myself. Any takers on that one?"

    Don, the Collaxa product is available for download (http://www.collaxa.com). You're hereby cordially invited to evaluate it and post your impressions with respect to traditional tools (like InConcert) and to the benefits you see it providing as compared with the build-your-own approach.

    Doron.
  34. Thanks Doron.
  35. Michael Szlapa writes:

    "My point is that JMS based solutions are simply not there yet. Real EAI tools (Tibco, Vitria etc.) have been around for years. You get: "

    ...

    - GUI, which can be efficiently used by Business Analyst rather then programmer,

    - tons of prebuild connectors to number of business applications (ERP, CRM, OSS),

    ....

    So it is whole truck plus service station as opposed to just the engine. Most vendors take it this stack even further by selling preconfigured solutions for existing B2B echanges (like RosettaNet). For me it is a proof that applications really work. "

    The problem sometimes is that there is less than meets the eye here. I cannot speak for Vitria, SeeBeyond, or Webmethods here, but I do have experience with the Tibco suite of products. Problems with Tibco:

    - The 'tons of prebuilt connectors' are written by tools vendor, not Tibco. They vary WIDELY in quality and usability. Some are useful, some are moderately useful, and some are useless time-wasters which must be replaced once their problems have been exposed.

    The impression which Tibco marketing tends to give is that these 'adapters' are pre-built components which can just be configured and plugged in to a framework a la VB components. Not so.

    The degree of back-end integration of many software packages is laughingly primitive. I've done integration where I've had to directly load DB files, use utilities to load these files, and build to strange XML file formats to simulate the build up of choices from a series of screens from a user interface.

    Even when a tools vendor HAS thought of back-end integration and done something, too often they have chosen to do it in Tibco format, which is pretty useless for anyone using another SI suite.

    Finally, not every organization needs a mature, full-featured SI product to connect everything with everything. Often these products are oversold and don't deliver the business value to justify the price tag.

    They can be rogue elephants of solutions in search of problems to solve. It seems to me that the JMS/MD-EJB/XSLT archictecture can be every bit as viable an approach, a lot cheaper, and can be built up on an as-needed basis. With Tibco SI I constantly see the 'big-bang' approach being favored. Possibly because of the sheer cost of the tools as much as anything! I would like to see Tibco go to a high volume low price tag marketing model, because that is the way I see the world going.
  36. I would agree with that. As I stated earlier there it probably not make any sense to use EAI tool if you have less then 4 apps to integrate and/or your business rules (message translation and routing) are easy.

    I would also agree that these tools are sometimes oversold, but it is a case with most expensive tools.

    My experience with prebuild connectors has too been mixed. There was one that did not work and I had to be re-written. Still the custom connector would plug in nicely to the overall architecture, allowing others to understand it and monitor it while it is runs.

    These are the problems no doubt about this. My opinion is that the reason the new JMS based tools will have similar problems once they reach similar level of complexity. It is kind of difficult to have wide-spread connector problems if you have less then a dozen connectors ;-).

  37. Michael Szlapa writes:

    "I would agree with that. As I stated earlier there it probably not make any sense to use EAI tool if you have less then 4 apps to integrate and/or your business rules (message translation and routing) are easy."

    "I would also agree that these tools are sometimes oversold, but it is a case with most expensive tools."

    What we're seeing in our SI marketplace is that big projects are nearly impossible to sell, but customers are willing to start small and work upwards.

    The problem with the Tibco pricing model is that starting small is unrealistic. I am told that the cost of Tibco licenses for a minimal system amount to about $2 million and a medium-scale system can run $3 million or more. This before a single integrator lifts a finger.

    On some projects this is peanuts. Tibco contends that their pricing is a bargain compared with what it would cost to build the full capabilities from scratch, and I have to agree. The problem is that our customers in telecoms don't HAVE money to invest in big systems. They want small systems which have a high and swift ROI assured

    With the license costs a Tibco-based project must think big from the start and ramp up quickly to justify the investment. I haven't the slightest idea how this compares to competitors such as WebMethods or Vitria, but I believe Webmethods costs about 90% less.

    The JMS/MD-EJB/XSLT architecture can be started with virtually zero software investment at first, and scaleup costs are relatively minor. The problem with this architecture is the lack of enterprise-level tools such as message brokers.

  38. Don wrote:

    "With the license costs a Tibco-based project must think big from the start and ramp up quickly to justify the investment. I haven't the slightest idea how this compares to competitors such as WebMethods or Vitria, but I believe Webmethods costs about 90% less.

    The JMS/MD-EJB/XSLT architecture can be started with virtually zero software investment at first, and scaleup costs are relatively minor. The problem with this architecture is the lack of enterprise-level tools such as message brokers."

    We're currently involved in a project in the financial services space where WebMethods is about to be selected. The price tag for the software only is $4MM. The customer owns BEA WebLogic Server already but would not consider working with raw JMS/WS due to operational needs to manage and monitor the business process applications in production. We are coming in to this project with a $100K-$150K price tag for the Web Service Orchestration Server, running on top of the BEA WebLogic Server and providing the enterprise-level management and monitoring (a fringe benefit of developing with Scenario Beans).

    Doron.
  39. Doron Sherman writes:

    "We're currently involved in a project in the financial services space where WebMethods is about to be selected. The price tag for the software only is $4MM."

    Four Million bucks, correct? That seems comparable to Tibco, perhaps higher!

    "The customer owns BEA WebLogic Server already but would not consider working with raw JMS/WS due to operational needs to manage and monitor the business process applications in production."

    That seems reasonable. I wonder what their ROI projectstion look like? If all they are doing is monitoring I have to wonder whether it's not possible to build sufficient monitoring for a lot less than $4 million? Oversold?

    "We are coming in to this project with a $100K-$150K price tag for the Web Service Orchestration Server, running on top of the BEA WebLogic Server and providing the enterprise-level management and monitoring (a fringe benefit of developing with Scenario Beans)."

    Your pricing seems most reasonable on a build or buy basis. I doubt that one could replace it for less. Congrats, and continue to stay lean....

  40. Don wrote:

    "That seems reasonable. I wonder what their ROI projectstion look like? If all they are doing is monitoring I have to wonder whether it's not possible to build sufficient monitoring for a lot less than $4 million? Oversold?"

    I doubt that the $4MM can be justified on a product value basis for the customer but the fact is that all vendors, IBM (MQSeries, CrossWorlds), WebMethods and... BEA (WLI) came with a similar price tag and the customer would not consider building the solution from scratch with JMS/J2EE due to the reasons mentioned earlier.

    The EAI/messaging tools provide routing and transformation functions which are valueable but monitoring is needed more at the application-level (business process execution) where Scenario Beans running within the context of a Web Service Orchestration Server provide this type of activity monitoring and operational visibility (for a fraction of the EAI tools price tag).

    Doron.
  41. Doron, sorry for giving you a hard time earlier. I work at a Si shop and am tired of seeing projects die because of Tibco's license fees. So I have been fighting for using a much cheaper approach utilizing cheaper commercial products and open source. The Tibco dinosaurs around here are fighting any attempt to use cheaper architectures, so we have no new work coming in..... Arggggg!

    I take it out on the tool vendors around here!
  42. Oh, not a problem, this makes for a very interesting discussion and I'm sure the points you've raised are quite useful for other SIs involved in implementing business process integration solutions.

    Politics aside, if customers want to solve their business process integration challenges in a cheaper, faster and simpler way... AND... there are qualified SIs eager to leverage their Java skills to address these problems... AND... there are vendors (like Collaxa) that offer viable solutions that are 1/10th of the price of an EAI suite that can be implemented in 1/5th of the time... the paradigm shift towards using ubiquitous technologies such as JMS and Web Services will occur.

    $.02,

    Doron.
  43. Just had to add my 0.02 to this discussion at this point:

    <QUOTE>
    If you could have a JSP-like abstraction for orchestrating web services, would it make more sense to use it as opposed to learning a proprietary tool environment? Taking a look at the history of application server technology is quite enlighting in that respect. JSP is what made publishing web pages so ubiquitous. In contrast, EAI tools are only used by the skilled few who can afford the learning curve and vast expense. What about the rest of the Java developer community and their ability to address integration problems?
    </QUOTE>

    This layer would have to be fully testable. JSPs are
    not testable artifacts, as such, which is one of the
    reasons why all the fuss on getting code out of JSPs
    and into ordinary classes (a.k.a. Business Objects).

    Not only are JSPs not testable, they don't encode the
    structure of the application so that it is understandable.

    So, a tag layer that expressed the structure of the
    application? It hasn't been invented yet. It would
    have to be fully testable artifact, *and* have wide
    enough acceptance to be affordable.

    Why do this layer at all, when we've already got
    the programming language with cheap tools widely
    available? Looked at this way, it would
    seem very costly.

    IMHO the concept of using tags to access web services
    contructed by either a high-level tag-based language
    or a web services gui-builder like thing, is expensive
    and not a sustainable business.

  44. Rich wrote:

    "This layer would have to be fully testable. JSPs are
    not testable artifacts, as such, which is one of the
    reasons why all the fuss on getting code out of JSPs
    and into ordinary classes (a.k.a. Business Objects)."

    Rich, you are absolutely right, testability is a must. If simple synchronous interactions handled by a JSP require testing/debugging of presentation logic, you bet it is going to be mandatory for any abstraction used for orchestration logic, since the latter entails coordination of asynchronous conversations with loosely-coupled services for delivering long-lived multi-step collaborative and/or transactional business processes. The JSP-like abstraction I'm referring to makes use of a few orchestration tags in order to elevate the Java programming to a semantical level of a business processes AND enable procedural encoding of non-linear orchestration logic. I know this sounds rather obscure without seeing the code, so my invitation is extended to you as well to download Collaxa's Web Service Orchestration Server and take a close look at Scenario Beans. (http://www.collaxa.com).

    I have to agree with your other statement as well concerning wide adoption. This is where standardization and applicability to mainstream Java developers is called for. This is something that proprietary tool environments cannot achieve.

    Doron.