News Stay informed about the latest enterprise technology news and product updates.

Web services client concerns

Implementing Web services can be tricky in any organization. How should it be done? Why should it be done? Can it save money? These are just a few of the questions customers will ask their VARs and systems integrators trying to sell and support this technology. Get a head start and prepare for these potential Web services questions.

What's the biggest problem you see people running into as they attempt to migrate to SOA?

The biggest problem is that people frequently dive in assuming that a technical solution can solve a business or organizational problem. SOA can establish patterns of reuse, alignment of stakeholders, consolidation of disparate systems and increased flexibility and agility of IT--but the existence of technical standards and tools doesn't make it magically happen.

Get more information on SOA in our topics section. A lot of vendors are talking about next generation SOA before users have built first generation SOAs. What for you constitutes "next generation" and should users consider skipping right to that?
Oracle (in conjunction with Gartner) proposed a much derided "SOA 2.0" concept based on Event Driven Architecture. Many people think that the future of SOA involves integration with business processes in the form of a dynamic event driven model. However, there are many governance issues with a radically composition and orchestration based model, as there are too many moving parts. Therefore I wouldn't recommend skipping too far ahead, and to try to walk with SOA before you can run.

Get more information on SOA in our topics section. Proprietary technologies aside, what are some of the major challenges to wide-spread SOA adoption?

Some of the greatest obstacles to a successful SOA transition are associated with cultural and organizational issues. Successfully propagating service-orientation across an enterprise imposes requirements, such as the disciplined application of open industry technology standards as well as the consistent usage of internal design standards.

Furthermore, the governance demands introduced by large-scale service delivery can be overwhelming to say the least. The impact of establishing a governance platform capable of properly evolving an ever-growing service portfolio can go well beyond the enhancements required to technology infrastructure and runtime environments. The organizational structure of an IT division can be transformed as the need for new roles and processes increases in response to critical IT asset ownership requirements.

Get more information on SOA in our topics area. How does today's SOA measure up in terms of fulfilling quality of service (QoS) requirements?
When implemented via Web services, the primitive (basic) SOA model provides little in the way of standardized mechanisms for reliability, security, and transaction management. Second-generation specifications and frameworks, such as WS-ReliableMessaging, WS-Security, and WS-Coordination (in association with WS-AtomicTransaction and WS-BusinessActivity) attempt to address these deficiencies in an industry-standard manner. In doing so, they intend to enable a Web services-based SOA to provide a level of QoS comparable to what traditional RPC-based distributed systems have been providing for years.

However, the support and adoption of these key specifications is not yet industry-wide. That is why providing an increased level of QoS is a characteristic of what I call "contemporary SOA", as opposed to the baseline primitive model that is widely supported. In the immediate future, the extent to which you can achieve an acceptable level of QoS with a Web services-based SOA will vary depending on which vendor platform you are building on. Watch out, though, for proprietary extensions that may limit your ability to transition toward future industry standards.

For more on Web services visit topics area. How do you see SOA evolving?
All primary software vendors that officially support SOA seem genuinely committed to advancing their product platforms to provide increasingly sophisticated implementation technology capable of realizing service-orientation on a broad level.

There is currently every indication that SOA will establish itself as the de facto and default architectural model for distributed automation. The primary implementation technology currently associated with the creation of services in support of SOA is the Web services platform.

Continue reading Erl's answer to find out how SOA can beleveraged for strategic benefits. How much of my Web services activity can I effectively monitor at the moment? What potential blind spots should I be aware of?

With today's tools, quite a bit of monitoring can be performed on Web services but there are two main blind spots that I see on a regular basis. First is the matter of making sure that your policy enforcement points are actually enforcing the right policies. In other words, ensuring effective compliance with your policies. Next is the issue of what to do with all the information, and how useful is that information. For example, signed audit logs can be used in some cases for non-repudiation, but that is not an automatic assumption. Some legal framework needs to be established in advance of that functionality. Another case is problem of reconciling Web services level faults with higher level business processes. For example, can the service monitoring information you collect help you correlate with an online product ordering process break-down, and can it help you streamline that process?

See the rest of Boubez's response. Are there any advantages to using platform-based database access protocols, like JDBC and ADO, in my Web services as opposed to Web services standards such as SOAP?
Typically, performance is the major advantage for using native protocols such as JDBC or ADO. And typically, flexibility and reuse are the major advantages of using a platform neutral protocol such as SOAP. The job of architects and developers is to determine the opportunity cost of each alternative (performance vs. flexibility/reuse) and to make the decision. Database access protocols such as JDBC and ADO are likely to be found happily co-existing with other platform APIs in any Web Services deployment. In many cases, however, JDBC/ADO calls are too fine-grained to be surfaced as SOAP Web services.

For more advice on SOA check out our SOA crash course. My company has been through a lot of acquisitions over the past decade, which has led to a lot of integration projects with multiple middleware providers. Is there a rule of thumb on how much middleware latency is too much?

The answer lies in what is an acceptable level of latency for your customers. A SOA management platform can help you to keep latency within the levels specified by your Service Level Agreements (SLA) that you have with each given customer. It can do this by monitoring and measuring your service request traffic and alerting you to violations. In addition, when a SLA violation occurs, it can help you to perform root cause analysis by reporting timings on individual service calls and specific WSDL operations. In the case of the Actional products, this alerting and reporting can be done within the context of an individual business process, and service requests may also be dynamically routed and prioritized based on higher valued customers. Depending on the architecture of the SOA management platform, the additional latency introduced may be measured in microseconds rather than milliseconds.

Read the rest of Chappell's answer. Everyone claims to be an enterprise service bus these days, but they sure don't look the same once you start looking into how they operate. Are there some design patterns that sort them into different categories that match up to different needs?
A good place to start is whether the ESB is simply a web services veneer on top of an EAI broker or an Application Server. Another thing to look for is whether the ESB actually has a good reliable messaging layer. If it does have a reliable messaging layer, is there the notion of the separation of the reliable messaging layer from the rest of the ESB? The reason for needing that is the independent scalability of the individual parts of the ESB. As you begin to increase the service request traffic across a SOA infrastructure, the performance and scalability bottlenecks can occur in multiple places. Two important potential bottlenecks are in the processing of the service request itself—the service implementation, or in the heavy lifting involved in performing the reliable message delivery. A third place for bottlenecks are in mediation services such as XML transformation. If the ESB implementation is based on a monolithic stack that lumps all of these categories of processing together, then your options for scaling and relieving bottlenecks can be somewhat limiting.

Get more info about enterprise service bus.

Dig Deeper on IT systems integrators

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.