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...
Putting the EDA in SOA
How Upcoming Web services Message Standards Will Merge Event-Driven Architectures with SOAs

The current slate of Web services standards has evolved into a mature set of very useful API's and into service-oriented architectures, or SOAs. Enterprise integration, however, includes many requirements that are not met by SOAs alone. A movement is under way to augment Web services with a new set of standards that address the other side of integration - Event Driven Architectures, or EDAs.

The wave that pushed Web services to the forefront of the worldwide developer community's consciousness has left behind a working set of standards that allow organizations to effectively cooperate in processes over the Internet. Web services standards enable organizations to realize some of the goals of integration in a standards-based and, even more importantly, interoperable manner across operating systems, hardware platforms, and application development platforms. While some of those responsible for enterprise-level application development and support have been understandably disillusioned by earlier inter-application communications attempts such as CORBA, Web services have crossed over the often turbulent initial technology adoption stages to become a reality. The standards that have emerged (with the help of organizations like the Web Services Interoperability Organization [WS-I], the World Wide Web Consortium [W3C], and OASIS are not only interoperable but are, even more importantly, being widely implemented throughout many of the Global 2000's IT departments.

Web Services and Service-Oriented Architectures
Many scenarios are well served by the functionality embodied in the current slate of Web services standards. An example scenario: One application requires information such as a credit score from another application. This application uses the SOAP standard to request the information (by passing the DUNS number of the company to check), hold for the answer, and then receive the requested information, at which point the communication between the two applications is completed. This is, on the surface, not a very complex problem and Web services serve it well (see Figure 1).

But what if this were to change later? A process could be designed that executes every week to check up on all of the credit scores of all customers served by a particular application. Maybe the result of this check is so important that a week between updates is too long. Maybe a lowering of a customer's credit rating should be known before completing any sale. This means that every single transaction moving through the application would cause a resulting credit check (these checks cost money, right?) before accepting any purchase order request. This is highly inefficient, especially if the credit ratings of these customers on average change only once or twice a year. This is also very inefficient in that it adds unnecessary load on the computers of the provider of these services, though the provider will not mind at all if they are charging for each transaction.

This on-demand style of information gathering can also cause dependent processes to ask and wait for an answer in places that may not be absolutely necessary. Additionally this method introduces a performance dependency on an outside application. It is very difficult for internal processes with external, ask-and-wait, dependencies to be held to service level agreements.

The "ask-and-wait" method of information gathering is often referred to as synchronous processing - one step must happen after the other, in-sync, for a process to move through on its path to completion. This is the style of process best served by current Web services standards. It's generally very linear in nature. This component-level request/reply functionality is at the heart of the SOA.

But if you go back to the credit check issue, a more efficient method of filling this need would be to allow applications that need up-to-date information to subscribe to this information, which would result in the credit service application publishing update events back to interested applications as the changes occur rather than waiting for the subscribing application to request the information. As Notifications of change are published to the consuming organization, the changes can be placed in a local data structure and can even kick off processes in response to the update event. For example, a particular customer's credit rating is raised a notch by a reputable credit rating organization, such as Moody's. A Notification event is sent to the consuming organization that this credit change has occurred. The consuming organization may wish to respond to this change event with a process that calculates a higher credit limit based on this rating increase. This process would then place the proposed increase in front of a credit officer. This credit officer would then has the opportunity to discuss the new limit with a representative of their customer and to then accept, deny, or change the amount of the credit limit increase. All subsequent orders now take advantage of this newly acquired information (see Figure 2).

This interaction style allows a high degree of trust to be placed on a datastore that is completely under the control of the information-consuming organization, alleviating outside bottlenecks and allowing increased confidence in an organization's ability to comply with service-level agreements and to further control product cycle times. In the high-tech industry, shaving even one second off the cycle from ordering through provisioning, manufacturing, and delivery of a product can save tremendous amounts of money. Additionally, many purchasers that rely on outside vendors for the components of their products do not purchase solely on the price of the goods but often weigh purchase decisions heavily based on a vendor's ability to deliver to a promised schedule. Being able to trust a vendor to deliver what they say they will - when they say they will - allows a customer to execute their business with less inventory, saving money in many ways.

