http://www.cio.com/archive/030103/netgains.html (alleges, in my opinion,
on-demand plans of IBM et al. as hype)

http://www.cio.com/archive/030103/et_article.html (example Web Service
implementation)

http://www.cio.com/archive/090102/prime.html (primer)

Thanks.
Kaleem. (x36250)
"If you know it from media, you are aware.
If you hear it from experts, you are informed.
If you work alongwith the experts, even then you know only the best known by
mankind.
However, you are as close to truth as one can be for your time."

Thanks.
Kaleem. (x36250)
"If you know it from media, you are aware.
If you hear it from experts, you are informed.
If you work alongwith the experts, even then you know only the best known by mankind.
However, you are as close to truth as one can be for your time."

Thanks.
Kaleem. (x36250)
"If you know it from media, you are aware.
If you hear it from experts, you are informed.
If you work alongwith the experts, even then you know only the best known by mankind.
However, you are as close to truth as one can be for your time."

-----Original Message-----
From: Dan Creswell [mailto:dan@...]
Sent: Thu, March 13, 2003 1:15 AM
To: service-orientated-architecture@yahoogroups.com
Subject: Re: [service-orientated-architecture] Re: SOA, WS & Jini

Kaleem Aziz wrote:

> We had such a discussion about UDDI searches not being "dynamic" in
> the sense that they are not real-time updated. However, with a little
> bit of effort, one can implement "economical" level of dynamic nature
> into it. I'll forward a mail on this subject soon.
> 

Cool.

> Wouldn't dynamic registration of Jini be a performance problem if used
> in a real webservice?
> 

What kind of performance problem are you thinking of?

From my perspective dynamic registration is a bootup issue - i.e. my
service is still "making itself available" - it's not available yet
because it's still booting.

I'm not sure but I think you actually meant dynamic lookup rather than
registration?  If that's the case, there are a myriad of patterns and
implementation options which remove any "performance issue".

Again, I'd also like to see you characterize what you think the
performance issue is.

I've seen these sorts of issues raised before but never really heard
exactly what the problem might be so, please, educate me.

Dan.

> Thanks.
> Kaleem. (x36250)
> "Too low they build, who build beneath the stars." -- Edward Young,
> Night Thoughts on Life, Death and Immortality, 1745 (inscribed on a
> wall of the Library of Congress).
>
>     -----Original Message-----
>     *From:* Peper [mailto:delarco71@...]
>     *Sent:* Tuesday, March 11, 2003 8:11 AM
>     *To:* service-orientated-architecture@yahoogroups.com
>     *Subject:* [service-orientated-architecture] Re: SOA, WS & Jini
>
>     Hi everybody,
>
>     Actually Web Services implementation has no complete support for
>     dynamic registering/discovering/invocation of services and the
>     UDDI/WSDL standards are statically based.
>
>     What do you think about semantic description of UDDI with DAML-S
>     ontologies?. Perhaps in a future the Semantic Web helps to fill the
>     gaps in the support for Web Services dynamic feautures. The web
>     services dynamic composition/discovering/invocation will be improving
>     with DAML-S and agents.
>
>     Best Regards,
>     José Carlos.
>
>     --------------------------------------------------------------
>
>     webservices-latinos Group:
>
>     http://es.groups.yahoo.com/group/webservices-latinos/  (spanish
>     language originality).
>
>     ---------------------------------------------------------------
>
>
>     --- In service-orientated-architecture@yahoogroups.com, Gervas
>     Douglas <gervasdouglas@y...> wrote:
>     > I recently posted an article by Ron Dearing of Cysive on SOA, Web
>     Service and Jini.  This theme is of especial interest to this group
>     as it studies the constructive interaction between two different SOA
>     implementations.  To quote from the introduction:
>     > "Currently, service-oriented architectures are becoming an integral
>     aspect of the IT strategy. Service-oriented architectures offer the
>     ability to register, discover, and use services, where the
>     architecture is dynamic in nature. Web Services promises to deliver
>     functionality that can be registered, discovered, and executed.
>     However, the technologies that provide the implementation of these
>     features are by its very core, statically based.
>     >
>     > "Jini's architecture promotes the concept of dynamic registration,
>     discovery, and execution. The architecture addresses the problems of
>     creating service-oriented architectures that are intended to be
>     adaptive, self-healing, self-administered, and distributed."
>     >
>     > You can find this article at http://groups.yahoo.com/group/service-
>     orientated-architecture/files/Articles-Whitepapers/ .
>     >
>     > We look forward to your comments!
>     >
>     > Gervas
>     >
>     >
>     >
>     >
>     > ---------------------------------
>     > With Yahoo! Mail you can get a bigger mailbox -- choose a size that
>     fits your needs
>
>
>
>
>     To unsubscribe from this group, send an email to:
>     service-orientated-architecture-unsubscribe@yahoogroups.com
>
>
>
>     Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>     Service <http://docs.yahoo.com/info/terms/>.
>
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> <http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1705007181:HM/A=1481646/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_flake/g22lp?Target=mm/g22lp.tmpl>
>
>
>
> To unsubscribe from this group, send an email to:
> service-orientated-architecture-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/>.





To unsubscribe from this group, send an email to:
service-orientated-architecture-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----Original Message-----
From: Dan Creswell [mailto:dan@...]
Sent: Thu, March 13, 2003 1:32 AM
To: service-orientated-architecture@yahoogroups.com
Subject: Re: [service-orientated-architecture] FW: FW: FW: IBM focus on WebService Orchestration

Hmmm, interesting.

Forgive me if I make a mistake cos I'm not entirely up on WSDL etc.
but......I've got some questions with respect to both the "dum" and UDDI
3.0 approaches:

I've got all these WSDL files locally representing various endpoints -
how do I know which of those endpoints is actually available at any
point?  Could I not find my preferred vendor is down, grab another WSDL
file and hit the same problem which is, potentially, taking a lot of
time to do?  What happens if one of these endpoints is revoked never to
return?

The UDDI 3.0 approach looks better but distinctly JINI like in terms of
its use of events etc.  But, let's say the public UDDI registry is
updated - it now wishes to post events to all those private UDDI
versions - what happens if it can't contact one?  Maybe you post the
events and then reflect the changes into the UDDI registry?  Or maybe
the events contain all the WSDL updates?  All these solutions appear to
have problems of one sort or another -  updates can, potentially, be
lost or race conditions occur where the client receives and event for
information it can't see yet or the public registry cannot be updated
because it's blocking waiting for a "private registry" (or intermediary)
to become available to receive the event.

Another question springs to mind also - for either scenario, there may
be clients already bound to WSDL that's just changed - how do THEY find
out about the changes made such that they can migrate to the new service
(or do they stay with the old version of the service?  If they do stay
with the old version of the service, when can one take that service out
of commission?).

Cheers,

Dan.

Kaleem Aziz wrote:

