Gervas, Yes, I can talk about this. Although I am not one of the Ionians who has actually worked on this famous project, I have talked with them and with the customer directly.
The Credit Suisse SOA (based in Zurich) is perhaps the largest in the world with about 1500 services in production from mainframe to Windows, processing about 1 billion banking transactions per year. One of the reasons it's so famous is that Credit Suisse is willing to speak publicly about it. Many of our other SOA customers are not so willing, often for competitive reasons. The Credit Suisse example is also often called the Gartner "SOA poster child" since they use it so often as an example. And yes, it does include the mainframe, in fact one of the service requests is invoked from IMS on the mainframe to a Windows server to obtain information necessary to complete the transaction. And yes, it does use IONA's Orbix, our CORBA-compliant product line. However, they also use MQ Series for some of the services. Roughly speaking Credit Suisse divides their services between online (request/response or RPC style) and asynchronous (sometimes called offline or document style) types. (I am not sure how many exist of each type but for sure the CS SOA is a mixture of both.) So CORBA and WebSphere MQ are among the technologies that historically have been used to implement an SOA. Today, more and more SOA implementations are using Web services. To cite Gartner again, the reason may be that Web services provide a cheaper technology for SOA, making SOA more accessible to a broader set of customers. However in my opinion another important factor is that the IT industry has reached a point of maturity at which Web services and SOA makes sense. People have enough fundamental IT assets - hardware, operating systems, database management systems, middleware, development tools, and packaged applications - and they need the improvements of vendor neutral standards and their application in service orientated architecture to obtain additional benefits from existing investments. The major distinguishing factor between an SOA and other software architectures is probably the definition of a service. A service is not an object although it can be implemented using one (among several options). A service is more abstract than an object. An object is intended to model a thing, such as a customer object, file object, order object, etc. The object encapsulates the data pertinent to this thing and exposes methods for operating on the data. A service is a function, not a thing. So a service is "get customer data" not a "get customer data method on the customer object." The implementation of the service doesn't have to be an object. The implication for architecture is that you can design a system based on the interactions between service functions rather than having to design the objects that implement the functions. The implementation of an SOA design in technology can (and should) be a separate step. Another way think about the difference is in the context of how a business provides services to its customers, and how service orientation is a way to model those business services in software. A bank (for example) offers withdrawal, currency exchange, transfer, loan payment, and so on as services to its customers. The job of a software service is to define the "exchange currency" service by focusing on the data exchanged between the reqeuster and provider. So the definition of the service starts with the data in the message, if you will, rather than with the object. In the Credit Suisse SOA they reuse a common service for foreign exchange calculation since this is a common function required by many applications. The service happens to run on a mainframe, let's say, and all of the Windows and Unix based systems request it when they need to calculate a currency exchange transaction based on current rates. Because this is CORBA based, it doesn't matter either to the requester or the provider what language, operating system, or hardware type is involved. The service is modeled using a CORBA IDL on both sides of the exchange. The requester is simply requesting the "currency exchange service" and sending the input data for the calculation. The CORBA system finds the location of the service on the network, routes the message to the right endpoint, and passes the message to the target service, which executes the request. The response is returned along the same path that the request followed. One of the benefits of moving toward Web services, as Credit Suisse is now doing (among many others interested in SOA) is that now you don't need CORBA (or WebSphere MQ) on both systems. Eric --- Gervas Douglas <[EMAIL PROTECTED]> wrote: > Jan, > > This Group has tried on more than one occasion ( as > have other fora) > to define SOA, but it would seem that the technology > has not matured > enough for a generally accepted consensus to emerge. > Although WS > brought SOA to the industry's widespread attention, > many would argue > that it has been around for some time. An example > of a pre-WS > implementation would be a major multi-platform > integration project > that IONA did for CSFB in Switzerland if my memory > is correct. Being > IONA, this was based on CORBA. > > I forget the details, but no doubt an Ionan on this > Group could > describe how it fits in or not with modern > conceptions of a SOA. An > interesting task of the project was to integrate > legacy platforms > (e.g. 3270/CICS) which had been designed as closed, > standalone > systems. I suspect that as technologies evolve > future SOAs will face > new unforeseen interoperability challenges not yet > envisaged. > > Gervas > > --- In > [email protected], Jan > Algermissen <[EMAIL PROTECTED]> wrote: > > > > Eric, > > > > On Jan 16, 2006, at 3:37 AM, Eric Newcomer wrote: > > > > > Jan (& Patrick), > > > > > > I should have added an apology for > misunderstanding > > > the question. Sorry about that! > > > > > > > NO! No problem at all. In fact, apologies if I > have maybe not > > responded on the point - I have no time to follow > closely, mostly > > posting whenever I see a mail that triggers a > thought. > > > > But the general question remains: Does any > definition exist that > > would allow me to distinguish SOA from <put any > distributed object > > technology here>? Especially if we consider that > SOA in a sense > > enforces some DO design practices while Corba et > al. do not, but that > > it does not build upon a conceptually different > architecture. > > > > Another way to ask: is there anything about SOA > that makes it > > architecturally different from old-fashioned DO > technologies? > > > > Sure, you have language independence, free choice > of transport > > mechanism,.. but this does not make SOA a > distinguishable software > > architectural style (which the name[1] implies, > IMHO). > > > > And if it is not....then it is just as good as > the old stuff, isn't it? > > > > > > Jan > > > > [1] and vendor promisses > > > > > > > > > Eric > > > > > > --- Jan Algermissen <[EMAIL PROTECTED]> > > > wrote: > > > > > >> Eric, > > >> > > >> On Jan 15, 2006, at 5:57 PM, Eric Newcomer > wrote: > > >> > > >>> I meant formal in the sense that it is as > simple > > >> and > > >>> precise a definition as possible. > > >> > > >> Umm...without any attempt to insult you, but > this is > > >> kinda meaningless. > > >> > > >> Honestly, where is that formal definition of > SOA > > >> that enables me to > > >> determine whether an architecture is of the SOA > > >> style or not? What > > >> are the formal criteria for this? > > >> > > >> Suppose a client asks: Are we SOA? How do I > find out > > >> if yes or no? > > >> > > >> I think that is what Patrick is asking for. > > >> > > >> Jan > > >> > > >> > > >> > > > > ______________________________________________________________________ > > > > __ > > >> > > >> _______________ > > >> Jan Algermissen, Consultant & Programmer > > >> > > >> http://jalgermissen.com > > >> Tugboat Consulting, 'Applying Web technology to > > >> enterprise IT' > > >> http://www.tugboat.de > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam > protection around > > > http://mail.yahoo.com > > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > ________________________________________________________________________ > > > _______________ > > Jan Algermissen, Consultant & Programmer > > > http://jalgermissen.com > > Tugboat Consulting, 'Applying Web technology to > enterprise IT' > > http://www.tugboat.de > > > > > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> 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/