Event-Driven Architectures
Publish-and-subscribe processing and the fire-and-forget messaging at its heart are a part of the functionality embodied in event-driven architectures. The information is updated independently of the processes that utilize the information. The update to the credit scores relieves the business process from having to query for an answer.

The Web Services Notification (WS-Notification) specification, managed by OASIS, will bring the publish/subscribe (EDA) functionality described in the example above to the very SOA-focused current incarnation of Web services standards. This specification enjoys broad industry support from integration industry leaders such as webMethods, IBM, Oracle, and SAP.

WS-Notification is important because it will bring standards-based interoperability across operating systems, hardware platforms, and application development platforms to the messaging world. This has already happened to a very limited extent with JMS where many messaging solution providers are able to achieve some level of interoperability with products from other vendors through JMS APIs. The clear benefit of WS-Notification over JMS is that it doesn't assume that all (or even any) applications utilizing these features will be developed in the Java programming language. WS-notification will additonally offer much greater vendor-level interoperability between messaging infrastructures. This does not mean that JMS will go away; on the contrary, this Web services standard will increase the adoption of EDA functionality between applications and will likely lead to increased demand for all types of messaging infrastructures as long as they can communicate with other infrastructures using WS-Notification.

The current WS-Notification specification provides support for both peer-to-peer and brokered publish/subscribe. In peer-to-peer, publishing and subscribing applications must implement the functionality of the specification (described in the WS-BaseNotification specification). For example, a publishing application must implement a registry to store a hierarchy of publishable document types (Topics) and a directory service to supply this information to interested subscribing applications. Subscribing applications must manage subscriptions that could span many different publishing applications. This is not to mention the support that must be implemented for many of the composable standards that will be required to provide facilities such as authentication, message persistence, message integrity, message encryption, delivery guarantees, etc.

In brokered publish/subscribe (described in the WS-BrokeredNotification specification), some of the burden of implementation of the WS-Notification features and composable features of related standards is off-loaded to a broker. This brokered implementation has one additional benefit, which is that publishers need never know anything about any of the subscribers. This complete decoupling of subscribers from publishers along with the centralized subscription and topic management provides IT departments with more control and allows them to more accurately measure performance against service-level agreements (SLAs).

While the current and planned WS-Notification specification versions bring much needed EDA functionality to the Web services battery of standards, there is still much to be considered before a "pure" implementation of a WS-Notification Broker would stand up to existing mature messaging infrastructures. For example, most current messaging infrastructures have built-in queuing mechanisms to ensure delivery of messages even if the subscribing clients are not available at the moment an event notification is published. This is often referred to as durability.

To illustrate the importance of message durability we will return to the credit check example scenario. After implementing a subscription to credit score changes, the credit scoring information will no longer be requested on-demand from each instance of the order process. How can it be trusted that the information in the locally maintained database is actually up-to-date? What if a change happened to a credit score; a notification was sent but never received? In the previous example, where the credit check is an in-line service in every order process instance, the information (credit score) is assumed to be as accurate and timely as possible. When the credit check is a separate, disconnected subscription process, what guarantees are there that an update has not been missed and that the local datastore correctly reflects the up-to-now credit state of a particular customer?

This information (a changed credit score in this scenario) is so important that it could potentially cost the selling organization a large amount of money if their local datastore had missed even a single credit score update. Some applications of messaging do not require that every single message published by an application be received by a subscribing application. For example, a stock-trading application receives a large number of updates as the price of stocks fluctuates during a trading session. This information, while very important, need not be entirely up-to-date as a price is negotiated for each sale. The stream of updates just gives the purchaser a good barometer of the probable price should a purchase be executed. If one update is missed another will be coming soon that would make the missed message obsolete anyway. If the stock purchaser were away from his/her desk and didn't have their trading software running at the time would it matter that they did not receive stock updates while they were away? No, it would just matter what the latest selling price was. This kind of messaging (where the subscriber does not need all updates, just the latest ones) is often referred to as volatile because it's allowable for them to evaporate if the client is not listening.

