SOA: The Subscriber-Publisher Model, Introduction and Implementation
By DGoins
This article explains a brief introduction to SOA and a Subscriber-Publisher model, along with how to implement one using WSE Soap Receiver and WSE Soap Sender classes inside a Windows .NET Application.
There’s a new buzzword going around the Developer’s ear. Have you heard it yet? It’s called SOA. It is an acronym for Service Oriented Architecture. This new concept is not really new; it is old in its definition; however the marketing departments of all the big wig companies are re-singing its tune. Microsoft is singing its SOA pop song with .NET building blocks, WSE, ASP.NET and XML. IBM is using another artist called On Demand, and others are following suit as well.
Traditional Distributed ApplicationsThis is new way in thinking especially for a Component architect. Let’s think about it for a second. In Object Oriented Programming from a windows developer perspective, we designed basic Com applications and Com Components around a basic three tier approach. Three Layers: one called the user interface layer. The second called the business logic layer, and the third known as the data layer. Our basic design was simple in concept, if a class had code that interacted with the User interface such as a windows application, or a web page, then we wrote the code on the user interface side. We wrote the code in the windows form, or in DHTML or some other user interface component. On the other hand, if we had logic that dealt with business rules, processes, day to day logic that was the real problem we were trying to solve, we’d place that code in one to many separate components within our business layer, and install that file on a business logic server such as MTS/COM+ services. Last, any logic that dealt with accessing a data source, such as a file, database, server and etc, we’d place that on the server or in a component that ran on the server like using stored procedures.
In OOP, we dealt with many sometimes frustrating terms and concepts. We had to learn Abstraction, Inheritance, Implementation, Encapsulation, Interfaces, Composition, Aggregation and other terms. OOP became so complex that we created diagrams to visually represent all of these terms and conditions called UML. We invested a lot of time and effort, and learning into this paradigm, yet, we still ran into One MAJOR subtly, one major flaw: Interoperability.
COM did not communicate with EJB, ISAM databases did not communicate with COM, CRM systems did not communicate with EJB, nor COM. These technologies did not allow for a smooth communication pattern automatically. We had to finesse and “tweak” each technology to be able to link these disparate designed systems together. The effort and hard work to make this possible caused many strains, and morphing of technologies. Even to the point where some technologies had many add-on features that are a 180 degree turn from its original designed architecture. Just look at ADO from its first versions to its current one, version 2.8 or so, and the most important change from COM technology to .NET. This eventually led to the inevitable.
SOA IntroductionA new paradigm in software design: SOA. So you mentioned all these songs the big wig companies are singing what are they all about? SOA is new way in designing systems. We now think of a system as a well designed, suite of components that is entirely based off of message communication patterns of what a component does (service). It is an idea to center the design of a system(s) on an “orchestrated” suite of services through message communication. These services talk to each other by passing Xml forms of messages back and forth to each other; this is the focal point.
An SOA System
The image to the left shows a standard depiction of a service, with three prongs sticking out from a triangle. These stubs, or points are known as “Endpoints” or “touchpoints”. They are the portals that allow the xml messages to come into and be sent out of some network using any protocol. This is quite the opposite of Distributed COM, where we were forced to use a proprietary protocol, and a special port to send network packets of data across the wire.
We could talk about services and how to architect them and all the new benefits that SOA offers, however the main point of this introduction is to talk about how these services talk to one another: messages. The basis of a message is Xml. Xml is the format, and within this format we have a very specific format called Simple Object Access Protocol (SOAP). SOAP messages contain all data needed to perform some unit of work. It may also contain security specifics like username and password, certificate information, and other secure concepts such as encryption and hashing.
SOAP messages give different platforms such as Unix a way to communicate with others like Microsoft. SOA, and SOAP solves our interoperability problems. The data being passed is all text, and all platforms understand text. Knowing this, the industry has comprised a set of templates, or models of ways in which these messages can pass back and forth. These models are known as Message Exchange Patterns.
Message Exchange PatternsThere are many Message Exchange Patterns (MEP). There is the first implementation of SOA called Xml web services which uses the Request/Response (Remote Procedure Call) MEP. There is also the Dead Letter Channel pattern, where a message is sent to a service, and any errors that occur during the processing of the message are sent to a special “node” or Channel. These errors, more often referred to as Soap Faults are then queued on to a stack. A client application can then retrieve the messages from this queue. There is the Message Router pattern where a message is routed to another service(s) based off of its content, or security credentials. There is the Message Splitter pattern, which splits or combines messages and sends them to other destinations, and most notably, there is the Publisher-Subscriber pattern.
The Publisher-Subscriber pattern is where a message comes into a service to notify it that it wants to listen for “messages that a publisher broadcasts to its listeners”. A Client application sends a “subscription” request message about who it is, and where it can receive these “responses” from the publisher. The application, be it physically installed on the Client or the Server, can then run, and wait on the Publisher service to generate these responses and send it back to its subscribers.
Client Application makes a Subscription Request
The Publisher service would then execute its logic and eventually loop through its collection of subscribers and send the message on. The publisher service may even send a “Fire and Forget” type of message to all the subscribers. This is because the Publisher service may not necessarily be concerned with who gets the message successfully, such as message confirmation.
Publisher service sends a copy of the message to subscribers
With Microsoft’s implementation of the community Standard: WSA, we can implement the Publisher Subscriber model of SOA. Microsoft implements this standard using an Add-on tool called Web Service Enhancements (WSE). Microsoft is currently in version 2.0 service pack 2 of the WSE toolkit, which is the version we’ll use to implement this model.
WSE gives us many classes and technologies we can use inside of a .NET based application. The two classes we’ll focus on is a SoapReceiver class and the SoapSender class.
SoapReceiversA SoapReceiver is a class that inherits/implements from the IHttpHandler interface. (see my article on using WSE with SimpleHandlerFactory) This class provides all the functionality you need to receive soap messages. To use this class just create a custom class and inherit from the SoapReceiver class. This class asks that you override the Receive method. This is the method that receives the soap message from a SoapSender class. Here is the signature of the Receive Method:
protected
本文地址：http://com.8s8s.com/it/it41573.htm