Steve, I would agree with your statement with one small addition:
"the RPC "style" as ONE OF OTHER'styles' "makes good looking models not that RPC as a technology is the way to go" I argue against exclusive use of RPC in the design of the services. I argue that top-down design of services defines and dictates the _style_ of the service development, not the technology used for the development. - Michael ________________________________ From: Steve Jones <[email protected]> To: [email protected] Sent: Fri, January 15, 2010 8:34:37 PM Subject: Re: [service-orientated-architecture] Steve on RPC 2010/1/15 Michael Poulin <m3pou...@yahoo. com> > > > > > > > > > > > > > > > > > >> > >> > >I agree with "the conceptual architecture using a single consistent style" but >I disagree that this style is RPC. Relationships and corresponding >interactions between architectural entities are the part of the architecture, >it is not a technology; I can send a message via MOM or via FedEx, this is >immaterial at the architecture level. Michael so what is your consistent "style" at this level. I'm explicitly saying that the RPC "style" makes good looking models not that RPC as a technology is the way to go. Steve > >- Michael > > > ________________________________ From: Steve Jones <jones.steveg@ gmail.com> > >To: service-orientated- architecture@ yahoogroups. com >Sent: Fri, January 15, 2010 10:08:07 AM >Subject: Re: [service-orientated -architecture] Steve on RPC > > > > > > >> > > > > >2010/1/14 Eric Newcomer <e_newco...@yahoo. com> > >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>>> >> >>>> >> >>I don't think this is correct. We are modeling and designing services with >>various message exchange patterns, both synchronous and asynchronous and we >>consider this to be consistent with SOA based designs. >> > > >At the IMPLEMENTATION and TECHNOLOGY levels I completely 100% agree that this >is what we do. What I'm saying (and Gregg pointed out) is that you are often >better off doing the conceptual architecture using a single consistent style >(RPC) and then making the implementation (design) decision afterwards. The >alternative is having a high-level architecture which exposes technical >implementation styles. > >Steve > > >>>>Eric >> >> >>>>On Thu Jan 14th, 2010 5:50 PM EST Steve Jones wrote: >> >>>>>Fight ;-o >>>>> >>>>>2010/1/15 Michael Poulin <m3pou...@yahoo. com> >>>>> >>>>>> >>>>>> >> >>>>>> 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 >>>>>> >>>>> >> >>>>>How do you work that out? >>>>> >>>>>To obtain a delivery status for an order is a core capability that an order >>>>>management service must have. To get that status it might have to query >>>>>external systems as well as doing internal work. >>>>> >>>>>A Forecast is even more of a business capability, creating a forecast >>>>>involves potentially millions of calculations and feeds from massive number >>>>>of other systems. If its a real-time forecast then the amount of work can >>>>>be stratospheric. >>>>> >>>>>A Capability is a thing that delivers the real world effect. Getting the >>>>>Delivery status or getting a forecast results in a real world effect and >>>>>undertakes a constrained piece of business functionality. >>>>> >>>>> >>>>> >> >>>>>> . 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. >>>>>> >>>>> >> >>>>>I can't really see it as an attack when you haven't explained, beyond a >>>>>statement how neither retrieving delivery status or a forecast result in a >>>>>real-world effect. >>>>> >>>>> >>>>> >>>>>> >> >>>>>> "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. >>>>>> >>>>> >> >>>>>I am NOT saying that the implementation should be RPC but that the >>>>>ARCHITECTURE is conceptually RPC. Having a consistent conceptual model and >>>>>allowing multiple implementation models is the under-pinning strength of a >>>>>business SOA approach. >>>>> >>>>> >>>>>> >> >>>>>> "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. >>>>>> >>>>> >> >>>>>Eh? I'm not saying that RPC at the conceptual level = RPC at the >>>>>implementation level. >>>>> >>>>> >>>>> >>>>>> >>>>>> >> >>>>>> 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. >>>>>> >>>>> >> >>>>>Nope, its nothing of the sort. Its proving the point that RPC as a >>>>>conceptual framework can be used and then mapped to multiple implementation >>>>>approaches. The Business folks don't need to worry about the exact >>>>>implementation approach (see Christmas SOA) but the validity of the >>>>>conceptual model. >>>>> >>>>> >>>>>> >> >>>>>> 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. >>>>>> >>>>> >> >>>>>I'm not even going there... >>>>> >>>>> >>>>>> >> >>>>>> 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. >>>>>> >>>>> >> >>>>>Nope I don't think you have. What you've demonstrated is that at the >>>>>implementation level you can use lots of approaches (which is what I've >>>>>said). Having a conceptual architecture which surfaces EDA, GDA, REST, >>>>>RPC, >>>>>MOM and all the other implementation approaches to the business is just >>>>>wrong and not (IMO) SOA. >>>>> >>>>>SOA means that you have services and they have capabilities which can be >>>>>exercised >>>>>RPC means that you have interfaces and they have operations which can be >>>>>exercised >>>>> >>>>>This is why the two go well together at a *conceptual level* and you then >>>>>choose the right *implementation approach* as you move into design. >>>>> >>>>>Steve >>>>> >>>>> >>>>> >>>>> >>>>>> >> >>>> - Michael >>>>>> >>>>>> ------------ --------- --------- >>>>>> *From:* Gervas Douglas <gervas.douglas@ gmail.com> >>>>>> *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<http://service- >>>> architecture. blogspot. com/2010/ 01/think- in-rpc-develop- in-anything. >>>> html> >>>> >> >>>> >>>>>> Gervas* >>>>>> >>>>>> >>>>>> >>>>>> >> >> > >