In our example, however, it is important that even if the seller's datastore server has crashed and is therefore not listening for credit score updates, that they be stored for eventual retrieval. This is called non-volatile, or durable, messaging - messages must be maintained even if the subscribing client is not listening. Generally, support for durable messaging means that messages intended for offline subscribers are stored until the subscriber is ready to receive them.

With volatile messaging publishing applications and subscribing applications don't need to know anything about each other except for an agreement on the type of message that they are sharing and the mode of transportation. Durable messaging, on the other hand, requires quite a bit more logical cooperation between publishers and subscribers.

Durability has been identified by the WS-Notification Working Committee at OASIS as an important feature that will be addressed in an upcoming version of the specification. With Durability will most likely come other very important enterprise-class messaging features such as shared queues (for balancing of load), ordering (where a client can be sure that it is receiving messages in the exact order in which they are published), policy enforcement (for control of access to particular message types and content), and authentication, just to name a few.

The current incarnation of WS-Notification has been built to address the most ubiquitous pattern in EDAs, volatile publish and subscribe. The future of WS-Notification will bring us not only interoperability between different messaging infrastructures but will also make it much easier to extend the reach of messaging solutions out over the Internet. The work being accomplished by the WS-Notification Working Group is likely to have a profound effect on Web services and on the future of integration. As companies investing in integration solutions become more and more confident that these solutions will interoperate with others, reducing risk, they will invest more in integration.

About Marc Breissinger
Marc Breissinger joined webMethods in 1999 and is currently vice president and chief artchitect. He manages webMethods' standards activites and defines the product strategy of their solutions. In his current role, Marc is responsible for shaping webMethods' technology vision and ensuring that vision is translated into industry-leading products. webMethods, the industry's first Web services infrastructure company, is a member of the Web Services Notification working group and is coeditor of the upcoming Web Services Notification specification version 1.2.

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

Register | Sign-in

Reader Feedback: Page 1 of 1

Your article would have been more complete if you had mentioned WS-Events as per IBM's comment below:

A summary statement from IBM characterizes WS-Eventing 2004-08 as a specification which "supports the simplest levels of Web services interfaces for notification producers and consumers for a distributed event management system. The WS-Notification specifications (WS-BaseNotification, WS-BrokeredNotification, WS-Topics), by contrast, "provide a rich set of functions supporting publish/subscribe required by robust, scalable enterprise applications including message brokering and topic based subscription management."

Your Feedback
David Tildesley wrote: Your article would have been more complete if you had mentioned WS-Events as per IBM's comment below: A summary statement from IBM characterizes WS-Eventing 2004-08 as a specification which "supports the simplest levels of Web services interfaces for notification producers and consumers for a distributed event management system. The WS-Notification specifications (WS-BaseNotification, WS-BrokeredNotification, WS-Topics), by contrast, "provide a rich set of functions supporting publish/subscribe required by robust, scalable enterprise applications including message brokering and topic based subscription management."
SOA World Latest Stories
There is a huge demand for responsive, real-time mobile and web experiences, but current architectural patterns do not easily accommodate applications that respond to events in real time. Common solutions using message queues or HTTP long-polling quickly lead to resiliency, scalability...
"We started a Master of Science in business analytics - that's the hot topic. We serve the business community around San Francisco so we educate the working professionals and this is where they all want to be," explained Judy Lee, Associate Professor and Department Chair at Golden Gate...
We call it DevOps but much of the time there’s a lot more discussion about the needs and concerns of developers than there is about other groups. There’s a focus on improved and less isolated developer workflows. There are many discussions around collaboration, continuous integration a...
The dynamic nature of the cloud means that change is a constant when it comes to modern cloud-based infrastructure. Delivering modern applications to end users, therefore, is a constantly shifting challenge. Delivery automation helps IT Ops teams ensure that apps are providing an optim...
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...
"CA has been doing a lot of things in the area of DevOps. Now we have a complete set of tool sets in order to enable customers to go all the way from planning to development to testing down to release into the operations," explained Aruna Ravichandran, Vice President of Global Marketin...
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