Skip to Content

Over the years movement of Integration platforms towards more reusability, industry standards approach to interoperability and better performance have resulted in SOA based architecture as a panacea for integration challenges.Some of these recommendations have resulted also in implementations , building application composed of webservices or orchestrating complete business processes using webservices.This has however resulted in multiple standards being adopted towards creating such platforms of reusability.This weblog intends to look at just some of these features that can have a major impact on any system landscape study that would need to be critically looked at by a Solution architect while designing Services using webservices over an EAI.

Webservices are basically a message based interfacing layers built over the existing applications/systems to basically achieve the following

Interoperability and integration capability:-
      Webservices are a result of an evolution of consistent, standards based protocols linking together applications from a variety of legacy and monolithic architectures.Some of the lower level standards like WSDL and SOAP are widely adopted platforms for exposing functionality of business applications to EAI and middleware layers for seamless integration to other latest platforms.But the question is do we have the same kind of agreement on issues like security , reliability where the emerging standards are not yet agreed upon as the basis of collaboration between applications?
One answer to this question could be the Web Services Interoperability Organization(WS-I) whose WS-I Basic Profile 1.1 is considered a best practice towards creating webservices for attaining maximum interoperability. This can be verified by testing the developed webservices for conformance through actual webclients which would consume these services.Some off the shelf toolkits can also be used to verify the conformance of these webservices to the standards.

QOS:- QOS is an area, which I feel needs some thought, b’cos typically unlike an EAI where the standard product offerings provided QOS thro’ say the infamous CertifiedMessaging/RV of say Tibco or the BE/EO/EOIO mechanisms of SAP Xi, we may not be clearly able to define the QOS standards for messages from webservices which would come into the new landscape.I have faced this dilemma during many integrations involving webservices and WSFL standard based process implementations like Siebel UAN on Tibco.
Eg: How would you manage a HTTP synchronous call, which would required ‘n’ process calls to different application systems before the data from the different systems can be picked up, transformed and the content filtered before being sent as a single response from within EAI layer.(XI’s S-A bridge is one mechanisam which can bridge this problem, but in a multi application scenario, it may not be the solution to the problem)
But recently, reliable messaging standards have arrived that are protocol-independent like WS-Reliability and WS-ReliableMessaging which provide guaranteed messaging capability but choosing the infrastructure required for implementing them would still need an evaluation .

Performance:- As in any standard web based interface measurement strategy, the catch here is on the throughput of the server and latency time involving the request-response.This is dependent on the Network bandwidth, Server-Client performance, Message size, transformation logic involved and Memory- CPU constraints.

I havent dealt with other issues which may need to be considered in any Webservices strategy like message security , manageability of the deployments,clustering capabilities(in relevance to QOS) but these we can deal with them probably in a future weblog…

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. John Patterson
    Sriram, good job. I think that there is real value in highlevel Weblogs, individuals talking about best practices, issues and risks faced in real life etc.

    Especially relevant is SAP XI and webservices, which while opening up an enterprise for integration, it also poses a lot of architectural questions with regards to the techologies and mechanisms. There is seldom one correct solution in regards to technology and it is rare to get enough time to research to a conclusion. We design to be scalable and durable, when a new problem or requirement surfaces we havent thought of, this is where other peoples experiences are invaluable.

    One thing dealing with technology everyday we are bombarded by TLA’s (Three Letter Acronym), these need to be fleshed out the first time used. I grasped QoS to be Quality of Service, but after RVCM the rest of that paragraph went IoE/OTO (In one Ear / Out The Other). It was only after reading the paragraph that followed did I understand, in the context to asynchronous and synchronous integration SAP XI offers the following mechanisms for guaranteed delivery BE (Best Effort), EO (Exactly Once), EOIO (Exactly Once In Order), but due to the nature of webservices the level of guarantee may not be as easily defined as the async/sync bridge.

    Cool, what is the answer?

    1. Former Member Post author
      lemme first thk for your comment..Will try to be more restrictive on my acronym usage..:)
      Well for offcourse my answer is thr is no single solution to fit all WS scenarios.What is important however is giving more thought to how we design/structure the webservices and
      choose appropriate ESB/EAI (SAPXi or whatever) depending on landscape and direction.
  2. Former Member

    So here I am literally about to take my first steps at implementing Web Services using XI and I ran across your blog.  I don’t know whether to thank you for highlighting and making concrete some of the concerns and thoughts I’ve had surrounding this whole design, or whether to get mad at you for stressing me out by raising a bunch of concerns without answers!  I agree, at this point there really doesn’t seem to be a standard method to address these issues.  In particular, I’m concerned most about WS security.  At the early stages of the whole WS/ESA discussion, my first reaction was great – reusable, reconfigurable, discoverable code across the enterprise (and even outside), but what about security?!  In my novice opinion, the implementation of standard way to handle security in Web Services is a large, often neglected issue.  I’ve garnered a few articles on WS security, but I’d love to see more heads put together on a best practice or standard method for handling security – ideally something robust enough to handle access based on some centrally defined system or user roles/profiles.  I.e I like to have my WS’s be smart enough to say, hey wait a minute, you’re a program from HR, you shouldn’t be able to consume this order fullfillment web service!…

    1. Former Member Post author

      I agree security is a consideration I havent addressed durign the blog but considering the kind of hype cycle which WS security stds are facing,I would wait till one of the stds(WS-Security is what i bet on-unless offcourse IBM and MS lock horns over their disagreements) to get on to full main stream adoption.Other would be standard SSL offcourse.

      Until the peaking happens it would be more of taking a call..till Gartners of the world decide a particular st’d to have met all expectations( which I doubt they would) 2 cents


Leave a Reply