> This is in response to the "dynamic" searches work around to UDDI.
> 
> The mail may not come up well on Yahoo groups, because Noel's comments
> are embedded in different color within my comments to her. I hope you
> can make that out as you read bottom up.
>
> Thanks.
> Kaleem. (x36250)
> "Too low they build, who build beneath the stars." -- Edward Young,
> Night Thoughts on Life, Death and Immortality, 1745 (inscribed on a
> wall of the Library of Congress).
>
> -----Original Message-----
> *From:* Ricky Ho [mailto:riho@...]
> *Sent:* Tuesday, December 03, 2002 4:10 PM
> *To:* Kaleem Aziz; edpiment@...; Xml-Interest@Cisco. Com;
> Web-Services@Cisco. Com; Xml-Webservices
> *Cc:* Weblog-Blog@Cisco. Com
> *Subject:* RE: FW: FW: IBM focus on WebService Orchestration
>
> I guess a very dum approach will work.
>
> Company X downloaded the WSDL files of their preferred partners into a
> file directory.  Their error handling code (in case of their most
> preferred business partner goes offline) will just go to this
> directory, find another WSDL file and rebind to another service
> provider endpoint.  No UDDI, Cache, Proxy is involved.
>
> You probably like this more sophisticated one better.
>
> Under UDDI 3.0 (where it has a better federation model , access
> control and change notification), company X will create its private
> UDDI by replicating a certain (manually defined) portion of public
> UDDI which company X trust.  In case company X's business partners
> change their WSDL, the public UDDI will notify company X to update
> their private UDDI latest version.  The error handling mechanism is
> very similar.  The error handling code will go to the private UDDI to
> find another WSDL file and rebind to another trusted service provider
> endpoint.  No cache and proxy is involved.
>
> Best regards,
> Ricky
>
> At 02:51 PM 12/3/2002 -0800, Kaleem Aziz wrote:
>
>> Thanks Ricky. Noel's comments give a new angle to my thoughts,
>> probably because she is confident she knows the system, and I am just
>> excited about the next great toy.
>> 
>> About this:
>> " For the same argument, I don't believe "dynamic discovery" (as you
>> describe in the UDDI lookup scenario) is realistic in foreseeable
>> future."
>> 
>> I would love to have a cache or proxy or copy of UDDI lookup, thereby
>> making it as dynamic as possible. This is my personal preference,
>> because I don't understand at this time how the deploy will take
>> place. That is, what the companies that is so dependent on the
>> network for their survival will do if one or all of their preferred
>> vendor's go offline (may be the country blocks the web service during
>> war, or the area gets destroyed during earthquake, etc., etc.).
>>
>> Take care.
>> Kaleem. (x36250)
>> "One of the greatest discoveries a man makes, one of his great
>> surprises, is to find he can do what he was afraid he couldn't do."
>> -- Henry Ford (1863-1947)
>>
>>     -----Original Message----- From: Ricky Ho [mailto:riho@...]
>>     Sent: Tuesday, December 03, 2002 1:50 PM To: Kaleem Aziz;
>>     edpiment@...; Xml-Interest@Cisco. Com; Web-Services@Cisco.
>>     Com; Xml-Webservices Cc: Weblog-Blog@Cisco. Com Subject: Re: FW:
>>     FW: IBM focus on WebService Orchestration
>>
>>     Kaleem, thanks for sharing the conversation.  There are a lot of
>>     good points there requiring deep thoughts.
>>
>>     I don't view "reuse" and "saving development effort" is the
>>     biggest motive behind web services.  We can achieve a high degree
>>     of reuse by buying more "off-the-shelf" Component Libraries.  I
>>     think the biggest motive for web services is enabling B2B
>>     integration, an old concept in the EDI days but we've never
>>     achieved the expected scale.
>>
>>     So the biggest thing is "WE CAN DO BUSINESS TRANSACTION
>>     ELECTRONICALLY" -- think we can take orders 24 hrs a day, from
>>     any countries; think we can immediately confirm any customer
>>     booking and arrange logistics; think we can keep our stock at the
>>     lowest level while still fulfilling fluctuating customer demands;
>>     think we only need to hire minimum number of staffs to maintain
>>     business operation.
>>
>>     On the internet, so far we have the "content web", and you
>>     already see how it impact our daily life.  Web services is now
>>     going to turn the "B2C content web" to the "B2B transaction
>>     web".  This is the biggest impact web services will make.  Moving
>>     further, the distinction between "B" and "C" will blur, and we
>>     will have a "P2P collaboration and transaction web" (my favorite
>>     topic of "intelligent software agents")
>>
>>     I agree with Noel that not every functionality will be exposed as
>>     web service.  As both of you has pointed out, the biggest problem
>>     is "trust" (not just security).  When you have no control on the
>>     implementation behind a "standardized" interface, how can you
>>     trust it is doing what you want ?  For the same argument, I don't
>>     believe "dynamic discovery" (as you describe in the UDDI lookup
>>     scenario) is realistic in foreseeable future.
>>
>>     To further elaborate my point, there is NO way to specify the
>>     "semantics" of a "shopping cart services", why do you expect your
>>     purchased items will be saved for a reasonable period of time and
>>     you won't be over-charged ?  You have to trust the company
>>     implementing the services.  The good news is :  This is not a new
>>     issue because we already deal with these trust issues daily.
>>     Just don't think these issues will disappear when using web
>>     services.  In fact, this is one reason why web services is still
>>     NOT widely adopted as expected today.
>>
>>     There is a huge marketing advantages for those "authorities" who
>>     has already gained trust from the public to expose their
>>     functionalities as web services.  They can quickly dominate their
>>     field.  In fact, you can see there will be race between
>>     competitors to gain trust from their customer.
>>
>>     Thanks again for sharing the discussion !  It triggers me a lot
>>     of thoughts !
>>
>>     Best regards, Ricky At 12:04 PM 12/3/2002 -0800, Kaleem Aziz wrote:
>>
>>>         Some interesting discussion with Noel my professor in
>>>         e-commerce and security. I think she hit it right on many of
>>>         the things, even though she is new to Web Services, but
>>>         experienced with businesses. Also, you can see that she is
>>>         skeptical about IT promising a silver bullet yet again. :)
>>>         Thanks Ricky for demonstrating "unlearning" of
>>>         "conventional" IT wisdom while explaining the new paradigm
>>>         of thinking. PS: Btw, my examples were not so good for Web
>>>         Services implementation. Take care. Kaleem. (x36250) "One of
>>>         the greatest discoveries a man makes, one of his great
>>>         surprises, is to find he can do what he was afraid he
>>>         couldn't do." -- Henry Ford (1863-1947) -----Original
>>>         Message----- From: Kaleem Aziz [mailto:kaaziz@...]
>>>         Sent: Tuesday, December 03, 2002 10:31 AM To: Noel
>>>         Haskins-Hafer Subject: RE: FW: IBM focus on WebService
>>>         Orchestration
>>>
>>>         Noel, Yes, your insight is right, and it is happening
>>>         already. In the rat race, people/organizations ARE
>>>         compromising on standards. Also, I picked some wrong
>>>         examples (like accounting being open to world, etc.). I
>>>         mean, there are certain areas Web Services will not apply,
>>>         and business will learn about that during evolution of this
>>>         technology. Treat them only as examples, and not as real
>>>         world solutions. Web Services will not, as you said, benefit
>>>         smaller corporations, but make the larger corporations even
>>>         more efficient. It is a master architecture of conventional
>>>         B2B, and B2B is a REAL need. And just like Nike and DELL are
>>>         orchestrators, yes Web Services is merely a computerization
>>>         of real-life orchestration (which was slower earlier). Also,
>>>         I agree, most corporations will have to decide between
>>>         opening up their business in part to the world; in order to
>>>         benefit from Web Services implementation. It will be a tough
>>>         choice, but it is being predicted in Forrester report and
>>>         Harvard Business Review reports that the business will be
>>>         slow to accept it at first, and as the technology refines,
>>>         we will have as many Web Services in future as we have web
>>>         sites today. Also, Microsoft, Sun, IBM and Oracle are
>>>         lobbying companies to open up to standards this time, unlike
>>>         just W3C or Apache or RosettaNet. The way they are selling
>>>         it is not as a silver bullet or a panacea to anything, but
>>>         are willing to lose money in showing initially that the
>>>         model DOES work. (Just like Amazon.com went through lot of
>>>         losses to make a market share.) I think, our conventional
>>>         life will become faster, and we will start seeing several
>>>         lifetimes in a lifetime. :) In the sense that we will
>>>         witness more companies rise and fall, have more
>>>         relationships, more divorces, etc., due to the added speed
>>>         and comfort. :) This is not in the HBR reports, or anything,
>>>         just my intuition. :) Take care. Kaleem. (x36250) "One of
>>>         the greatest discoveries a man makes, one of his great
>>>         surprises, is to find he can do what he was afraid he
>>>         couldn't do." -- Henry Ford (1863-1947) -----Original
>>>         Message----- Sent: Tuesday, December 03, 2002 9:18 AM To:
>>>         Kaleem Aziz Subject: RE: FW: IBM focus on WebService
>>>         Orchestration See below.
>>>
>>>          Kaleem Aziz <kaaziz@...> wrote: Hi Noel, Currently,
>>>         each organization employs developers and implements a
>>>         system. They have developers that develop software, either
>>>         client side or server side, to carry out the business. Some
>>>         clients have needs of developing the software as a client
>>>         side system (where in the logic is totally residing on
>>>         client machine, and the client machine "thinks" almost
>>>         always). Some other clients have the need of developing the
>>>         software as a server side system (where in the logic is
>>>         totally residing on the company's server, and the server
>>>         "thinks" for every client, ultimately). What this does, in
>>>         either case, is: it requires each company to hire a team of
>>>         developers/designers/architects for the functions. Each IT
>>>         company is "spending" on software development costs, in
>>>         order to carry out their business operations.  Trust me, I
>>>         know this part -- been there done that for longer than you
>>>         or Ricky!  It is expensive and much of it is "charged" to
>>>         corporate ego (or corporate lack of understanding of how to
>>>         collaborate).  However, there are -- and should be -- some
>>>         areas of business in which some participants don't want to
>>>         share their data or the possibility at least that their data
>>>         and business processes will/could be compromised to
>>>         competitors, etc. In future, the Web Services based software
>>>         development will not require "in-house" developers to
>>>         develop mundane logic. All the developers (lesser in number)
>>>         will ever have to do is use several Web Services (over
>>>         internet or intranet) to do any task. All business
>>>         operations will be done over the internet, and for every
>>>         atomic thing, it'll make a hit to another company's
>>>         (providers) server. Removing the mundane stuff, such as
>>>         payment processing, makes a lot of sense, since that's what
>>>         computers were for: automating the boring work.  However, I
>>>         question the wisdom of "every atomic thing" being placed at
>>>         the hands of the partners, who are, in many cases in the
>>>         value web/chain, also competitors and customers. For
>>>         example, today we create e-commerce websites which validate
>>>         credit card and make the purchases in a shopping cart. Each
>>>         and every e-commerce company is hiring developers for
>>>         writing the credit card validation logic, and a shopping
>>>         cart logic. With Web Services, there'll be several credit
>>>         card validation sites running their web services. Say there
>>>         are 3 companies, ABC, DEF and GHI, running a Web Service
>>>         that validates credit card. Each e-commerce company will not
>>>         tie up with anyone of these companies. Any of the three
>>>         companies will only register at one place saying that they
>>>         provide that service. Any e-commerce company looks up in
>>>         something like a telephone address book (technically known
>>>         as UDDI) and finds these 3 companies that it could hit for
>>>         credit card validation. It sends its details to ABC Co, gets
>>>         a valid response and goes on automatically with next part of
>>>         logic of completing the pur! chase. ABC will bill the
>>>         e-commerce companies for the transaction automatically.
>>>         However, if ABC fails to give valid response, there will be
>>>         either a retry of a try with DEF Co. Which ever company
>>>         offers the service gets paid. This happens to quickly, and
>>>         automatically (once the Web Services infrastructure is
>>>         complete). Suppose now that besides the validation of credit
>>>         card, there are 3 companies PQR, RST and UVW that provide
>>>         shopping cart Web Service. This means that, these three
>>>         companies run Web Services that can hold user purchases
>>>         temporarily for a session. This would further reduce any
>>>         e-commerce company's need to hire developers to code for a
>>>         shopping cart functionality. In addition, the above scenario
>>>         will be like this: Step 1: One Web Service call to credit
>>>         card companies ABC, or DEF or GHI after looking them in the
>>>         UDDI (like a "phone book") Step 2: Once the call shows valid
>>>         credit card, another Web Service to handle the shopping cart
>>>         purchase to companies PQR, RST and UVW after looking them up
>>>         in the UDDI as well Step 3, 4,5, etc. could also be such Web
>>>         Services calls! These steps of calling up web services that
>>>         "this company never did develop" forms "orchestration".
>>>         That's the technical term Ricky is referring to -- calling
>>>         of one web service after the other based on certain
>>>         conditions. Therefore, client side logic or server side
>>>         logic has not much to do with web services. The company is
>>>         "effectively", "at a micro level", "outsourcing" each
>>>         activity it's not an expert in to the expert companies,
>>>         which it looks up in UDDI. So, unless I'm oversimplifying
>>>         this, we're just using "COTS" services on the web -- in
>>>         effect NOT reinventing the wheel.  I fail to see where this
>>>         is new and innovative, except in that the software and
>>>         functionality resides out of the traditional boundaries of
>>>         the corporation and more in a collective pool of companies.
>>>         How REALLY is this different from an ASP -- or rather, a
>>>         collection of ASPs?  The savings for each company are huge
>>>         -- besides having to maintain the developers, servers,
>>>         non-standard logic across businesses, etc. Having this
>>>         automated implementation, it makes it very network dependent
>>>         and therefore provides standardized versions on the fly. It
>>>         really brings about the best of using "experts" to do the
>>>         job, rather than having the race to hire the computer
>>>         experts in "each" company. Standardization allows companies
>>>         to search not like on conventional web or in a phone book,
>>>         but in a more powerful fashion. For example, it could search
>>>         in the following manner: 200 pairs of shoes, model number:
>>>         1245, maker: Ashton Spears, dealers in distance: 55 miles,
>>>         price expected: $5000, protocol to follow: EDI 825. Trying
>>>         to search in the above manner on conventional web will give
>>>         10,000 useless results; but doing this same thing in UDDI
>>>         will have 5 companies competing for th! e order in the next
>>>         minute. Billing wouldn't take swiping of a credit card, but
>>>         would be automatic, and the proof of sale would be
>>>         maintained by yet another validated/standardized web
>>>         service! As you say later, the implications for security are
>>>         huge here.  It becomes not only a matter of needing to
>>>         protect customer data from prying eyes (inside AND outside
>>>         the organization) but also one of needing to depend on a
>>>         network that is out of the organization's own control.
>>>         Thus, to a large degree, the company must be willing to give
>>>         up much of its autonomy for the price of saving money.
>>>         Don't get me wrong, here.  I think much of the concept is
>>>         good.  However, I can also see where we're heading here for
>>>         the McDonald's of software, where every web-based company
>>>         looks and feels identical and no one stands out or excells.
>>>         If that made sense, Ricky is going to the next stage of
>>>         visualizing not one company, but several such companies
>>>         operating in such cyber-space. Hence, the sentence: "Looking
>>>         into the future, the real value of web service is complex,
>>>         orchestrated, B2B interactions across diverse enterprises.".
>>>         One looking for credit card service, another for shoes,
>>>         another for airplane parts, and none of this is individually
>>>         implemented by each company. Yes, we've used a similar model
>>>         for businesses for years.  For example, Nike doesn't make
>>>         shoes -- it contracts out every piece of the shoe making and
>>>         marketing process.  The Nike company only orchestrates the
>>>         activities. There are a few disadvantages, like companies
>>>         having to open up their transaction system and forming trust
>>>         based preferential relationships, etc. Don't underestimate
>>>         this disadvantage  It is what makes the shining stars in
>>>         business worth doing repeat business with: innovation and
>>>         differentiation (remember Michael Porter's three methods of
>>>         strategic success?).  Security is a MAJOR issue, since
>>>         programs intended with misdemeanor will be rampant. However,
>>>         business ROI, and standardization benefits to B2B are going
>>>         to be driving factors for the initial phase of Web Services
>>>         implementation. Later it will catch more mass and the idea
>>>         will start rolling with more acceptance. ROI -- an
>>>         interesting concept, which has traditionally been in the
>>>         purview of accountants only -- and even THEY don't agree on
>>>         how to calculate it or its overall value in the profit
>>>         equation.  My guess is that for a while, at least until the
>>>         economy picks up again, this will be the fad of IT, just as
>>>         CRM and ERPs have been in the recent past.   Cutting costs
>>>         is the "activity du jour" but history tells me we'll
>>>         discover that we're not very good at keeping track of all
>>>         the elements of ROI, we're not all that good at managing our
>>>         "investments" (partly because we're not all that sure that
>>>         we know exactly what an investment is vs. what we want it to
>>>         be) and we'll jump to the next silver bullet at our earliest
>>>         convenience. This time, it is not a hype, simply because it
>>>         has been worked with ROI, and keeping in mind that many
>>>         companies have been bit by technology not being able to meet
>>>         expectations. Also, infrastructure this time is going to be
>>>         provided by gaints Microsoft, IBM, Sun, Oracle, SAP, Cisco,
>>>         etc., instead of smaller players like i2, CommerceOne,
>>>         Ariba, etc. Microsoft is way ahead of the game right now,
>>>         with its .NET implementations. More so because, once Web
>>>         Services is in roads, it will not really matter if companies
>>>         buy UNIX or Windows boxes -- all will work seamlessly (all
>>>         talk will happen over internet using XML -- understood by
>>>         all systems in the same way). This, and standards that truly
>>>         ARE standards, would be nice.  However, our industry isn't
>>>         all that good at setting standards and playing by them.
>>>         Instead, we set minimum standards and everyone goes off and
>>>         changes them when they implement their own products.  Also,
>>>         playing a great role will be standard societies like W3C,
>>>         RosettaNet, etc., where they will reach standards for almost
>>>         every type of industry (chemical, aircraft, banking, etc.,
>>>         etc.). A great concept -- but one that works only until the
>>>         next big innovation, which then causes everyone else to
>>>         rethink the standards -- at which point they are no longer
>>>         standards.  EDI will be integrated to work with Web
>>>         Services, by the work of these standards organizations. So,
>>>         the motivation is there, and it is solid. Let me know what
>>>         you think of this architecture. My guess is that my comments
>>>         tell you what I think, but here's the gist of it.  Right
>>>         now, it sounds like yet another silver bullet concept.  As
>>>         with e-commerce and the dot-coms, we will derive some good
>>>         from it in the long run and the wise ones will incorporate
>>>         the good into their best practices.  However, we will
>>>         neither have the discipline nor the patience to give it
>>>         enough time to mature and reach its potential before we
>>>         discover that the ROI upon which you claim this is based is
>>>         ephemeral and not grounded in solid business.  We aren't at
>>>         the holy grail of the Internet yet -- we may never be.
>>>         There are too many issues that we, as a world, haven't
>>>         resolved, including legal issues of the Internet
>>>         (jurisdiction, etc.) and security/privacy.  We Americans
>>>         talk a lot about privacy and we value what little we have
>>>         left of it.  What we don't realize is that many others don't
>>>         have it, don't value it and don't want us to have it.  For
>>>         web services to work outside of theory demands an
>>>         extraordinary willingness to trust in others.  We have not
>>>         developed that trust in ourselves and the recent news events
>>>         (accounting scandals, political scandals, etc.) undermine
>>>         our desire to develop the level of trust we will require to
>>>         make use of this model in its purest fashion.  My guess is
>>>         that we will end up having major companies as service
>>>         providers, much the way our financial institutions now offer
>>>         the full range of banking, insurance and investing
>>>         services.  The idea of lots of little organizations
>>>         benefitting from this is irrational. Gotta get started on
>>>         work -- thanks for the explanation.  It DID help me
>>>     understand better.  Noel
>>
>
> To unsubscribe from this group, send an email to:
> service-orientated-architecture-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/>.







