yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..

2008 West
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
Red Hat
The Opening of Virtualization
User Environment Management – The Third Layer of the Desktop
Cloud Computing for Business Agility
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Return on Assests: Bringing Visibility to your SOA Strategy
Managing Hybrid Endpoint Environments
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
How Can AJAX Improve Homeland Security?
Beyond Widgets: What a RIA Platform Should Offer
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I u...
Tools for Taming Web Services Management
Tools for Taming Web Services Management

As Web services move beyond opportunistic implementations and proof-of-concept deployments to support enterprise-wide services in mission-critical applications, the need for Web services management becomes ever more pressing. While Web services present a tremendous opportunity for organizations to improve coordination and integration both within the enterprise and with old and new business partners, dealing with a multitude of partners with changing requirements in an open heterogeneous environment also provides new opportunities for failure. These problems can be mitigated through the use of policies representing proper procedures and best practices. It is the role of Web services management to allow users to choose procedures, establish best practices, and then enforce them in real time.

I will discuss the touch points for applying these policies and some means of organizing them so your Web Services Management Platform (WSMP) doesn't become, itself, unmanageable. We use two organizational techniques for this: service views, a way of organizing Web service operations for different audiences; and policy groups, a way of organizing policy decisions applicable to multiple operations. First we will show how management concerns arise from an examination of Web service messages and then show how these two concepts provide an effective means of organizing management policies.

Web Services Management Areas of Concern
In choosing what to manage, there is an inevitable trade-off between processing that happens in the manager and processing that happens in the Web service. At one end is information that must be tracked globally for the whole network to function, or policies that must be consistently applied across many services. At the other is processing that is more application specific, but more easily handled by the manager and can insulate the application from changes, such as transformations into and out of standard formats. Perhaps the best way to show the many ways management can impact message processing and provide stability is to observe the handling of a message or two by a Web Services Manager. Listing 1 presents a short Web service message - in particular, a Simple Object Access Protocol (SOAP) message. Looking at this message, we can ask a number of WSM-related questions:

  • Mitigating outside attacks: Along with the message, we have the (alleged) IP address of the originator. How many times has this IP attempted to access this service? Have there been a slew of unsuccessful attempts indicating an attempt to break into this service or related ones? Should we block this IP? Should we shut down the service? Who do we inform?
  • Information security (encryption/signature): The message contains a WS-Security header block indicating a signature for certain parts of the document. Who signed these elements? Where is the Certificate Authority (CA) for this signature? Is there critical information that hasn't been signed? Is there information that needs to be encrypted given its source or destination? If we need to sign/encrypt it, which key do we use?
  • Access control: Who is this message from/ to? How do we identify them? Are they allowed to access the service they are contacting? Once we identify them, do we need to switch credentials to access the ultimate service? Do we need to filter information in the Web service's response? If they have no access rights, who do we inform?
  • Metering/resource management: Is there a cost to access this service? What account should be used? How much do we charge?
  • Quality of service and service-level agreements: Is the service up? What is its response time? Given two simultaneous requests, which is serviced first?
  • Quality assurance: Is the message valid according to its schema? If I've transformed the message, is the new message valid? Do the values make sense? Is it the expected response?
  • Standards implementation and conformance: Because SOAP itself allows so much variability, other groups, such as WS-I, have specified best practices for conforming SOAP messages. Is this a SOAP message? Is it SOAP1.1 or SOAP1.2? Is it WS-I Basic Profile compliant?
Because of the heterogeneity of the network and the variety of clients that need to access an ever-burgeoning list of Web services, the answers to these questions can vary considerably depending on who (requestor) is sending what (message) over the network (channel) to whom (receiver/base service). This tuple (sender, message, channel, receiver) is the key to these different answers. Any set of answers represents a policy, a specification of how your system will react to a particular set of circumstances.

The sheer amount of work required to support the entirety of this agenda makes implementing a management capability on a Web service-by-Web service basis prohibitively expensive. Clearly the work required to build a management capability from scrap far overshadows the cost of implementing any single Web service.

