Loading ...
Sorry, an error occurred while loading the content.
 

Re: [service-orientated-architecture] Re: good or bad practice? or maybe ugly

Expand Messages
  • Steve Jones
    Unfortunately so, they did have some very clever stuff around object evolution though. Steve
    Message 1 of 48 , Aug 31, 2009
      Unfortunately so, they did have some very clever stuff around object
      evolution though.

      Steve


      2009/8/30 gervasdouglas <gervas.douglas@...>:
      >
      >
      > 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 service-orientated-architecture@yahoogroups.com, Michael Poulin
      > <m3poulin@...> 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.steveg@...>
      >> To: service-orientated-architecture@yahoogroups.com
      >> 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 <m3poulin@...>:
      >> >
      >> >
      >> > 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.steveg@...>
      >> > To: service-orientated-architecture@yahoogroups.com
      >> > 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 <gergg@...>:
      >> >>
      >> >>
      >> >> 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 <gergg@...>
      >> >>> *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
      >>
      >
      >
    • Hitoshi Ozawa
      Want to add a comment again because I just saw something like this. The situation was they were trying to increase reusability rate up by bundling interfaces
      Message 48 of 48 , Sep 12, 2009
        Want to add a comment again because I just saw something like this.
         
        The situation was they were trying to increase "reusability rate" up by bundling interfaces together
        using "OO concepts". For example, forms were bundled into one interface even though they had different data fields. Another example involved customer interface which were made to handle individual's data and corporate data even though most of the data were different.
         
        The question was, if to add all data from all bundled functionalities into an interface or use use dynamic list. For example, in the second example above, all individual's data fields and all corporate data fields are added to the interface parameter list. This obviously is not very good practice because if individual's data field is modified, all service consumers (i.e. service needing individual's data AND service needing corporate data) needs to be modified as well. There's also an overhead of sending and receiving unnecessary data.
         
        The better solution seems to be to use a List and dynamically change content. For example, consumer needing individual's data receives a List with individual's data and consumer needing corporate data receives a List the corporate data.
         
        This seems like a good solution but it really isn't. An interface should only have one MESSAGE definition for input and one MESSAGE definition for output. I think the problem like the one above comes about because people equate messages and interfaces.
         
        Furthermore, I think this problem comes up because developers are still accustomed to designing service PROVIDER interface first and using OO concepts to increase "reusability".
        H.Ozawa
         
        2009/8/25 Sasan <sasanplus@...>
         

        Gregg,

        If a service takes a parameter as List<SomeType> this will be mapped to a complexType of SomeType with maxoccure = -1

        the content of SomeType will then be exposed by other complex types in the same schema. At least the practice prototype is behaving like this. At the same time, I have seen that a some attributes of a customized type ( a custom class) has not become visible if it doesn't have bean convention accessors, this is why I think its risky to fully rely on reading of complex Type and then client will not have full understanding of SomeType by just parsing wsdl. This however this is a problem for dynamic access to services that have either List<SomeType> or SomeType on its own, as a parameter.

        Sasan



        From: Gregg Wonderly <gergg@...>Sent: Monday, August 24, 2009 10:32:39 PM

        Subject: Re: [service-orientated-architecture] Re: good or bad practice? or maybe ugly

         

        Sasan wrote:


        > I'm sorry that I have to talk technology oriented. In this particular
        > case the client only has access to abstract contract i.e WSDL. So if
        > list includes the type i.e. List<SomeType> , it is possible to identify
        > the content structure of "SomeType" but it seems to be very risky
        > because based on some prototypes, some of the content might not be
        > discovered if "SomeType" do not fully comply with a java bean convention
        > (having getter/setter for all attributes). this is only for dynamic
        > access to services

        I fail to understand how the SomeType being "known" because it is in the
        declaration as List<SomeType> has any baring on "risky". No matter what type of
        object is in the List, it has to be a usable "type" for the application. If you
        are using some non-native transport technology such as XML driven by some kind
        of packaging standard such as WSDL, than your objects have to allow you to
        construct the needed content. If you need JavaBean conventions supported, than
        it doesn't matter what type of object that is does it?

        There really is no reason that adding type information would make things more
        risky it seems to me.

        Gregg Wonderly


      Your message has been successfully submitted and would be delivered to recipients shortly.