To unsubscribe from this group, send an email to:
service-orientated-architecture-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I have just read an interesting article on how WS will tie in with
IBM's "on-demand" initiative (I interpret this as a re-invention of
the computer bureau after the lukewarm attempt to do this through
ASPs, but to be fair to IBM it does go beyond this).  This will be a
true test of the viability of Web Services as a practicable
implementation of SOA. There is a useful banking example of how WS
can fulfil the SOA aspiration of reusable software components.

I have put the URL at the bottom of the page to avoid the wretched
advert for those of you looking at this message on-site.

Gervas











http://searchwebservices.techtarget.com/originalContent/0,289142,sid26
_gci885282,00.html

Kaleem Aziz wrote:

> We had such a discussion about UDDI searches not being "dynamic" in
> the sense that they are not real-time updated. However, with a little
> bit of effort, one can implement "economical" level of dynamic nature
> into it. I'll forward a mail on this subject soon.
>

Cool.

> Wouldn't dynamic registration of Jini be a performance problem if used
> in a real webservice?
>

What kind of performance problem are you thinking of?

  From my perspective dynamic registration is a bootup issue - i.e. my
service is still "making itself available" - it's not available yet
because it's still booting.

I'm not sure but I think you actually meant dynamic lookup rather than
registration?  If that's the case, there are a myriad of patterns and
implementation options which remove any "performance issue".

Again, I'd also like to see you characterize what you think the
performance issue is.

I've seen these sorts of issues raised before but never really heard
exactly what the problem might be so, please, educate me.

Dan.

> Thanks.
> Kaleem. (x36250)
> "Too low they build, who build beneath the stars." -- Edward Young,
> Night Thoughts on Life, Death and Immortality, 1745 (inscribed on a
> wall of the Library of Congress).
>
>     -----Original Message-----
>     *From:* Peper [mailto:delarco71@...]
>     *Sent:* Tuesday, March 11, 2003 8:11 AM
>     *To:* service-orientated-architecture@yahoogroups.com
>     *Subject:* [service-orientated-architecture] Re: SOA, WS & Jini
>
>     Hi everybody,
>
>     Actually Web Services implementation has no complete support for
>     dynamic registering/discovering/invocation of services and the
>     UDDI/WSDL standards are statically based.
>
>     What do you think about semantic description of UDDI with DAML-S
>     ontologies?. Perhaps in a future the Semantic Web helps to fill the
>     gaps in the support for Web Services dynamic feautures. The web
>     services dynamic composition/discovering/invocation will be improving
>     with DAML-S and agents.
>
>     Best Regards,
>     José Carlos.
>
>     --------------------------------------------------------------
>
>     webservices-latinos Group:
>
>     http://es.groups.yahoo.com/group/webservices-latinos/  (spanish
>     language originality).
>
>     ---------------------------------------------------------------
>
>
>     --- In service-orientated-architecture@yahoogroups.com, Gervas
>     Douglas <gervasdouglas@y...> wrote:
>     > I recently posted an article by Ron Dearing of Cysive on SOA, Web
>     Service and Jini.  This theme is of especial interest to this group
>     as it studies the constructive interaction between two different SOA
>     implementations.  To quote from the introduction:
>     > "Currently, service-oriented architectures are becoming an integral
>     aspect of the IT strategy. Service-oriented architectures offer the
>     ability to register, discover, and use services, where the
>     architecture is dynamic in nature. Web Services promises to deliver
>     functionality that can be registered, discovered, and executed.
>     However, the technologies that provide the implementation of these
>     features are by its very core, statically based.
>     >
>     > "Jini's architecture promotes the concept of dynamic registration,
>     discovery, and execution. The architecture addresses the problems of
>     creating service-oriented architectures that are intended to be
>     adaptive, self-healing, self-administered, and distributed."
>     >
>     > You can find this article at http://groups.yahoo.com/group/service-
>     orientated-architecture/files/Articles-Whitepapers/ .
>     >
>     > We look forward to your comments!
>     >
>     > Gervas
>     >
>     >
>     >
>     >
>     > ---------------------------------
>     > With Yahoo! Mail you can get a bigger mailbox -- choose a size that
>     fits your needs
>
>
>
>
>     To unsubscribe from this group, send an email to:
>     service-orientated-architecture-unsubscribe@yahoogroups.com
>
>
>
>     Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>     Service <http://docs.yahoo.com/info/terms/>.
>
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
>
<http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1705007181:H\
M/A=1481646/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_flake/g22lp?Target=\
mm/g22lp.tmpl>
>
>
>
> To unsubscribe from this group, send an email to:
> service-orientated-architecture-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/>.

Hmmm, interesting.

Forgive me if I make a mistake cos I'm not entirely up on WSDL etc.
but......I've got some questions with respect to both the "dum" and UDDI
3.0 approaches:

I've got all these WSDL files locally representing various endpoints -
how do I know which of those endpoints is actually available at any
point?  Could I not find my preferred vendor is down, grab another WSDL
file and hit the same problem which is, potentially, taking a lot of
time to do?  What happens if one of these endpoints is revoked never to
return?

The UDDI 3.0 approach looks better but distinctly JINI like in terms of
its use of events etc.  But, let's say the public UDDI registry is
updated - it now wishes to post events to all those private UDDI
versions - what happens if it can't contact one?  Maybe you post the
events and then reflect the changes into the UDDI registry?  Or maybe
the events contain all the WSDL updates?  All these solutions appear to
have problems of one sort or another -  updates can, potentially, be
lost or race conditions occur where the client receives and event for
information it can't see yet or the public registry cannot be updated
because it's blocking waiting for a "private registry" (or intermediary)
to become available to receive the event.

Another question springs to mind also - for either scenario, there may
be clients already bound to WSDL that's just changed - how do THEY find
out about the changes made such that they can migrate to the new service
(or do they stay with the old version of the service?  If they do stay
with the old version of the service, when can one take that service out
of commission?).

Cheers,

Dan.

Kaleem Aziz wrote:

