Putting the EDA in SOA @ JDJ

来源：互联网发布：未来大数据化的行业编辑：程序博客网时间：2024/05/04 01:15

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.