ok, I can see what you're saying, and that's probably a valid design approach. But we also take the approach of identifying the message exchange pattern as part of the initial design. I suppose synchronous or request/response could be a good default though.
Eric On Fri Jan 15th, 2010 5:08 AM EST Steve Jones wrote: >2010/1/14 Eric Newcomer <[email protected]> > >> >> >> 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 <[email protected] <m3poulin%40yahoo.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 >> >> <[email protected]<gervas.douglas%40gmail.com> >> > >> >> *To:* >> >> [email protected]<service-orientated-architecture%40yahoogroups.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* >> >> >> >> >> >> >> >> >> >> >>