> This is in response to the "dynamic" searches work around to UDDI.
>
> The mail may not come up well on Yahoo groups, because Noel's comments
> are embedded in different color within my comments to her. I hope you
> can make that out as you read bottom up.
>
> Thanks.
> Kaleem. (x36250)
> "Too low they build, who build beneath the stars." -- Edward Young,
> Night Thoughts on Life, Death and Immortality, 1745 (inscribed on a
> wall of the Library of Congress).
>
> -----Original Message-----
> *From:* Ricky Ho [mailto:riho@...]
> *Sent:* Tuesday, December 03, 2002 4:10 PM
> *To:* Kaleem Aziz; edpiment@...; Xml-Interest@Cisco. Com;
> Web-Services@Cisco. Com; Xml-Webservices
> *Cc:* Weblog-Blog@Cisco. Com
> *Subject:* RE: FW: FW: IBM focus on WebService Orchestration
>
> I guess a very dum approach will work.
>
> Company X downloaded the WSDL files of their preferred partners into a
> file directory.  Their error handling code (in case of their most
> preferred business partner goes offline) will just go to this
> directory, find another WSDL file and rebind to another service
> provider endpoint.  No UDDI, Cache, Proxy is involved.
>
> You probably like this more sophisticated one better.
>
> Under UDDI 3.0 (where it has a better federation model , access
> control and change notification), company X will create its private
> UDDI by replicating a certain (manually defined) portion of public
> UDDI which company X trust.  In case company X's business partners
> change their WSDL, the public UDDI will notify company X to update
> their private UDDI latest version.  The error handling mechanism is
> very similar.  The error handling code will go to the private UDDI to
> find another WSDL file and rebind to another trusted service provider
> endpoint.  No cache and proxy is involved.
>
> Best regards,
> Ricky
>
> At 02:51 PM 12/3/2002 -0800, Kaleem Aziz wrote:
>
>> Thanks Ricky. Noel's comments give a new angle to my thoughts,
>> probably because she is confident she knows the system, and I am just
>> excited about the next great toy.
>>
>> About this:
>> " For the same argument, I don't believe "dynamic discovery" (as you
>> describe in the UDDI lookup scenario) is realistic in foreseeable
>> future."
>>
>> I would love to have a cache or proxy or copy of UDDI lookup, thereby
>> making it as dynamic as possible. This is my personal preference,
>> because I don't understand at this time how the deploy will take
>> place. That is, what the companies that is so dependent on the
>> network for their survival will do if one or all of their preferred
>> vendor's go offline (may be the country blocks the web service during
>> war, or the area gets destroyed during earthquake, etc., etc.).
>>
>> Take care.
>> Kaleem. (x36250)
>> "One of the greatest discoveries a man makes, one of his great
>> surprises, is to find he can do what he was afraid he couldn't do."
>> -- Henry Ford (1863-1947)
>>
>>     -----Original Message----- From: Ricky Ho [mailto:riho@...]
>>     Sent: Tuesday, December 03, 2002 1:50 PM To: Kaleem Aziz;
>>     edpiment@...; Xml-Interest@Cisco. Com; Web-Services@Cisco.
>>     Com; Xml-Webservices Cc: Weblog-Blog@Cisco. Com Subject: Re: FW:
>>     FW: IBM focus on WebService Orchestration
>>
>>     Kaleem, thanks for sharing the conversation.  There are a lot of
>>     good points there requiring deep thoughts.
>>
>>     I don't view "reuse" and "saving development effort" is the
>>     biggest motive behind web services.  We can achieve a high degree
>>     of reuse by buying more "off-the-shelf" Component Libraries.  I
>>     think the biggest motive for web services is enabling B2B
>>     integration, an old concept in the EDI days but we've never
>>     achieved the expected scale.
>>
>>     So the biggest thing is "WE CAN DO BUSINESS TRANSACTION
>>     ELECTRONICALLY" -- think we can take orders 24 hrs a day, from
>>     any countries; think we can immediately confirm any customer
>>     booking and arrange logistics; think we can keep our stock at the
>>     lowest level while still fulfilling fluctuating customer demands;
>>     think we only need to hire minimum number of staffs to maintain
>>     business operation.
>>
>>     On the internet, so far we have the "content web", and you
>>     already see how it impact our daily life.  Web services is now
>>     going to turn the "B2C content web" to the "B2B transaction
>>     web".  This is the biggest impact web services will make.  Moving
>>     further, the distinction between "B" and "C" will blur, and we
>>     will have a "P2P collaboration and transaction web" (my favorite
>>     topic of "intelligent software agents")
>>
>>     I agree with Noel that not every functionality will be exposed as
>>     web service.  As both of you has pointed out, the biggest problem
>>     is "trust" (not just security).  When you have no control on the
>>     implementation behind a "standardized" interface, how can you
>>     trust it is doing what you want ?  For the same argument, I don't
>>     believe "dynamic discovery" (as you describe in the UDDI lookup
>>     scenario) is realistic in foreseeable future.
>>
>>     To further elaborate my point, there is NO way to specify the
>>     "semantics" of a "shopping cart services", why do you expect your
>>     purchased items will be saved for a reasonable period of time and
>>     you won't be over-charged ?  You have to trust the company
>>     implementing the services.  The good news is :  This is not a new
>>     issue because we already deal with these trust issues daily.
>>     Just don't think these issues will disappear when using web
>>     services.  In fact, this is one reason why web services is still
>>     NOT widely adopted as expected today.
>>
>>     There is a huge marketing advantages for those "authorities" who
>>     has already gained trust from the public to expose their
>>     functionalities as web services.  They can quickly dominate their
>>     field.  In fact, you can see there will be race between
>>     competitors to gain trust from their customer.
>>
>>     Thanks again for sharing the discussion !  It triggers me a lot
>>     of thoughts !
>>
>>     Best regards, Ricky At 12:04 PM 12/3/2002 -0800, Kaleem Aziz wrote:
>>
>>>         Some interesting discussion with Noel my professor in
>>>         e-commerce and security. I think she hit it right on many of
>>>         the things, even though she is new to Web Services, but
>>>         experienced with businesses. Also, you can see that she is
>>>         skeptical about IT promising a silver bullet yet again. :)
>>>         Thanks Ricky for demonstrating "unlearning" of
>>>         "conventional" IT wisdom while explaining the new paradigm
>>>         of thinking. PS: Btw, my examples were not so good for Web
>>>         Services implementation. Take care. Kaleem. (x36250) "One of
>>>         the greatest discoveries a man makes, one of his great
>>>         surprises, is to find he can do what he was afraid he
>>>         couldn't do." -- Henry Ford (1863-1947) -----Original
>>>         Message----- From: Kaleem Aziz [mailto:kaaziz@...]
>>>         Sent: Tuesday, December 03, 2002 10:31 AM To: Noel
>>>         Haskins-Hafer Subject: RE: FW: IBM focus on WebService
>>>         Orchestration
>>>
>>>         Noel, Yes, your insight is right, and it is happening
>>>         already. In the rat race, people/organizations ARE
>>>         compromising on standards. Also, I picked some wrong
>>>         examples (like accounting being open to world, etc.). I
>>>         mean, there are certain areas Web Services will not apply,
>>>         and business will learn about that during evolution of this
>>>         technology. Treat them only as examples, and not as real
>>>         world solutions. Web Services will not, as you said, benefit
>>>         smaller corporations, but make the larger corporations even
>>>         more efficient. It is a master architecture of conventional
>>>         B2B, and B2B is a REAL need. And just like Nike and DELL are
>>>         orchestrators, yes Web Services is merely a computerization
>>>         of real-life orchestration (which was slower earlier). Also,
>>>         I agree, most corporations will have to decide between
>>>         opening up their business in part to the world; in order to
>>>         benefit from Web Services implementation. It will be a tough
>>>         choice, but it is being predicted in Forrester report and
>>>         Harvard Business Review reports that the business will be
>>>         slow to accept it at first, and as the technology refines,
>>>         we will have as many Web Services in future as we have web
>>>         sites today. Also, Microsoft, Sun, IBM and Oracle are
>>>         lobbying companies to open up to standards this time, unlike
>>>         just W3C or Apache or RosettaNet. The way they are selling
>>>         it is not as a silver bullet or a panacea to anything, but
>>>         are willing to lose money in showing initially that the
>>>         model DOES work. (Just like Amazon.com went through lot of
>>>         losses to make a market share.) I think, our conventional
>>>         life will become faster, and we will start seeing several
>>>         lifetimes in a lifetime. :) In the sense that we will
>>>         witness more companies rise and fall, have more
>>>         relationships, more divorces, etc., due to the added speed
>>>         and comfort. :) This is not in the HBR reports, or anything,
>>>         just my intuition. :) Take care. Kaleem. (x36250) "One of
>>>         the greatest discoveries a man makes, one of his great
>>>         surprises, is to find he can do what he was afraid he
>>>         couldn't do." -- Henry Ford (1863-1947) -----Original
>>>         Message----- Sent: Tuesday, December 03, 2002 9:18 AM To:
>>>         Kaleem Aziz Subject: RE: FW: IBM focus on WebService
>>>         Orchestration See below.
>>>
>>>          Kaleem Aziz <kaaziz@...> wrote: Hi Noel, Currently,
>>>         each organization employs developers and implements a
>>>         system. They have developers that develop software, either
>>>         client side or server side, to carry out the business. Some
>>>         clients have needs of developing the software as a client
>>>         side system (where in the logic is totally residing on
>>>         client machine, and the client machine "thinks" almost
>>>         always). Some other clients have the need of developing the
>>>         software as a server side system (where in the logic is
>>>         totally residing on the company's server, and the server
>>>         "thinks" for every client, ultimately). What this does, in
>>>         either case, is: it requires each company to hire a team of
>>>         developers/designers/architects for the functions. Each IT
>>>         company is "spending" on software development costs, in
>>>         order to carry out their business operations.  Trust me, I
>>>         know this part -- been there done that for longer than you
>>>         or Ricky!  It is expensive and much of it is "charged" to
>>>         corporate ego (or corporate lack of understanding of how to
>>>         collaborate).  However, there are -- and should be -- some
>>>         areas of business in which some participants don't want to
>>>         share their data or the possibility at least that their data
>>>         and business processes will/could be compromised to
>>>         competitors, etc. In future, the Web Services based software
>>>         development will not require "in-house" developers to
>>>         develop mundane logic. All the developers (lesser in number)
>>>         will ever have to do is use several Web Services (over
>>>         internet or intranet) to do any task. All business
>>>         operations will be done over the internet, and for every
>>>         atomic thing, it'll make a hit to another company's
>>>         (providers) server. Removing the mundane stuff, such as
>>>         payment processing, makes a lot of sense, since that's what
>>>         computers were for: automating the boring work.  However, I
>>>         question the wisdom of "every atomic thing" being placed at
>>>         the hands of the partners, who are, in many cases in the
>>>         value web/chain, also competitors and customers. For
>>>         example, today we create e-commerce websites which validate
>>>         credit card and make the purchases in a shopping cart. Each
>>>         and every e-commerce company is hiring developers for
>>>         writing the credit card validation logic, and a shopping
>>>         cart logic. With Web Services, there'll be several credit
>>>         card validation sites running their web services. Say there
>>>         are 3 companies, ABC, DEF and GHI, running a Web Service
>>>         that validates credit card. Each e-commerce company will not
>>>         tie up with anyone of these companies. Any of the three
>>>         companies will only register at one place saying that they
>>>         provide that service. Any e-commerce company looks up in
>>>         something like a telephone address book (technically known
>>>         as UDDI) and finds these 3 companies that it could hit for
>>>         credit card validation. It sends its details to ABC Co, gets
>>>         a valid response and goes on automatically with next part of
>>>         logic of completing the pur! chase. ABC will bill the
>>>         e-commerce companies for the transaction automatically.
>>>         However, if ABC fails to give valid response, there will be
>>>         either a retry of a try with DEF Co. Which ever company
>>>         offers the service gets paid. This happens to quickly, and
>>>         automatically (once the Web Services infrastructure is
>>>         complete). Suppose now that besides the validation of credit
>>>         card, there are 3 companies PQR, RST and UVW that provide
>>>         shopping cart Web Service. This means that, these three
>>>         companies run Web Services that can hold user purchases
>>>         temporarily for a session. This would further reduce any
>>>         e-commerce company's need to hire developers to code for a
>>>         shopping cart functionality. In addition, the above scenario
>>>         will be like this: Step 1: One Web Service call to credit
>>>         card companies ABC, or DEF or GHI after looking them in the
>>>         UDDI (like a "phone book") Step 2: Once the call shows valid
>>>         credit card, another Web Service to handle the shopping cart
>>>         purchase to companies PQR, RST and UVW after looking them up
>>>         in the UDDI as well Step 3, 4,5, etc. could also be such Web
>>>         Services calls! These steps of calling up web services that
>>>         "this company never did develop" forms "orchestration".
>>>         That's the technical term Ricky is referring to -- calling
>>>         of one web service after the other based on certain
>>>         conditions. Therefore, client side logic or server side
>>>         logic has not much to do with web services. The company is
>>>         "effectively", "at a micro level", "outsourcing" each
>>>         activity it's not an expert in to the expert companies,
>>>         which it looks up in UDDI. So, unless I'm oversimplifying
>>>         this, we're just using "COTS" services on the web -- in
>>>         effect NOT reinventing the wheel.  I fail to see where this
>>>         is new and innovative, except in that the software and
>>>         functionality resides out of the traditional boundaries of
>>>         the corporation and more in a collective pool of companies.
>>>         How REALLY is this different from an ASP -- or rather, a
>>>         collection of ASPs?  The savings for each company are huge
>>>         -- besides having to maintain the developers, servers,
>>>         non-standard logic across businesses, etc. Having this
>>>         automated implementation, it makes it very network dependent
>>>         and therefore provides standardized versions on the fly. It
>>>         really brings about the best of using "experts" to do the
>>>         job, rather than having the race to hire the computer
>>>         experts in "each" company. Standardization allows companies
>>>         to search not like on conventional web or in a phone book,
>>>         but in a more powerful fashion. For example, it could search
>>>         in the following manner: 200 pairs of shoes, model number:
>>>         1245, maker: Ashton Spears, dealers in distance: 55 miles,
>>>         price expected: $5000, protocol to follow: EDI 825. Trying
>>>         to search in the above manner on conventional web will give
>>>         10,000 useless results; but doing this same thing in UDDI
>>>         will have 5 companies competing for th! e order in the next
>>>         minute. Billing wouldn't take swiping of a credit card, but
>>>         would be automatic, and the proof of sale would be
>>>         maintained by yet another validated/standardized web
>>>         service! As you say later, the implications for security are
>>>         huge here.  It becomes not only a matter of needing to
>>>         protect customer data from prying eyes (inside AND outside
>>>         the organization) but also one of needing to depend on a
>>>         network that is out of the organization's own control.
>>>         Thus, to a large degree, the company must be willing to give
>>>         up much of its autonomy for the price of saving money.
>>>         Don't get me wrong, here.  I think much of the concept is
>>>         good.  However, I can also see where we're heading here for
>>>         the McDonald's of software, where every web-based company
>>>         looks and feels identical and no one stands out or excells.
>>>         If that made sense, Ricky is going to the next stage of
>>>         visualizing not one company, but several such companies
>>>         operating in such cyber-space. Hence, the sentence: "Looking
>>>         into the future, the real value of web service is complex,
>>>         orchestrated, B2B interactions across diverse enterprises.".
>>>         One looking for credit card service, another for shoes,
>>>         another for airplane parts, and none of this is individually
>>>         implemented by each company. Yes, we've used a similar model
>>>         for businesses for years.  For example, Nike doesn't make
>>>         shoes -- it contracts out every piece of the shoe making and
>>>         marketing process.  The Nike company only orchestrates the
>>>         activities. There are a few disadvantages, like companies
>>>         having to open up their transaction system and forming trust
>>>         based preferential relationships, etc. Don't underestimate
>>>         this disadvantage  It is what makes the shining stars in
>>>         business worth doing repeat business with: innovation and
>>>         differentiation (remember Michael Porter's three methods of
>>>         strategic success?).  Security is a MAJOR issue, since
>>>         programs intended with misdemeanor will be rampant. However,
>>>         business ROI, and standardization benefits to B2B are going
>>>         to be driving factors for the initial phase of Web Services
>>>         implementation. Later it will catch more mass and the idea
>>>         will start rolling with more acceptance. ROI -- an
>>>         interesting concept, which has traditionally been in the
>>>         purview of accountants only -- and even THEY don't agree on
>>>         how to calculate it or its overall value in the profit
>>>         equation.  My guess is that for a while, at least until the
>>>         economy picks up again, this will be the fad of IT, just as
>>>         CRM and ERPs have been in the recent past.   Cutting costs
>>>         is the "activity du jour" but history tells me we'll
>>>         discover that we're not very good at keeping track of all
>>>         the elements of ROI, we're not all that good at managing our
>>>         "investments" (partly because we're not all that sure that
>>>         we know exactly what an investment is vs. what we want it to
>>>         be) and we'll jump to the next silver bullet at our earliest
>>>         convenience. This time, it is not a hype, simply because it
>>>         has been worked with ROI, and keeping in mind that many
>>>         companies have been bit by technology not being able to meet
>>>         expectations. Also, infrastructure this time is going to be
>>>         provided by gaints Microsoft, IBM, Sun, Oracle, SAP, Cisco,
>>>         etc., instead of smaller players like i2, CommerceOne,
>>>         Ariba, etc. Microsoft is way ahead of the game right now,
>>>         with its .NET implementations. More so because, once Web
>>>         Services is in roads, it will not really matter if companies
>>>         buy UNIX or Windows boxes -- all will work seamlessly (all
>>>         talk will happen over internet using XML -- understood by
>>>         all systems in the same way). This, and standards that truly
>>>         ARE standards, would be nice.  However, our industry isn't
>>>         all that good at setting standards and playing by them.
>>>         Instead, we set minimum standards and everyone goes off and
>>>         changes them when they implement their own products.  Also,
>>>         playing a great role will be standard societies like W3C,
>>>         RosettaNet, etc., where they will reach standards for almost
>>>         every type of industry (chemical, aircraft, banking, etc.,
>>>         etc.). A great concept -- but one that works only until the
>>>         next big innovation, which then causes everyone else to
>>>         rethink the standards -- at which point they are no longer
>>>         standards.  EDI will be integrated to work with Web
>>>         Services, by the work of these standards organizations. So,
>>>         the motivation is there, and it is solid. Let me know what
>>>         you think of this architecture. My guess is that my comments
>>>         tell you what I think, but here's the gist of it.  Right
>>>         now, it sounds like yet another silver bullet concept.  As
>>>         with e-commerce and the dot-coms, we will derive some good
>>>         from it in the long run and the wise ones will incorporate
>>>         the good into their best practices.  However, we will
>>>         neither have the discipline nor the patience to give it
>>>         enough time to mature and reach its potential before we
>>>         discover that the ROI upon which you claim this is based is
>>>         ephemeral and not grounded in solid business.  We aren't at
>>>         the holy grail of the Internet yet -- we may never be.
>>>         There are too many issues that we, as a world, haven't
>>>         resolved, including legal issues of the Internet
>>>         (jurisdiction, etc.) and security/privacy.  We Americans
>>>         talk a lot about privacy and we value what little we have
>>>         left of it.  What we don't realize is that many others don't
>>>         have it, don't value it and don't want us to have it.  For
>>>         web services to work outside of theory demands an
>>>         extraordinary willingness to trust in others.  We have not
>>>         developed that trust in ourselves and the recent news events
>>>         (accounting scandals, political scandals, etc.) undermine
>>>         our desire to develop the level of trust we will require to
>>>         make use of this model in its purest fashion.  My guess is
>>>         that we will end up having major companies as service
>>>         providers, much the way our financial institutions now offer
>>>         the full range of banking, insurance and investing
>>>         services.  The idea of lots of little organizations
>>>         benefitting from this is irrational. Gotta get started on
>>>         work -- thanks for the explanation.  It DID help me
>>>     understand better.  Noel
>>
>
> To unsubscribe from this group, send an email to:
> service-orientated-architecture-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/>.

