Archived

This forum has been archived. Please start a new discussion on GitHub.

Ice-based service-oriented arhitecture

Hello,

the ZeroC team provides an Ice vs. SOAP comparison mentioning that the implementation of service-oriented architectures is possible with Ice, too.
The provided advantages of using Ice over web services are: performance and simplicity. I agree to the better performance, but I don't think that complexity of WSDL is a disadvantage, since descriptors will be generated and can be edited - if needed - with appropriate tools which hide the irrelevant structure.
What I think is important in case of web services is that they rely on standards by e.g. OASIS and W3C. Based on such standards implementations it is easy to develop reliable systems. Furthermore, not only distributed systems themselves can be implemented through modeling, but also the interactions of the businesses, the choreography of them and the most important: business processes.
I've tried to figure out, whether it is possible with Ice, too, but I didn't find any appropriate reading source or example (also searching the forum for the terms SOA and service-oriented architecture didn't give any result).
So, if I'm right, then Ice wasn't meant to improve the interoperability between businesses, but rather to improve the interoperability within businesses.
Is this assumption true or is it possible to use Ice-based systems to compose larger systems on the same high abstraction level, like web service-oriented technologies?


Many thanks in advance for your reply,
best regards
Andras

Comments

  • Hi Andras,

    imho, SOA wasn't created to create cross-enterprise communication but rather to improve business process support by providing a similar structure on the technical level.
    This was achieved by the paradigm of defining business services which are given a corresponding IT service implementation.

    This paradigm can be perfectly adapted in the Ice world, however, imho Ice is on a somewhat lower stack as it also provides a runtime and the infrastructure for running such services, i.e. Ice already contains stuff where web servers, ESBs etc. are used in the 'other' world.

    Furthermore, it's even desirable to use coarse-grained interfaces also for Ice to get a decent performance: having atomic getters and setters on your interfaces (e.g. one setter for the firstname, another setter for the lastname) won't result into good performance in Ice as well.
    Coarse-grained interfaces are no SOA invention but are good choice in all distributed object scenario. The same is basically true for stateless-ness...

    One way of doing this would be to use newer SOA techniques like SDO. Why not passing XML documents to Ice objects and why not returning them from those objects.

    Using this approach, you can also easily create WS wrappers around your Ice objects and make them accessible from within the 'standard' world, e.g. calling them from an ESB etc.

    This is not quite optimal, it would be better if ESBs would support Ice out of the box which would then perfectly close the gap between the 'open' world of web services and the more 'autonomous' world of Ice. Unfortunately, I also didn't find any information about such implementations.

    On the other hand, in case Ice-based services should be the main part of your infrastructure, you can also design the world the other way around: make web services accessible using small Ice wrappers, and implement choreography on top of that. You could use IceGrid as the runtime for your services and as the directory part of your environment. Unfortunately, there's no beautiful cheorography designer available but why not use a simple python or ruby script to compose a 'process' chain.
    Probably you can even faster modify such a script than dragging around boxes in a nice-looking graphical interface...

    Last but not least: You might even create EDA like solutions using IceStorm :)

    Stephan
  • Hello Stephan,

    thanks for your reply. Please see my comments inline.
    imho, SOA wasn't created to create cross-enterprise communication but rather to improve business process support by providing a similar structure on the technical level.
    This was achieved by the paradigm of defining business services which are given a corresponding IT service implementation.
    I didn't write that SOA was meant for creating communication between businesses, but from my point of view the interoperability of them is the most interesting part.
    ...
    One way of doing this would be to use newer SOA techniques like SDO. Why not passing XML documents to Ice objects and why not returning them from those objects.
    Because as the ZeroC team wrote it: "The required XML parsing puts heavy load on the CPU, increases latency, and lowers throughput. Even a slow CORBA ORB has typically 10-100 times better latency and throughput than the best SOAP products;..."
    Using this approach, you can also easily create WS wrappers around your Ice objects and make them accessible from within the 'standard' world, e.g. calling them from an ESB etc.
    So if I'd go this way, the main advantage (better performance of throughput) of using Ice would have gone lost.
    This is not quite optimal, it would be better if ESBs would support Ice out of the box which would then perfectly close the gap between the 'open' world of web services and the more 'autonomous' world of Ice. Unfortunately, I also didn't find any information about such implementations.
    Yes, but this is exactly the problem I see: Ice uses an easy, compact BUT non-standard interface definition language. So, I think that such a solution can only be used within a business, where only one CIO has to decide.
    On the other hand, in case Ice-based services should be the main part of your infrastructure, you can also design the world the other way around: make web services accessible using small Ice wrappers, and implement choreography on top of that. You could use IceGrid as the runtime for your services and as the directory part of your environment. Unfortunately, there's no beautiful cheorography designer available but why not use a simple python or ruby script to compose a 'process' chain.
    That sounds good and I think, if Ice could be adapted/extended to use/to be used e.g. BPEL processes, it would be another strong argument in deciding for Ice.
    Probably you can even faster modify such a script than dragging around boxes in a nice-looking graphical interface...
    I agree with that, but not programmers make business decisions, like process establishment, but department managers who usually don't (want to) understand scripts. Moreover, one picture is worth a thousand words ;)
    Last but not least: You might even create EDA like solutions using IceStorm :)
    That's another important information, thanks.
    You also pointed two technologies, which I didn't know (SDO, EDA), so it really was a wise decision to start a thread on the topic :cool:

    Best regards,
    Andras

    p.s. By the way, implementing IT systems like in the real world is really exciting. But these new approaches mean a lot of overhead -> performance loss -> more resources -> growing expenses and maintenance effort...
  • Because as the ZeroC team wrote it: "The required XML parsing puts heavy load on the CPU, increases latency, and lowers throughput. Even a slow CORBA ORB has typically 10-100 times better latency and throughput than the best SOAP products;..."

    So if I'd go this way, the main advantage (better performance of throughput) of using Ice would have gone lost.

    that's right if Ice had to interpret the xml content (as with WebServices). If passing xml documents as 'string' parameters/ return values, there'll be no additional latency, only the type safety will be load which would be present if you'd pass more structured data.
    Yes, but this is exactly the problem I see: Ice uses an easy, compact BUT non-standard interface definition language. So, I think that such a solution can only be used within a business, where only one CIO has to decide.

    hmmm. I totally agree to that. No standard-business CIO will agree to a technology which isn't mentioned in business magazines. That's true. The sad part about this is that SOA might only be the big hype particularly because it's being pushed by SAP and Oracle so much which are competing against each other concerning ERP solutions and are desparetely seeking for 'arguments' why one is better than the other.

    I still do not get what you mean with 'within' but indeed due to the fact that interoperability is limited currently, Ice's main advantage might be to optimize communication within a given set of applications/ infrastructure but not within the entire enterprise landscape.

    But that's another funny thing: did anyone ever really connect big ERP systems and the likes generically with SOA? I think not.

    regards,

    Stephan
  • I still do not get what you mean with 'within' but indeed due to the fact that interoperability is limited currently, Ice's main advantage might be to optimize communication within a given set of applications/ infrastructure but not within the entire enterprise landscape.
    With 'within' I mean company-specific solution not directly used by business partners, as you correctly described.
    But that's another funny thing: did anyone ever really connect big ERP systems and the likes generically with SOA? I think not.
    I think, for example companies of the automobile industry using ebXML for automated electronic data interchange take the advantage of this approach.
    ebXML will continuously be enhanced and refined to include new development views, like it happened in case of SOA and web services some years ago.

    Best regards,
    Andras
  • I think, for example companies of the automobile industry using ebXML for automated electronic data interchange take the advantage of this approach.
    ebXML will continuously be enhanced and refined to include new development views, like it happened in case of SOA and web services some years ago.

    automobile industry is using EDIFACT for ages, imho EbXML is no SOA success story.
    The payload is standardized but you would rarely replace one of the communication parties: the parties are not isolated from each other but have a heavy semantic connection (business contracts), that's no loose coupling.

    Anyway. This off-topic discussion doesn't answer the Ice vs. SOA question. In my opinion you need to implement gateways or facades around either Ice or your favourite Web Services and could quite easily achieve a nice integration.
    On the other hand, the Ice framework once contained a slice2wsdl compiler, I guess nobody ever mentioned what this thing was about...

    Stephan
  • automobile industry is using EDIFACT for ages, imho EbXML is no SOA success story.
    The payload is standardized but you would rarely replace one of the communication parties: the parties are not isolated from each other but have a heavy semantic connection (business contracts), that's no loose coupling.
    Oh, true, I thought on EDIFACT :o
    But since ebXML isn't a success, too, it can be another argument, why to decide for Ice and not for web services...

    Bye,
    Andras
  • stephan wrote: »
    This off-topic discussion doesn't answer the Ice vs. SOA question. In my opinion you need to implement gateways or facades around either Ice or your favourite Web Services and could quite easily achieve a nice integration.

    SOA is entirely independent of the transport or middleware. You can do SOA with anything that can do remote comms.
    On the other hand, the Ice framework once contained a slice2wsdl compiler, I guess nobody ever mentioned what this thing was about...

    There once was an early prototype for a WS-Ice bridge, which we decided not to pursue further.

    Cheers,

    Michi.
  • stephan wrote: »
    But that's another funny thing: did anyone ever really connect big ERP systems and the likes generically with SOA? I think not.

    Au contraire, my good friend...

    Our primary ERP system is the fantabulous (yes, I'm being sarcastic) JD Edwards OneWorld, now owned by Oracle corporation. JDE is a monstrous beast, and one that uses a moderately thin "on-the-wire" message passing format that is quite well suited for processing on an AS/400 or Microsoft MQ platform architecture. And that indeed is what the typical fat clients use to communicate with the server.

    But the interop API is a wickedly ugly XML-based RPC mechanism, that bears a close resemblance to SOA. The whole thing is poorly documented, and the easiest thing to do is pass an empty function name into the interop engine, and look at the response that comes back to figure out what you really need to include in the initial request. It's tedious, and insanely slow. Every time we have a transaction that goes over the XML system, the transaction literally takes tens of seconds, as opposed to one second or less for the fat-client to make the exact same call.

    Worse yet, the binary message format is completely undocumented, and subject to change without notice between patch levels.

    If they would use ICE as the primary communications system, my life would be much better.
  • michi wrote: »
    SOA is entirely independent of the transport or middleware. You can do SOA with anything that can do remote comms.

    Yes, indeed. My 'Ice vs. SOA' statement was a too short abbreviation of things. Sure, SOA is independent of the transport as it is rather a concept how to build and manage IT environments.
    As interoperation is another key issue of SOA (on the technical level), the question remains how to integrate Ice servers aka 'services' into SOA (aka ESB, WebServices and orchestration) ecosystems.

    cheers,

    Stephan