Organizing Policies and Services
XML provides the possibility to directly examine and operate on the message stream, and many common policies require examining, if not actively manipulating, the message. Therefore, WSMPs tend to use an intermediary or broker architecture; messages between the requestor and the base service first pass through the manager. The manager sees a sequence of structured messages from a particular network port destined for another network port. While it is possible to design policies exclusively at the message level, this inevitably leads to diminishing returns. In a complex environment, the set of if-then-else conditions to first determine the (sender, message, channel, receiver) tuple and then answer our list of questions will be torturously complex. With no abstraction level above the message, all the decision logic must be specified explicitly, while a more abstract view would answer many of them implicitly. Additional layers up the stack include the operation level, the port level, the service level, and even, in the other direction, the XML element level. In addition to messages, there are the requestors to consider as well. Service views and policy groups are two techniques to organize these various levels according to the changing requestor/message/channel/operation mix so they can be managed in concert, rather than in conflict, in a way that simplifies rather than complicates.

The key standard for organizing Web services is the Web Services Description Language (WSDL). WSDL organizes operations by endpoint and specifies the structures for messages to those endpoints. It has also become the focal point for specifying other information about services. A <definition> element contains a list of services, ports, bindings, and operations. Nevertheless, what may appear as a logical organization of operations from the developer's viewpoint may no longer be so when looked at from other perspectives. Different sets of users will be allowed access to different sets of operations with different access rights using different authentication mechanisms. Mixing all of these in a single WSDL is dangerous.

But there's no reason to see a WSDL <definition> as universally valid. We can treat a WSDL <definition> element as a protocol for a provider to communicate a permitted set of operations and policies to a specific set of users. Internally, we can link a given <definition> with a particular set of policies about messages, ports, and operations. We take a particular set of (sender, message, channel, receiver) decisions about some set of services and formulate those as a set of policies. From those policies we generate a <definition> element reflecting those policies, and send it to the particular requestors to whom we wish to apply those policies. The <definition> can therefore serve as a tool for management and a mechanism for conveying policies, with different sets of users receiving different WSDLs, even with different addresses, although the underlying operations may be the same.

We call each of these a service view by analogy to the database view of SQL. In many ways, this is an extension of the WSDL <binding>, which provides for multiple serialization formats for Web services messages, depending on the characteristics of the recipient. Another analogy is to interfaces in traditional programming languages, such as Java. In Java, a single object can support any number of interfaces, with each different interface including a subset of the methods of the class. A client object sees another object by the interface provided, without knowing about the underlying class and any other methods available.

For example, in Listings 2a and 2b we see abbreviated WSDL for two services - purchase orders and support - where there may be a variety of clients, or service requestors, some internal to the organization and some external. Both services, though, are designed for internal customers.

In Listings 3a and 3b we can see two different service views of these operations. In each case we've organized a subset of the operations into a single port with a new address, combining operations from both underlying services. Immediately we've divided our users into two groups that will access different mixes of our underlying base services through different routes. In Listing 3a, the "AcmeSpecialService", authentication is specified by adding username and password fields. This is accomplished differently for the RPC- style SubmitIssue from the document-style SendPurchaseOrder. In the first case, extra parts can be inserted directly into the message. In the second, because everything needs to tie back to a W3C schema, we create a new namespace to house the extra elements and then add them to the message. In Listing 3b, the clearly more sophisticated ZenithSpecialService, we've added features. For example, we've added a WS-Security header to the mix, specifying the use of WS-Security as the access mechanism. This also requires importing the WS-Security schema. We've added a WS-I Basic Profile (BP) conformance claim and associated header. But because BP doesn't support RPC encoding, a document-style equivalent needs to be generated (including a new schema corresponding to the namespace). These indicate different levels of integration, depending on the sophistication of the clients.