If you understand Spanish, have a look at
http://es.groups.yahoo.com/group/webservices-latinos/ .  This is a
Web Services group with a broader SOA vision than I have seen in
other WS groups.

Gervas

http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci884581,00.html

Something I came across. Good to debate about.

Thanks.
Kaleem. (x36250)
"Too low they build, who build beneath the stars." -- Edward Young, Night
Thoughts on Life, Death and Immortality, 1745 (inscribed on a wall of the
Library of Congress).

Thanks.
Kaleem. (x36250)
"Too low they build, who build beneath the stars." -- Edward Young, Night Thoughts on Life, Death and Immortality, 1745 (inscribed on a wall of the Library of Congress).

Thanks Ricky. Noel's comments give a new angle to my thoughts, probably because she is confident she knows the system, and I am just excited about the next great toy.
 
About this:
" For the same argument, I don't believe "dynamic discovery" (as you describe in the UDDI lookup scenario) is realistic in foreseeable future."
 
I would love to have a cache or proxy or copy of UDDI lookup, thereby making it as dynamic as possible. This is my personal preference, because I don't understand at this time how the deploy will take place. That is, what the companies that is so dependent on the network for their survival will do if one or all of their preferred vendor's go offline (may be the country blocks the web service during war, or the area gets destroyed during earthquake, etc., etc.).

Take care.
Kaleem. (x36250)
"One of the greatest discoveries a man makes, one of his great surprises, is to find he can do what he was afraid he couldn't do." -- Henry Ford (1863-1947)

-----Original Message-----

From: Ricky Ho [mailto:riho@...]

Sent: Tuesday, December 03, 2002 1:50 PM

To: Kaleem Aziz; edpiment@...; Xml-Interest@Cisco. Com; Web-Services@Cisco. Com; Xml-Webservices

Cc: Weblog-Blog@Cisco. Com

Subject: Re: FW: FW: IBM focus on WebService Orchestration

Kaleem, thanks for sharing the conversation.  There are a lot of good points there requiring deep thoughts.

I don't view "reuse" and "saving development effort" is the biggest motive behind web services.  We can achieve a high degree of reuse by buying more "off-the-shelf" Component Libraries.  I think the biggest motive for web services is enabling B2B integration, an old concept in the EDI days but we've never achieved the expected scale.

So the biggest thing is "WE CAN DO BUSINESS TRANSACTION ELECTRONICALLY" -- think we can take orders 24 hrs a day, from any countries; think we can immediately confirm any customer booking and arrange logistics; think we can keep our stock at the lowest level while still fulfilling fluctuating customer demands; think we only need to hire minimum number of staffs to maintain business operation.

On the internet, so far we have the "content web", and you already see how it impact our daily life.  Web services is now going to turn the "B2C content web" to the "B2B transaction web".  This is the biggest impact web services will make.  Moving further, the distinction between "B" and "C" will blur, and we will have a "P2P collaboration and transaction web" (my favorite topic of "intelligent software agents")

I agree with Noel that not every functionality will be exposed as web service.  As both of you has pointed out, the biggest problem is "trust" (not just security).  When you have no control on the implementation behind a "standardized" interface, how can you trust it is doing what you want ?  For the same argument, I don't believe "dynamic discovery" (as you describe in the UDDI lookup scenario) is realistic in foreseeable future.

To further elaborate my point, there is NO way to specify the "semantics" of a "shopping cart services", why do you expect your purchased items will be saved for a reasonable period of time and you won't be over-charged ?  You have to trust the company implementing the services.  The good news is :  This is not a new issue because we already deal with these trust issues daily.  Just don't think these issues will disappear when using web services.  In fact, this is one reason why web services is still NOT widely adopted as expected today.

There is a huge marketing advantages for those "authorities" who has already gained trust from the public to expose their functionalities as web services.  They can quickly dominate their field.  In fact, you can see there will be race between competitors to gain trust from their customer.

Thanks again for sharing the discussion !  It triggers me a lot of thoughts !

Best regards,

Ricky

At 12:04 PM 12/3/2002 -0800, Kaleem Aziz wrote:

Some interesting discussion with Noel my professor in e-commerce and security. I think she hit it right on many of the things, even though she is new to Web Services, but experienced with businesses. Also, you can see that she is skeptical about IT promising a silver bullet yet again. :)

Thanks Ricky for demonstrating "unlearning" of "conventional" IT wisdom while explaining the new paradigm of thinking.

PS: Btw, my examples were not so good for Web Services implementation.

Take care.

Kaleem. (x36250)

"One of the greatest discoveries a man makes, one of his great surprises, is to find he can do what he was afraid he couldn't do." -- Henry Ford (1863-1947)

-----Original Message-----

From: Kaleem Aziz [mailto:kaaziz@...]

Sent: Tuesday, December 03, 2002 10:31 AM

To: Noel Haskins-Hafer

Subject: RE: FW: IBM focus on WebService Orchestration

Noel,

Yes, your insight is right, and it is happening already. In the rat race, people/organizations ARE compromising on standards.

Also, I picked some wrong examples (like accounting being open to world, etc.). I mean, there are certain areas Web Services will not apply, and business will learn about that during evolution of this technology. Treat them only as examples, and not as real world solutions.

Web Services will not, as you said, benefit smaller corporations, but make the larger corporations even more efficient. It is a master architecture of conventional B2B, and B2B is a REAL need.

And just like Nike and DELL are orchestrators, yes Web Services is merely a computerization of real-life orchestration (which was slower earlier).

Also, I agree, most corporations will have to decide between opening up their business in part to the world; in order to benefit from Web Services implementation. It will be a tough choice, but it is being predicted in Forrester report and Harvard Business Review reports that the business will be slow to accept it at first, and as the technology refines, we will have as many Web Services in future as we have web sites today. Also, Microsoft, Sun, IBM and Oracle are lobbying companies to open up to standards this time, unlike just W3C or Apache or RosettaNet. The way they are selling it is not as a silver bullet or a panacea to anything, but are willing to lose money in showing initially that the model DOES work. (Just like Amazon.com went through lot of losses to make a market share.)

I think, our conventional life will become faster, and we will start seeing several lifetimes in a lifetime. :) In the sense that we will witness more companies rise and fall, have more relationships, more divorces, etc., due to the added speed and comfort. :) This is not in the HBR reports, or anything, just my intuition. :)

Take care.

Kaleem. (x36250)

