Discussions

News: Enabling Web Services with BEA WebLogic and CapeConnect

  1. A new article is now online at Web Services Architect.com:
    Romin Irani takes a look at Enabling Web Services with BEA WebLogic, and Using WebLogic and CapeConnect from CapeClear.

    Read Enabling Web Services with BEA WebLogic.


    With BEA including direct support for Web Services in their WebLogic Application Server, the question we could ask now: "Is there room for Web Services toolkits?"

    (Please note - I only ask this question in the spirit of encouraging debate. I personally believe there will be room for toolkits for some long time to come, largely due to the slow uptake of new servers)




  2. I think there will be some room for toolkits, especially with respect to WebLogic.

    Their support in WebLogic 6.1 is fairly basic with more robust and extensive support appearing in their integration server (which is not cheap). While I'm sure it's a pretty good product, there will be other toolkits that offer value as well that I think can carve out a sustainable niche in the near term.

    The toolkits will probably do okay in the short term but none of us really know how much web services will catch on and how quickly these toolkits become commodotized packages so its hard to predict how long there will be room for companies basing their business model on it (and I'm sure there are a lot of them that are basing their business model solely in this area).
  3. As long as WebLogic's "full support for Web Services" does not include
    SOAP Headers, SOAP Attachments and the WSDL import statement, it is not usable for my companies requirements.

    I can't use WebLogic 6.1 to support our SOAP messaging standard
    because the SOAP header is thrown away. The same goes for supporting
    BizTalk messages. And as for ebXML messages, not only can you not get the SOAP header,
    but the business payload, which is a SOAP attachment, gets
    thrown away as well!

    And I can't use WebLogic 6.1 to support the UDDI recommended way of
    publishing WSDL-described Web Services in UDDI if the WSDL import statment is not supported.
    But that is a moot point anyways, considering that the WebLogic 6.1 generated WSDL for
    a message-based web service is next to useless because it
    defines the type of every message to be "xsd:anyType"!!!

    To be fair, though, I don't see much support in any of the Web Services toolkits for message-based
    Web Services either.
  4. It has already been said that WebLogic 6.1 doesn't fully support Web Services. It will probably be the case, that vendors are a little "behind". Maybe it would be better for BEA to partner with "The Web Service Gurus" and embed the best toolkit out there, instead of re-inventing the wheel, and not having it as shiny.

    For example, it is trivial to "install" Apache SOAP (or AXIS) into WebLogic.
  5. In order to answer this question you may want to first ask, “What is a Web Service and why is it useful?”

    A Web Service is fundamentally an abstract representation of a backend system. It may be as simplistic as a function call in a component or may represent a call across multiple technology domains and packaged applications. A Web Service may be implemented as a tightly coupled interface to implementation or not. Fundamentally, people are migrating towards Web Service standards for one of the following reasons:

         a) Interoperability (J2EE, COM, .NET, CORBA, python, etc.)
         b) Leverage ubiquitous standards for communication over an Internet based infrastructure
         c) Build a Service Oriented Architecture (SOA) that is common for Integration purposes within and beyond the enterprise. Tends to be for the purpose of B2B and EAI.

    In all of these scenarios, the logic already exists. WebLogic is assuming that you will take a programmatic approach at creating a Web Service. Why? If the logic already exists what you really want to do is simply make that logic available for consumption via this new avenue.

    One of the benefits of Web Services is its loosely coupled nature. Web Services enable you to have an arms length relationship from the service being provided to the actual implementation. Think of 100 clients communicating to a server. If you want to maintain the functionality provided by that server, you will need to update all of the clients to that server. With Web Services, this is not the case. The idea is to create a new WSDL for new or upgrading clients and retain the old WSDL for existing clients by simply mapping the original WSDL onto the new end-point.

    In conversation with a VSP, I found that one of their #1 challenges was their ability to customize services for each of their customers quickly. Simplistic toolkits that do 1:1 mappings of Java components to Web Services are not sufficient for this purpose. The needed the ability to manipulate data types and exposes new functionality without having to write code.

    In B2B, the needs of every partner tend to be different. The hope is that Web Services will more readily enable Enterprises to re-factor existing systems for the customized needs of those trading partners.

    All of the toolkits out there are a good starting point, but the must evolve to more readily enable the end-user to manipulate datatypes, interfaces, process flows, and re-factor existing systems on the fly.

    If tools such as the IONA XMLBus already exist for turning existing logic into Web Services within minutes, what is the point in hand coding a solution?

    If products like the IONA Enterprise Integrator already allow you to integrate disparate technology domains and packaged applications, what is the point in hand coding a solution?

    The Engineering Manager for the IONA XMLBus wrote an article about the need for A Web Service Container. This article will be published in Web Services Journal next month. If you want more information on Why a Web Service Container read the following: http://www.xmlbus.com/learn/tip/web-serv-container.htm

    It should be noted that the IONA XMLBus technology preview supports SOAP with Attachments.

    Rebecca Dias
    XMLBus Product Manager
    www.xmlbus.com
    IONA Technologies
  6. Rebecca

    I agree with most of your points. But the main one is web services are not particularly useful without a Services Oriented or Based Architecture. Bluntly put - to do web services, 95% of the effort is in the services part. The web part is easy.

    Our company would argue that you need a Services Framework to host your services. We would also argue that service re-use is a process problem, and hence an appropriate process is required.

    Visit our website for more information - www.enba.com.sg. We have just put the site up, so feedback is appreciated.

    Phil Bradley