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 ________________________________ From: Steve Jones <[email protected]> To: [email protected] 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* >>>> >>>> >>>> >>>> > >