"One of the greatest discoveries a man makes, one of his great surprises, is to find he can do what he was afraid he couldn't do." -- Henry Ford (1863-1947)

-----Original Message-----

Sent: Tuesday, December 03, 2002 9:18 AM

To: Kaleem Aziz

Subject: RE: FW: IBM focus on WebService Orchestration

See below.

 Kaleem Aziz <kaaziz@...> wrote:

Hi Noel,

Currently, each organization employs developers and implements a system. They have developers that develop software, either client side or server side, to carry out the business. Some clients have needs of developing the software as a client side system (where in the logic is totally residing on client machine, and the client machine "thinks" almost always). Some other clients have the need of developing the software as a server side system (where in the logic is totally residing on the company's server, and the server "thinks" for every client, ultimately). What this does, in either case, is: it requires each company to hire a team of developers/designers/architects for the functions. Each IT company is "spending" on software development costs, in order to carry out their business operations. 

Trust me, I know this part -- been there done that for longer than you or Ricky!  It is expensive and much of it is "charged" to corporate ego (or corporate lack of understanding of how to collaborate).  However, there are -- and should be -- some areas of business in which some participants don't want to share their data or the possibility at least that their data and business processes will/could be compromised to competitors, etc.

In future, the Web Services based software development will not require "in-house" developers to develop mundane logic. All the developers (lesser in number) will ever have to do is use several Web Services (over internet or intranet) to do any task. All business operations will be done over the internet, and for every atomic thing, it'll make a hit to another company's (providers) server.

Removing the mundane stuff, such as payment processing, makes a lot of sense, since that's what computers were for: automating the boring work.  However, I question the wisdom of "every atomic thing" being placed at the hands of the partners, who are, in many cases in the value web/chain, also competitors and customers.

For example, today we create e-commerce websites which validate credit card and make the purchases in a shopping cart. Each and every e-commerce company is hiring developers for writing the credit card validation logic, and a shopping cart logic. With Web Services, there'll be several credit card validation sites running their web services. Say there are 3 companies, ABC, DEF and GHI, running a Web Service that validates credit card. Each e-commerce company will not tie up with anyone of these companies. Any of the three companies will only register at one place saying that they provide that service. Any e-commerce company looks up in something like a telephone address book (technically known as UDDI) and finds these 3 companies that it could hit for credit card validation. It sends its details to ABC Co, gets a valid response and goes on automatically with next part of logic of completing the pur! chase. ABC will bill the e-commerce companies for the transaction automatically. However, if ABC fails to give valid response, there will be either a retry of a try with DEF Co. Which ever company offers the service gets paid. This happens to quickly, and automatically (once the Web Services infrastructure is complete).

Suppose now that besides the validation of credit card, there are 3 companies PQR, RST and UVW that provide shopping cart Web Service. This means that, these three companies run Web Services that can hold user purchases temporarily for a session. This would further reduce any e-commerce company's need to hire developers to code for a shopping cart functionality. In addition, the above scenario will be like this:

Step 1: One Web Service call to credit card companies ABC, or DEF or GHI after looking them in the UDDI (like a "phone book")

Step 2: Once the call shows valid credit card, another Web Service to handle the shopping cart purchase to companies PQR, RST and UVW after looking them up in the UDDI as well

Step 3, 4,5, etc. could also be such Web Services calls! These steps of calling up web services that "this company never did develop" forms "orchestration". That's the technical term Ricky is referring to -- calling of one web service after the other based on certain conditions. Therefore, client side logic or server side logic has not much to do with web services. The company is "effectively", "at a micro level", "outsourcing" each activity it's not an expert in to the expert companies, which it looks up in UDDI.

So, unless I'm oversimplifying this, we're just using "COTS" services on the web -- in effect NOT reinventing the wheel.  I fail to see where this is new and innovative, except in that the software and functionality resides out of the traditional boundaries of the corporation and more in a collective pool of companies.  How REALLY is this different from an ASP -- or rather, a collection of ASPs?

 The savings for each company are huge -- besides having to maintain the developers, servers, non-standard logic across businesses, etc. Having this automated implementation, it makes it very network dependent and therefore provides standardized versions on the fly. It really brings about the best of using "experts" to do the job, rather than having the race to hire the computer experts in "each" company. Standardization allows companies to search not like on conventional web or in a phone book, but in a more powerful fashion. For example, it could search in the following manner: 200 pairs of shoes, model number: 1245, maker: Ashton Spears, dealers in distance: 55 miles, price expected: $5000, protocol to follow: EDI 825. Trying to search in the above manner on conventional web will give 10,000 useless results; but doing this same thing in UDDI will have 5 companies competing for th! e order in the next minute. Billing wouldn't take swiping of a credit card, but would be automatic, and the proof of sale would be maintained by yet another validated/standardized web service!

As you say later, the implications for security are huge here.  It becomes not only a matter of needing to protect customer data from prying eyes (inside AND outside the organization) but also one of needing to depend on a network that is out of the organization's own control.  Thus, to a large degree, the company must be willing to give up much of its autonomy for the price of saving money.  Don't get me wrong, here.  I think much of the concept is good.  However, I can also see where we're heading here for the McDonald's of software, where every web-based company looks and feels identical and no one stands out or excells. 

If that made sense, Ricky is going to the next stage of visualizing not one company, but several such companies operating in such cyber-space. Hence, the sentence: "Looking into the future, the real value of web service is complex, orchestrated, B2B interactions across diverse enterprises.". One looking for credit card service, another for shoes, another for airplane parts, and none of this is individually implemented by each company.

Yes, we've used a similar model for businesses for years.  For example, Nike doesn't make shoes -- it contracts out every piece of the shoe making and marketing process.  The Nike company only orchestrates the activities.

There are a few disadvantages, like companies having to open up their transaction system and forming trust based preferential relationships, etc. Don't underestimate this disadvantage  It is what makes the shining stars in business worth doing repeat business with: innovation and differentiation (remember Michael Porter's three methods of strategic success?).  Security is a MAJOR issue, since programs intended with misdemeanor will be rampant. However, business ROI, and standardization benefits to B2B are going to be driving factors for the initial phase of Web Services implementation. Later it will catch more mass and the idea will start rolling with more acceptance.

ROI -- an interesting concept, which has traditionally been in the purview of accountants only -- and even THEY don't agree on how to calculate it or its overall value in the profit equation.  My guess is that for a while, at least until the economy picks up again, this will be the fad of IT, just as CRM and ERPs have been in the recent past.   Cutting costs is the "activity du jour" but history tells me we'll discover that we're not very good at keeping track of all the elements of ROI, we're not all that good at managing our "investments" (partly because we're not all that sure that we know exactly what an investment is vs. what we want it to be) and we'll jump to the next silver bullet at our earliest convenience.

This time, it is not a hype, simply because it has been worked with ROI, and keeping in mind that many companies have been bit by technology not being able to meet expectations. Also, infrastructure this time is going to be provided by gaints Microsoft, IBM, Sun, Oracle, SAP, Cisco, etc., instead of smaller players like i2, CommerceOne, Ariba, etc. Microsoft is way ahead of the game right now, with its .NET implementations. More so because, once Web Services is in roads, it will not really matter if companies buy UNIX or Windows boxes -- all will work seamlessly (all talk will happen over internet using XML -- understood by all systems in the same way).

This, and standards that truly ARE standards, would be nice.  However, our industry isn't all that good at setting standards and playing by them.  Instead, we set minimum standards and everyone goes off and changes them when they implement their own products.  Also, playing a great role will be standard societies like W3C, RosettaNet, etc., where they will reach standards for almost every type of industry (chemical, aircraft, banking, etc., etc.). A great concept -- but one that works only until the next big innovation, which then causes everyone else to rethink the standards -- at which point they are no longer standards.  EDI will be integrated to work with Web Services, by the work of these standards organizations. So, the motivation is there, and it is solid.

Let me know what you think of this architecture.

My guess is that my comments tell you what I think, but here's the gist of it.  Right now, it sounds like yet another silver bullet concept.  As with e-commerce and the dot-coms, we will derive some good from it in the long run and the wise ones will incorporate the good into their best practices.  However, we will neither have the discipline nor the patience to give it enough time to mature and reach its potential before we discover that the ROI upon which you claim this is based is ephemeral and not grounded in solid business. 

We aren't at the holy grail of the Internet yet -- we may never be.  There are too many issues that we, as a world, haven't resolved, including legal issues of the Internet (jurisdiction, etc.) and security/privacy.  We Americans talk a lot about privacy and we value what little we have left of it.  What we don't realize is that many others don't have it, don't value it and don't want us to have it. 

For web services to work outside of theory demands an extraordinary willingness to trust in others.  We have not developed that trust in ourselves and the recent news events (accounting scandals, political scandals, etc.) undermine our desire to develop the level of trust we will require to make use of this model in its purest fashion. 

My guess is that we will end up having major companies as service providers, much the way our financial institutions now offer the full range of banking, insurance and investing services.  The idea of lots of little organizations benefitting from this is irrational.

Gotta get started on work -- thanks for the explanation.  It DID help me understand better. 

Noel

-----Original Message-----
From: Peper [mailto:delarco71@...]
Sent: Tuesday, March 11, 2003 8:11 AM
To: service-orientated-architecture@yahoogroups.com
Subject: [service-orientated-architecture] Re: SOA, WS & Jini

Hi everybody,

Actually Web Services implementation has no complete support for
dynamic registering/discovering/invocation of services and the
UDDI/WSDL standards are statically based.

What do you think about semantic description of UDDI with DAML-S
ontologies?. Perhaps in a future the Semantic Web helps to fill the
gaps in the support for Web Services dynamic feautures. The web
services dynamic composition/discovering/invocation will be improving
with DAML-S and agents.

Best Regards,
José Carlos.

--------------------------------------------------------------

webservices-latinos Group:

http://es.groups.yahoo.com/group/webservices-latinos/  (spanish
language originality).

---------------------------------------------------------------


--- In service-orientated-architecture@yahoogroups.com, Gervas
Douglas <gervasdouglas@y...> wrote:
> I recently posted an article by Ron Dearing of Cysive on SOA, Web
Service and Jini.  This theme is of especial interest to this group
as it studies the constructive interaction between two different SOA
implementations.  To quote from the introduction:
> "Currently, service-oriented architectures are becoming an integral
aspect of the IT strategy. Service-oriented architectures offer the
ability to register, discover, and use services, where the
architecture is dynamic in nature. Web Services promises to deliver
functionality that can be registered, discovered, and executed.
However, the technologies that provide the implementation of these
features are by its very core, statically based.
>
> "Jini's architecture promotes the concept of dynamic registration,
discovery, and execution. The architecture addresses the problems of
creating service-oriented architectures that are intended to be
adaptive, self-healing, self-administered, and distributed."
>
> You can find this article at http://groups.yahoo.com/group/service-
orientated-architecture/files/Articles-Whitepapers/ .
>
> We look forward to your comments!
>
> Gervas
>
>
>
>
> ---------------------------------
> With Yahoo! Mail you can get a bigger mailbox -- choose a size that
fits your needs




To unsubscribe from this group, send an email to:
service-orientated-architecture-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi everybody,

Actually Web Services implementation has no complete support for
dynamic registering/discovering/invocation of services and the
UDDI/WSDL standards are statically based.

What do you think about semantic description of UDDI with DAML-S
ontologies?. Perhaps in a future the Semantic Web helps to fill the
gaps in the support for Web Services dynamic feautures. The web
services dynamic composition/discovering/invocation will be improving
with DAML-S and agents.

Best Regards,
José Carlos.

--------------------------------------------------------------

webservices-latinos Group:

http://es.groups.yahoo.com/group/webservices-latinos/  (spanish
language originality).

---------------------------------------------------------------


