This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Web Services and the fly likes Best implementation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Best implementation" Watch "Best implementation" New topic
Author

Best implementation

HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Which are the best platform implementations of Web Services that there is currently?

regards
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Best in what sense? It's really a difficult task to arrange the available products in (any) order.
I'd guess the list would have the following products on top (in some order), however:
  • Apache Axis
  • BEA WebLogic
  • IBM WebSphere
  • The Mind Electric GLUE
  • Systinet WASP
  • Oracle 9iAS
  • (Microsoft .NET)


  • Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    I can safely assume all platforms you have listed provide Java add-on toolkit for developing Web services apart from Microsoft which provides a .Net implementation.
    regards
    Lasse Koskela
    author
    Sheriff

    Joined: Jan 23, 2002
    Posts: 11962
        
        5
    The above mentioned are all deployment platforms for web services. Not all of them come with development tools beyond the necessary libraries. I don't know about GLUE and WASP but for the others, either the vendor himself or someone else provides high-quality development tools.
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Best in what sense ?
    =============================
    For a solution with : Java 2 Enterprise Edition (J2EE) compliant application servers, Visual Studio .NET, ASP.NET, Web services,Universal Description, Discovery and Integration (UDDI), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL),
    Start by identifying the differences :
    .NET is coupled tightly with the operating systems on which it runs (all of them are Windows systems), and includes a full range of features and functionality, including the database, desktop interface, browser, and everything in between.
    J2EE provides a more abstracted and loosely integrated environment than .NET, but it's one that runs on virtually any hardware and operating system platform.
    .NET integrates Web services more tightly with other Microsoft products. J2EE developers must, by definition, employ a broader approach to integrate with other comparable technologies, often from different vendors. .NET is available on Windows only, which requires the hardware to be Intel-based.
    J2EE is available on multiple platforms, including a broader range of hardware.
    Microsoft takes the .NET architecture a step, basing a large part of it on XML and Web services. This means you need to recode your existing Microsoft applications to move them to .NET.
    The J2EE community, which relies upon a large vendor community consensus-process to define and incorporate new technologies, views Web services more as an evolution of application servers rather than a technology requiring any fundamental architectural change.
    The leading Java vendors, including Sun, IBM, Oracle, BEA, and IONA, are part of an organization called the Java Community Process (JCP). Sun chairs the JCP, which chooses how J2EE defines standard features, APIs, and protocols for Java-based application servers, including Enterprise JavaBeans (EJBs), servlets, Java Server Pages (JSPs), and Remote Method Invocation (RMI).
    For J2EE, adding Web services support means adding more APIs to an already long list of APIs that integrate applications servers with other, external technologies.
    The .NET environment treats Web services as an integral part of the major pieces of .NET, which includes the .NET Framework, Visual Studio .NET (VS.NET), and ASP.NET. .NET hosts Web services as client and server technologies equally.
    J2EE hosts EJBs within a server container, which can't host Web services. Therefore, a Web service that connects to an EJB, always requires a separate Java class "proxy" or wrapper. (This isn't necessary within the .NET environment.) The additional development step complicates design and development activities. For .NET, deciding to expose a server object as a Web service is one of several options supported natively within the VS.NET framework.
    For J2EE application servers, deciding to expose a server object as a Web service involves an additional, completely separate development and deployment step.
    Supporting standards is a more significant undertaking for the J2EE application server vendor community because there's a double requirement of sorts. The internal APIs that manipulate XML, SOAP, WSDL, and UDDI must be standardized, in addition to providing support for those base standards. Within .NET, objects send and receive SOAP messages using .NET-specific APIs.
    Within J2EE application servers, vendors are moving toward adopting the Java API for XML-Based RPC (JAX-RPC), a standard API for sending and receiving SOAP messages. The goal is to standardize the APIs developers use, as well as the formats and protocols for communication transports, configuration parameters, and data interchange formats. Application servers that conform to J2EE reassure customers that their investments in application development are protected by, at least, the potential to port to another application server product (hopefully at minimal cost), and assures them that their application server products work well with external standards.
    In practice, customers don't often port applications from one application server to another after they've chosen one and deployed upon it successfully. However, customers tend to insist on J2EE conformance, just in case.
    The opposite issue plagues .NET. Despite its technical advantages, and some open source and porting initiatives, it remains a Windows-only implementation. This means customers must choose between .NET and J2EE based on the whole environment�not just the application server or its equivalent in .NET�and not simply on the basis of which environment has superior Web services support. Many end up seeking solutions that join .NET- and J2EE-based applications to get the full power of application development and deployment on Windows and Unix platforms. But such applications often become "lowest common denominator" solutions, because aside from the commonality around Web services, many differences remain in both platforms.
    Developers can use WSDL as a service description and SOAP/HTTP as a communication protocol to bridge .NET and J2EE. However, integrated security, transactions, and reliable messaging constructs (such as conversations or sessions) aren't available. Web services standards themselves are lacking in features compared to .NET and J2EE.

    Therefore, you can use Web services for basic interoperability, but not for building applications with a combination of .NET and J2EE components yet�at least, not without sacrificing significant functionality.


    And as always , specifications are open to interpretation.
    .NET and J2EE implementations of SOAP and WSDL tend to vary somewhat.
    These core Web services specifications contain optional parts that not all vendors support. The WS-Interop organization, (Microsoft and IBM ) focuses on this problem, defining and certifying a common interpretation of the core Web services specifications.
    Now that I've discussed the general aspects of J2EE, .NET, and Web services standards, I'll look more closely at the different approaches to Web services. Most application servers provide an add-on toolkit for developing Web services. However, most of these toolkits are for the Java language, which is natural given that the application servers are coded in Java. Web services are implemented using a Java class that's responsible for receiving the HTTP/SOAP message, parsing the XML, and mapping the message to another Java class or Bean that provides the implementation of the service (see Figure 1). Developers can place the implementation of the service within the Servlet engine, or within the EJB container. When you place the implementation of the Web service within the EJB container, as either a session Bean or an entity Bean, the container must be accessed using the RMI or RMI/IIOP protocol rather than the HTTP protocol.

    Figure 1 Analyze the J2EE Web Services Architecture

    In other words, J2EE requires you to create a protocol bridge or gateway class to accept a Web services invocation over HTTP and call an EJB using RMI or RMI/IIOP, adding additional complexity to the design, development, and deployment tasks. Application server containers don't support HTTP as a native communication protocol currently, while .NET servers do. Adding this capability is a primary theme for J2EE 1.4, the next major version of J2EE, which is planned for release in Fall 2002.
    The .NET environment provides a single, generic mechanism for supporting Web services in multiple languages. The common language runtime (CLR) hosts objects or components developed in multiple languages using the same infrastructure, which is basically the .NET Framework (see Figure 2). So far, VS.NET for C#, Visual Basic, and J# offer native support for Web services, and support for C++ Web services is provided through the Active Template Library (ATL). And now that Microsoft has opened up Visual Studio for additional ports, you can get third-party support for additional languages. ASP.NET, the recommended approach for creating Web services, and ADO.NET, the recommended approach for accessing data resources, also create objects that are hosted by the CLR, providing a consistent, seamless architecture.
    .NET provides a binary and XML version of its communication protocol. For J2EE, the binary protocol is RMI or RMI/IIOP, and the XML protocol isn't supported currently. However, you should note the .NET XML protocol doesn't support many of the features available in the binary protocol, .NET remoting. It includes features such as full type fidelity, references to server-side objects, and control over the lifetime of those objects. If your application needs these object lifetime services, you should implement both client and server applications using .NET remoting (see the Go Online box for additional information on .NET remoting).

    Figure 2 Assess How the .NET Architecture Measures Up

    Therefore developers can use VS.NET to develop a Web service using any one of the supported languages, and choose either the HTTP or binary communication channel. However, developing and deploying Web services with J2EE remains a two-stage process in which Web services and EJBs communicate using different protocols.
    Living Up to the Promise
    =================================
    I think it's fair to say that Microsoft initiated, and continues to lead, the Web services movement, and that the leading platform implementation of Web services is found within the .NET initiative. Although .NET represents more than just Web services, these servers are perhaps the most significant part of the initiative.
    Web services offer the promise of universal interoperability and reusable components for rapid application assembly. But these promises can't be fulfilled in a vacuum�both .NET and J2EE need to provide equivalent, or at least compatible, implementations of Web services technologies. The real difficulty for Microsoft will be to continue to find a way to promote the standards that need to be widely adopted and, at the same time, stay ahead as the J2EE community closes the gap. As long as Microsoft and the Java vendors remain at war, businesses will suffer when they have to deal with both environments in different ways, with different skill sets, and using different hardware platforms.
    The difference will be settled by the rate of adoption, and the rate at which Web services provide value�in other words, if Web services take off big-time, the Microsoft bet will pay off. If Web services prove to be a significant force for industry change, Windows developers will find the additional effort to migrate and convert existing applications worthwhile. If not, they might look seriously at migrating to alternatives within the J2EE environment, where the changes are more incremental (read the sidebar, "Understanding the Past and Future Direction of Web Services").
    You can expect the next release of J2EE, J2EE 1.4, to standardize many of the features required for Web services support that individual vendors have developed using proprietary architectures and APIs. The speed at which the Java community can advance its ideas and specifications for Web services collectively will be critical to maintaining parity with Microsoft, who often advances ideas on its own.
    Some J2EE vendors are closing the gap with .NET already by providing development environments that focus more on Web services, such as IONA's XMLBus, IBM's Web Services Toolkit, and BEA's WebLogic Workship.
    Significant work is already underway within the Java Community Process (JCP) for Web services security and transactions (see Resources). These additional technologies will provide the basis for secure, reliable, robust, and complex business applications for J2EE-hosted Web services. Similarly, Microsoft is promoting its Global XML Architecture (GXA), which offers additional Web services features such as security, message routing, and process flow.
    The fact that Sun, Microsoft, and IBM are all cooperating on WS-Security at Organization for the Advancement of Structured Information Standards (OASIS) is a good sign, but this is only one of many specifications in the Web services arena (see Resources). Microsoft should avoid requiring its software to be at each end of the communication, as it does with .NET remoting, because that's antagonistic to the Web's origins as a free, open, and completely standard place.
    Microsoft has reinvented its distributed computing development and deployment platform around XML and Web services. Therefore, the .NET platform is less mature than most Java-based application servers, where vendors have tended to view Web services support more as an add-on to a proven technology. However, Microsoft seems to have done the right thing by taking the plunge.
    Is the Microsoft .Net "embrace and extend" approach is superior to the J2EE "redesign and rework" approach when it comes to Web services ?
    Web services are sufficiently different from the features and functions that motivated J2EE and Windows DNA originally ?
    I need to find a few WebServices that I could use on a web site.
    For simple ones like map directions and payments,how do I choose ?
    regards
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Best in what sense ?
    =============================
    For a solution with : Java 2 Enterprise Edition (J2EE) compliant application servers, Visual Studio .NET, ASP.NET, Web services,Universal Description, Discovery and Integration (UDDI), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL),

    Start by identifying the differences :
    .NET is coupled tightly with the operating systems on which it runs (all of them are Windows systems), and includes a full range of features and functionality, including the database, desktop interface, browser, and everything in between.
    J2EE provides a more abstracted and loosely integrated environment than .NET, but it's one that runs on virtually any hardware and operating system platform.
    .NET integrates Web services more tightly with other Microsoft products. J2EE developers must, by definition, employ a broader approach to integrate with other comparable technologies, often from different vendors. .NET is available on Windows only, which requires the hardware to be Intel-based.
    J2EE is available on multiple platforms, including a broader range of hardware.
    Microsoft takes the .NET architecture a step, basing a large part of it on XML and Web services. This means you need to recode your existing Microsoft applications to move them to .NET.
    The J2EE community, which relies upon a large vendor community consensus-process to define and incorporate new technologies, views Web services more as an evolution of application servers rather than a technology requiring any fundamental architectural change.
    The leading Java vendors, including Sun, IBM, Oracle, BEA, and IONA, are part of an organization called the Java Community Process (JCP). Sun chairs the JCP, which chooses how J2EE defines standard features, APIs, and protocols for Java-based application servers, including Enterprise JavaBeans (EJBs), servlets, Java Server Pages (JSPs), and Remote Method Invocation (RMI).
    For J2EE, adding Web services support means adding more APIs to an already long list of APIs that integrate applications servers with other, external technologies.
    The .NET environment treats Web services as an integral part of the major pieces of .NET, which includes the .NET Framework, Visual Studio .NET (VS.NET), and ASP.NET. .NET hosts Web services as client and server technologies equally.
    J2EE hosts EJBs within a server container, which can't host Web services. Therefore, a Web service that connects to an EJB, always requires a separate Java class "proxy" or wrapper. (This isn't necessary within the .NET environment.) The additional development step complicates design and development activities. For .NET, deciding to expose a server object as a Web service is one of several options supported natively within the VS.NET framework.
    For J2EE application servers, deciding to expose a server object as a Web service involves an additional, completely separate development and deployment step.
    Supporting standards is a more significant undertaking for the J2EE application server vendor community because there's a double requirement of sorts. The internal APIs that manipulate XML, SOAP, WSDL, and UDDI must be standardized, in addition to providing support for those base standards. Within .NET, objects send and receive SOAP messages using .NET-specific APIs.
    Within J2EE application servers, vendors are moving toward adopting the Java API for XML-Based RPC (JAX-RPC), a standard API for sending and receiving SOAP messages. The goal is to standardize the APIs developers use, as well as the formats and protocols for communication transports, configuration parameters, and data interchange formats. Application servers that conform to J2EE reassure customers that their investments in application development are protected by, at least, the potential to port to another application server product (hopefully at minimal cost), and assures them that their application server products work well with external standards.
    In practice, customers don't often port applications from one application server to another after they've chosen one and deployed upon it successfully. However, customers tend to insist on J2EE conformance, just in case.
    The opposite issue plagues .NET. Despite its technical advantages, and some open source and porting initiatives, it remains a Windows-only implementation. This means customers must choose between .NET and J2EE based on the whole environment�not just the application server or its equivalent in .NET�and not simply on the basis of which environment has superior Web services support. Many end up seeking solutions that join .NET- and J2EE-based applications to get the full power of application development and deployment on Windows and Unix platforms. But such applications often become "lowest common denominator" solutions, because aside from the commonality around Web services, many differences remain in both platforms.
    Developers can use WSDL as a service description and SOAP/HTTP as a communication protocol to bridge .NET and J2EE. However, integrated security, transactions, and reliable messaging constructs (such as conversations or sessions) aren't available. Web services standards themselves are lacking in features compared to .NET and J2EE.

    Therefore, you can use Web services for basic interoperability, but not for building applications with a combination of .NET and J2EE components yet�at least, not without sacrificing significant functionality.


    And as always , specifications are open to interpretation.
    .NET and J2EE implementations of SOAP and WSDL tend to vary somewhat.
    These core Web services specifications contain optional parts that not all vendors support. The WS-Interop organization, (Microsoft and IBM ) focuses on this problem, defining and certifying a common interpretation of the core Web services specifications.
    The different approaches to delivering Web Services?
    Web services are implemented using a Java class that's responsible for receiving the HTTP/SOAP message, parsing the XML, and mapping the message to another Java class or Bean that provides the implementation of the service .Developers can place the implementation of the service within the Servlet engine, or within the EJB container. When you place the implementation of the Web service within the EJB container, as either a session Bean or an entity Bean, the container must be accessed using the RMI or RMI/IIOP protocol rather than the HTTP protocol.


    In other words, J2EE requires you to create a protocol bridge or gateway class to accept a Web services invocation over HTTP and call an EJB using RMI or RMI/IIOP, adding additional complexity to the design, development, and deployment tasks. Application server containers don't support HTTP as a native communication protocol currently, while .NET servers do. Adding this capability is a primary theme for J2EE 1.4.
    The .NET environment provides a single, generic mechanism for supporting Web services in multiple languages. The common language runtime (CLR) hosts objects or components developed in multiple languages using the same infrastructure, which is basically the .NET Framework (see Figure 2). So far, VS.NET for C#, Visual Basic, and J# offer native support for Web services, and support for C++ Web services is provided through the Active Template Library (ATL). And now that Microsoft has opened up Visual Studio for additional ports, you can get third-party support for additional languages. ASP.NET, the recommended approach for creating Web services, and ADO.NET, the recommended approach for accessing data resources, also create objects that are hosted by the CLR, providing a consistent, seamless architecture.
    .NET provides a binary and XML version of its communication protocol. For J2EE, the binary protocol is RMI or RMI/IIOP, and the XML protocol isn't supported currently. However, you should note the .NET XML protocol doesn't support many of the features available in the binary protocol, .NET remoting. It includes features such as full type fidelity, references to server-side objects, and control over the lifetime of those objects. If your application needs these object lifetime services, you should implement both client and server applications using .NET remoting (see the Go Online box for additional information on .NET remoting).

    Assess How the .NET Architecture Measures Up

    Therefore developers can use VS.NET to develop a Web service using any one of the supported languages, and choose either the HTTP or binary communication channel. However, developing and deploying Web services with J2EE remains a two-stage process in which Web services and EJBs communicate using different protocols.
    Living Up to the Promise
    =================================
    I think it's fair to say that Microsoft initiated, and continues to lead, the Web services movement, and that the leading platform implementation of Web services is found within the .NET initiative. Although .NET represents more than just Web services, these servers are perhaps the most significant part of the initiative.
    Web services offer the promise of universal interoperability and reusable components for rapid application assembly. But these promises can't be fulfilled in a vacuum�both .NET and J2EE need to provide equivalent, or at least compatible, implementations of Web services technologies. The real difficulty for Microsoft will be to continue to find a way to promote the standards that need to be widely adopted and, at the same time, stay ahead as the J2EE community closes the gap. As long as Microsoft and the Java vendors remain at war, businesses will suffer when they have to deal with both environments in different ways, with different skill sets, and using different hardware platforms.
    The difference will be settled by the rate of adoption, and the rate at which Web services provide value�in other words, if Web services take off big-time, the Microsoft bet will pay off. If Web services prove to be a significant force for industry change, Windows developers will find the additional effort to migrate and convert existing applications worthwhile. If not, they might look seriously at migrating to alternatives within the J2EE environment, where the changes are more incremental (read the sidebar, "Understanding the Past and Future Direction of Web Services").
    You can expect the next release of J2EE, J2EE 1.4, to standardize many of the features required for Web services support that individual vendors have developed using proprietary architectures and APIs. The speed at which the Java community can advance its ideas and specifications for Web services collectively will be critical to maintaining parity with Microsoft, who often advances ideas on its own.
    Some J2EE vendors are closing the gap with .NET already by providing development environments that focus more on Web services, such as IONA's XMLBus, IBM's Web Services Toolkit, and BEA's WebLogic Workship.
    Significant work is already underway within the Java Community Process (JCP) for Web services security and transactions (see Resources). These additional technologies will provide the basis for secure, reliable, robust, and complex business applications for J2EE-hosted Web services. Similarly, Microsoft is promoting its Global XML Architecture (GXA), which offers additional Web services features such as security, message routing, and process flow.
    The fact that Sun, Microsoft, and IBM are all cooperating on WS-Security at Organization for the Advancement of Structured Information Standards (OASIS) is a good sign, but this is only one of many specifications in the Web services arena (see Resources). Microsoft should avoid requiring its software to be at each end of the communication, as it does with .NET remoting, because that's antagonistic to the Web's origins as a free, open, and completely standard place.
    Microsoft has reinvented its distributed computing development and deployment platform around XML and Web services. Therefore, the .NET platform is less mature than most Java-based application servers, where vendors have tended to view Web services support more as an add-on to a proven technology. However, Microsoft seems to have done the right thing by taking the plunge.
    Is the Microsoft .Net "embrace and extend" approach is superior to the J2EE "redesign and rework" approach when it comes to Web services ?
    Web services are sufficiently different from the features and functions that motivated J2EE and Windows DNA originally ?

    I've taken the above from Web Services - J2EE or .Net

    I need to find a few WebServices that I could use on a web site.
    For simple ones like map directions and payments,how do I choose ?
    regards
    Balaji Loganathan
    author and deputy
    Bartender

    Joined: Jul 13, 2001
    Posts: 3150
    Originally posted by HS Thomas:
    I need to find a few WebServices that I could use on a web site.
    For simple ones like map directions and payments,how do I choose ?
    regards

    if i understood ur question correctly then u can visit this" target="_blank" rel="nofollow">http://www.xmethods.net[URL=http://www.xmethods.net]this site to see many webservices that are online. if you want u can try consuming one of them and test further.
    [ August 26, 2003: Message edited by: Balaji Loganathan ]

    Spritle Software Blogs
    Lasse Koskela
    author
    Sheriff

    Joined: Jan 23, 2002
    Posts: 11962
        
        5
    If you need just "some" web services to play with, go to xmethods.net. They list hundreds of free/commercial web services for various purposes.
    By the way, I wouldn't take the implied superiorities in the article too seriously as it was printed in the "dotnetmag" section...
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Thanks Balaji.
    But which site do you mean ? Do you mean the Fawcette site I listed ?
    regards
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Thanks , Balaji. Which site do you mean ?
    Lasse, I can't get into the site you've shown. I guess a few billion JavaRanchers are trying to connect.
    Here's an extract of a sales pitch for a course that landed in my mailbox just now.

    Differentiate between the major approaches employed by J2EE and .NET in building Enterprise applications
    1: Learn how J2EE and .NET can transform your approach to building, integrating and deploying Enterprise applications, giving you a competitive advantage
    2: Understand how the two technologies address the scalability and reliability challenges and which platform is best suited to your environment
    3: Evaluate the state and maturity level of the competing platforms
    4: Discover the platforms breadth of support for XML and Web Services and what the key differentiators are
    5: Learn about the different options that J2EE and .NET offer for the integration of your new component-based applications with your back-end legacy and packaged applications
    6: Understand the impact that the platform selection will have on your IT organization, including migration from
    previous platforms, skill requirements, technology choices and vendor lock-in
    7: Determine a strategy for selecting the right platform
    8: Understand the Total Cost of Ownership (TCO) for both platforms
    """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
    1. Introduction
    2. Setting the Stage:
    from Middleware 101 to
    Componentware
    • Middleware evolution
    • Components vs. Objects
    • Service Oriented Architecture
    (SOA)
    • Web Services
    3. Requirements for
    Development and Integration
    of Enterprise Applications
    • What makes e-Business integra-
    tion so difficult
    • Requirements for Middleware
    services
    • Overview of Middleware plat-
    forms
    4. J2EE Overview
    • Java 2 Enterprise Edition
    (J2EE) - overview
    • Java Database Connectivity
    (JDBC)
    • Java Remote Method Invocation
    (RMI)
    • Java Naming and Directory
    Interface (JNDI)
    • Java Messaging Service (JMS)
    • Java Transaction Service (JTS)
    • Enterprise Java Beans (EJB)
    5. .NET Overview
    • Introduction to COM and DCOM
    • COM+ overview
    • ActiveX
    • The .NET Framework
    - Common Language Runtime
    - Supported programming lan-
    guages
    - ASP.NET
    - ADO.NET
    - Remote objects
    - Interoperability between COM
    and .NET
    6. Comparative Analysis
    a) Basic concepts
    - Language and OS Support
    - JVM vs. CRL
    - Java Community Process
    (JCP) vs. Microsoft Shared
    Development Process (SDP)
    b) Core platform capabilities
    - Performance
    - Scalability (clustering, load
    balancing, resource Manage-
    ment, activation policies, net-
    work connection pooling)
    - Availability/failover
    - Security
    - Naming
    - Communication Models (syn-
    chronous, asynchronous,
    event driven)
    - Persistence
    - Data access
    - State and session Manage-
    ment
    - Distributed transaction support
    - Management and monitoring
    c) Comparing platform tiers
    - Presentation tier
    - Portal integration
    - Legacy application integration
    - Packaged application inte-
    gration
    d) Developing Web Services
    - Support for XML processing
    - SOAP protocol support
    - Interface definition
    (WSDL), Client vs. Server
    implementation
    - Registration
    (UDDI and other registries)
    e) Impact on the IT organization
    - Platform maturity
    - Portability and vendor lock-in
    - Development tools
    - Ease of use
    (development, deployment)
    - Skill requirements and skill
    availability
    - Alternative platforms
    - Migration from previous plat-
    forms
    - Total Cost of Ownership (TCO)
    (f) Conclusions
    I'd like to put some web services on a Web site that needs to handle payments among other things.I don't want to write these myself but would rather use components.
    I'd like to use Open Source software as much as possible.As a user of the component how much of the above should I worry about.
    [ August 26, 2003: Message edited by: HS Thomas ]
    Lasse Koskela
    author
    Sheriff

    Joined: Jan 23, 2002
    Posts: 11962
        
        5
    Well, there is a lot more (active and mature) open source products available in the Java/J2EE world. For example, you won't have to pay a dime for the web services platform if you go with Apache Axis on Tomcat/JBoss/JOnAS/Jetty/etc.
    As a user of a web service, you only need to worry about the language/platform you write your ws-client in. I'd suggest using the same language/platform the website is otherwise using.
    Balaji Loganathan
    author and deputy
    Bartender

    Joined: Jul 13, 2001
    Posts: 3150
    Originally posted by HS Thomas:
    Thanks , Balaji. Which site do you mean ?
    I'd like to put some web services on a Web site that needs to handle payments among other things.I don't want to write these myself but would rather use components.
    I'd like to use Open Source software as much as possible.As a user of the component how much of the above should I worry about.

    Sorry thomas, I too was refering www.xmethods.net website only. please try later, I can browse that site now.
    For your case, first try to search whether this webservice is available already by visiting xmethods, MS,IBM repository's..
    If not, then try write to your own "Handle Payment" function or interface in the standard that that you do, I mean using proper OOP strategy!. For example using javabean/classes in Java or Classes in C# or Vb.net. After doing this read the Apache Axis documentation(open source software)and see how you can expose your function "Handle Payment" as a webservice whcih can be consumed any SOAP complaint engines!.,.
    .NET also has the same capability to expose a function as a webservice.
    Its all depends whcih language you are very familiar with so that you can tune your webservice to suits interoperability in a more efficient way.
    I hope this answers question, if not please post your requirements again.
    BYW one request, please don't cut and paste BIG articles as no readers will be ready to read it unless they need it.
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Thanks Lasse , Balaji.
    Good advice.
    Regarding length of artcles it was actually an extract of what I thought I ought to be concerned about.
    Actually I didn't think it would look this big though.

    regards
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    By the way, I wouldn't take the implied superiorities in the article too seriously as it was printed in the "dotnetmag" section...

    The author of the article is Eric Newcomer who wrote "Understanding Web Services" , so hopefully he knows what he is talking about.
    He is also one of the authors of the acclaimed Principles of Transaction Processing.
    I kind of would go with what he says.
    The only problem I'd have with the article is that it was written in Aug 2002. Which may still hold for projects starting now but maybe not in 3 years time (?)!
    regards
    Lasse Koskela
    author
    Sheriff

    Joined: Jan 23, 2002
    Posts: 11962
        
        5
    The author of the article is Eric Newcomer who wrote "Understanding Web Services" , so hopefully he knows what he is talking about. He is also one of the authors of the acclaimed Principles of Transaction Processing.
    I kind of would go with what he says.

    I didn't mean to imply that the author would be somehow incompetent but when the publication's name is ".NET Magazine", there's always a chance of that affecting the tone of the articles being published.
    The only problem I'd have with the article is that it was written in Aug 2002. Which may still hold for projects starting now but maybe not in 3 years time (?)!

    The platforms will probably look a lot different 3 years from now.
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Best implementation