Let's say I went out and bought the new version of SAP and it exposed
3,084 services. How do I get these in my UDDI registry?

Good question. It depends on the tooling you have available.

Some of the commercial registries provide registration utitlities. For
example, Systinet has a utility called wsdl2uddi. Feed it a stack of
WSDLs, and it will register them all for you automatically in
compliance with the "Using WSDL in a UDDI Registry v2" technical note.
This utility is also available interactively via the Systinet Registry
consoles. I believe that this utility will work with other UDDI
registries, although I haven't tried it. The utility is a web service,
and you simply configure the UDDI access URLs. In any case, you can
download the Systinet Registry in trial mode and give it a try...

SOA Software also provides a visual WSDL mapping wizard, although I
don't know if it's available as a batch utility. (They provide
registration capabilities through an SDK, but I don't know if exposes
the WSDL mapping wizard.)

IBM provides a visual WSDL mapping wizard, but I believe it is only
available through the Web Services Explorer tool for Eclipse. My
understanding is that the only programmatic API is the JAX-RPC API,
and it doesn't support WSDL mapping.

Blue Titan also supplies a console-based visual registration wizard
and a SOAP API. (Blue Titan Registry isn't UDDI compliant, though.)

Infravio provides a console-based visual registration wizard and a JAXM API.

Any one of the small companies would be very happy to create a batch
registration wizard for you if the sale depended on it.

Anne


Anne

On 5/2/05, jeffrschneider <jeffrschneider@...> wrote:
> Let's say I went out and bought the new version of SAP and it exposed
> 3,084 services. How do I get these in my UDDI registry?
>
>
> Yahoo! Groups Links
>
>
>
>
>

ECOWS 2005
                Third European Conference on Web Services
                  http://wscc.info/ecows2005/research/

                   Vaxjo, Sweden, 14-16 November 2005

Sponsored by IEEE Computer Society, Technical Committee on Services
Computing (approval pending).

Scope:

The design of distributed applications and users' expectations for
software evolution have changed dramatically in the last 15 years. An
important milestone was set when distributed object environments (e.g.,
CORBA) made it possible to program distributed applications as if
remote objects were local. This gave birth to a thriving middleware
market and popularized the use of open APIs in the software industry.
This approach led to object-oriented software components, whereby a
group of objects that collectively fulfill a given task provide a
single interface to remote applications; examples include CCM and J2EE.

Over a decade of experience has taught the community (researchers and
practitioners alike) that distributed object computing has inherent
problems, because of the tight coupling that is requires between
distant systems. First, guaranteeing interoperability and openness
among all objects and components in a distributed application is
difficult when these objects are developed by competing commercial
entities. Software vendors prefer to segment markets, because niche
markets are more lucrative than commodity markets. Second, most
customers need to integrate large application chunks (as opposed to
fine-grained objects) written by different vendors, so having
object-level interoperability is often unnecessary in practice.

The success encountered by the Web has convinced most of the community
that tightly coupled software systems are only good for niche markets,
whereas loosely coupled software systems can be more flexible, more
adaptive and often more appropriate in practice. Loose coupling makes
it easier for a given system to interact with other systems (be they
legacy or not) that share very little with it.

At the crossing of distributed computing and loosely coupled systems
lies
service-oriented computing, which appears to many as the next important
step in distributed computing. When applications adopt service-oriented
architectures, they can evolve during their lifespans more easily and
better adapt to changing or unpredictable environments. When properly
implemented, services can be discovered and invoked dynamically using
non-proprietary mechanisms, while each service can still be implemented
in a black-box manner. This is important from a business perspective:
there is no need for customers to "choose their sides" anymore. Each
service can be implemented using any technology, independently of the
others. What matters is that everybody agrees on the integration
technology, and there is a consensus about this in today's middleware
market: customers want to use Web technologies, notably XML.

ECOWS 2005 will cover all aspects of Web Services, which constitute the
main technology available to date for implementing service-oriented
architectures and computing. The main objectives of this conference are
to facilitate exchanges between researchers and practitioners and foster
future collaborations in Europe and beyond. Topics of interest to the
Research Track include, but are not limited to, the following:

    - Modeling of Web Services
    - Design of Web Services
    - Software Architectures for Web Services
    - Testing of Web Services
    - Composition of Web Services
    - Interoperability of Web Services
    - Orchestration and Choreography of Web Services
    - Management of Web Services
    - Scalability and Performance of Web Services
    - Security Aspects of Web Services
    - Trusting and Negotiating with Web Services
    - Web Service Discovery and Selection: Beyond UDDI
    - Business Process Integration and Management using Web Services
    - Web Services for e-Business
    - Web Services for Workflow Systems
    - Web Services and Mobility
    - Web Services for Grids
    - Web Services for P2P
    - Economics of Web Services, Pricing Models
    - Frameworks for Building Web Service-Based Applications
    - Comparison of Web Services and Grid Services
    - Formal Methods for Web Services
    - Semantic Web Services
    - Ontology Languages for Web Services
    - Quality of Service-Aware Web Services
    - Service-Oriented Architectures
    - Service-Oriented Computing
    - Life Cycle of Web Services
    - Integration of Web Services and Legacy Systems

General Chairs:

Welf Loewe, Vaxjo University, Sweden
Jean-Philippe Martin-Flatin, Consultant, Switzerland

Steering Committee:

Schahram Dustdar, TU Wien, Austria
Frank Leymann, University of Stuttgart, Germany
Liang-Jie Zhang, IBM Research, USA

Program Committee Co-Chairs:

Welf Loewe, Vaxjo University, Sweden
Jean-Philippe Martin-Flatin, Consultant, Switzerland

Program Committee:

Karl Aberer, EPFL, Switzerland
Nikos Anerousis, IBM Research, USA
Farhad Arbab, CWI, The Netherlands
Luciano Baresi, Politecnico di Milano, Italy
Boualem Benatallah, University of New South Wales, Australia
Djamal Benslimane, University Claude Bernard, Lyon, France
David Breitgand, IBM Research, Israel
Christoph Bussler, DERI, Ireland
Geoff Coulson, Lancaster University, UK
Theo Dimitrakos, BT, UK
Wolfgang Dostal, IBM, Germany
Schahram Dustdar, TU Wien, Austria
Vadim Ermolayev, Zaporozhye State University, Ukraine
David Eyers, University of Cambridge, UK
Dieter Fensel, University of Innsbruck and DERI, Austria
Bogdan Franczyk, Leipzig University, Germany
Martin Gerdes, Ericsson, Germany
Christian Geuer-Pollmann, Microsoft, Germany
Paul Grefen, Eindhoven University of Technology, The Netherlands
John Grundy, University of Auckland, New Zealand
Thomas Gschwind, IBM Research, Switzerland
Martin Henkel, Stockholm University, Sweden
Michael Huhns, University of South Carolina, USA
Alexander Keller, IBM Research, USA
Birgitta Koenig-Ries, University of Jena, Germany
Ernoe Kovacs, NEC Europe Network Labs, Germany
Frank Leymann, University of Stuttgart, Germany
Ling Liu, Georgia Tech, USA
Zongwei Luo, University of Hong-Kong, China
Ingo Melzer, DaimlerChrysler Research, Germany
Rainer Neumann, PTV, Germany
Roy Oberhauser, Aalen University of Applied Sciences, Germany
Claus Pahl, Dublin City University, Ireland
Cesare Pautasso, ETH Zurich, Switzerland
Barbara Pernici, Politecnico di Milano, Italy
Akhil Sahai, HP Labs, USA
Ulf Schreier, University of Applied Sciences Furtwangen, Germany
Michael Stal, Siemens, Germany
Tran Cao Son, New Mexico State University, USA
Aphrodite Tsalgatidou, National & Kapodistrian Uni. of Athens, Greece
Rainer Unland, University of Duisburg-Essen, Germany
Wim Vanderperren, Vrije Universiteit Brussel, Belgium
Aad van Moorsel, University of Newcastle, UK
Do van Thanh, NTNU and Telenor, Norway
Thanos Vasilakos, University of Thessaly, Greece
Jim Webber, ThoughtWorks, Australia
Andreas Wombacher, University of Twente, The Netherlands
Gianluigi Zavattaro, University of Bologna, Italy
Jia Zhang, Northern Illinois University, USA
Liang-Jie Zhang, IBM Research, USA
Wolf Zimmermann, Martin-Luther Uni. of Halle-Wittenberg, Germany

Important Dates:

Submission deadline: 15 June 2005
Notification of acceptance: 15 July 2005
Final paper due: 15 August 2005

Details about the submission procedure are available on the website.
The proceedings will be published (to be announced soon). The authors
shortlisted for the best-paper award will be invited to submit enhanced
versions of their papers to the International Journal of Web Services
Research (JWSR) for fast-track publication.

Business Sponsors:

Please contact Lars Hornborg <lars@...>.

Jose Carlos del Arco Prieto wrote:
> Over a decade of experience has taught the community (researchers and
> practitioners alike) that distributed object computing has inherent
> problems, because of the tight coupling that is requires between
> distant systems. First, guaranteeing interoperability and openness
> among all objects and components in a distributed application is
> difficult when these objects are developed by competing commercial
> entities. Software vendors prefer to segment markets, because niche
> markets are more lucrative than commodity markets. Second, most
> customers need to integrate large application chunks (as opposed to
> fine-grained objects) written by different vendors, so having
> object-level interoperability is often unnecessary in practice.

I continue to be amused by this type of characterization of distributed
object computing.  The issues mentioned here are very specific to the
problems that a CORBA/DCOM style computing environment creates.

The lack of mobile code means that granularity must be small so that a
service can be used from multiple places, or code must be copied
everywhere so that granularity can be larger.  The RMI programming model
and Jini's use thereof removes these barriers by allowing granularity to
be managed remotely and to be dynamically evolved.

CORBA and COM/DCOM promoted some really poor system designs.  Now,
everyone who has experience with these systems feels like that is the
limit of a distributed object environment. This is simply not the case.

The path to web services introduces patches and band-aids to the whole
data-only communications paradigms that CORBA etc. use.  XML provides
the mechanism for evolving the data.  But, it does not provide the
mechanism for improving the efficiency of the system through bandwidth
management.

XML introduces and promotes the expansion of the data path into a
monolithic dependency of the system.  XML encourages the addition of
data to one interface to create a new interface without providing
separation that the interface based Java RMI programming model
encourages.  The result can be that monolithic services swell up out of
base services and create dependencies through coupling that can make it
much harder to provide lightweight interfaces to existing systems for
specific applications.

> The success encountered by the Web has convinced most of the community
> that tightly coupled software systems are only good for niche markets,
> whereas loosely coupled software systems can be more flexible, more
> adaptive and often more appropriate in practice. Loose coupling makes
> it easier for a given system to interact with other systems (be they
> legacy or not) that share very little with it.

The web doesn't singularly provide an opportunity for loosly coupled
systems.  And, it doesn't discourage, through design time constraints,
the creation of tightly coupled services.  Good design principals must
still be used to create the right SOA architecture.  And, because of the
ease with which "more data" can be added to an XML document, it can
tremendously enable and encourage poor architectures.

> At the crossing of distributed computing and loosely coupled systems lies
> service-oriented computing, which appears to many as the next important
> step in distributed computing. When applications adopt service-oriented
> architectures, they can evolve during their lifespans more easily and
> better adapt to changing or unpredictable environments. When properly
> implemented, services can be discovered and invoked dynamically using
> non-proprietary mechanisms, while each service can still be implemented
> in a black-box manner.

Currently, every development environment and application environment for
J2EE and .NET promote and create vendor dependencies and lockin related
to the most valuable part of the SOA investment.  The communications
between different services is the most trivial part of the system.  The
value added is in the actions that the services perform and how they
interact with the host environment.  So, web services doesn't create a
'non-proprietary' architecture.  You are locked into your language of
choice already.  Your development tools and deployment servers limit and
   control your ability to scale up or down.

The use of HTTP as the communications between services directly limits
the choices of how data is exchanged and confines the choices of how
communications enhancments are made.  The fact that compression is being
design/discussed for standardization says that poor/excessive data
models are already prevalent.

The RMI programming model and the JERI stack in Jini2.0 provides choices
that allow optimization, evolutionary and revolutionary changes to occur
independantly of the clients of the service.

Web services, because of the dependency on transport protocol and data
format, lock down the choices and limit the opportunities of an SOA to
reach maturation.

Gregg Wonderly

Gregg,

If I may so observe, it looks as if you would be an ideal candidate to
speak at this conference.  I am sure you could get the Sun Jini group
to sponsor your trip!  IMHO it would be an extremely judicious way of
them to spend their marketing budget.  In fact I would suggest that
they pay for Patrick May to go along as well.

Gervas

--- In service-orientated-architecture@yahoogroups.com, Gregg Wonderly
<gergg@c...> wrote:
> Jose Carlos del Arco Prieto wrote:
> > Over a decade of experience has taught the community (researchers and
> > practitioners alike) that distributed object computing has inherent
> > problems, because of the tight coupling that is requires between
> > distant systems. First, guaranteeing interoperability and openness
> > among all objects and components in a distributed application is
> > difficult when these objects are developed by competing commercial
> > entities. Software vendors prefer to segment markets, because niche
> > markets are more lucrative than commodity markets. Second, most
> > customers need to integrate large application chunks (as opposed to
> > fine-grained objects) written by different vendors, so having
> > object-level interoperability is often unnecessary in practice.
>
> I continue to be amused by this type of characterization of distributed
> object computing.  The issues mentioned here are very specific to the
> problems that a CORBA/DCOM style computing environment creates.
>
> The lack of mobile code means that granularity must be small so that a
> service can be used from multiple places, or code must be copied
> everywhere so that granularity can be larger.  The RMI programming
model
> and Jini's use thereof removes these barriers by allowing
granularity to
> be managed remotely and to be dynamically evolved.
>
> CORBA and COM/DCOM promoted some really poor system designs.  Now,
> everyone who has experience with these systems feels like that is the
> limit of a distributed object environment. This is simply not the case.
>
> The path to web services introduces patches and band-aids to the whole
> data-only communications paradigms that CORBA etc. use.  XML provides
> the mechanism for evolving the data.  But, it does not provide the
> mechanism for improving the efficiency of the system through bandwidth
> management.
>
> XML introduces and promotes the expansion of the data path into a
> monolithic dependency of the system.  XML encourages the addition of
> data to one interface to create a new interface without providing
> separation that the interface based Java RMI programming model
> encourages.  The result can be that monolithic services swell up out of
> base services and create dependencies through coupling that can make it
> much harder to provide lightweight interfaces to existing systems for
> specific applications.
>
> > The success encountered by the Web has convinced most of the community
> > that tightly coupled software systems are only good for niche markets,
> > whereas loosely coupled software systems can be more flexible, more
> > adaptive and often more appropriate in practice. Loose coupling makes
> > it easier for a given system to interact with other systems (be they
> > legacy or not) that share very little with it.
>
> The web doesn't singularly provide an opportunity for loosly coupled
> systems.  And, it doesn't discourage, through design time constraints,
> the creation of tightly coupled services.  Good design principals must
> still be used to create the right SOA architecture.  And, because of
the
> ease with which "more data" can be added to an XML document, it can
> tremendously enable and encourage poor architectures.
>
> > At the crossing of distributed computing and loosely coupled
systems lies
> > service-oriented computing, which appears to many as the next
important
> > step in distributed computing. When applications adopt
service-oriented
> > architectures, they can evolve during their lifespans more easily and
> > better adapt to changing or unpredictable environments. When properly
> > implemented, services can be discovered and invoked dynamically using
> > non-proprietary mechanisms, while each service can still be
implemented
> > in a black-box manner.
>
> Currently, every development environment and application environment
for
> J2EE and .NET promote and create vendor dependencies and lockin related
> to the most valuable part of the SOA investment.  The communications
> between different services is the most trivial part of the system.  The
> value added is in the actions that the services perform and how they
> interact with the host environment.  So, web services doesn't create a
> 'non-proprietary' architecture.  You are locked into your language of
> choice already.  Your development tools and deployment servers limit
and
>   control your ability to scale up or down.
>
> The use of HTTP as the communications between services directly limits
> the choices of how data is exchanged and confines the choices of how
> communications enhancments are made.  The fact that compression is
being
> design/discussed for standardization says that poor/excessive data
> models are already prevalent.
>
> The RMI programming model and the JERI stack in Jini2.0 provides
choices
> that allow optimization, evolutionary and revolutionary changes to
occur
> independantly of the clients of the service.
>
> Web services, because of the dependency on transport protocol and data
> format, lock down the choices and limit the opportunities of an SOA to
> reach maturation.
>
> Gregg Wonderly

Services: Build, Buy, or Repurpose? ZapFlash

By Ronald Schmelzer
Document ID: ZAPFLASH-200553 | Document Type: ZapFlash

Smart companies approach all IT investment decisions with a three-part
question: should they buy, build, or repurpose their IT resources to
meet their emerging business needs? Such fundamental investment
questions apply to all aspects of IT, ranging from network devices to
application software to professional services needs. As a result, the
same thought processes apply to burgeoning implementations of
Service-Oriented Architecture (SOA).

However, one of the significant shifts in thinking that SOA introduces
is the notion that business logic is not engrained in programming
code, but rather in the declarative metadata that describes a Service
and how it interacts with other Services. In essence, SOA advocates a
movement away from code-centric development to configuration-centric
composition. This shift to metadata-driven development introduces new
challenges to how organizations purchase, repurpose, or develop
Services. Rather than dealing with traditional development lifecycles,
companies must now understand how to continually iterate the
development of their Services and therefore, their Service metadata as
well. Just as companies have the choice of developing applications
in-house or purchasing their IT assets from third parties, so too they
must they resolve the issue of whether to create and maintain their
Services and associated metadata themselves, repurpose them from
existing assets, or purchase them from third party suppliers.

Building Services from Scratch
When faced with an SOA mandate, the first thing that most IT
departments feel compelled to do is to start developing Service
interfaces for their existing legacy systems. But what does it mean to
"develop a Service"? There are actually two different sorts of assets
developers must deal with when building Services in an SOA: the
application logic that underlies a Service interface, and the Service
metadata themselves.

Application logic development that underlies a Service is much the
same as it has always been, with one key difference: developers should
not hard-code business process or any other business logic into the
application, but rather leave them for the metadata to handle. In an
SOA implementation, security, reliability, and transport binding
considerations should likewise be relegated to the Service interface
and policy contracts that surround a Service, rather than to its
underlying code. As such, the real kernel of functionality that
remains abstracted beneath the Service interface simply provides the
implementation that guarantees the service level agreed to in the
Service contract.

Most importantly, companies should realize that putting Service
interfaces in front of existing application logic is not all that
challenging. Since adding Service interfaces to legacy systems is
straightforward, the real development work comes from defining Service
contracts and creating the process, security, management, and other
metadata that sit on top of the Services themselves. Furthermore, this
approach to Service development is only applicable for fine-grained
Services where it's easy to control the functionality and scope of
change for those Services. Simply wrapping legacy systems with Service
interfaces is not sufficient for coarse-grained business Services.

As such, building business Services "from scratch" really means coming
up with the policies and other metadata that govern how the Services
work. In this context, it makes more sense to build such Services
in-house than to source them from third parties. While it's possible
to purchase the underlying code that makes the Service work, it's hard
to make the same case for Service metadata. Therefore, while companies
might be able to buy fine-grained Services from third-party providers,
they should look to build their own Service metadata and composite,
coarse-grained business Services.

Repurposing Services
One of the major tenets of SOA is that companies should reuse Services
as broadly as possible to support their growing and changing set of
business requirements. As such, companies should expect their
investment in Services to gradually shift over time from Service
exposure and fine-grained development to composition focused on
Service reuse. Rather than spending time and money trying to figure
out which new Services to build, companies should focus their efforts
and resources identifying existing Services in the enterprise,
composing them into new processes, and refactoring them as necessary
to support new capabilities.

Thus, the significant question that companies will be forced to
grapple with is which Services to build from scratch and which to
repurpose to meet changing needs. The answer to this question depends
upon the particular circumstances of the business and the scope of
their existing Services. Furthermore, many of the fine-grained
Services that companies will have in the early days of their SOA
projects will not be amenable to much refactoring, since they might
come from pre-packaged enterprise application suites or simple
extensions of legacy APIs.

That said, companies that have properly defined their Services in a
top-down fashion by starting with an overall architectural plan,
rather than building their SOA from the bottom up by building
fine-grained Services as legacy wrappers will be better able to
repurpose and refactor their Services for new capabilities. Therefore,
companies that develop process-driven, coarse-grained, composite
Services will find greater flexibility and ability to extract
continuing value from their Service investments. On the other hand,
companies that fail to move beyond fine-grained Services may hardly
even get the chance to think about repurposing their Services, let
alone do so successfully.

Of course, Service metadata that define security, policy, reliability
and declarative business logic for interacting with Services should be
amenable to repurposing. Companies should try their hardest to create
Service metadata once and repurpose them as many times as possible to
meet ever-changing business requirements. As such, the real
development effort here is not one of creating Services from scratch,
but rather developing from the start the most agile, flexible Services
that can be repurposed to meet new needs.

Buying Services
If companies can repurpose Services, then they can also purchase them
from third parties, as a logical extension of the basic ability to
reuse Services. In many cases, companies may find that the Services
they are using the most do indeed come from IT suppliers, rather than
their own development shops. For example, enterprise application
vendors are increasingly providing fine-grained Services for
consumption in corporate SOA implementations. However, a
business-centric, process-driven SOA composes these fine-grained
Services with other Services that may or may not come from that
technology supplier. As such, even in situations where the bulk of the
Services might come from a third-party vendor, the business logic
itself should be in the composite metadata, which the company most
likely develops from scratch in-house.

The forward-looking question is whether companies will purchase
composite, coarse-grained Services from third-party vendors. This
question actually doesn't have anything to do with technology, but
rather is one of business process outsourcing. Buying a
business-focused Service from a third-party vendor should be the same
thing as outsourcing an entire business process to that vendor. The
Service would have to be at such a level of granularity that the
actual implementation and process details are abstracted from the
consumer, and therefore, would appear to be a process the company
outsources in its entirety. As a result, companies looking at
purchasing coarse-grained Services must first think about whether or
not they want that process outsourced.

While a third party can readily supply the underlying implementation
of a Service can be readily supplied by a third-party, it's not clear
what sort of metadata can realistically be purchased from a
third-party supplier. Every company's security, reliability, process,
and management criteria will differ significantly, and as such, the
most that a company can expect from a vendor are technologies for
managing metadata or tools to simplify their creation. Therefore, the
purchasing decision for Services is only relevant for either
fine-grained Services or for processes that are outsourced in their
entirety.

The ZapThink Take
In reality, most companies will find that they have to adopt a hybrid
of all of the above approaches for their Service development and
maintenance. Existing technology vendors will pre-package a wide
variety of Services that a company will use, while other Services will
emerge when companies extend their legacy systems using in-house
resources. As companies devote more effort to developing Services,
it's clear that the one thing companies will need most of all is a
corporate memory for how they create and evolve their Services over time.

In an SOA world, it isn't sufficient for companies to make point
decisions about the Services they build, buy, or repurpose. Rather,
they must think of the architecture as a whole and how its
implementation will evolve over time. Some Services are more
economical to build in-house , not necessarily the first time around,
but as they are repurposed for future activities. Likewise,
outsourcing certain Services may be economical only in the long run.
As such, the decision to buy, build, or repurpose must also be capable
of evolving as the business changes.

<<OASIS on Tuesday is announcing the formation of a technical
committee that will develop a reference model to provide clarity on
the definition of an SOA, said Duane Nickull, chairman of the new
OASIS SOA-RM (Reference Model) Technical Committee and senior
standards strategist at Adobe. The reference model is intended for use
by developers and IT professionals as a guideline for implementing
architectures across service environments.

"This arose from the fact that SOA as a term was being used in a vast
array of contexts, sometimes with conflicting definitions of exactly
what it was," Nickull said. OASIS hopes to have its reference model
completed by the end of the year and has been working on the project
for approximately six weeks. A working draft document already has been
published.

An SOA is generally regarded as an IT architecture that links loosely
coupled services in an easily changeable fashion, usually based on Web
services integration.There has not been unanimity, however, on a
definition, OASIS acknowledged.>>

You can find this at:

http://www.infoworld.com/article/05/05/03/HNsoareference_1.html?source=rss&url=h\
ttp://www.infoworld.com/article/05/05/03/HNsoareference_1.html

Gervas

<<Standards body the Organization for the Advancement of Structured
Information Standards (OASIS) has started a committee that will seek
to provide guidance on a much-discussed software design pattern called
a service-oriented architecture.

The committee, announced Tuesday, will create a reference model for
service-oriented architectures, or SOAs, that will seek to improve the
understanding of them. "The term SOA is used in an increasing number
of contexts with differing--and even conflicting--meanings," said
Adobe Systems' Duane Nickull, who is also a chair of the OASIS SOA-RM
Technical Committee. In general, an SOA is a method of designing
applications so that individual programs can be used in different
scenarios. A network authentication process, for example, could be
used by many departments within a company. Software companies and
corporate customers are incorporating an SOA design in business
applications to provide a more flexible and cost-effective software
infrastructure.>>

You can read this at:
http://news.zdnet.com/2110-3513_22-5694070.html?tag=zdnn.alert

Gervas

--- In service-orientated-architecture@yahoogroups.com, Anne Thomas
Manes <atmanes@g...> wrote:
> Good question. It depends on the tooling you have available.

What I'm hearing is that there is no standard "batch upload" facility
for UDDI; hence vendors will use this as a differentiating feature. No
big deal - but something the OASIS people are probably kicking around.

The second concern would be how to batch upload entries according to a
predefined taxonomy that is internal to the organization. I guess
you'd have to have some tool prompt you for each entry and identify if
the entry was superceding a prior entry (ick).

My guess is that the SAP's of the world will just package their
platform with a pre-populated UDDI registry. Then, you have the option
of replicating their UDDI instance to the "UDDI system of record" or
just doing federated queries. Thoughts?
Jeff

You are correct. The UDDI spec doesn't specify a batch load utility.
One of the core principles of the UDDI-spec technical committee (TC)
is that the core spec shouldn't define usability information -- it
only defines normative behavior. All usability information is defined
in separate technical notes (such as the "Using WSDL in a UDDI
Registry" technical note). The TC has define 3 technical notes
regarding the creation, management, and versioning of user defined
taxonomies (now called "value sets" in V3). Right now they're working
on a set of security related technical notes. I don't recall the TC
discussing batch load processing (but I'm not nearly as involved in
the TC as I once was). If you think it's an important topic for a
technical note, send a note to the uddi-spec-comment list.

It's possible that SAP and other application vendors may provide a
prepopulated registry, but the challenge with this approach is that it
doesn't give the customer the ability to model its organizations --
you want to be able to indication which organization offers which set
of services. Perhaps they might want to provide a registry that's
prepopulated with tModels, but I think the company will want to
register their own businesses, services, and binding templates. I
think it's more likely that the app vendors will provide a batch of
SOAP messages which can be processed by any registry.

Any UDDI registry can process a batch of UDDI SOAP messages. No
additional specification or technical note is required to enable this
much.

As far as enabling batch loading when using custom value sets -- if I
were doing it, I would write my own utility. First, I'd annotate my
WSDLs with the value set information, then extend a wsdl2uddi utility
to automatically map the WSDL annotations to catagory bags. You might
take a look at what LogicLibrary has done. They can capture any
properties they've captured in Logidex and map it to UDDI. Currently
they use the general_categories taxonomy to map the properties, but I
suspect it's customizable.

Anne

On 5/5/05, jeffrschneider <jeffrschneider@...> wrote:
> --- In service-orientated-architecture@yahoogroups.com, Anne Thomas
> Manes <atmanes@g...> wrote:
> > Good question. It depends on the tooling you have available.
>
> What I'm hearing is that there is no standard "batch upload" facility
> for UDDI; hence vendors will use this as a differentiating feature. No
> big deal - but something the OASIS people are probably kicking around.
>
> The second concern would be how to batch upload entries according to a
> predefined taxonomy that is internal to the organization. I guess
> you'd have to have some tool prompt you for each entry and identify if
> the entry was superceding a prior entry (ick).
>
> My guess is that the SAP's of the world will just package their
> platform with a pre-populated UDDI registry. Then, you have the option
> of replicating their UDDI instance to the "UDDI system of record" or
> just doing federated queries. Thoughts?
> Jeff
>
>
> Yahoo! Groups Links
>
>
>
>

There is a BPM Conferene coming up in London (the one in England, not
Ontario), details of which you can find at the link below:






http://groups.yahoo.com/group/business-process-management/message/102

Gervas

<<Fast forward to 2004, and emerging, SOA-based SAP or Oracle
applications still consists of a complex mass of intertwined
connections, but now, the major difference is these interconnections
are more finely grained, and easier to connect or remove. They are
less of a Gordian knot of hard-coded proprietary APIs and more like an
electronic patch-board or hub, with each virtual plug identically
shaped into a message-based, Web service. For example, many SAP
application features can now be presented via Web services interfaces
because the vendor has catalogued over 1,000 services that will be
accessed and combined with others. The first services that will soon
be published soon are commonly used tasks already in the SAP system,
such as a financial program for tracking the time between a purchase
order receipt and actual payment.

Over time, SAP intends to publish more of these services. It is also
building an enterprise services repository (ESR) to serve as the
central repository (equivalent to a data dictionary for traditional
applications) and used by third parties. There are several dozens
message-based services available now, including purchase order
requisition, purchase order confirmation, purchase order change
request, and so on. Depending on the level of granularity required,
there could, in the long run, be more than 10,000 services in the
repository.

For most SAP and Oracle customers, this hub will be SAP NetWeaver and
Oracle Application Server 10g with a few upcoming data integration
hubs respectively, while others might use counterpart third-party
products, such as IBM WebSphere, BEA Systems' WebLogic or IONA Artix,
or on open-source platform, such as JBoss. (For more information, on
SAP and Oracle, see SAP Bolsters NetWeaver's MDM Capabilities and
Oracle Further Orchestrates Its SOA Forays)

SOA has the promise of interoperability in an increasingly global and
heterogeneous business world by promoting loosely-coupled architecture
and the non-intrusive reuse of software components. Such a move should
do away with user dependency on vendors for enterprise applications
and also allow these applications to communicate in near real-time.
Nevertheless, before it can all work, the likes of SAP and Oracle, for
instance, must first open up, redesign, and expose the hundreds of
application functions as services. This will be a multi-year project
that it is, at best, only halfway completed. Also, for customers, who
have customized these product instances, and added additional custom
functions and third-party programs, it will also be difficult.>>

You can find this article at:

http://www.technologyevaluation.com/Research/ResearchHighlights/Erp/2005/05/rese\
arch_notes/TU_ER_XOT_05_06_05_1.asp?id=81.2005.05.06.2966&e=gervasdouglas%2Cyaho\
o.co.uk

Gervas

<<A source in IBM's Hursley, UK software labs - which are responsible
for much of the WebSphere integration software development - said in
an interview with ComputerWire that, "We are actively looking at this
space to see whether for some requirements, something actually labeled
WebSphere ESB is a requirement, or if our approach is to say that we
can build something out of the technologies we already have."

Asked whether a possible WebSphere ESB would be a brand new product or
merely a rebranding of existing functionality within the broad
WebSphere suite, the source said: "I can't disclose future product
plans in exacting detail. I can say that we are working with the
market and customers to see what works best for them."

While IBM has started to use the term ESB when describing the
capabilities of WebSphere MQ Series 6, it is debatable whether it
satisfies all of the requirements of an ESB. For example analysts have
said it lacks features such as a repository and certain smart routing
capabilities that buses should provide, though these could potentially
be handled by other components in IBM's WebSphere portfolio.>>

Hmm.  Interesting development.  Anyone got any intelligence on this
one??  You can find the story at:

http://www.cbronline.com/article_news.asp?guid=44400A8C-8E88-48F4-95BD-90E60E545\
39E

Gervas

IBM currently markets ESB as a set of "architectural patterns" --
basically a refinement of SOA patterns. They market an ESB solution,
which includes WebSphere MQ and WebSphere Business Integration (WBI)
Message Broker.I suspect that sales people are finding the simplicity
of the Sonic ESB solution to be disruptive competition, and they are
asking the product people to give them a simpler, easier solution to
sell.

In the long run, though, I think the whole question is moot, because
the next version of WebSphere Application Server will include built-in
ESB functionality. Why buy a separate ESB product when you already
have the functionality in your app server?

(As I've said before, the ESB market is transitory, and it will fade
from relevancy within a couple of years.)

Anne

On 5/9/05, Gervas Douglas <gervasdouglas@...> wrote:
> <<A source in IBM's Hursley, UK software labs - which are responsible
> for much of the WebSphere integration software development - said in
> an interview with ComputerWire that, "We are actively looking at this
> space to see whether for some requirements, something actually labeled
> WebSphere ESB is a requirement, or if our approach is to say that we
> can build something out of the technologies we already have."
>
> Asked whether a possible WebSphere ESB would be a brand new product or
> merely a rebranding of existing functionality within the broad
> WebSphere suite, the source said: "I can't disclose future product
> plans in exacting detail. I can say that we are working with the
> market and customers to see what works best for them."
>
> While IBM has started to use the term ESB when describing the
> capabilities of WebSphere MQ Series 6, it is debatable whether it
> satisfies all of the requirements of an ESB. For example analysts have
> said it lacks features such as a repository and certain smart routing
> capabilities that buses should provide, though these could potentially
> be handled by other components in IBM's WebSphere portfolio.>>
>
> Hmm.  Interesting development.  Anyone got any intelligence on this
> one??  You can find the story at:
>
>
http://www.cbronline.com/article_news.asp?guid=44400A8C-8E88-48F4-95BD-90E60E545\
39E
>
> Gervas
>
>
> Yahoo! Groups Links
>
>
>
>
>

Anne,

--- Anne Thomas Manes <atmanes@...> wrote:
> (As I've said before, the ESB market is transitory,
> and it will fade
> from relevancy within a couple of years.)
>
While I agree that simplicity (ease of development/
deployment/loosely coupled process composition) of ESB
products is what is making it a hot pick today - I
fail to understand your stand on "ESB being
transitionary". You seem to be advocating "everything
inside your app-server" theory which has obvious
pitfalls. I think this is a usual mistake which most
graduating technologies make at some stage. Last
example I can think off was when Oracle tried building
entire app-server stack inside their DB engine itself.

ESBs are not a feature extension of app-servers. They
are a different way of going about distributed
business process composition and it can be argued that
an app-server model is not the best suited model for
such distributed event processes.

Thanks,
Amit Gupta
amitg@...
www.fiorano.com




Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html

WS and SOA need to accommodate legacy systems if they are to have
practical value.  I have just come across a guide to vendors who
supply technologies to Web-enable iSeries (AS/400) systems.  I guess
that won't necessarily provide you with a complete solution, although
I am sure many of these vendors will be happy to lead you further down
the path.  You can find this guide at:




http://search400.techtarget.com/originalContent/0,289142,sid3_gci1085538,00.html

Gervas

-----Original Message-----
From: service-orientated-architecture@yahoogroups.com [mailto:service-orientated-architecture@yahoogroups.com]On Behalf Of Gervas Douglas
Sent: 09 May 2005 11:32
To: service-orientated-architecture@yahoogroups.com
Subject: [service-orientated-architecture] WebSphere ESB??

<<A source in IBM's Hursley, UK software labs - which are responsible
for much of the WebSphere integration software development - said in
an interview with ComputerWire that, "We are actively looking at this
space to see whether for some requirements, something actually labeled
WebSphere ESB is a requirement, or if our approach is to say that we
can build something out of the technologies we already have."

Asked whether a possible WebSphere ESB would be a brand new product or
merely a rebranding of existing functionality within the broad
WebSphere suite, the source said: "I can't disclose future product
plans in exacting detail. I can say that we are working with the
market and customers to see what works best for them."

While IBM has started to use the term ESB when describing the
capabilities of WebSphere MQ Series 6, it is debatable whether it
satisfies all of the requirements of an ESB. For example analysts have
said it lacks features such as a repository and certain smart routing
capabilities that buses should provide, though these could potentially
be handled by other components in IBM's WebSphere portfolio.>>

Hmm.  Interesting development.  Anyone got any intelligence on this
one??  You can find the story at:

http://www.cbronline.com/article_news.asp?guid=44400A8C-8E88-48F4-95BD-90E60E54539E

Gervas

Thanks to you all, this Group has now grown to about 780 members.  I
suspect it is one of the better quality SOA usergroups on the Internet
in terms of membership and quality of traffic.  I also suspect that we
have more than a handful of members in the UK where I live.  I have
discussed with a couple of members living in England the possibility
of holding an inaugural, albeit informal meeting in Southern England.

Central London, perhaps coinciding with a trade event which brings you
to the same locality would seem a potentially convenient choice of
location (if anything to do with travelling to and within London can
be described as convenient.)

Any one interested?  Any thoughts?

Yes, we would consider a commercial sponsor or merely someone who
could kindly lend a room.  Failing the latter, a large pub might do.

Gervas
Moderator

Annie, it is a good observation. IBM is implementing ESB as an
extendable framework in the new WebSphere application server. I have
attended a session at IBM and it was interesting to see how the ESB
pattern is being incorporated into the application server. For
example, WebSpehere v6 has the base ESB elements already in place.
This is built on three basic elements in the app server - service
bus, destination and mediator. They have also implemented a new JMS
based messaging engine (not MQ package) into the base app server.
The service buses can also be distributed and bus to bus
communication is easily configured. It is also easy to configure the
bus in a clustered environment where a cluster can be a member of
the service bus. These capabilities are already in the WebSphere app
server version 6. However, this version of WebSphere misses one
element - i.e. BPEL engine. For this, IBM is has higher level
product named WBI (WebSpehere business integartion). This product
includes everything the base WebSphere v6 has and the BPEL engine
for business process implementation. There are tools being built
around these to simplify development and deployment - the obvious
one being IBM's WBI modeler. This tool is interesting in that you
model business process with all details and export process artifacts
as BPEL, WSDL and XSD files. Which then imported into other
development tool for actual service integration, implementation and
package for deployment.

Other areas IBM may get into is in the service management area
including end-to-end service monitoring.

Note - I am not from IBM and this is purely my personal observation -
  I am equaly interested and watching implementations from other
vendors. My interest is around looking at how new technologies and
concepts may impact the larger enterprise - interprise architecture.

Regards,
Awel

--- In service-orientated-architecture@yahoogroups.com, Anne Thomas
Manes <atmanes@g...> wrote:
> IBM currently markets ESB as a set of "architectural patterns" --
> basically a refinement of SOA patterns. They market an ESB
solution,
> which includes WebSphere MQ and WebSphere Business Integration
(WBI)
> Message Broker.I suspect that sales people are finding the
simplicity
> of the Sonic ESB solution to be disruptive competition, and they
are
> asking the product people to give them a simpler, easier solution
to
> sell.
>
> In the long run, though, I think the whole question is moot,
because
> the next version of WebSphere Application Server will include
built-in
> ESB functionality. Why buy a separate ESB product when you already
> have the functionality in your app server?
>
> (As I've said before, the ESB market is transitory, and it will
fade
> from relevancy within a couple of years.)
>
> Anne
>
> On 5/9/05, Gervas Douglas <gervasdouglas@y...> wrote:
> > <<A source in IBM's Hursley, UK software labs - which are
responsible
> > for much of the WebSphere integration software development -
said in
> > an interview with ComputerWire that, "We are actively looking at
this
> > space to see whether for some requirements, something actually
labeled
> > WebSphere ESB is a requirement, or if our approach is to say
that we
> > can build something out of the technologies we already have."
> >
> > Asked whether a possible WebSphere ESB would be a brand new
product or
> > merely a rebranding of existing functionality within the broad
> > WebSphere suite, the source said: "I can't disclose future
product
> > plans in exacting detail. I can say that we are working with the
> > market and customers to see what works best for them."
> >
> > While IBM has started to use the term ESB when describing the
> > capabilities of WebSphere MQ Series 6, it is debatable whether it
> > satisfies all of the requirements of an ESB. For example
analysts have
> > said it lacks features such as a repository and certain smart
routing
> > capabilities that buses should provide, though these could
potentially
> > be handled by other components in IBM's WebSphere portfolio.>>
> >
> > Hmm.  Interesting development.  Anyone got any intelligence on
this
> > one??  You can find the story at:
> >
> > http://www.cbronline.com/article_news.asp?guid=44400A8C-8E88-
48F4-95BD-90E60E54539E
> >
> > Gervas
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >

Folks

I am from IBM. If you want more information about the WebSphere v6.0
integration capabilities this series of articles is probably the best
starting point:

http://www-128.ibm.com/developerworks/websphere/techjournal/0501_reinitz/0501_re\
initz.html

Paul

<<As we look at the current business climate, stiff competition and
the demand for near real-time access to the state of the business is
now driving the need to map software solutions across a complex maze
of enterprise systems. The challenge, however, is to link these
islands of data, in a mission critical manner that avoids breakage
through customization or changes.

As we all know, a large-scale swap of legacy systems for new systems
is not a viable option. So, the real choice is to extend what is in
place by applying new technologies that can provide the benefits of a
modular system.

As we look at some of the emerging technologies, there are several
likely candidates that will help ease this transition. It will not be
one technology, but the application of several new technologies—taken
together—to create an environment that is more flexible. Among the
core ones are Web services, XML and a growing list of interop
standards from IBM, Microsoft, BEA and others.

But, there is another piece of the puzzle, the ESB, which looks to
provide needed manageability and visibility to these service-driven
integrations.

In simple terms, the ESB provides the management layer to tie all of
these services together in a standard way. The resulting marriage of
ESB, Web services, XML and WS standards now provides the ability to
leverage the various Web services, talking to our legacy systems and
former islands of data, and expose them in a way that allows
aggregation and roll-up of information that can then be delivered
inside a management console.>>

You can find this at:

http://www.ebizq.net/hot_topics/esb/features/5877.html

Gervas

<<Aiming to provide some of this firepower, the OASIS WS-Security
standard defines how to use XML encryption and XML digital signatures,
and provides a framework for using various security profiles such as
Security Assertion Markup Language (SAML), X.509 and Kerberos, inside
SOAP headers.

Members of the WS-Security technical committee marked the first
anniversary of the standard last month with an interoperability
showcase in which 14 vendors demonstrated the exchange of messages
protected by WS-Security using X.509 certificates.

"WS-Security is a foundational standard for many other standards, but
it doesn't quite do everything," Wagner said. To establish trust in
terms of hand-shaking between organizations, "we still need lawyers
and CEOs playing golf," he said.

Although WS-Security doesn't provide things like automated policy
agreement, arbitration or policy representation, there are other
standards-in-progress aimed at addressing these needs, such as
WS-Federation, WS-SecurityPolicy, WS-Trust and others.

"The standards are a little ahead of the game," said Paul Lipton,
senior architect at Computer Associates International Inc. "When you
get into [WS-] Federation, it gets a little esoteric."

People are waiting for some of the parallel security standards to
coalesce and tools just aren't there yet in terms of security
standards support, Lipton said.

Security and management coalesce

Gartner predicts that by year-end, vendors will offer a single,
policy-based Web services product encompassing security and management
functionalities.

"I advocate the use of a security layer separate from the
application," Wagner said. "A management layer that sits between [IT]
and the business unit solves the problem of having security policies
for every department, development team and environment."

Last fall, the industry saw rapid consolidation in the management and
security spaces as Digital Evolution Inc. (now known as SOA Software
Inc.) acquired Flamenco Networks Inc., Computer Associates
International Inc. purchased Netegrity Inc. and Actional Corp. merged
with Westbridge Technology.>>

You can find this at:

http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci108666\
7,00.html?track=NL-110&ad=512185HOUSE

Gervas

Gervas Douglas wrote:
> But, there is another piece of the puzzle, the ESB, which looks to
> provide needed manageability and visibility to these service-driven
> integrations.
>
> In simple terms, the ESB provides the management layer to tie all of
> these services together in a standard way. The resulting marriage of
> ESB, Web services, XML and WS standards now provides the ability to
> leverage the various Web services, talking to our legacy systems and
> former islands of data, and expose them in a way that allows
> aggregation and roll-up of information that can then be delivered
> inside a management console.>>

One of the most interesting issues in Web services, for me, is that WS*
standards and SOAP are supposed to provide the vendor neutralization
that enables isolation and integration of arbitrary technologies into
your enterprise systems.

Adding an ESB as some form of management system further demonstrates the
interlocking and proliferation of the implementation requirements into
all parts of the system.  This will further anchor applications into a
very specific technology with limitations associated with that
technologies implementation.

Jini's use of the RMI programming model allows code to dynamically
follow an services remote interface/implementation.  One of the ways
dynamic programming is utilized is through the serviceUI mechanism.  The
inclusion of the string "UI" in serviceUI might cause one to think GUI,
but it really is more than that.  It is another layer of abstraction to
allow for a particular role to have customized interfaces for service
integration and management.  One of those roles might be GUI based.
But, other roles can be simple service interface recasting and/or
integration.

The serviceUI mechanism uses downloaded factories to create new objects
for particular roles.  These service registration entries allow the
service to be integrated into new roles in the enterprise.

Each serviceUI descriptor can be attached to the service registration
after the fact so that a vendors service can be extended to include new
interfaces for a particular role of the service in the enterprise.

What I see happening with ESB is less opportunity for vendor
independence and more opportunity for lock-in.  This is because the
standards don't include the right kind of technologies, or so it seems
to me, to provide flexibility in implementation and integration with
varying technologies.  New technologies will develop over time both
through standardization processes and through independent needs and
opportunities in the market place.

It sure seems to me that the WS* standards are going to provide a lot of
restrictions on what can happen, and ESB will likely add another layer
of dependency that will further lock down the choices.

Gregg Wonderly

> Agree with you 100%. Application Servers are better
> development platforms but not deployment platforms.
> Develop your service on App Server and deploy
> on a ...?
>
ESB.

Thanks,
Amit Gupta
amitg@...


--- Vikas Deolaliker <vikasd@...> wrote:
>
>
> Amit,
>
>
>
> Agree with you 100%. Application Servers are better
> development platforms
> but not deployment platforms. Develop your service
> on App Server and deploy
> on a ...?
>
>
>
> Vikas
>
>
>
>
>
>   _____
>
> From:
> service-orientated-architecture@yahoogroups.com
>
[mailto:service-orientated-architecture@yahoogroups.com]
> On Behalf Of Amit
> Gupta
> Sent: Monday, May 09, 2005 5:03 AM
> To: service-orientated-architecture@yahoogroups.com
> Subject: Re: [service-orientated-architecture]
> WebSphere ESB??
>
>
>
> Anne,
>
> --- Anne Thomas Manes <atmanes@...> wrote:
> > (As I've said before, the ESB market is
> transitory,
> > and it will fade
> > from relevancy within a couple of years.)
> >
> While I agree that simplicity (ease of development/
> deployment/loosely coupled process composition) of
> ESB
> products is what is making it a hot pick today - I
> fail to understand your stand on "ESB being
> transitionary". You seem to be advocating
> "everything
> inside your app-server" theory which has obvious
> pitfalls. I think this is a usual mistake which most
> graduating technologies make at some stage. Last
> example I can think off was when Oracle tried
> building
> entire app-server stack inside their DB engine
> itself.
>
> ESBs are not a feature extension of app-servers.
> They
> are a different way of going about distributed
> business process composition and it can be argued
> that
> an app-server model is not the best suited model for
> such distributed event processes.
>
> Thanks,
> Amit Gupta
> amitg@...
> www.fiorano.com
>
>
>
>
> Yahoo! Mail
> Stay connected, organized, and protected. Take the
> tour:
> http://tour.mail.yahoo.com/mailtour.html
>
>
>
>
>
>
>   _____
>
> Yahoo! Groups Links
>
> * To visit your group on the web, go to:
>
http://groups.yahoo.com/group/service-orientated-architecture/
>
> * To unsubscribe from this group, send an email to:
>
service-orientated-architecture-unsubscribe@yahoogroups.com
>
<mailto:service-orientated-architecture-unsubscribe@yahoogroups.com?subject=
> Unsubscribe>
>
> * Your use of Yahoo! Groups is subject to the Yahoo!
> <http://docs.yahoo.com/info/terms/>  Terms of
> Service.
>
>



Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html

There are a couple of threads in my N-GAA Group which you might find
of interest:





http://groups.yahoo.com/group/n-gaa/message/499

and

http://groups.yahoo.com/group/n-gaa/message/496

Gervas

<<Architecting a robust SOA is an involved process that needs to take
into account a plethora of considerations. Many of these concern the
design of the services themselves. I discussed eight such
considerations in the aforementioned series of two articles. However,
there are other considerations in an SOA that are not directly related
to the services; rather they focus on the lower-level plumbing that
makes these services available to their clients. Consider, as an
example, that you have very diligently and painstakingly identified
the correct business services that perfectly align your SOA with the
business. Furthermore, for each identified service you have defined
the input and output contract that will enforce the semantics of how
clients will use your service. Finally, you implement your services in
the technology of your choice, such as Java or .NET Web Services. If,
at this point you think you are done, then you are wrong. In fact,
this is the stage where the most serious problems often begin. For
example, at this stage how does your SOA fare with the following
questions?

-Can your clients find your services without having to know the
details of your deployment?

-Can clients securely exchange confidential information with your
services?

-Can your SOA meet its contractual obligations regarding availability,
reliability, and response time?

-Can your SOA scale to meet the peal client load and still perform
within contracted guidelines?

-Can your SOA support evolving standards and technologies?

-Can your SOA be expanded to support clients with different
connectivity and data format requirements?

The bad news is that all of these questions need to be answered. The
good news is that you're not alone in having to answer them. Better
yet, you don't have to architect, design, and implement the answers to
these questions from scratch.

ESB to the rescue An ESB is the term applied to the combined
infrastructure (or middleware) for building an SOA that can answer all
the above questions affirmatively. In other words an ESB serves as the
backbone for an SOA implementation. It fulfills many of the
"architecture" requirements of an SOA.

To the casual observer, an ESB may look very similar to an EAI broker
or a glorified message queue. This similarity is not coincidental
since there is significant overlap in the services provided by all
three of them. They all provide connectivity and application adapters,
complex content- and rules-based message routing and transformation
capabilities, and allow for all of the "ilities" (such as reliability,
scalability, availability, etc.) within your solution.>>

You can find this at:

http://www.webservicespipeline.com/160503220

Gervas

I believe this kind of utilities should remain out of the scope of the
UDDI specification.

Anyway, Systinet Registry provides for export/import of taxonomies (we
use our own proprietary taxonomy schema and we are considering owl for
future). The registry can also import/export uddi data - this can be
used for batch processing - but this feature is not documented and it
is used by our professional services only. In 6.0 (June) we will open
this api as well.

Cheers,
Radovan

Radovan Janecek, VP of Engineering
Systinet Corporation
http://www.systinet.com
http://radovanjanecek.net/blog


On 5/5/05, Anne Thomas Manes <atmanes@...> wrote:
> You are correct. The UDDI spec doesn't specify a batch load utility.
> One of the core principles of the UDDI-spec technical committee (TC)
> is that the core spec shouldn't define usability information -- it
> only defines normative behavior. All usability information is defined
> in separate technical notes (such as the "Using WSDL in a UDDI
> Registry" technical note). The TC has define 3 technical notes
> regarding the creation, management, and versioning of user defined
> taxonomies (now called "value sets" in V3). Right now they're working
> on a set of security related technical notes. I don't recall the TC
> discussing batch load processing (but I'm not nearly as involved in
> the TC as I once was). If you think it's an important topic for a
> technical note, send a note to the uddi-spec-comment list.
>
> It's possible that SAP and other application vendors may provide a
> prepopulated registry, but the challenge with this approach is that it
> doesn't give the customer the ability to model its organizations --
> you want to be able to indication which organization offers which set
> of services. Perhaps they might want to provide a registry that's
> prepopulated with tModels, but I think the company will want to
> register their own businesses, services, and binding templates. I
> think it's more likely that the app vendors will provide a batch of
> SOAP messages which can be processed by any registry.
>
> Any UDDI registry can process a batch of UDDI SOAP messages. No
> additional specification or technical note is required to enable this
> much.
>
> As far as enabling batch loading when using custom value sets -- if I
> were doing it, I would write my own utility. First, I'd annotate my
> WSDLs with the value set information, then extend a wsdl2uddi utility
> to automatically map the WSDL annotations to catagory bags. You might
> take a look at what LogicLibrary has done. They can capture any
> properties they've captured in Logidex and map it to UDDI. Currently
> they use the general_categories taxonomy to map the properties, but I
> suspect it's customizable.
>
> Anne
>
>
> On 5/5/05, jeffrschneider <jeffrschneider@...> wrote:
> > --- In service-orientated-architecture@yahoogroups.com,
> Anne Thomas
> > Manes <atmanes@g...> wrote:
> > > Good question. It depends on the tooling you have available.
> >
> > What I'm hearing is that there is no standard "batch upload" facility
> > for UDDI; hence vendors will use this as a differentiating feature. No
> > big deal - but something the OASIS people are probably kicking around.
> >
> > The second concern would be how to batch upload entries according to a
> > predefined taxonomy that is internal to the organization. I guess
> > you'd have to have some tool prompt you for each entry and identify if
> > the entry was superceding a prior entry (ick).
> >
> > My guess is that the SAP's of the world will just package their
> > platform with a pre-populated UDDI registry. Then, you have the option
> > of replicating their UDDI instance to the "UDDI system of record" or
> > just doing federated queries. Thoughts?
> > Jeff
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
> ________________________________
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/service-orientated-architecture/
>
> To unsubscribe from this group, send an email to:
> service-orientated-architecture-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


--
Radovan Janecek
http://radovanjanecek.net/blog

<<There are two primary camps where Web services are concerned. One
camp firmly believes that there are essentially no differences between
Web services and distributed objects while the other camp could not
disagree more strongly. As with most other polarizing issues (such as
J2EE vs. .NET and man's influence on global warming) the truth lies
somewhere in between.

In a recent article titled SOA: Debunking 3 Common Myths, I asserted
that Web services and services in general (as in a service-oriented
architecture or SOA) are not object-oriented. So the obvious question
is: Am I contradicting myself when I take the position that web
services and distributed objects have more similarities than some
would like to concede?

The answer is a resounding no -- and here's why:

All of us will agree that SOA is the direct successor to
object-oriented (OO) and component-based programming. Consequently,
most developers, designers, and architects have carried over their OO
skills into the SOA world. Many of these skills, such as the use of
software modeling tools, are equally valuable in the SOA world. At the
same time, this carry over of skills has not been without its
shortcomings. Understanding why this is so is key to comprehending why
Web services are not object-oriented. Objects in an OO world have
state and behavior and are accessed via a number of fine-grained
methods. I refer to such objects as "traditional" objects. Traditional
objects work well for smaller systems. They also work well for larger
systems deployed on a single machine or spread across a few machines
in a very fast intranet. Unfortunately, most real-world systems do not
always fall neatly into one of the former categories. Rather, most
real-world (enterprise class) systems are distributed over multiple
machines (or a farm of machines) and accessed by remote clients over
networks with varying network speeds and bandwidth. Objects in such
systems are referred to as distributed objects and must be architected
differently than traditional objects. In fact, there are two major
problems with architecting distributed objects as traditional objects. >>

You can read this article at:

http://www.webservicespipeline.com/57704023

Gervas

I am organizing the Javapolis 2005 conference
http://www.javapolis.com/confluence/display/JP05/Home
It will happen in Antwerpen, Belgium, 3 hours of Eurostar away from
London in December 2005.
We can offer you the infrastructure to hold the first (or next) SOA
group meeting including a big-enough room with all the necessary stuff.

We expect additional 1800 people during this 5-day event which is the
biggest Java event in Europe.

We are also currently searching for speakers for topics related to
SOA. We select only non-commercial presentations.
Anyone interested can contact me directly by E-mail robin at mulkers
dot net