2008/5/29 Alexander Johannesen <[EMAIL PROTECTED]>: > Hiya, > > Ok, I'll be brave and cut down on the length a little bit without > killing the "importance". :) > > On Wed, May 28, 2008 at 6:25 PM, Steve Jones <[EMAIL PROTECTED]> wrote: >> I do hope there are non-XML examples of modelling as well. I loathe >> and detest XML, its sort of the democracy of document exchange (the >> worst form, except for all the other ones). > > Always non-XML around. I don't detest XML per se, but what some people > do with it. > >>> Ok, let's see if I can provide you with an example of resource >>> oriented models in REST. I've changed from cars to planes (because I >>> happen to have this data already), so hope you don't mind. Let's GET >>> an IRI about the SAAB 35 Draken fighter plane ; >> >> BTW the following isn't (in my simple mind) a modelling notation ;) > > Well, it isn't notation in the generic sense, but it certainly depicts > the model. Or, more specifically, it depicts model fragment results. I > guess here comes another RESTful way of dealing with this; I'm dealing > it out piecemeal, and you resolve the model until you're happy with it > (or can work with it). In some ways, this is incredibly revolutionary > way (and, I'm talking from my own perspective, of course) of dealing > with interoperability of a complex nature as the cache and hyperlinks > drives the state of the *model*. I find that very sexy.
I find Sophie Marceau attractive (http://www.imdb.com/name/nm0000521/) I think you need to get out more ;) What I mean is that what you are doing (to me) is going down to the detail to find the model, to me I think you have to step back to find the model to make it clear what the detail means. http://en.wikipedia.org/wiki/Feynman_diagram is a good example of how pictures can make the complex simple and act as the stepping stone into the detail. The implementation can be great but if its going to impact the big wide world of business then it needs to be in a way that makes sense beyond IT and XML docs are not that thing. > > ... > >>> All these items normally have names, but hopefully they also should >>> have PSD (descriptions, to make the ontological parts as clear as >>> possible as to their neature and meaning). >> >> Or use a commonly agreed definition? > > There is no "or" in that; it's what the PSI / PSD mechanism is; shared > agreement and definitions. My point is that you can do the agreement with out the PSI/PSD mechanism. > > ... > >> Now for data modelling I'm with you, I'm still struggling with the >> functional modelling aspect as it seems some what hidden behind the >> "POST" > > Ok, any examples of such which I can chew on? Those pictures I linked to. The functions are the interactions between the services. How do you model them? They aren't just data links they actually have a business purpose and result in defined real world effects. > > ... > >> Again I see this as a way to implement a modelled SOA rather than >> being the modelling approach itself. For me what you've show is an >> OrderService which enables you to order a bunch of things, or a >> generic OrderService which has a series of concrete implementations. >> You've then decided to implement that using REST (which effectively >> means taking the generic and concrete path) which is fine. >> I'm just not seeing the modelling bit. > > REST is here detached from resource orientation. In fact, through my > Topic Maps background I've been doing resource orientation (in a > specific sense) for years already. What I've got here are, as you say, > examples of something modeled. To see what resource orientation does > for the modeling exercise itself I'd use prose and notation language > (or XML, just to piss some people off :). Heck, I use napkins a lot, > too. > > But then, maybe I'm just not getting your point here. Is there any > examples you could give of what you're missing? What would you do? What I mean is that you couldn't take that to a business person and say "is this what you want" it just wouldn't make any sort of sense to them. > > ... > >> I'm not sure about no-inheritance. You've basically shown that a >> specific example inherits information from a generic example haven't >> you? That looks and smells like inheritance just implemented via >> hyperlinks rather than a compiler. > > I've said that you indeed *can* have these things, but they would be > part of the model you explicitly mark up, not part of some underlying > assumption about the architecture of the systems. In other words, you > can model up whatever you'd like, but there's no inherit (pun > intended) constraints like that in resource orientation as such. I'm missing the bit in OO where inheritance isn't explicitly "marked up" in the model. > >>> This is a web; lots of resource representing various stuff, in a web, >>> all typified (they all are a type of something, which can be >>> resolved). When you understand how the web is put together, you can >>> act on it through the REST mechanisms in a fairly uniform way, reusing >>> your basic handling code pretty much for every single resource. There >>> are less special cases you need to worry about. >> >> Assuming all the ontology stuff is done (big assumption). > > Why is that a big assumption? You already do ontology work, except you > hard-code it in code and configuration files for your bus and network. Yup. The big assumption is that doing this fixed way (which requires prior agreement) is less efficient and less reliable than... > Ontology work really is about detaching the systems specific ontology > (name of tables and columns in databases, names of variables, names of > API's, etc) in a way to free the data from its container (probably > inspired by how some words have multiple meaning and can be in many > categories at once). This way. That is the big assumption. > > It's not as hokey as I may come across here. For example, Topic Maps > delivers a meta data model which you extend to support any crazy > modeling idea you have, so we've taken a half step forward but leaves > a lot up to you to define, as opposed to the four steps forward of > SemWeb (basic RDF, then RDFS, then three levels of OWL, and *then* > your own models) but five steps back when you understand the > constraints involved. Which is my point, yes its "uber flexible" but when I wanted to do a B2B piece between 120 systems in 60 countries I did the following 1) Had a meeting 2) Told everyone what the interface specifications would be 3) Told them how I was going to test their interfaces to make sure they had done the work properly That was it. 120 systems, 60 countries a huge number of different ontologies and we fixed it in one meeting. I could have done something more flexible from a technology standpoint but the solution was perfectly flexible from a business standpoint. > > Anyway, I like to detach my data from its containers, but many others > don't, and I can understand why. Don't detach data to far from its function, from bitter experience there is lots of implicit state in applications that render data pointless when queried independently of the application that creates it. Once its a completed transaction then go for your life on it but during the flow... too many variables. > > ... > >>> Ok, what's an example of that sort of higher level, and let's see if I >>> can help out somehow. >> >> http://blueprints.jot.com/WikiHome/SOA%20Business%20Blueprint >> >> With pictures. Basically this is how I model businesses and help them >> re-organise their people and systems to match more effectively how the >> business works. I might choose to use REST in certain circumstances >> for implementation but the architectural model is SO. > > Ok, I see where you're going, and I think that no matter how much > notation or XML I throw your way, they won't turn into drawings. :) > Well, kind of. I do have a GraphViz engine that maps up Topic Maps, so > I *can* use notation for what you draw and have both a drawing and a > model and a RESTful interface to it, but I need a little bit more time > than I have right now. (I assume you work too? :) But I'm keen on > trying it out. My notation language looks a bit like this YAML > friendly snippet: > > Manufacture [color:green]: > -> Logistics & Warehouse ("Supply stock") > > Finance [color:pink]: > <-> Manufacture ("Budget") > <-> Marketing ("Budget") > <-> Logistics & Warehouse ("Budget") > <-> Sales ("Budget") > > Logistics & Warehouse [color:]: > -> Manufactore ("Request stock") > > Marketing [color:blue]: > -> Distributor > > Sales [color:gray]: > -> Logistics & Warehouse ("Ship Order") > -> Distributor ("Sell product") > > person:Plant Machinery Supplier > person:Materials Supplier > person:Logistics Company > person:Distributor > > Each thing here is a resource, so ; > > http://example.com/core/manufacture > http://example.com/core/logistics > http://example.com/business/finance > http://example.com/business/marketing > http://example.com/business/sales > > http://example.com/parts/plant_machinery_supplier > http://example.com/parts/raw_materials_supplier > http://example.com/parts/logistics_company > http://example.com/parts/distributor > > The relationships themselves are resources ; > > http://example.com/business/rel/budget > http://example.com/business/rel/invoice > http://example.com/business/rel/sell_product > http://example.com/business/rel/ship_order > > Yes, I could put more effort into cooler IRIs for all these things, > but we'll use these for now. In my notation I use URL Templating to > specify these, for example ; > > Sales [color:gray tmpl:business/sales]: > -> Logistics & Warehouse ("Ship Order" tmpl:rel/ship_order) > -> Distributor ("Sell product" tmpl:rel/sell_product) > > And so on. The thing here is that the notation has converted all of > this to a Topic Map. My RESTful framework just use this Topic Map as > the application engine, and the mechanisms of REST delivers this > piecemeal (or as big as requested). > > Ok, I assume you now want a link between this conceptual model, and > the real world (or the real OO objects and software). I do this in > either of two ways; if it's a straight easy task, I just have an > action class for each resource, or, if there's more complexity not > depicted in this model, I defer that resource to be a Topic Map in > itself, with its own notation and resources, etc. I can here narrow > the scope of the model as I dig deeper into the semantics of the > problems the applications are trying to solve. this creates a nice > link from the most conceptual to very specific models. And by "model", > I include a simple struct of integers and floats as a model as well. > Since all of them are resources with unique addressability, I can > connect these otherwise disjoint pieces together if that makes sense > to do (for example, a marketing campaign object in a CMS can have a > direct link to the conceptual model of the "Target" link between > Marketing and Distributor. Some applications can react to this > relationship if they see fit, and they can either know about it or > resolve it, or browse to it, ignore it, map it, etc. I guess the > openness / addressability is what I'm mostly salivating over here. > > I'm fond of domain-driven design, but instead of doing that on the > object level, I do that on the modeling and Topic Maps level, and feed > that model to the REST framework. Resource orientation makes sure that > the integrity I had in my conceptual model can be transfered to the > actual implementation (no translation). If I choose do to so, the > conceptual model is an actual part of the end product. > > Does this make sense? Makes a bit more sense... I'm just not seeing the simplicity. Although it does give me an interesting idea (when I get any free time) of how I could translate the business SOA into REST more easily. > > ... > >> It would take someone smarter than Einstein and Newton combined to be >> able to look at the problem in totality and then sit down and write >> the solution! > > Ok, off you go, then. :) > > ... > >> And the way they did that was to poison themselves to prove the point >> (self-testing unsafe medical experiments being the only way to do it). > > That's the part of science I think I love the most. Not sure what that > means. > > ... > >> What I mean is that having been on the skeptical camp around semantics >> since I first saw it in academic anger in 2002 I still think that >> sitting down and agreeing on things is a quicker and more secure route >> than relying on semantic mappings. > > Well, if you look at it from the academic and SemWeb angle, I can > certainly emphasize with your view. Its probably the loudest one out there. > >> The mappings can help you but what >> can be miles more effective is a bunch of people sitting down and >> saying "central database with all the codes in, codes written down as >> a series of lines, bobs your uncle we've massively improved the global >> supply chain" > > But you must admit that such system are rarely built for change, no? Actually my experience has been that these ruggedly defined systems with strict policies and control are often better at coping with change because they have the engineering rigour. So lets say you have a system that currently does Single Customer view for sales, takes in data from over a hundred current solutions and runs them through a data standardisation and cleansing bit. Next up you want to do the same for suppliers, no problem the infrastructure and process is in place you just need to repeat with a different data set. Now lets say you want to push changes back into the source systems. Well you've got the mappings that you need and an integration bridge. Repeat the process but the other way around. Now sometimes they can become just sink pits, but that is because the design (not the architecture ;) ) has been done badly and not thought about the overall structure and concentrated just on the limited phase 1 requirement set. The point is that having enforcement is often a very effective way of driving business change, even if technically its not as flexible. > >> Lots of people agree how to interact without an RDF, OWL/S or other >> semantic technology. > > Possibly true, although I suspect the efforts going into agreeing > sometimes are just so huge, so intense, so politically charged. I've worked in those areas, and yes it can be tough but the idea of trying to do it automatically via a semantic approach. Lets put it this way, I used to work in Air Traffic Control systems, would you be happy if the interface between two countries was based upon an OWL/S translation or via an internationally agreed standard? My experience has been that you need the skill to define the interfaces and get the agreement and then its all easy. From what I have seen on OWL/S and RDF attempts its the classic backend problems, and as we all know its always cheapest to fix problems up front. > Inference does have some areas in which it *will* kick ass and > revolutionize the way we do things. Which areas is yet to be seen, > however, and that this area is somewhat muddy doesn't help things > along right now. It will help in some areas particularly when human assisted (IMO) but in a B2B automatic transformation approach? Nope. > > ... my example ... > >> But this doesn't say how they work together and collaborate, it says >> they are in the same team but doesn't say what their measures are an >> how those cascade from the team downwards etc. In otherwords how are >> tactics applied to that next work etc. > > I could do all that, I just thought I'd give you the small pitch > instead of the 500Kb example. And, I don't sit around picking my nose > all day, so time is scarce, but yes, I could do more if you like. :) > But maybe give me a few concrete examples of how tactics are applied > to the stuff you do? Take two services, lets say Warehouse and Stores Warehouse has a policy of reducing stock and meeting stock requests from Stores. Stores also don't want much stock in Store and they NEVER want an empty shelf when someone wants to buy that thing. This gives some competing policies on these services as for the Store (which doesn't care about Warehouse stock levels) it would prefer the Warehouse to have infinite stock and zero lead times so it can request just before it becomes a problem, the Warehouse however wants lots of notice of what the Store wants so it can do Just In Time delivery. What this leads to therefore is a collaboration between the two in order to both meet their SLAs. The Warehouse will commit to fufilling an order if given a lead time of X and if the Store promises not to order then cancel. Put in place some measures and penalities on this interaction and you get an effective collaboration. The Warehouse then backs these agreements off to its suppliers and thus helps decrease the cost of purchase and reduce the stock outs while keeping stock as low as possible. The point here is that this negotiation spreads across the network and is part of the reason (in my mind) services are different to applications as a given service has to guarantee the full ecosystem as it is that service that is perceived as delivering the real world effect. Vendor Managed Inventory is another good example of competing yet collaborating policies between services. The point of this is that services have policies and contracts, in order to deliver these in an ecosystem they have to negotiate with others to ensure the total delivery > >> Which is where I see the stuff above as implementation rather than >> modelling. The first thing I'd like to know is the model, I'm just >> not seeing models above I'm seeing implementation examples. > > It was there in how the XML snippets were bound together. Maybe you're > after one whopping XML or notation language file which has a complete > model for you to work with. I could provide that, too, but I prefer - > no, I insist! - on the piecemeal delivery and how REST can cache it > and get just enough to do that little thing it needs to do. I find > that so cool, and you won't find it in the SOAP stack. This isn't REST v SOAP. Its about Service modelling v Resource modelling. > >> I'm thick so it takes me a while > > Hey, I'm Norwegian, so this could take even longer ... ;) Steve > > Alex > -- > ---------------------------------------------------------- > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > ------------------------------------------ http://shelter.nu/blog/ -------- >
