Gervas, my apologies; I indeed had assumed that was your post that time... - Michael
________________________________ From: Gervas <[email protected]> To: [email protected] Sent: Thu, January 14, 2010 10:28:41 PM Subject: [service-orientated-architecture] Re: Steve on RPC Michael, some confusion here which looks like my fault. I was merely quoting Steve's blog but failed to put the opening brackets, <<, in place. Gervas --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > [Michael, there is a misunderstanding here which is my fault - I seem to have > forgotten to include my initial quote brackets, "<<". What I quoted verbatim > was Steve's blog. Gervas] > > > > Gervas, > > let's start with that "Get Delivery Status" is not really a capability as > well as "Get Forecast", they are operations of the interface as the most. > That is, we have clearly distinguish between service capabilities and service > interface operations. This is the first 'attack' on the RPC as a high level > of 'a consistent view' - what is consistent from RPC perspective may be > inconsistent from service perspective. > > "When we call "Make Forecast" on the Finance Service it needs to ask the > Sales Service for its Forecast and therefore does a "Get Forecast" call on > the Sales Service. We need the Forecast to be updated daily" - from the > service consumer perspective (the only correct viewpoint for analysing > services), the Finance Service is responsible for the Forecast irrespective > to whether it gets it from the Sales Service or not. From architectural > viewpoint, > the Finance Service has to interact with the Sales Service, and this is not > necessary to an RPC call (may be MOM-based request); this depends on the > Finance Service's Service Description. If "we need the Forecast to be updated > daily", this is another reason for NOT using RPC between the Finance Service > and the Sales Service. > > "Now when we start working through this at a systems level ..." utilisation > of legacy systems in Mainframes and FTP/ETL is fine but this is not dictated > by the RPC style (as you confirmed: "...but instead of making an RPC call to > get that information we have decided...". That is, RPC is good but not really > universal to become the Development Solution #1. This is the second 'attack' > on the RPC. > > > Provided description of "RPC into Events" calls for messaging solution > bypassing anything related to RPC. Given event-driven scenario is typical > 'push' scenario, which operates in contra-RPC model. This is the third > 'attack' on the RPC. > > REST=RPC via special transport protocol, no doubts. But REST can play only > the interface role for the service. REST is technology not a separate > concept, and this concept is RPC. > > Finally, I totally disagree with the "Conceptual v Delivery" and, I hope, I > have demonstrated on your examples limited usability of RPC for service > design. This is why I repeat - service must be designed as service and its > implementation must respect and preserve service constraints and boundaries. > The horse pools the cart; the cart, does not matter if it is a phaeton or a > royal carriage, does not push the horse. > > - Michael > > > > ____________ _________ _________ __ > From: Gervas Douglas <gervas.douglas@ ...> > To: service-orientated- architecture@ yahoogroups. com > Sent: Thu, January 14, 2010 11:01:08 AM > Subject: [service-orientated -architecture] Steve on RPC > > > Gregg Wonderly made a good comment on the Yahoo SOA list the other day > > I > >think one of the still, largely unrecognized issues is that developers > >really should be designing services as RPC interfaces, always. Then, > >different service interface schemes, such as SOAP, HTTP (Rest et.al.), > >Jini, etc., can be more easily become a "deployment" technology > >introduction instead of a "foundation" technology implementation that > >greatly limits how and under what circumstances a service can be used. > >Programming Language/platform IDEs make it too easy to "just use" a > >single technology, and then everything melds into a pile of > >'technology' instead of a 'service'. > > The point here is that conceptually RPC is very easy for everyone to > understand and at the highest levels > it provides a consistent view. Now before people shriek that "But > RPC sucks" I'll go through how it will work. > > First off lets take a simple three service system where from an "RPC" > perspective we have the following: > > The Sales Service which has capabilities for "Buy > Product" and "Get Forecast" > > The Finance Service which has capabilities for "Report > Sale" and "Make Forecast" > > The Logistics Service which has capabilities for "Ship > Product" and "Get Delivery Status" > > There is also a customer who can "Receive Invoice" > > Now > we get into the conceptual design stage and we want to start talking > through how these various services work and we use an "RPC language" to > start working out how things happen. > > RPC into Push > When > we call "Make Forecast" on the Finance Service it needs to ask the > Sales Service for its Forecast and therefore does a "Get Forecast" call > on the Sales Service. We need the Forecast to be updated daily. > > Now > when we start working through this at a systems level we see that the > mainframe solution of the Finance team is really old and creaky but it > handles batch processing really well. Therefore given our requirement > for a daily forecast what we do is take a nightly batch out of the CRM > solution and Push it into the Mainframe. Conceptually we are still > doing exactly what the RPC language says in that the data that the > mainframe is processing has been obtained from the Sales area, but > instead of making an RPC call to get that information we have decided > in implementation to do it via Batch, FTP and ETL. > > RPC into Events > The > next piece that is looked at is the sales to invoice process Here the > challenge is that historically there has been a real delay in getting > invoices out to customers and it needs to be tightened up much more. > Previously a batch has been sent at the end of each day to the > logistics and finance departments and they've run their own processing. > This has led to problems with customers being invoiced for products > that aren't shipped and a 48 hour delay in getting invoices out. > > The > solution is to run an event based system where Sales sends out an event > on a new Sale, this is received by both Finance and the Logistics > department . The Logistics department then Ships the Product (Ship > Product) after which it sends a "Product Shipped" event which results > in the Finance department sending the invoice. > > So while we have the conceptual view in RPC speak we have an > implementation that is in Event Speak. > > RPC into REST > The > final piece is buying the products and getting the delivery status > against an order. The decision was made to do this via REST on a shiny > new website. Products are resources (of course), you add them to a > shopping basket (by POSTing the URI of the product into the basket) > this shopping basket then gets paid for and becomes an Order. The Order > has a URI and you just simply GET to have the status. > > So conceptually its RPC but we've implemented it using REST. > > Conceptual v Delivery > > The > point here is that we can extend this approach of thinking about things > in RPC terms through an architecture and people can talk to each other > in this RPC language without having to worry about the specific > implementation approach. By thinking of simply "Services" and > "Capabilities" and mentally placing them as "Remote" calls from one > service to another we can construct a consistent architectural model. > > Once we've agreed on this model, that this is what we want to deliver, > we are then able to design the services using the most > appropriate technology approach. I'd contend that there really aren't any > other conceptual > models that work consistently. A Process Model assumes steps, a Data > Model assumes some sort of entity relationship a REST model assumes its > all resources and an Event model assumes its all events. Translating > between these different conceptual models is much harder than jumping > from a conceptual RPC model that just assumes Services and Capabilities > with the Services "containing" the capabilities. > > So the basic > point is that architecture, and particularly business architecture, > should always be RPC in flavour. Its conceptually easier to understand > and its the easiest method to transcribe into different implementation > approaches.> > > > You can read Steven's blog at: http://service- architecture. blogspot. > com/2010/ 01/think- in-rpc-develop- in-anything. html > > Gervas >
