Unfortunately so, they did have some very clever stuff around object evolution though.
Steve 2009/8/30 gervasdouglas <[email protected]>: > > > Sadly, Intamission is no more as far as I know. As it so happens I was doing > some contract work for them in Windsor when I founded this Group. > > Gervas > > --- In [email protected], Michael Poulin > <m3pou...@...> wrote: >> >> Steve, is this what you referred to http://www.aboutus.org/IntaMission.com >> ? >> >> Also, it would be interesting to read the works of Dan Creswell and Nigel >> Warren ( they have many publications, which one do you refer?) >> - Michael >> >> >> >> >> ________________________________ >> From: Steve Jones <jones.ste...@...> >> To: [email protected] >> Sent: Sunday, August 30, 2009 11:02:07 AM >> Subject: Re: [service-orientated-architecture] Re: good or bad practice? >> or maybe ugly >> >> 2009/8/29 Michael Poulin <m3pou...@...>: >> > >> > >> > In this case, I agree with Steve not more than in 90%. >> > >> > Sending objects, in Java, C#, Smalltalk or any other compiled languages, >> > requires re-compilation for any changes. In the case of XML or other >> > declarative languages, it is possible to construct parsers that can be >> > modified/tuned based on the externalised onthologies and logic rules >> > applied >> > to new combinations of vocabulary and parsing decisions. This is more >> > laborious approach (then in Java) but it is more flexible (less coupling >> > life-cycles of the consumer and service (code)). The efforts are for the >> > sake of existing consumers who should not be bothered with unrelated >> > service >> > changes (including the changes in the interfaces). Here is nothing in my >> > logic related to the 'human readable' aspect of XML. >> >> You don't have to recompile if the protocol is binary either, its just >> the "quicker" way that most people do. >> >> The point here is between commonplace reality and technical theory. >> It is possible to have a Java to Java interaction that doesn't require >> recompilation at version changes (Intamission and the stuff that Dan >> Creswell and Nigel Warren wrote did this) and that can be extended to >> other languages. >> >> The point is that people _haven't_ done that, not that it isn't possible. >> >> > >> > There is a minor semantic difference between interaction and data >> > transmission. Inefficient text-based protocol may be more suitable for >> > interactions while IIOP is much better for transmission. A text as a >> > less >> > formalised form than a combination of bits, i.e. a text is less certain, >> > can >> > work for nuances of business tasks having wider interpretation. That is, >> > with text, we can send data and new instructions about manipulations on >> > this >> > data, and all this may be done through the same service with no changes >> > in >> > the code (one service can ignore new instructions, if properly >> > constructed, >> > while another service can accept and perform the instructions â€" this >> > is the >> > old pattern, nothing new in this world except for “the excess of >> > bandwidth >> > and CPU power we have these days†). >> >> See above. Intamission used to enable this in a Java environment >> using binary protocols, very clever stuff. >> >> Steve >> >> >> > >> > - Michael >> > >> > ________________________________ >> > From: Steve Jones <jones.ste...@...> >> > To: [email protected] >> > Sent: Friday, August 28, 2009 10:55:09 AM >> > Subject: Re: [service-orientated-architecture] Re: good or bad practice? >> > or >> > maybe ugly >> > >> > >> > >> > The point is one of perception and "because XML is human readable" it >> > is perceived that XML is a better neutral interchange format that IIOP >> > or the Java specific protocols. With a "neutral" protocol like XML >> > you have a perceived greater degree of independence of end-points and >> > as a result the market goes with that perception and voila you have a >> > greater degree of independence because multiple people in multiple >> > languages now have developed parsers for XML rather than the numerous >> > binary protocols that exist. >> > >> > Technically there is ZERO difference between the protocol defined in >> > XML or in any other exchange mechanism but the reality is that there >> > is a significant increase in independence by choosing XML because that >> > is what people have backed. >> > >> > As my father noted at an XML conference in 2001 "Oh great ASCII RPC" >> > the point being than none of these elements are fundamentally >> > different but thanks to the excess of bandwidth and CPU power we have >> > these days we can use one of the most inefficient mechanisms (Text >> > processing) based in part on a false assumption (its human readable) >> > rather than nice efficient protocols that are better suited to M2M >> > exchange. >> > >> > My reading on this thread is that Gregg is right technically and >> > Michael is right in the reality of how the world works today. >> > >> > Steve >> > >> > 2009/8/26 Gregg Wonderly <ge...@...>: >> >> >> >> >> >> Michael Poulin wrote: >> >>> Sorry, Greag, I did not mean to push you :-) >> >> >> >> I am trying to find the gap between our thinking because I still don't >> >> sense >> >> you >> >> get my point, and I am not sure I understand where you find the gap >> >> between >> >> Java >> >> and XML. >> >> >> >>> By coupling I meant programming coupling which threats usability. >> >>> There >> >>> are no totally decoupled things in the interaction (otherwise there >> >>> will >> >>> be two monologues). >> >> >> >> This is an important point. If I send you XML, you have to have an XML >> >> engine >> >> to access it. If I send you a Java serialized stream you have to have >> >> an >> >> engine >> >> to access it. For me, both a sequences of data values, delimited by >> >> some >> >> documented structure that allows access to the real data. >> >> >> >> XML requires that I write code and depend on the structure of the XML >> >> to >> >> know >> >> how to use it. Even XSL is "code". It requires knowledge of what you >> >> have >> >> and >> >> what you need. This is the basic premise behind software development. >> >> Taking >> >> something present in "your" world and processing it into something more >> >> useful >> >> in "your" world. >> >> >> >>> Java and XML do couple but if Java/C# couples by compilation and >> >>> semantics, XML couples by references and semantics. None of the >> >>> elements >> >>> in your XML exist on its own, it has to be defined in an XML Schema. >> >> >> >> There has to be something to document the stucture Schema is one way to >> >> say >> >> what >> >> should be in the structure, but any "documentation" is a dependency >> >> identical in >> >> nature to a software system interface definition. >> >> >> >>> However, you can have one Schema for the whole document - for all >> >>> elements, or individual Schemas for each element (it is a bit of >> >>> extreme >> >>> but if you want full structure flexibility, you can have it). >> >> >> >> I illustrated below that ticket, person and event could be seen >> >> separately >> >> as >> >> the interfaces or together as the class object that implements the >> >> interfaces. >> >> This is exactly equivalent to an XML schema in complexity and knowledge >> >> of >> >> what >> >> is "present" in the service definition. >> >> >> >>> Then, if >> >>> you consumer know only a sub-set of your Schemas - this is what the >> >>> consumer want to receive - you can send the same document partially; >> >>> plus, the consumer can use different (preliminary agreed - this is the >> >>> coupling) Schema for request or require particular Schemas to be used >> >>> in >> >>> the responses. >> >> >> >> With a smart proxy, I can deliver only a portion of the data, and then >> >> if >> >> the >> >> other parts are requested, I can go get them, or derive them in some >> >> way. >> >> The >> >> presence of software in the form of mobile code, allows me, as the >> >> service >> >> provider, to optimize my users experience by adapting and changing over >> >> time, >> >> what the service implementation is, without having to ask the client to >> >> do >> >> something different as long as I meet the contract that they signed up >> >> for >> >> (the >> >> interfaces that I documented). >> >> >> >> The problem with XML is that it has to be there. You have to send the >> >> data, >> >> or >> >> the client has to have all the knowledge to know what bits and pieces >> >> come >> >> from >> >> where, how to get them, what's expensive to get, what changes over >> >> time, >> >> when it >> >> changes etc. All the clients have to do all the same work to get >> >> changed >> >> behavior that is needed to evolve the services interface if not >> >> implementation. >> >> >> >>> Now, preliminary agreed Schemas are also not that strong level of >> >>> coupling as in Java because the agreement may be about two tings: 1) >> >>> locations of the XML Schema; 2) ontology (vocabulary) that may be >> >>> potentially used. This allows changing even the Schemas on the fly if >> >>> both sides understand the same ontology. The deployment of code and >> >>> code >> >>> modification in the consumer and service sides remains immutable. >> >> >> >> If the content of the document is not identical in element, attribute >> >> and >> >> structure, how can there be immutable code? >> >> >> >>> Using technique like XMLBeans, I can generate the full or partial >> >>> documents from XML-to-Java and from Java-to-XML having both controlled >> >>> by XML Schema (another use of this thing is data quality control in >> >>> Java >> >>> since I can define, e.g. Java String to the last character and its >> >>> position in the XML Schema. It is possible the same feature is now >> >>> available in Java, I am not sure). >> >> >> >> I didn't quite understand this. Mapping between XML and Java requires >> >> an >> >> engine >> >> that somehow has knowledge of how that works. This is no different that >> >> the >> >> underlying Java Serialization between on the wire structure and live >> >> Java >> >> object. >> >> >> >>> To conclude, I would like to say that, IMO, I have much more >> >>> flexibility >> >>> with XML in manipulating the service interaction (message content) >> >>> with >> >>> already deployed service than with other programming languages I am >> >>> aware about. >> >> >> >> But you are just writing code in Schema defn, XSL or otherwise, instead >> >> of >> >> writing it elsewhere. In Jini, we write code into proxies to do the >> >> types >> >> of >> >> stuff that you might do in Schema and XSL things. >> >> >> >> The big difference is that I, as the service provide can do this once, >> >> and >> >> all >> >> of my clients can benefit, where as, you, as an XML service provider, >> >> can't >> >> change the document elements, attributes and structure, without >> >> delivering >> >> something to your clients to aid them in making use of the new >> >> "structure" >> >> of >> >> your XML. >> >> >> >> Sending them such things is a type of mobile code I guess, but it is >> >> delivered >> >> and activated out of band, which creates decoupling that can seem >> >> empowering, >> >> but for me, it is nerve wracking, because I can't change anything on >> >> the >> >> service >> >> until everyone has the changed "code". >> >> >> >> When I deliver such things with mobile code, its the service object >> >> reference >> >> that the client is accessing that provides the new implementation, and >> >> so >> >> everyone sees it the moment I make the change active, and I don't have >> >> to >> >> ask >> >> people reporting problems, what version of the schema they have and >> >> where >> >> they >> >> got it from etc. They always have the "production" version and I can >> >> always >> >> support problems with my service with a full understanding of the >> >> "software" >> >> involved. >> >> >> >> Gregg Wonderly >> >> >> >>> - Michael >> >>> >> >>> ------------ --------- --------- --------- --------- --------- - >> >>> *From:* Gregg Wonderly <ge...@...> >> >>> *To:* service-orientated- architecture@ yahoogroups. com >> >>> *Sent:* Wednesday, August 26, 2009 12:12:59 AM >> >>> *Subject:* Re: [service-orientated -architecture] Re: good or bad >> >>> practice? or maybe ugly >> >>> >> >>> >> >>> >> >>> Michael Poulin wrote: >> >>> > >> >>> > >> >>> > Oh, this is a new stream: Java vs. XML. When I responded to initial >> >>> > post, I did not mean to open this new stream... >> >>> > >> >>> > Anyway, I, personally, never ever considered XML as a data >> >>> > structure, >> >>> > it >> >>> > was always about semantics to me. At the same time, Java >> >>> > serialization >> >>> > is a Java object state snapshot, i.e. data structure. To use this >> >>> > data >> >>> > on the receiver side, we need to have a shared interface/class >> >>> > definition. This leads to programming coupling. >> >>> >> >>> No, it leads to structured understanding. The meaning of the data, at >> >>> some >> >>> point is always understood, or you can't "use" it. >> >>> >> >>> What you are supposing, I think, is that somehow, a piece of software, >> >>> is not a >> >>> piece of data that can be consumed and used. >> >>> >> >>> XML schema, XSL and other conversions are equivalent, see below... >> >>> >> >>> > Since you emphasis on serialization smart proxy, I can tell you that >> >>> > I >> >>> > can do exactly the same reduction of sent data with with XML, i.e. >> >>> > in >> >>> > the XML Schema, by manipulating with name-spaces. I am not a big >> >>> > specialist in Jini (though always wanted to be) but, to my >> >>> > understanding, smart proxy can be designed as a wrapper of the >> >>> > remote >> >>> > call or even as a replica of remote service acting locally, on the >> >>> > client side. This only confirms, IMO, that the client and service >> >>> > sides >> >>> > have to share the same Java interfaces/classes if not packages (due >> >>> > to >> >>> > the requirement of serialization object tree). This is a clear >> >>> > coupling, >> >>> > isn't it? >> >>> >> >>> If we have an XML document such as >> >>> >> >>> <ticket> >> >>> <person> >> >>> <first>Gregg< /first> >> >>> <last>Wonderly< /last> >> >>> </person> >> >>> <event> >> >>> <title>U2 Concert</title> >> >>> <location>Chicago< /location> >> >>> </event> >> >>> </ticket> >> >>> >> >>> How do you know what these things refer to? The only way is through >> >>> understanding, which creates a coupling from the source, to you as a >> >>> consumer. >> >>> In Java and other places where there is support for mobile code >> >>> (mobile >> >>> code is >> >>> anything that causes change in what the user experiences with >> >>> consumption of the >> >>> data, aside from visually observing the content), there is an "engine" >> >>> of >> >>> understanding that consumes the content, and then outputs something >> >>> else >> >>> different. >> >>> >> >>> A SAX or DOM parser, for example is such an engine. Only with this >> >>> engine (and >> >>> it might be code you wrote yourself) can you get the "values" out of >> >>> this XML >> >>> document. >> >>> >> >>> So if my java Serialization generated XML, instead of the JRMP or JERI >> >>> stream of >> >>> bytes for my mobile code, the engine on the other side would still >> >>> have >> >>> to have >> >>> a coupled understanding of the content to consume it at some level. >> >>> >> >>> There is always coupling. The biggest factor is whether that coupling >> >>> is >> >>> too >> >>> complex for the value it adds. Simplifying "features" of any >> >>> technology >> >>> are >> >>> what we like to pay for. >> >>> >> >>> > I have mentioned XML only as an example of decoupling code on the >> >>> > sender >> >>> > and receiver sides because with services (even in Java) we are more >> >>> > and >> >>> > more getting in the the world of different authorities and ownership >> >>> > that prevents sharing packages (libraries). >> >>> >> >>> XML creates a coupling just like any data does. The coupling it >> >>> creates >> >>> is two >> >>> fold. First, you have to have the XML engine. If you don't have that, >> >>> you >> >>> loose. Second, you have to understand the XML content. You have to >> >>> know >> >>> what >> >>> elements and attributes are present, or you can't ask for the content >> >>> by >> >>> bit and >> >>> piece that you need. The names of elements and attributes couple your >> >>> software >> >>> to that document structure, plain and simple. This is no different >> >>> than >> >>> knowing >> >>> the names of java methods and the types of parameters as in >> >>> >> >>> public interface Ticket { >> >>> public Person getPerson(); >> >>> public Event getEvent(); >> >>> } >> >>> public interface Person { >> >>> public String getFirst(); >> >>> public String getLast(); >> >>> } >> >>> public interface Event { >> >>> public String getTitle(); >> >>> public String getLocation( ); >> >>> } >> >>> >> >>> It's exactly the same complexity. >> >>> >> >>> What smart proxy's and mobile code provide is that I can write the >> >>> Event >> >>> implementation as >> >>> >> >>> public class RemoteTicketImpl implements Event,Person, >> >>> Ticket,Serializa >> >>> ble { >> >>> public Person getPerson() { return this; } >> >>> public Event getEvent() { return this; } >> >>> public String getFirst() { return first; } >> >>> public String getLast() { return last; } >> >>> public String getTitle() { return title; } >> >>> public String getLocation( ) { return location; } >> >>> private String first, last, title, location; >> >>> } >> >>> >> >>> or I could implement it as something like >> >>> >> >>> public class LocalTicketImpl implements Ticket,Serializable { >> >>> DataAccess db; >> >>> public Event getEvent() { >> >>> return db.handleFor( ticketId) .getEvent( ); >> >>> } >> >>> public Person getPerson() { >> >>> return db.handleFor( ticketId) .getPerson( ); >> >>> } >> >>> } >> >>> >> >>> and the details of implementation can change at any point because the >> >>> implementation is not exposed, the data is. >> >>> >> >>> > Now, about productive development. If one is very productive today >> >>> > and >> >>> > produces simple and straight-forward code that couples everything, I >> >>> > would say it is very much contra-productive for services. Yes, SOA >> >>> > services require different understanding of may traditional things. >> >>> > If >> >>> > you want, this is about 'what should be done' rather than 'what can >> >>> > be >> >>> > done'. >> >>> >> >>> I think you'll have to describe what you mean by coupling. It sounds >> >>> to >> >>> me that >> >>> you believe that any "code" that any application has knowledge of is a >> >>> coupling, >> >>> but somehow data never creates coupling. Perhaps you can explain more >> >>> about >> >>> what you mean with coupling. >> >>> >> >>> > Could you, please, elaborate on your example with JavaScript with >> >>> > regard >> >>> > to this discussion? >> >>> >> >>> Javascript is code, it is transported to web browsers around the world >> >>> and used >> >>> day in and day out to deliver services to users. How does that not >> >>> couple the >> >>> client with the service? Can I send my own language to the browser >> >>> without >> >>> installing a plugin for that language, and it just works? Can I send >> >>> any >> >>> XML >> >>> document to the browser and the user instantly use it? Not really, >> >>> they >> >>> can >> >>> look at it, and if I refer to some XSL, I can convert it to an XHTML >> >>> document, >> >>> and do some rendering. >> >>> >> >>> But, I am using the XML and XSL and HTML "engines" in the browser to >> >>> do >> >>> this. >> >>> I've coupled my service and client with "software" that must work >> >>> together or >> >>> else the service doesn't work. >> >>> >> >>> Code and data, equally create coupling. For example, if you always >> >>> posted your >> >>> emails in German, while you are using SMTP to post them and I am using >> >>> POP to >> >>> retrieve them, the transport/transfer standards don't guarantee that I >> >>> can read >> >>> them. The SMTP message format is simple, headers, blank line, content. >> >>> But >> >>> that still doesn't allow me to consume your message, until I have an >> >>> understanding of what the content actually is. >> >>> >> >>> XML vs java serialization is the same issue. There is equal coupling >> >>> created by >> >>> either choice. You have to have the engine to wrap the content, you >> >>> have >> >>> to >> >>> have a transport to send it to the other end, and you have to have the >> >>> engine/knowledge to unwrap the content and consume it as intended. >> >>> >> >>> Gregg Wonderly >> >>> >> >>> >> >>> >> >> >> >> >> > >> > >> >> >> ------------------------------------ >> >> Yahoo! Groups Links >> > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
