A previous article asserts that SOA must be able to respond to business challenges quickly and cost effectively. Otherwise development teams will find it easier to develop their own private, single-use solutions, undermining the enterprise SOA. We understand this at RSSBus, and offer an SOA solution specifically designed to reduce the cost of building, using and maintaining shared services.
A follow-on article explained how RSSBus connectors and service definitions make it easy for service providers to create simple services. But if we make service creation easy, we need to make service changeability easy, too, or teams will always build new services instead of extending those already in place.
RSSBus simple services are easy to extend and compose because they use very simple input and output formats. The input format is based on a hashtable of attributes, which can be implemented as parameters on a URL query string, as POST data input, or as items from an RSS v2.0 feed. The output format is based on lists of hashtables of attributes that can be represented as RSS v2.0, rows in a spreadsheet, or HTML tabular data:
|
Item |
|
|
Item |
|
|
City |
Chicago |
Lookup |
FirstName |
Bob |
|
EndItem |
|
Customers |
LastName |
Jones |
|
HTTP Request |
By City |
Phone |
123-4567 |
|
|
|
|
City |
Chicago |
|
|
|
|
EndItem |
|
|
|
|
|
Item |
|
|
|
|
|
FirstName |
Joe |
|
|
|
|
LastName |
Smith |
|
|
|
|
Phone |
234-5678 |
|
|
|
|
City |
Chicago |
|
|
|
|
EndItem |
|
|
|
|
|
. . . |
|
|
|
|
|
RSS Response |
Enterprise data represented in these formats can be extended anytime without breaking existing services. For example, to add a cell phone number to an existing customer contact service response, we simply add a new attribute for CellPhone:
|
Item |
|
|
Item |
|
|
FirstName |
Bob |
|
FirstName |
Bob |
|
LastName |
Jones |
|
LastName |
Jones |
|
Phone |
123-4567 |
|
Phone |
123-4567 |
|
City |
Chicago |
|
City |
Chicago |
|
EndItem |
|
|
CellPhone |
456-7890 |
|
Item |
|
|
EndItem |
|
|
FirstName |
Joe |
|
Item |
|
|
LastName |
Smith |
|
FirstName |
Joe |
|
Phone |
234-5678 |
|
LastName |
Smith |
|
City |
Chicago |
|
Phone |
234-5678 |
|
EndItem |
|
|
City |
Chicago |
|
. . . |
|
|
CellPhone |
345-6789 |
|
Original Response |
|
EndItem |
|
|
|
|
|
. . . |
|
|
|
|
|
With New Data |
Because the data is delivered as a list of hashtables, existing services that don't know about the CellPhone attribute simply ignore the new data, and continue to extract the attributes that they need.
Simple formats make it easy for one service to augment the output of another. For example, service output is easy to combine by chaining service calls:
|
Item |
|
|
Item |
|
|
Item |
|
|
City |
Chicago |
Lookup |
FirstName |
Bob |
Append |
FirstName |
Bob |
|
EndItem |
|
Custs. |
LastName |
Jones |
Sales |
LastName |
Jones |
|
1st Service Request |
By City |
Phone |
123-4567 |
By |
Phone |
123-4567 |
|
|
|
|
City |
Chicago |
Cust. |
City |
Chicago |
|
|
|
|
EndItem |
|
|
Volume |
$100,000 |
|
|
|
|
Item |
|
|
EndItem |
|
|
|
|
|
FirstName |
Joe |
|
Item |
|
|
|
|
|
LastName |
Smith |
|
FirstName |
Joe |
|
|
|
|
Phone |
234-5678 |
|
LastName |
Smith |
|
|
|
|
City |
Chicago |
|
Phone |
234-5678 |
|
|
|
|
EndItem |
|
|
City |
Chicago |
|
|
|
|
. . . |
|
|
Volume |
|