--- In service-orientated-architecture@yahoogroups.com, Gervas
Douglas <gervasdouglas@y...> wrote:
> I recently posted an article by Ron Dearing of Cysive on SOA, Web
Service and Jini.  This theme is of especial interest to this group
as it studies the constructive interaction between two different SOA
implementations.  To quote from the introduction:
> "Currently, service-oriented architectures are becoming an integral
aspect of the IT strategy. Service-oriented architectures offer the
ability to register, discover, and use services, where the
architecture is dynamic in nature. Web Services promises to deliver
functionality that can be registered, discovered, and executed.
However, the technologies that provide the implementation of these
features are by its very core, statically based.
>
> "Jini's architecture promotes the concept of dynamic registration,
discovery, and execution. The architecture addresses the problems of
creating service-oriented architectures that are intended to be
adaptive, self-healing, self-administered, and distributed."
>
> You can find this article at http://groups.yahoo.com/group/service-
orientated-architecture/files/Articles-Whitepapers/ .
>
> We look forward to your comments!
>
> Gervas
>
>
>
>
> ---------------------------------
> With Yahoo! Mail you can get a bigger mailbox -- choose a size that
fits your needs

"Currently, service-oriented architectures are becoming an integral aspect of the IT strategy. Service-oriented architectures offer the ability to register, discover, and use services, where the architecture is dynamic in nature. Web Services promises to deliver functionality that can be registered, discovered, and executed. However, the technologies that provide the implementation of these features are by its very core, statically based.

"Jini’s architecture promotes the concept of dynamic registration, discovery, and execution. The architecture addresses the problems of creating service-oriented architectures that are intended to be adaptive, self-healing, self-administered, and distributed."

You can find this article at http://groups.yahoo.com/group/service-orientated-architecture/files/Articles-Whitepapers/ .

We look forward to your comments!

Gervas

I think another intersting facet of the statements made in the article
is that they are with reference to a single computer.  Now, on occasion
I might even agree with the related statement about performance
inversion but, I'd make the following observations:

(1)    No useful network has one computer.
(2)    For the sake of manageability (along with a whole pile of other
reasons), not every computer has a dedicated link to every other
computer.  i.e. Computers share bandwidth.
(3)    Traditionally, more bandwidth or more computer power results in
the creation of more powerful software which then generates a need for a
further leap in bandwidth and computer power.
(4)    A single computer can get rather large - 64 or even 128
processors, and is capable of generating large amounts of data VERY
quickly (think scientific applications).  Now think about clusters of
computers which can go way bigger than 128 processors and generate still
more data.
(5)    IPv4 supports a fairly large number of computers but the IETF
created IPv6 with a much larger address space because they have concerns
about the sheer number of networked devices that will likely be deployed
as ubiquitous computing becomes a reality.

Basically, fast networks attract complex software and lots of computers
which consume all their existing bandwidth such that further network
infrastructure has to be deployed to maintain quality of service.

Whilst this "arms race" may come to an end eventually, I certainly don't
see it for a few years yet.

Just my two cents,

Dan

Gervas Douglas wrote:

>Kaleem,
>
>This article is almost as interesting for what it doesn't say as for
>what it does.  Frankly I doubt that the author has much in-depth
>technical knowledge of the subject.  The transmission speed of almost
>1 Gb/s is no big deal nowadays across a modern D-WDM-equipped fibre-
>optic backbone.  The distance is not of so much significance as the
>implications for the local loop connection.  This sort of high-speed
>facility will be relevant to SOA application components wishing to
>interchange huge datasets between remotely located data centres.  It
>is also very relevant to new Internet2 apps such as tele-immersion
>and tele-medecine which require a combination of high-speed, low-
>latency, low-jitter connections and significant computing power.  It
>would also be very relevant to system-mirroring requirements.
>
>That said, the reality is that connectivity to end-user devices will
>continue to be patchy and frequently slow.  For the forseeable future
>SOA system designers will have to make provision for the lowest
>common denominators in system connectivity as well as taking
>advantage of new communication facilities.  If you want examples of
>how low bandwidth connections can be used effectively, look at the
>old mainframe networks such as IBM's SNA.  More recently I ran
>Windows apps in Citrix's Floridian office from England over a
>14.4kb/s dial-up connection in 1995.  Yes, it worked!
>
>I understand that you have connections with Cisco who believe in IP
>and wall-to-wall fibre as goals.  All very praiseworthy, but don't
>forget that outside countries like Sweden and Finland, the reality of
>communication options is usually more prosaic.  There are still
>countries where E1 lines (2 Mb/s) are looked on as an expensive
>luxury.
>
>Gervas
>
>--- In service-orientated-architecture@yahoogroups.com, "Kaleem Aziz"
><kaaziz@c...> wrote:
>
>
>>"You have this inversion where the limitations on advances will not
>>
>>
>be the
>
>
>>speed of the Internet but rather the speed of your computer."
>>-- Harvey Newman, California Institute of Technology
>>http://www.cnn.com/2003/TECH/internet/03/07/speed.record/index.html
>>
>>Thanks.
>>Kaleem. (x36250)
>>"Too low they build, who build beneath the stars." -- Edward Young,
>>
>>
>Night
>
>
>>Thoughts on Life, Death and Immortality, 1745 (inscribed on a wall
>>
>>
>of the
>
>
>>Library of Congress).
>>
>>
>
>
>
>To unsubscribe from this group, send an email to:
>service-orientated-architecture-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>
>

Kaleem,

This article is almost as interesting for what it doesn't say as for
what it does.  Frankly I doubt that the author has much in-depth
technical knowledge of the subject.  The transmission speed of almost
1 Gb/s is no big deal nowadays across a modern D-WDM-equipped fibre-
optic backbone.  The distance is not of so much significance as the
implications for the local loop connection.  This sort of high-speed
facility will be relevant to SOA application components wishing to
interchange huge datasets between remotely located data centres.  It
is also very relevant to new Internet2 apps such as tele-immersion
and tele-medecine which require a combination of high-speed, low-
latency, low-jitter connections and significant computing power.  It
would also be very relevant to system-mirroring requirements.

That said, the reality is that connectivity to end-user devices will
continue to be patchy and frequently slow.  For the forseeable future
SOA system designers will have to make provision for the lowest
common denominators in system connectivity as well as taking
advantage of new communication facilities.  If you want examples of
how low bandwidth connections can be used effectively, look at the
old mainframe networks such as IBM's SNA.  More recently I ran
Windows apps in Citrix's Floridian office from England over a
14.4kb/s dial-up connection in 1995.  Yes, it worked!

I understand that you have connections with Cisco who believe in IP
and wall-to-wall fibre as goals.  All very praiseworthy, but don't
forget that outside countries like Sweden and Finland, the reality of
communication options is usually more prosaic.  There are still
countries where E1 lines (2 Mb/s) are looked on as an expensive
luxury.

Gervas

--- In service-orientated-architecture@yahoogroups.com, "Kaleem Aziz"
<kaaziz@c...> wrote:
> "You have this inversion where the limitations on advances will not
be the
> speed of the Internet but rather the speed of your computer."
> -- Harvey Newman, California Institute of Technology
> http://www.cnn.com/2003/TECH/internet/03/07/speed.record/index.html
>
> Thanks.
> Kaleem. (x36250)
> "Too low they build, who build beneath the stars." -- Edward Young,
Night
> Thoughts on Life, Death and Immortality, 1745 (inscribed on a wall
of the
> Library of Congress).

The Stencil Group produce some excellent material on Web Services.
They are also very SOA aware.  They have recently published a n
interesting paper on "Web Services Rules: Real-World Lessons from
Early Adopters" which you can find at:
http://www.stencilgroup.com/ideas/reports/2003/wsrules/2_today.html

Here is an extract relating to SOA:

"If service-oriented architecture represents the technical vision
driving web services, then the service-oriented enterprise reflects a
change in the human, business process, and organizational governance
factors that shape how IT interacts with the business. The well-
designed technical backbone of an SOA helps deliver upon the promise
of reduced maintenance costs and better interoperability, but it is
the application and management of the technology that delivers bottom-
line productivity benefits."

Gervas

"You have this inversion where the limitations on advances will not be the
speed of the Internet but rather the speed of your computer."
-- Harvey Newman, California Institute of Technology
http://www.cnn.com/2003/TECH/internet/03/07/speed.record/index.html

Thanks.
Kaleem. (x36250)
"Too low they build, who build beneath the stars." -- Edward Young, Night
Thoughts on Life, Death and Immortality, 1745 (inscribed on a wall of the
Library of Congress).

Do you think maybe IBM is using Tspaces as well?  I have just seen an
article on BEA's website about implementing SOA.  You can find it at
the address further down (to avoid the advertisement):













http://dev2dev.bea.com/articles/518.jsp

Jasmine

--- In service-orientated-architecture@yahoogroups.com, "Gervas
Douglas" <gervasdouglas@y...> wrote:
> I think you are probably right about them using MQ somewhere or
> other, Enrique.  However I have just come across an article from
the
> same source (ZDNet) in which IBM claim that WebSphere is becoming
an
> SOA product through its support of XML and WS.  Funny how many
people
> are discovering the virtues of SOA!  The URL, being in advert-
evasive
> mode is at the bottom of this message.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> http://zdnet.com.com/2102-1104-983155.html
>
> Gervas
>
>
> --- In service-orientated-architecture@yahoogroups.com, "Enrique
> Heydrich" <enriqueheydrich@y...> wrote:
> > This article is interesting for IBM's strategy.  IBM obviously
put
> a
> > lot of effort into implementing workflow, choreography etc. in
the
> > upperlayers, but they must also use some "middleware adhesive"
for
> > their SOA.  I think this must be Websphere MQ.  It was MQ
series.
> > This had the reputation of a good, solid product but it is not
very
> > modern in design concept.  I do not think they use CORBA.
> >
> >
> > Enrique.
> >
> > --- In service-orientated-architecture@yahoogroups.com, "Gervas
> > Douglas" <gervasdouglas@y...> wrote:
> > > It has been pointed out to me that yet again the URL has been
cut
> > by
> > > one of those wretched adverts.  So here it is again further
down
> > the
> > > page!
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2911915,00
> > > .html
> > >
> > > --- In service-orientated-architecture@yahoogroups.com, "Gervas
> > > Douglas <gervasdouglas@y...>" <gervasdouglas@y...> wrote:
> > > > And here is an interesting article on IBM's approach:
> > > >
> > >
> >
>
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2911915,00
> > > > .html
> > > >
> > > > Interesting to see the "on-demand" hype put in such an
> explicitly
> > > SOA
> > > > context.  How about this quotation from Scott Hebner, the
> > marketing
> > > > man responsible for WebSphere explaining why J2EE and Web
> > Services
> > > > (WS)alone are not sufficient: "There needs to be something
else-
> -
> > a
> > > > service oriented architecture (SOA) that's more than just
J2EE
> > with
> > > > Web services."  Any ideas what special technology Big Blue
> could
> > > best
> > > > use to achieve this goal?
> > > >
> > > > Gervas
> > > >
> > > > Gervas
> > > >
> > > > --- In service-orientated-
architecture@yahoogroups.com, "Gervas
> > > > Douglas <gervasdouglas@y...>" <gervasdouglas@y...> wrote:
> > > > > Interesting and concise article from a thoughtful company,
> > > ZapThink:
> > > > >
> > > > >
> > > >
> > >
> >
>
http://searchwebservices.techtarget.com/originalContent/1,289142,sid26
> > > > > _gci882714,00.html
> > > > >
> > > > > Gervas

I think you are probably right about them using MQ somewhere or
other, Enrique.  However I have just come across an article from the
same source (ZDNet) in which IBM claim that WebSphere is becoming an
SOA product through its support of XML and WS.  Funny how many people
are discovering the virtues of SOA!  The URL, being in advert-evasive
mode is at the bottom of this message.















http://zdnet.com.com/2102-1104-983155.html

Gervas


