Sun's Tom Barrett has produced a set of very well written and easy to follow tutorials, which can gently lead the reader toward a step by step introduction with many of the newest OpenESB related technologies, together with Netbeans and Glassfish. Good job Tom!
Tom Barrett's OpenESB Tutorials
Sunday, January 25, 2009
Friday, January 23, 2009
Dump Glassfish HTTP conversations to debug security
In Glassfish is possible to dump the HTTP conversation to debug Web Services, by adding the following two JVM options to domain.xml:
Then when the web service is called the server.log will show complete SOAP envelopes for both request and reply:
<jvm-options>-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true</jvm-options>
<jvm-options>-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true</jvm-options>
Then when the web service is called the server.log will show complete SOAP envelopes for both request and reply:
[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
---[HTTP request]---|#]
[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
Host: localhost:8080|#]
[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
Content-type: text/xml;charset=UTF-8|#]
[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
Content-length: 866|#]
[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
User-agent: Jakarta Commons-HttpClient/3.1|#]
[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
Soapaction: ""|#]
[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:svc="http://xml.netbeans.org/schema/svcMessages">
<soapenv:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:UsernameToken wsu:Id="UsernameToken-27540698" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsse:Username>wsitUser</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">xhM3irVV+4ROPhzEjwlEeL7IViI=</wsse:Password><wsse:Nonce>oE1wwvm+ZLeBuvgDJvaLvw==</wsse:Nonce><wsu:Created>2009-01-21T02:13:32.238Z</wsu:Created></wsse:UsernameToken></wsse:Security>
</soapenv:Header>
<soapenv:Body>
<svc:payload>Maurizio</svc:payload>
</soapenv:Body>
</soapenv:Envelope>|#]
[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|--------------------|#]
[#|2009-01-21T03:13:34.828+0100|SEVERE|sun-appserver9.1|com.sun.xml.wss.logging.impl.filter|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;_RequestID=9ffc6c88-9210-451f-ad64-08ec2bc5ca74;|WSS1408: UsernameToken Authentication Failed|#]
[#|2009-01-21T03:13:35.015+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
---[HTTP response 500]---|#]
[#|2009-01-21T03:13:35.015+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
<?xml version="1.0" ?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><S:Fault xmlns:ns3="http://www.w3.org/2003/05/soap-envelope"><faultcode xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">wsse:FailedAuthentication</faultcode><faultstring>Authentication of Username Password Token Failed</faultstring></S:Fault></S:Body></S:Envelope>|#]
Monday, January 19, 2009
Alistair's top ten ways to know you are not doing agile
I stumbled upon the following not-so-new blog entry by Alistair Cockburn, a nice short list of "bad smells" for lack of agile project management. These days companies are still frequently trying to engage project managers asking for arcane list of certifications which are mostly theoretical and paperwork-oriented. Alistair, who has written one of the best book ever about Use-Cases, instead insists on agile methodologies and expert leadership as the only effective way to deliver projects.
In my experience pragmatism, agility and the ability to deeply dig for real business requirements are the most important factors for successful integration projects. For effective consulting is mandatory to keep open a constant, daily communication link with business experts and project stakeholders, relationships with just customer's technical people almost never provide for the necessary unbiased information.
Too many developers are just trying to experiment with the latest "cool" technologies, only because they want to fill a row in their CV, regardless of the real business needs of their employers. In my experience these days two of the biggest CV-fillers are SOAP Webservices and BPEL, as I rarely see those technologies used properly.
Not that they couldn't be useful, but:
SOAP WS and BPEL are the nowadays' hammers.
In my experience pragmatism, agility and the ability to deeply dig for real business requirements are the most important factors for successful integration projects. For effective consulting is mandatory to keep open a constant, daily communication link with business experts and project stakeholders, relationships with just customer's technical people almost never provide for the necessary unbiased information.
Too many developers are just trying to experiment with the latest "cool" technologies, only because they want to fill a row in their CV, regardless of the real business needs of their employers. In my experience these days two of the biggest CV-fillers are SOAP Webservices and BPEL, as I rarely see those technologies used properly.
Not that they couldn't be useful, but:
"When all you have is a hammer, everything looks like a nail."
SOAP WS and BPEL are the nowadays' hammers.
Monday, January 12, 2009
Buzzwords demystification
Words like "SOA", "ESB", "EDA" are common and, unfortunately, extremely abused. In summary, below a one page description of the main buzzwords floating around.
Architectural Styles
SOA is an architectural style aimed to create a conceptual framework and a collection of practices to improve the alignment of IT to core business needs. SOA is not about technologies. At its core there is the concept of Service, which is an abstract interface to a concrete business function, for example: logistics management, HR & recruiting, stock control, order management, invoicing, ... A Service implementation is governed by a policy, exposes an end-point, implements a defined contract and sends / receives messages. A service is transactionally atomic by definition, otherwise it's a process, which actually is about atomic services orchestration, so a very different and higher-level concept than service itself.
ESB is an architectural style aimed to highly decouple clients form service implementations, by creating an uniquely identifiable space where service policies can be applied uniformly and managed consistently.
SOI Service Oriented Integration is an evolution of classical EAI concepts, introducing an higher level of decoupling among applications by connecting abstract interfaces defined by service contracts instead of mere point to point connectivity usually happening within EAI traditional solutions. SOI = EAI + SOA.
EDA Event Driven Architecture is an architectural style which is the evolution of previous MOM techniques toward SOA concepts, by using one-way asynchronous message exchange patterns. It is a way to model the typical real-time, asynchronous system interactions happening in the real world. Routing, filtering, pipe-lining of messages are the typical tasks of an EDA, activities like CEP (Complex Event Processing) are sometimes necessary.
In Conclusions
Architectural styles and practices are the "what", "who", and "why" of a solution, they shouldn't be confused with technologies, which are the mere "how". Still we read around or listen to people who think that to make his/her IT infrastructure better and more fashionable they need to implement a bunch of SOAP Web-Services + some BPEL orchestration... That is deadly wrong and has driven the acronym SOA to be abused and inflationed and a lot of projects to fail.
Updates: yesterday Paul forwarded me this very interesting article about how Bechtel Corporation is implementing a huge SOA effort to create an internal SaaS infratructure.
Architectural Styles
SOA is an architectural style aimed to create a conceptual framework and a collection of practices to improve the alignment of IT to core business needs. SOA is not about technologies. At its core there is the concept of Service, which is an abstract interface to a concrete business function, for example: logistics management, HR & recruiting, stock control, order management, invoicing, ... A Service implementation is governed by a policy, exposes an end-point, implements a defined contract and sends / receives messages. A service is transactionally atomic by definition, otherwise it's a process, which actually is about atomic services orchestration, so a very different and higher-level concept than service itself.
ESB is an architectural style aimed to highly decouple clients form service implementations, by creating an uniquely identifiable space where service policies can be applied uniformly and managed consistently.
SOI Service Oriented Integration is an evolution of classical EAI concepts, introducing an higher level of decoupling among applications by connecting abstract interfaces defined by service contracts instead of mere point to point connectivity usually happening within EAI traditional solutions. SOI = EAI + SOA.
EDA Event Driven Architecture is an architectural style which is the evolution of previous MOM techniques toward SOA concepts, by using one-way asynchronous message exchange patterns. It is a way to model the typical real-time, asynchronous system interactions happening in the real world. Routing, filtering, pipe-lining of messages are the typical tasks of an EDA, activities like CEP (Complex Event Processing) are sometimes necessary.
In Conclusions
Architectural styles and practices are the "what", "who", and "why" of a solution, they shouldn't be confused with technologies, which are the mere "how". Still we read around or listen to people who think that to make his/her IT infrastructure better and more fashionable they need to implement a bunch of SOAP Web-Services + some BPEL orchestration... That is deadly wrong and has driven the acronym SOA to be abused and inflationed and a lot of projects to fail.
Updates: yesterday Paul forwarded me this very interesting article about how Bechtel Corporation is implementing a huge SOA effort to create an internal SaaS infratructure.
Wednesday, January 7, 2009
The word “SOA” is dead
As usual Anne Thomas Manes wrote a brilliant and controversial article about SOA:
"Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.
But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services."
I humbly wrote something similar before, I was discussing about governance needs but the problems are almost the same:
"IT is broken: we clearly see this simple and true fact daily, but I hardly find organizations able to recognize the fact that they need to reconcile their IT operations with their business needs first through organizational changes. They too often just try to buy the next magical box and hope that plugging it into their IT department it will fix problems.
Again and as usual: lot of money, few successes and SOA is becoming another abused bad word."
However the concrete requirement, as Anne wrote, is still here and unresolved.
Updates
Anne's article is creating a lot of discussions on blogs, here time by time I will collect some of the most interesting reactions.
Steve Jones's In a recession its even more about the services:
"Reading between the lines of what Anne writes I think I'd say that her statement is that vendors are moving away from SOA as they've flogged you enough stuff and now they want to flog you its offspring: mashups, BPM, SaaS, Cloud Computing
[...]
the marketing fury of T-SOA has moved on as their just aren't that many more ESBs and Web Service tools that you can be sold.
[...]
If you adopt the new technologies without having a services mentality then you will create a degree of mess that will make the one that consultants and vendors got fat on with EAI look like a trivial problem. Doing Spaghetti inside your firewall in big applications is one thing, doing it over the internet and with thousands of small ones is a completely different scale of problem.
So in a recession you need to Identify your services, understand the business value that they deliver, understand the cost model to deliver that value and then decide on the right technology approach.
If that isn't SOA then I don't know what is. So in reality its the "other" SOA that is dead, not the SOA of today."
Yes, that's the point: vendors are looking for the next cash cow. But if you don't want to be treat like a cow you shouldn't behave like a cow and stop eating all the hypes vendors are always throwing around. SOA is actually a good thing, but it is not something new and does not require special tools unless you have all your requirements clear. Is really SOA that different from old object-oriented domain modelling? Isn't that about clean separation of public interfaces from their implementations?
A deep and savy analysis is presented by Gary Barnett:
Gary writes:
"Architecture is pivotal to the success of service based IT. It’s not a “nice to have”, it’s a fundamental necessity. Unless we as an industry make a real commitment to architecture we’re doomed to continue to make the same mistakes we’ve been making for decades."
[...]
"Take mash-ups, as an example – Sure, you can quickly assemble some fantastic apps by simply grabbing some javascript and coding away. But there are big, big, disappointments in store for mash-up builders who assume that because it’s cool and new they don’t need to think about all those boring questions that a mature approach to architecture helps you to answer (Reliability, security, availability, scalability, re-use etc etc)."
[...]
"As growing numbers of people succeed, we’re learning (or re-learning) a host of lessons about how to deliver the agility, re-use, scalability and general goodness that a service oriented approach to software architecture, design and development can provide."
Read his complete blog article.
"Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.
But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services."
I humbly wrote something similar before, I was discussing about governance needs but the problems are almost the same:
"IT is broken: we clearly see this simple and true fact daily, but I hardly find organizations able to recognize the fact that they need to reconcile their IT operations with their business needs first through organizational changes. They too often just try to buy the next magical box and hope that plugging it into their IT department it will fix problems.
Again and as usual: lot of money, few successes and SOA is becoming another abused bad word."
However the concrete requirement, as Anne wrote, is still here and unresolved.
Updates
Anne's article is creating a lot of discussions on blogs, here time by time I will collect some of the most interesting reactions.
Steve Jones's In a recession its even more about the services:
"Reading between the lines of what Anne writes I think I'd say that her statement is that vendors are moving away from SOA as they've flogged you enough stuff and now they want to flog you its offspring: mashups, BPM, SaaS, Cloud Computing
[...]
the marketing fury of T-SOA has moved on as their just aren't that many more ESBs and Web Service tools that you can be sold.
[...]
If you adopt the new technologies without having a services mentality then you will create a degree of mess that will make the one that consultants and vendors got fat on with EAI look like a trivial problem. Doing Spaghetti inside your firewall in big applications is one thing, doing it over the internet and with thousands of small ones is a completely different scale of problem.
So in a recession you need to Identify your services, understand the business value that they deliver, understand the cost model to deliver that value and then decide on the right technology approach.
If that isn't SOA then I don't know what is. So in reality its the "other" SOA that is dead, not the SOA of today."
Yes, that's the point: vendors are looking for the next cash cow. But if you don't want to be treat like a cow you shouldn't behave like a cow and stop eating all the hypes vendors are always throwing around. SOA is actually a good thing, but it is not something new and does not require special tools unless you have all your requirements clear. Is really SOA that different from old object-oriented domain modelling? Isn't that about clean separation of public interfaces from their implementations?
A deep and savy analysis is presented by Gary Barnett:
Essentially - this is what I have to say -
- Saying “SOA is Dead” is as meaningful as saying “Art is dead”
- It is either misleading or foolish (or both) to state that SOA is dead
- Giving up on architecture just because it’s a “chore” is the road to failure…
- If SOA is dead, then Web 2.0 is dead
- The good news, though, is that SOA is as fit as a fiddle
- The bad news is that if you want to succeed, you have to be willing to make an effort
- We have a simple choice: get it right, or do it all over again
Gary writes:
"Architecture is pivotal to the success of service based IT. It’s not a “nice to have”, it’s a fundamental necessity. Unless we as an industry make a real commitment to architecture we’re doomed to continue to make the same mistakes we’ve been making for decades."
[...]
"Take mash-ups, as an example – Sure, you can quickly assemble some fantastic apps by simply grabbing some javascript and coding away. But there are big, big, disappointments in store for mash-up builders who assume that because it’s cool and new they don’t need to think about all those boring questions that a mature approach to architecture helps you to answer (Reliability, security, availability, scalability, re-use etc etc)."
[...]
"As growing numbers of people succeed, we’re learning (or re-learning) a host of lessons about how to deliver the agility, re-use, scalability and general goodness that a service oriented approach to software architecture, design and development can provide."
Read his complete blog article.
Subscribe to:
Posts (Atom)