In essence, the service view allows a constellation of concerns - service requestors, operations, formatting, authorization, and authentication - to be unified in a single view. While the number of different combinations of these is astronomic, in reality there will be very few. With a service view, the actual combinations can be brought together and easily managed by a set of consistent policies. The original service, now hidden behind and protected by the view, remains the same. Other policies not directly describable by the WSDL can still be segregated by view. For example, the authentication mechanism used can be assigned on a per-view basis. Then policies regarding requestors from a particular location - such as Acme - need only be tested for messages coming to specified ports - as only requestors from the targeted group will be authenticated.

The other organizing principle, the policy group, provides a mechanism to specify policies applying to operations in multiple views, or to a subset of a view. For example, a service view can provide a mapping from requestor to role, but the rights granted to a role may be linked to the underlying operation and be consistent across views. A role can be used to control access to operations within a view (in a traditional access control fashion) or enable content-filtering policies to control the content of a message (limiting the size of a purchase order is a commonly used example).

Additionally, there may be policies applicable to a variety of operations, regardless of which views they appear in. A policy that cuts across both service view and policy groups would be a policy to prevent a requestor from seeing information concerning other organizations. The Web service in Listing 3b allows customers at Zenith access to the ListOpenIssues operation. A logical policy would be to restrict Zenith to viewing only its own issues, but the underlying operation may not be able to do so. A policy employing a filter could implement this for the Zenith view, but a more general policy would be to apply this restriction to any organization with access to the underlying operation. This can be implemented by a filter to stop the message, or a transformation to excise the information. The policy would apply across many operations, but the identity of the requesting organization comes from the view. As different operations have different structure, the filter or transformation would need to be attached to the underlying operation. The policy would be applied across all operations, using either a service view-supplied organization name and the operation-specific filter or information from the incoming message. Were these not present, the policy would fail.

At present there is no uniform way to describe the variety of policies that may be applied to Web services. WS-Policy, a set of proposals related to WS-Security, may provide a means for naming the policies being applied to a particular service view; however, policy implementation will undoubtedly remain proprietary to different Web service management products. The degree to which they are automated will also vary from WSMP to WSMP.

I've described a number of practical issues related to forming effective policies for managing Web services as messages flow back and forth. Given the large number of these and the multitude of ways they can interact, we've described two mechanisms, service views and policy groups, that provide an effective means of organizing policies into different coherent groups and reflecting those groups out to partners as WSDL. By presenting different specific WSDLs to different groups, an organization can succeed in controlling the cacophony of different agreements and capabilities of many partners, as well as insulating the underlying base services from the filtering, authentication, authorization, and other ancillary processing performed at the management layer.

The field of Web services management is still in the early stages, but already it has shown itself to be a complex area requiring new techniques beyond previous management tools. New complexity generally requires new abstractions to reorganize information and keep it from degenerating into chaos; service views and policy groups are techniques to control the additional requirements and possibilties of Web services. Without this, Web services themselves will become a drain on the organizations that deploy them. But they sit at the bottom of a new stack of management issues surrounding Web services. Above this are other exciting areas, such as business process orchestration and real-time business intelligence. What new techniques will be added to the list will become apparent as this technology moves to maturity.

About Matthew Fuchs
Dr. Matthew Fuchs is a member of the technical staff at Westbridge Technology. Previously, he was chief scientist for XML Technologies at Commerce One, and pioneered the theory and practice of using domain-specific languages in XML and SGML for distributed applications and agent-oriented communication over the Internet. At Commerce One he developed a variety of XML technologies, including SOX, the first implemented, publicly available, object-oriented Schema language and parser for XML

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

SOA World Latest Stories
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand usin...
When building large, cloud-based applications that operate at a high scale, it’s important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. “Fly two mistakes ...
Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and sy...
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portabil...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is founda...
Using new techniques of information modeling, indexing, and processing, new cloud-based systems can support cloud-based workloads previously not possible for high-throughput insurance, banking, and case-based applications. In his session at 18th Cloud Expo, John Newton, CTO, Founder an...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)!

Advertise on this site! Contact advertising(at)! 201 802-3021

SYS-CON Featured Whitepapers
Most Read This Week