Service-Oriented Architecture Attributes Progress Report 1

Service-Oriented Architecture Attributes Progress Report 1

The modification of my Exploratory Project to incorporate the component and topic attributes of my blog post of a week ago is complete.  That is, complete enough to execute the same set of test components and topics as previously. 

The Display Application can send events to the Display Interface component of User Application 1.  It then extracts the event data from the message and publishes a Delivery Identifier message exchange topic where the identifier of the button, checkbox, edit box, etc of the widget of the event is used as the delivery identifier.  The instance of the Widget Event topic is then routed by the framework to the application component that registered/subscribed to treat the widget event.  Three different components in two different applications so registered to treat a set of widget events.

These components then create a request-response topic as the command to be sent back to the display application.  This is routed to the Display Interface component as the component that registered to consume the request and it forwards it as a Display Command message to the Display Application which modifies what is displayed.  In addition the Display Interface component creates and publishes the response to the request.  Two of three Widget Event handler components didn’t subscribe to the response so the framework discards these responses while routing those for the third component back to it.

Another Content Filtered topic response is created and published by a component and routed by the framework to the particular component that requested it.

Certain previous attribute classifications were eliminated while other classifications were added.  This caused the need to restructure some of the framework packages / classes for consistency with the new attribute classifications.  Also, the modification of some of the logic was necessary when a combination of the new attribute options was necessary to specify a characteristic of a previous classification that had a greater range of more specific options.  For instance, N-to-One had to become a combination of the Request-Response, Queued, and Point-to-Point attribute options whereas N-to-One had previously implied all three.

Since there are now more combinations of options available, such as the ability of a periodic component to consume a point-to-point topic via polling of queued instances of the topic, further updates to the framework are going to be necessary for such combinations.  Thus further test components and topics will be necessary to debug these modifications as they are made.

A future progress post will report this.