Jeff Tonkel of Infravio recently pointed out the importance of the registry in a service oriented architecture. I'd like to second that thought. While I'm at it, I'll go so far as to state my opinion on who is leading in the space.
For starters, you have to look at BlueTitan. These guys get one real simple fact - you don't implement a registry for the sake of having a registry. Many vendors wrote a registry and encouraged their customers to dump crap in it. Bad idea. BlueTitan took the other approach - they started with the 'ilities' and worked backwards into the metadata that needed to be captured to manage a service network. Their registry is designed to capture only 'usable' metadata (actionable information); don't store anything that can't be used. Also they focused on the needs of enterprise grade service networks, the people with the really hard problems. I'm thrilled to see BlueTitan recognize that services are often just 'bumps on the network', that policies are 'service oriented aspects' and that the metadata and registry are the heart of making it functionally scalable. Most networks grow exponentially for some period of time; BlueTitan makes it possible to manage high growth networks on a linear cost scale.
After BlueTitan, you have to look at Systinet. Although these guys started with a strong UDDI slant, I believe they not only understand the limitations of UDDI, but are well on their way to overcoming the issues. I anticipate that Systinet will also have strong 'developer-side' integration into the registry (think reusable assets).
The registry is quickly turning into the 'metadata warehouse' - it is the point where a 'metadata driven architecture' and the 'service oriented architecture' merge. Architects are slowly figuring out that an important aspect of the SOA is the ability to factor the ilities out of applications. The registry is key to facilitating this movement.
Saturday, October 30, 2004
Friday, October 22, 2004
The AToM Splits Definition
The AToM, Anne Thomas Manes, took the time to mark up some definitions of SOA. I love it. Four things I'd change:
1. Services don't have to be 'autonomous'
2. Services don't have to be used for 'business'
3. In many cases services shouldn't be designed for 'reuse'
4. In many cases services won't be 'discovered'
Thus, try not to use those four words in the definition.
Posted on the soa news group...
===============================================
SearchWebServices asked this group of people to provide 50 word descriptions
of SOA. It's very hard to describe SOA in just 50 words (and obviously some
folks ignored the 50 word limit). You simply can't describe the tenets of
SOA so succinctly. Burton Group recently published a 22 page report
describing SOA, which I think does a much better job than any of these short
descriptions. I could easily write an entire book on the topic.
In my description, I endeavored to convey two of what I consider to be the
three major tenets of SOA: application factoring and abstraction, although I
was not able to convey the multiple aspects of these two tenets. I was also
not able to convey the third tenet: the requirement for standard protocols
for description, discovery, and communication.
Please see my comments below bracketed by ::atm::::/atm::.
-----Original Message-----
From: Gervas Douglas [mailto:gervasdouglas@yahoo.co.uk]
Sent: Thursday, October 21, 2004 12:53 PM
To: service-orientated-architecture@yahoogroups.com
Subject: [service-orientated-architecture] Re: Definition of SOA
Here are some definitions provided by SearchWebServices:
::::-------------------------------------------------------------------
-------------
"SOA is a framework enabling application functionality to be
provided, discovered and consumed as re-usable Web Services sets.
While Web Services do not equal SOA, it's one of the enabling
standards. SOA abstracts complexity and implementation details,
making it an ideal architectural mindset to leverage functionality
trapped within mainframe/midrange systems."
Scott Rosenbloom is chief strategist with WRQ Inc.
::atm:: SOA is an architecture -- not a framework. It is a style of design --
not a tool. On the other hand, "web services" is a framework -- a set of
tools (middleware) to help you implement applications and systems that
adhere to SOA design principles. (Although note that building applications
using the web services framework does not guarantee SOA.) SOA requires
standard protocols for description, discovery, and communication. The web
services framework standards define these standard protocols --
XMLSchema/WSDL, UDDI, and SOAP respectively, at a fundamental level,
although these core standards are not sufficient to support all SOA
requirements (secure, reliable, transacted applications supporting diverse
message exchange patterns) -- hence the ongoing effort to develop the WS-*
standards.
From my perspective, the best way to describe SOA is in terms of design
principles. Abstraction is one of the core tenets of SOA -- abstraction
between the interface and the implementation, and abstraction between
infrastructure and business logic. WSDL facilitates the first, and SOAP
facilitates the second. Another core tenet is proper application
functionality factoring. What granularity should a service have to best
enable reusability? I think this is the most challenging aspect of SOA. My
rule of thumb is that a service should represent a business task. But it's
hard to quantify this rule. ::/atm::
---------------------------------------------------------------------
-----------
"Secure, integrated delivery of IT solutions meeting business
requirements. Solutions must implement, optimize and guide business
process execution by combining the functionality of separate,
discreet, reusable services. SOA moves away from complex application
development, promoting a focus on standardizing interfaces between
atomic service components with centralized management and
distributed implementation."
Dave Morris, I.T. Security Lead TransAlta Corp.
::atm:: For the most part, I don't think this definition helps explain what
SOA means, but I like that fact that he associates SOA with "centralized
management and distributed implementation". As I said in my response to the
first definition, one of the core tenets of SOA is the requirement for
abstraction between infrastructure and business logic. Via the separation of
the SOAP Header from the SOAP Body, and via the requirements of the SOAP
processing model, SOAP enables the clean separation of infrastructure from
business logic. It permits developers to externalize most, if not all,
infrastructure functionality to the middleware. This feature enables
centralized management of the distributed implementation. ::/atm::
---------------------------------------------------------------------
-----------
"The SOA models the business as a collection of self-contained
services that are available across the enterprise that can be evoked
through standard protocols both internally and externally."
Dave McComb, president, Semantic Arts
::atm:: An accurate description, but it doesn't give you any real information
to work with. ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture is nothing but business oriented
architecture, which allows the flexibility of business applications,
to become independent but collaborative, while providing their
services. The applications under this architecture are both 'client'
and 'server' at the same time with freely available services."
Satheesan Kunnel, USWWI
::atm:: While it's definitely a brilliant idea to align IT with business, I
don't think this definition helps you figure out how to do so. ::/atm::
---------------------------------------------------------------------
-----------
"A service oriented architecture is an approach to design and
integrate software in a modular method where each module is
precisely a 'loosely coupled service' that is accessible over a
network and has the capability of being dynamically integrated with
other services at run time. A service must present a standard
Interface (be it WSDL today) for its functionality and invocation
methods while the real implementation of the service is not a
concern of an SOA."
Rajesh Dawar
::atm:: I like this definition, although I'd like to see a little more
definition of what a "precisely" loosely coupled service is. From my
perspective, the standard communication protocol has equal importance to the
standard description protocol, although this definition obviously gives more
weight to the description language. I also view XML Schema as equal weight
to WSDL. Again note that SOA does not require XML Schema, WSDL, and SOAP
specifically, but it does require that applications rely on a set of
standard protocols. When using web services to implement SOA, those standard
protocols are XML Schema, WSDL, and SOAP. ::/atm::
---------------------------------------------------------------------
-----------
"Services provide something of value to those who know how to
request and consume them, without having to know how to produce that
value. SOA is an approach to building software applications as
collections of autonomous services that interact without regard to
each other's platform, data structures, or internal algorithms."
Michael Champion, R&D specialist, Software AG
::atm:: Excellent short description! ::/atm::
---------------------------------------------------------------------
-----------
"A pattern of design, development, deployment, and management of (a)
applications and (b) software infrastructure and frameworks in
which:
Applications are organized into business units of work (services)
that are (typically) network accessible
Service interface definitions are first-class development artifacts
Quality of service (QoS) characteristics (security, transactions,
performance, etc.) are explicitly identified at design time
Software infrastructure takes active responsibility for managing QoS
and enforcing policy for service access and execution
Services and their metadata are cataloged in a repository
Protocols and structures within the architecture are, optionally,
based on industry standards (e.g., the emerging SOAP stack of
standards)
Randy Heffner, vice president, Forrester Research Inc.
::atm:: I have to question Randy's requirement that QoS characteristics must
be explicitly identified at design time. Perhaps he's talking about
composite application design time? -- the time when you are assembling
services? But even here I disagree. I contend that one of the most brilliant
features of SOAP and the web services framework is that it permits you to
externalize QoS functionality from the application so that it does not need
to be defined at service design time. Instead these requirements can and
should be specified at configuration time. QoS functionality can be
externalized from the application, specified via policies, and enforced
through the middleware. This is a required feature for reusability. The
security, reliability, transaction, and performance requirements of a
service may vary depending on how it is used in a particular composite
application or based on the specific client invoking the service. Rather
than hard-coding this complex functionality in the application, you can
configure the functionality using deployment and configuration wizards --
just tick the box to add security and reliability functionality. This
configuration process should generate a policy description (e.g.,
WS-Policy), which becomes part of the overall metadata/description contract
of the service (consisting of XML Schema, WSDL, WS-Policy, and potentially
other description languages).
Almost no one is using WS-Policy today, and I view it as one of the most
critical holes in the current web services framework. ::/atm::
---------------------------------------------------------------------
-----------
"SOA is a style of design that strives to enable easy integration
and flexible applications. In SOA, application functionality is
designed as shared reusable services. A service is a piece of
application functionality that exposes its functionality through an
abstract interface, which hides the inner workings of the service
implementation."
Anne Thomas Manes, analyst, Burton Group
---------------------------------------------------------------------
-----------
"An SOA is an enterprise-scale architecture (typically spanning
multiple applications within an enterprise or across multiple
enterprises) where the primary structuring element is a service (as
opposed to modules, systems, applications or components).
A service is a set of related business functions that are interacted
with locally or remotely using a message-passing/document-oriented
communication style. A service is composed of (1) a (functional)
service interface and (2) a service implementation that implements
one or more service interfaces and adheres to a certain set of (non-
functional) capabilities. Specific services are defined in terms of
the transport/application/messaging protocol, not in terms of a
specific programming model.
An SOA will typically include technical services to manage metadata
about service interfaces and implementations, service providers and
service consumers; and services for managing and enforcing policies,
access control, security features, and transactions, although all of
these are optional within any specific SOA instance."
Stefan Tilkov, CEO, innoQ
::atm:: Excellent description! (although Stefan obviously exceeded the 50 word
maximum) ::/atm::
---------------------------------------------------------------------
-----------
"Service-oriented architecture is an architectural discipline that
centers on the notion that IT assets are described and exposed as
Services. These Services can then be composed in a loosely-coupled
fashion into higher-level business processes, which providing
business agility in the face of IT heterogeneity."
Ronald Schmelzer, analyst, ZapThink LLC
::atm:: Excellent description! ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture (SOA) is an approach to the
development of loosely coupled, protocol-independent distributed
applications composed from well-defined, self-contained software
resources accessible as Services across the extended enterprise in a
standardized way, enhancing re-usability and interoperability."
Ankur Gupta, marketing manager, Fiorano Software Inc.
::atm:: Good description, although hard to parse. ::/atm::
1. Services don't have to be 'autonomous'
2. Services don't have to be used for 'business'
3. In many cases services shouldn't be designed for 'reuse'
4. In many cases services won't be 'discovered'
Thus, try not to use those four words in the definition.
Posted on the soa news group...
===============================================
SearchWebServices asked this group of people to provide 50 word descriptions
of SOA. It's very hard to describe SOA in just 50 words (and obviously some
folks ignored the 50 word limit). You simply can't describe the tenets of
SOA so succinctly. Burton Group recently published a 22 page report
describing SOA, which I think does a much better job than any of these short
descriptions. I could easily write an entire book on the topic.
In my description, I endeavored to convey two of what I consider to be the
three major tenets of SOA: application factoring and abstraction, although I
was not able to convey the multiple aspects of these two tenets. I was also
not able to convey the third tenet: the requirement for standard protocols
for description, discovery, and communication.
Please see my comments below bracketed by ::atm::::/atm::.
-----Original Message-----
From: Gervas Douglas [mailto:gervasdouglas@yahoo.co.uk]
Sent: Thursday, October 21, 2004 12:53 PM
To: service-orientated-architecture@yahoogroups.com
Subject: [service-orientated-architecture] Re: Definition of SOA
Here are some definitions provided by SearchWebServices:
::::-------------------------------------------------------------------
-------------
"SOA is a framework enabling application functionality to be
provided, discovered and consumed as re-usable Web Services sets.
While Web Services do not equal SOA, it's one of the enabling
standards. SOA abstracts complexity and implementation details,
making it an ideal architectural mindset to leverage functionality
trapped within mainframe/midrange systems."
Scott Rosenbloom is chief strategist with WRQ Inc.
::atm:: SOA is an architecture -- not a framework. It is a style of design --
not a tool. On the other hand, "web services" is a framework -- a set of
tools (middleware) to help you implement applications and systems that
adhere to SOA design principles. (Although note that building applications
using the web services framework does not guarantee SOA.) SOA requires
standard protocols for description, discovery, and communication. The web
services framework standards define these standard protocols --
XMLSchema/WSDL, UDDI, and SOAP respectively, at a fundamental level,
although these core standards are not sufficient to support all SOA
requirements (secure, reliable, transacted applications supporting diverse
message exchange patterns) -- hence the ongoing effort to develop the WS-*
standards.
From my perspective, the best way to describe SOA is in terms of design
principles. Abstraction is one of the core tenets of SOA -- abstraction
between the interface and the implementation, and abstraction between
infrastructure and business logic. WSDL facilitates the first, and SOAP
facilitates the second. Another core tenet is proper application
functionality factoring. What granularity should a service have to best
enable reusability? I think this is the most challenging aspect of SOA. My
rule of thumb is that a service should represent a business task. But it's
hard to quantify this rule. ::/atm::
---------------------------------------------------------------------
-----------
"Secure, integrated delivery of IT solutions meeting business
requirements. Solutions must implement, optimize and guide business
process execution by combining the functionality of separate,
discreet, reusable services. SOA moves away from complex application
development, promoting a focus on standardizing interfaces between
atomic service components with centralized management and
distributed implementation."
Dave Morris, I.T. Security Lead TransAlta Corp.
::atm:: For the most part, I don't think this definition helps explain what
SOA means, but I like that fact that he associates SOA with "centralized
management and distributed implementation". As I said in my response to the
first definition, one of the core tenets of SOA is the requirement for
abstraction between infrastructure and business logic. Via the separation of
the SOAP Header from the SOAP Body, and via the requirements of the SOAP
processing model, SOAP enables the clean separation of infrastructure from
business logic. It permits developers to externalize most, if not all,
infrastructure functionality to the middleware. This feature enables
centralized management of the distributed implementation. ::/atm::
---------------------------------------------------------------------
-----------
"The SOA models the business as a collection of self-contained
services that are available across the enterprise that can be evoked
through standard protocols both internally and externally."
Dave McComb, president, Semantic Arts
::atm:: An accurate description, but it doesn't give you any real information
to work with. ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture is nothing but business oriented
architecture, which allows the flexibility of business applications,
to become independent but collaborative, while providing their
services. The applications under this architecture are both 'client'
and 'server' at the same time with freely available services."
Satheesan Kunnel, USWWI
::atm:: While it's definitely a brilliant idea to align IT with business, I
don't think this definition helps you figure out how to do so. ::/atm::
---------------------------------------------------------------------
-----------
"A service oriented architecture is an approach to design and
integrate software in a modular method where each module is
precisely a 'loosely coupled service' that is accessible over a
network and has the capability of being dynamically integrated with
other services at run time. A service must present a standard
Interface (be it WSDL today) for its functionality and invocation
methods while the real implementation of the service is not a
concern of an SOA."
Rajesh Dawar
::atm:: I like this definition, although I'd like to see a little more
definition of what a "precisely" loosely coupled service is. From my
perspective, the standard communication protocol has equal importance to the
standard description protocol, although this definition obviously gives more
weight to the description language. I also view XML Schema as equal weight
to WSDL. Again note that SOA does not require XML Schema, WSDL, and SOAP
specifically, but it does require that applications rely on a set of
standard protocols. When using web services to implement SOA, those standard
protocols are XML Schema, WSDL, and SOAP. ::/atm::
---------------------------------------------------------------------
-----------
"Services provide something of value to those who know how to
request and consume them, without having to know how to produce that
value. SOA is an approach to building software applications as
collections of autonomous services that interact without regard to
each other's platform, data structures, or internal algorithms."
Michael Champion, R&D specialist, Software AG
::atm:: Excellent short description! ::/atm::
---------------------------------------------------------------------
-----------
"A pattern of design, development, deployment, and management of (a)
applications and (b) software infrastructure and frameworks in
which:
Applications are organized into business units of work (services)
that are (typically) network accessible
Service interface definitions are first-class development artifacts
Quality of service (QoS) characteristics (security, transactions,
performance, etc.) are explicitly identified at design time
Software infrastructure takes active responsibility for managing QoS
and enforcing policy for service access and execution
Services and their metadata are cataloged in a repository
Protocols and structures within the architecture are, optionally,
based on industry standards (e.g., the emerging SOAP stack of
standards)
Randy Heffner, vice president, Forrester Research Inc.
::atm:: I have to question Randy's requirement that QoS characteristics must
be explicitly identified at design time. Perhaps he's talking about
composite application design time? -- the time when you are assembling
services? But even here I disagree. I contend that one of the most brilliant
features of SOAP and the web services framework is that it permits you to
externalize QoS functionality from the application so that it does not need
to be defined at service design time. Instead these requirements can and
should be specified at configuration time. QoS functionality can be
externalized from the application, specified via policies, and enforced
through the middleware. This is a required feature for reusability. The
security, reliability, transaction, and performance requirements of a
service may vary depending on how it is used in a particular composite
application or based on the specific client invoking the service. Rather
than hard-coding this complex functionality in the application, you can
configure the functionality using deployment and configuration wizards --
just tick the box to add security and reliability functionality. This
configuration process should generate a policy description (e.g.,
WS-Policy), which becomes part of the overall metadata/description contract
of the service (consisting of XML Schema, WSDL, WS-Policy, and potentially
other description languages).
Almost no one is using WS-Policy today, and I view it as one of the most
critical holes in the current web services framework. ::/atm::
---------------------------------------------------------------------
-----------
"SOA is a style of design that strives to enable easy integration
and flexible applications. In SOA, application functionality is
designed as shared reusable services. A service is a piece of
application functionality that exposes its functionality through an
abstract interface, which hides the inner workings of the service
implementation."
Anne Thomas Manes, analyst, Burton Group
---------------------------------------------------------------------
-----------
"An SOA is an enterprise-scale architecture (typically spanning
multiple applications within an enterprise or across multiple
enterprises) where the primary structuring element is a service (as
opposed to modules, systems, applications or components).
A service is a set of related business functions that are interacted
with locally or remotely using a message-passing/document-oriented
communication style. A service is composed of (1) a (functional)
service interface and (2) a service implementation that implements
one or more service interfaces and adheres to a certain set of (non-
functional) capabilities. Specific services are defined in terms of
the transport/application/messaging protocol, not in terms of a
specific programming model.
An SOA will typically include technical services to manage metadata
about service interfaces and implementations, service providers and
service consumers; and services for managing and enforcing policies,
access control, security features, and transactions, although all of
these are optional within any specific SOA instance."
Stefan Tilkov, CEO, innoQ
::atm:: Excellent description! (although Stefan obviously exceeded the 50 word
maximum) ::/atm::
---------------------------------------------------------------------
-----------
"Service-oriented architecture is an architectural discipline that
centers on the notion that IT assets are described and exposed as
Services. These Services can then be composed in a loosely-coupled
fashion into higher-level business processes, which providing
business agility in the face of IT heterogeneity."
Ronald Schmelzer, analyst, ZapThink LLC
::atm:: Excellent description! ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture (SOA) is an approach to the
development of loosely coupled, protocol-independent distributed
applications composed from well-defined, self-contained software
resources accessible as Services across the extended enterprise in a
standardized way, enhancing re-usability and interoperability."
Ankur Gupta, marketing manager, Fiorano Software Inc.
::atm:: Good description, although hard to parse. ::/atm::
Wednesday, October 20, 2004
The State of SOA - Quick Summary
Here's a quick summary of what I've seen recently in the SOA space:
1. Styles
A. HTTP / XML-RPC / AddToCart *** xml over http
B. HTTP / Post / Cart/Add *** REST Rules!!
C. AnyTransport / SOAP WS-Hdr / AddToCart *** SOAP Rules!!
D. AnyTransport / SOAP WS-Hdr / POST / Cart *** SOAP with WS-Transfer Rules!!
E. All of the above (we'll use a bump in the network to translate between them)
2. BPEL
A. If you can't put J in front of it than it doesn't exist (J-BPEL). You "J" people are so myopic. No, you "X" people insist on doing things the hard way.
B. "When I say we support BPEL, what I mean is that we support X/Lang."
C. "So, the really powerful part about BPEL is Abstract Processes... What??? Is that why none of the vendors did an implementation???"
3. Vendors
A. Our CTO quit and then the team working on the ESB quit; other than that we're on schedule.
B. Startups: We have a better product!! So what - we have customers, and have already hit 10 million in revenue - go suck an egg.
C. Oh shit, this web service thing is for real. Let's go acquire someone with our devalued stock.
4. Analysts
A. ZapThink said "blah blah blah"... A recent report from ZapThink stated, "blah blah blah" and the market size is going to be "blah blah blah".
B. All others said, " ".
5. Consultants
A. "Yippee!!!"
B. "If we keep changing the specs, perhaps the offshore people won't be able to keep up!"
6. Offshore People
A. "Yippee!!"
B. "If they keep changing the specs, there is no way the customer can afford to keep using the onshore guys!"
7. Grids
A. Who cares about service oriented; it is about 'resource oriented'.
B. IBM: "A grid is a device whereby our consultants bill you on a regular basis; hence the billing is - on demand."
8. Fortune 500
A. "We're going to have a meeting to discus our SO [fill in blank]."
B. "The budget around our SO [fill in blank] looks good for 2005.
C. "Let's tell our big vendors that lost all their people to acquire some of these little guys, then convince the offshore contractors to team up with onshore consultants while partnering with the merged ISV's; I'm sure that will work out..."
All good fun.
1. Styles
A. HTTP / XML-RPC / AddToCart *** xml over http
B. HTTP / Post / Cart/Add *** REST Rules!!
C. AnyTransport / SOAP WS-Hdr / AddToCart *** SOAP Rules!!
D. AnyTransport / SOAP WS-Hdr / POST / Cart *** SOAP with WS-Transfer Rules!!
E. All of the above (we'll use a bump in the network to translate between them)
2. BPEL
A. If you can't put J in front of it than it doesn't exist (J-BPEL). You "J" people are so myopic. No, you "X" people insist on doing things the hard way.
B. "When I say we support BPEL, what I mean is that we support X/Lang."
C. "So, the really powerful part about BPEL is Abstract Processes... What??? Is that why none of the vendors did an implementation???"
3. Vendors
A. Our CTO quit and then the team working on the ESB quit; other than that we're on schedule.
B. Startups: We have a better product!! So what - we have customers, and have already hit 10 million in revenue - go suck an egg.
C. Oh shit, this web service thing is for real. Let's go acquire someone with our devalued stock.
4. Analysts
A. ZapThink said "blah blah blah"... A recent report from ZapThink stated, "blah blah blah" and the market size is going to be "blah blah blah".
B. All others said, " ".
5. Consultants
A. "Yippee!!!"
B. "If we keep changing the specs, perhaps the offshore people won't be able to keep up!"
6. Offshore People
A. "Yippee!!"
B. "If they keep changing the specs, there is no way the customer can afford to keep using the onshore guys!"
7. Grids
A. Who cares about service oriented; it is about 'resource oriented'.
B. IBM: "A grid is a device whereby our consultants bill you on a regular basis; hence the billing is - on demand."
8. Fortune 500
A. "We're going to have a meeting to discus our SO [fill in blank]."
B. "The budget around our SO [fill in blank] looks good for 2005.
C. "Let's tell our big vendors that lost all their people to acquire some of these little guys, then convince the offshore contractors to team up with onshore consultants while partnering with the merged ISV's; I'm sure that will work out..."
All good fun.
Sunday, October 17, 2004
What scares you?
Does this Burger King commercial scare you?
It should - it's freaky!!!
Well - this is why people like web services... you see, that Big ugly king is the VENDOR. And that guy that is scared shitless - that is you. So you're wondering why the BIG PLASTIC vendor is in bed with you... right?
People are using web services to decouple them from the BIG PLASTIC guys so that they don't have to wake up with them in the morning. Go ahead, put a little distance between you and the KING. :-)
Wake up with the King?
It should - it's freaky!!!
Well - this is why people like web services... you see, that Big ugly king is the VENDOR. And that guy that is scared shitless - that is you. So you're wondering why the BIG PLASTIC vendor is in bed with you... right?
People are using web services to decouple them from the BIG PLASTIC guys so that they don't have to wake up with them in the morning. Go ahead, put a little distance between you and the KING. :-)
Wake up with the King?
Monday, October 11, 2004
New Office
Momentum has launched a new Enterprise Architecture practice. This group will also be responsible for all of the Service Oriented offerings (service network design, service adapter for legacy, realtime SO-eventing, management, etc.) It will also be working with many other architectural concerns (metadata, business process, I.T. governance, etc.)
The new practice will be based out of Reston, VA and will service clients globally. With this change, I have also move to the D.C. area. The continued growth of service oriented environments is keeping us very busy. More to come soon.
The new practice will be based out of Reston, VA and will service clients globally. With this change, I have also move to the D.C. area. The continued growth of service oriented environments is keeping us very busy. More to come soon.
Subscribe to:
Posts (Atom)