1 - don't neglect other forms of XML messaging, such as RSS/Atom, "Plain old XML" (POX) over HTTP, and ebXML MS. RSS/Atom is appropriate to use for content syndication and could be used to support pub/sub requirements. External consumer-targeted services should support both POX and SOAP interfaces. ebXML may be necessary for B2B communications in certain industries.
2 - keep in mind that the limitations of current SOAP implementations (synchronous, non-reliabable, non-persistent, and non-transactional) is a short term situation. Many implementations already support WS-Addressing (enabling asynchronicity, routing, and references). A small number of implementations support WS-RM (enabling reliable and sometimes persistent messaging), and most implementations should do so by the end of 2007. Personally, I recommend that you avoid using 2PC transactional systems with loosely coupled services (there are other ways to ensure transactional integrity). But even so, you'll probably see many implementations implementing support for WS-TX in 2007 (and some already do). My point is that you should schedule a reassessment of your recommendations at least once a year.
3 - You have not identified technologies to use for the following requirements:
- pub/sub
- orchestration
- long term transactions
- human workflow
- security/domain federation
- management, instrumentation, logging, auditing, etc
4 - I encourage you to provide requirements analysis and technology selection guidelines
Anne
I'd like to get some opinions on when web services are most
appropriate in an SOA.
A little background....I've been charged with defining an enterprise
SOA for my company. We're currently defining the best ways to
enable legacy mainframe apps for participation in SOA. We have an
integration architecture in place now for legacy enablement that is
a MOM-based solution.
Our environment is primarily made up of...
J2EE consumers and providers
Mainframe (CICS, IMS) and COM providers
So here's my question: As we're maturing up the SOA stack
(currently at composite services), when do we expose services as web
services vs. jms or rmi interfaces?
My thoughts are:
- Use standards-based solutions where possible (eg. SOAP vs.
proprietary message model)
- For synchronous request/response, non-transactional, use SOAP/http
- For synch request/response, transactional, use rmi interface
(through an esb - app server-based)
- For asynch, use SOAP/jms (j2ee is the strategic direction at my
company)
I would appreciate your thoughts.
Brian
__._,_.___![]()
SPONSORED LINKS
Computer software program Computer software spy Computer job Database software Discount computer software
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
- Re: [service-orientated-architecture] Re: I... Michael Poulin
- Re: [service-orientated-architecture] Integration v... Michael Poulin
- Re: [service-orientated-architecture] Integrati... Stefan Tilkov
- Re: [service-orientated-architecture] Integration via jm... Gregg Wonderly
- Re: [service-orientated-architecture] Integration v... Steve Jones
- Re: [service-orientated-architecture] Integrati... Gregg Wonderly
- Re: [service-orientated-architecture] Integ... Steve Jones
- Re: [service-orientated-architecture] I... Dan Creswell
- Re: [service-orientated-architecture] I... Gregg Wonderly
- Re: [service-orientated-architecture] Integration via jm... Anne Thomas Manes
- Re: [service-orientated-architecture] Integration via jm... Gregg Wonderly
Reply via email to