--- In service-orientated-architecture@yahoogroups.com, "Enrique
Heydrich" <enriqueheydrich@y...> wrote:
> This article is interesting for IBM's strategy.  IBM obviously put
a
> lot of effort into implementing workflow, choreography etc. in the
> upperlayers, but they must also use some "middleware adhesive" for
> their SOA.  I think this must be Websphere MQ.  It was MQ series.
> This had the reputation of a good, solid product but it is not very
> modern in design concept.  I do not think they use CORBA.
>
>
> Enrique.
>
> --- In service-orientated-architecture@yahoogroups.com, "Gervas
> Douglas" <gervasdouglas@y...> wrote:
> > It has been pointed out to me that yet again the URL has been cut
> by
> > one of those wretched adverts.  So here it is again further down
> the
> > page!
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2911915,00
> > .html
> >
> > --- In service-orientated-architecture@yahoogroups.com, "Gervas
> > Douglas <gervasdouglas@y...>" <gervasdouglas@y...> wrote:
> > > And here is an interesting article on IBM's approach:
> > >
> >
>
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2911915,00
> > > .html
> > >
> > > Interesting to see the "on-demand" hype put in such an
explicitly
> > SOA
> > > context.  How about this quotation from Scott Hebner, the
> marketing
> > > man responsible for WebSphere explaining why J2EE and Web
> Services
> > > (WS)alone are not sufficient: "There needs to be something else-
-
> a
> > > service oriented architecture (SOA) that's more than just J2EE
> with
> > > Web services."  Any ideas what special technology Big Blue
could
> > best
> > > use to achieve this goal?
> > >
> > > Gervas
> > >
> > > Gervas
> > >
> > > --- In service-orientated-architecture@yahoogroups.com, "Gervas
> > > Douglas <gervasdouglas@y...>" <gervasdouglas@y...> wrote:
> > > > Interesting and concise article from a thoughtful company,
> > ZapThink:
> > > >
> > > >
> > >
> >
>
http://searchwebservices.techtarget.com/originalContent/1,289142,sid26
> > > > _gci882714,00.html
> > > >
> > > > Gervas

This article is interesting for IBM's strategy.  IBM obviously put a
lot of effort into implementing workflow, choreography etc. in the
upperlayers, but they must also use some "middleware adhesive" for
their SOA.  I think this must be Websphere MQ.  It was MQ series.
This had the reputation of a good, solid product but it is not very
modern in design concept.  I do not think they use CORBA.


Enrique.

--- In service-orientated-architecture@yahoogroups.com, "Gervas
Douglas" <gervasdouglas@y...> wrote:
> It has been pointed out to me that yet again the URL has been cut
by
> one of those wretched adverts.  So here it is again further down
the
> page!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2911915,00
> .html
>
> --- In service-orientated-architecture@yahoogroups.com, "Gervas
> Douglas <gervasdouglas@y...>" <gervasdouglas@y...> wrote:
> > And here is an interesting article on IBM's approach:
> >
>
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2911915,00
> > .html
> >
> > Interesting to see the "on-demand" hype put in such an explicitly
> SOA
> > context.  How about this quotation from Scott Hebner, the
marketing
> > man responsible for WebSphere explaining why J2EE and Web
Services
> > (WS)alone are not sufficient: "There needs to be something else--
a
> > service oriented architecture (SOA) that's more than just J2EE
with
> > Web services."  Any ideas what special technology Big Blue could
> best
> > use to achieve this goal?
> >
> > Gervas
> >
> > Gervas
> >
> > --- In service-orientated-architecture@yahoogroups.com, "Gervas
> > Douglas <gervasdouglas@y...>" <gervasdouglas@y...> wrote:
> > > Interesting and concise article from a thoughtful company,
> ZapThink:
> > >
> > >
> >
>
http://searchwebservices.techtarget.com/originalContent/1,289142,sid26
> > > _gci882714,00.html
> > >
> > > Gervas

It has been pointed out to me that yet again the URL has been cut by
one of those wretched adverts.  So here it is again further down the
page!


















http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2911915,00
.html

--- In service-orientated-architecture@yahoogroups.com, "Gervas
Douglas <gervasdouglas@y...>" <gervasdouglas@y...> wrote:
> And here is an interesting article on IBM's approach:
>
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2911915,00
> .html
>
> Interesting to see the "on-demand" hype put in such an explicitly
SOA
> context.  How about this quotation from Scott Hebner, the marketing
> man responsible for WebSphere explaining why J2EE and Web Services
> (WS)alone are not sufficient: "There needs to be something else--a
> service oriented architecture (SOA) that's more than just J2EE with
> Web services."  Any ideas what special technology Big Blue could
best
> use to achieve this goal?
>
> Gervas
>
> Gervas
>
> --- In service-orientated-architecture@yahoogroups.com, "Gervas
> Douglas <gervasdouglas@y...>" <gervasdouglas@y...> wrote:
> > Interesting and concise article from a thoughtful company,
ZapThink:
> >
> >
>
http://searchwebservices.techtarget.com/originalContent/1,289142,sid26
> > _gci882714,00.html
> >
> > Gervas

And here is an interesting article on IBM's approach:
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2911915,00
.html

Interesting to see the "on-demand" hype put in such an explicitly SOA
context.  How about this quotation from Scott Hebner, the marketing
man responsible for WebSphere explaining why J2EE and Web Services
(WS)alone are not sufficient: "There needs to be something else--a
service oriented architecture (SOA) that's more than just J2EE with
Web services."  Any ideas what special technology Big Blue could best
use to achieve this goal?

Gervas

Gervas

--- In service-orientated-architecture@yahoogroups.com, "Gervas
Douglas <gervasdouglas@y...>" <gervasdouglas@y...> wrote:
> Interesting and concise article from a thoughtful company, ZapThink:
>
>
http://searchwebservices.techtarget.com/originalContent/1,289142,sid26
> _gci882714,00.html
>
> Gervas

Interesting and concise article from a thoughtful company, ZapThink:

http://searchwebservices.techtarget.com/originalContent/1,289142,sid26
_gci882714,00.html

Gervas

I agree.

I expect to see a lot of broken and failed SOA implementations as we
get into their implementations. I mean, with less powerful HTML we
could create a mess on internet (majority web pages speak for
themselves), so we shouldn't be surprised to see stark failures in
unlearning and learning SOA "control".

Media, I believe, leads us also to wrong idealogies. We should
remember: Media makes us aware, not experts.

My 2 cents.

--- In service-orientated-architecture@yahoogroups.com, "Gordon Sim"
<gordonsim@h...> wrote:
> I agree with the assertion that SOA leverages two important design
> principles: modularity [...and...] encapsulation'. Another one
perhaps is
> the separation of interface from implementation.
>
> However, The claim 'although Web Services standards have significant
> limitations, they are better for SOA purposes than any previous
offerings' is
> unsubstantiated and - in my opinion - false.
>
> 'Unanimous vendor acceptance of web services standards' seems to be
the main
> benefit to me, as the article points out however they are 'narrower in
> scope'. Unanimous acceptance tends to imply 'lowest common denominator'.
>
> The 'ability of SOAP to cross firewall boundaries' is not
necessarily a good
> thing; control is the issue. The Corba 3 firewall specs seem to be a
better
> attempt to solve this issue.
>
>
>
>
> From: "Jasmine Schmidt <lottospiel2000@y...>" <lottospiel2000@y...>
> Reply-To: service-orientated-architecture@yahoogroups.com
> To: service-orientated-architecture@yahoogroups.com
> Subject: [service-orientated-architecture] Gartner & SOA
> Date: Tue, 25 Feb 2003 14:03:20 -0000
>
> For me Gartner is "l'Oracle de la SOA".  I have met many charming
> analystes from Gartner and I have always been impressed by their
> intelligence and knowledge of IT.  I recommend to you all to look at
> their predictions for SOA for this year.  This you can find at
>
http://www3.gartner.com/DisplayDocument?id=380364&ref=g_forward&call=email
>
> Bye,
>
> Jasmine
>
>
>
>
> To unsubscribe from this group, send an email to:
> service-orientated-architecture-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail

I recently noticed a two part article on IBMs developer works site that may
be of interest to this list:

http://www-106.ibm.com/developerworks/ibm/library/i-servicegrid/

http://www-106.ibm.com/developerworks/ibm/library/i-servicegrid2/


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus

I have just found an interesting article by Mr. Dearing at
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26
_gci871817,00.html

I would be interested to hear what you think, particularly technical
people like Gordon.

Also I post this message to the Jini-JavaSpaces group.

regards

Jasmine

I agree with the assertion that SOA leverages two important design
principles: modularity [...and...] encapsulation'. Another one perhaps is
the separation of interface from implementation.

However, The claim 'although Web Services standards have significant
limitations, they are better for SOA purposes than any previous offerings' is
unsubstantiated and - in my opinion - false.

'Unanimous vendor acceptance of web services standards' seems to be the main
benefit to me, as the article points out however they are 'narrower in
scope'. Unanimous acceptance tends to imply 'lowest common denominator'.

The 'ability of SOAP to cross firewall boundaries' is not necessarily a good
thing; control is the issue. The Corba 3 firewall specs seem to be a better
attempt to solve this issue.




From: "Jasmine Schmidt <lottospiel2000@...>" <lottospiel2000@...>
Reply-To: service-orientated-architecture@yahoogroups.com
To: service-orientated-architecture@yahoogroups.com
Subject: [service-orientated-architecture] Gartner & SOA
Date: Tue, 25 Feb 2003 14:03:20 -0000

For me Gartner is "l'Oracle de la SOA".  I have met many charming
analystes from Gartner and I have always been impressed by their
intelligence and knowledge of IT.  I recommend to you all to look at
their predictions for SOA for this year.  This you can find at
http://www3.gartner.com/DisplayDocument?id=380364&ref=g_forward&call=email

Bye,

Jasmine




To unsubscribe from this group, send an email to:
service-orientated-architecture-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail

For me Gartner is "l'Oracle de la SOA".  I have met many charming
analystes from Gartner and I have always been impressed by their
intelligence and knowledge of IT.  I recommend to you all to look at
their predictions for SOA for this year.  This you can find at
http://www3.gartner.com/DisplayDocument?id=380364&ref=g_forward&call=email

Bye,

Jasmine

The following is from a Thread on my other usergroup at
http://groups.yahoo.com/group/jini_javaspaces

where a comparison is drawn between Web Services and Jini:
=================================================================
Date:  Mon Feb 17, 2003  9:51 am
Subject:  RE: Re: [jini_javaspaces] New to the group


Yes, there's a strong similarity in terms of structure and
architecture.

Given the level of interest from those new to jini technology, it
might be
worth throwing the following rule of thumb into the debate:

Web Services is a good SOA for the edge of your network, where you
don't control or even know what type of client you're dealing with
and want to be flexible. Communications are generally made in terms
of 'structs' of data that resemble proper objects at the lowest level
only.

Jini in contrast, exchanges bona fide objects i.e. encapsulated
behaviour as well as the data - if you have control over both ends of
your communication, jini provides a more elegant and expressive
approach with lower overhead on serialisation and better reuse of
code.



Dave

--- Dan Creswell wrote:
>JINI is actually (IMHO) a chunk of infrastructure for handling
service lookup/registration and provides mechanisms to assist in
building distributed systems that cope with failure in an elegant
fashion. In this context, it very much supports SOA. It's interesting
to note that UDDI looks very much like JINI's lookup service and more
interesting still to note that JINI came before WebServices.
>

SOA is a software paradigm which has been around for some years,
albeit being called something else.  Examples were CORBA- or MOM-
based (message-orientated middleware).  However it has taken the
invention of Web Services as a SOA implementation to bring SOA to the
larger IT community's notice.  We do not want this group to concern
itself solely with Web Services, however it would be useful to
consider WS in a SOA context and in relation to other technologies,
both SOA and non-SOA based.

Examples of self-proclaimed SOA vendors include IONA, Sonic Software
and CapeClear as well the Jini/JavaSpaces community.  With reference
to the latter you mmight also like to visit
http://groups.yahoo.com/group/jini_javaspaces.

So come and share your thoughts, questions, inspirations and
proposals for this pivotal technology.

Gervas Douglas
Moderator