|
|
| Service Oriented Enterprise |
|
|
Friday, August 29, 2003 Offshore Backlash You know that an offshore backlash is in effect when 'The Economist' publishes pictures of 'Casual Friday' at an offshore company like this: 
posted by jeff |
7:06 AM
More confusion on course / fine grained at Syscon STOP THE MADNESS!! Yet another article has come out saying that we should write our web services using course grain interfaces. Authors, please stop writing this nonsense. The course/fine grain issue does not have a 1:1 relationship with web services. The course/fine grain trade-off is often related to distributed computing, but even that is incomplete. The course/fine grain trade-off is an issue of latency and usability. A web service that implements fine grained interfaces and is meant for local invocation is PERFECTLY FINE. A web service that implements fine grained interfaces and is meant for distributed invocation and is on a low-latency network is also PERFECTLY FINE. I really wish that Doug Kaye would get on the bandwagon and speak out on this issue - many, many people have misunderstood his book. I do like the SO design guidelines Mr. McDowall has going, note that he doesn't mention asynchronous or course grained (thank God). Now that both the Microsoft WSE and WebSphere 5.02 both support local in-proc web service calls without hitting the socket or marshalling the data to an XML format, we need people to QUIT saying that web services should be designed with course grained interfaces - it is wrong. Design web services using a course grained interface when you know that there is a latency issue - or when it just plain makes it easier (usability) on the end developer (and has no side effect). See: http://sys-con.com/webservices/article.cfm?id=641 posted by jeff | 6:31 AM Thursday, August 28, 2003 Stuck in Java Land I just caught the thread in "The Server Side" where the 50+ people all tried to say that Don Box was full of crap for commenting that SOA will eclipse OO as a programming model, see: http://www.theserverside.com/home/thread.jsp?thread_id=21132&article_count=39 Well, this seems to be the typical response that Java dudes have to web services and SOA. Now, if it was Bill Joy or James Gosling that made the comment these guys may have taken it seriously. So, BEA is on the SOA bandwagon - they seem to get it (thank Adam?), IBM gets it... but doesn't really have the evangelism going. I look forward to the day when the masses 'get it' and quit dogging on thought leaders like Box. posted by jeff | 5:27 PM Monday, August 25, 2003 Sun sees BPM, just doesn't know what the acronym is... Sure, 99.9999% of the world believes that BPM stands for Business Process Management, but to SUN it stands for Business Process Machines - good going. Alright, it is no secret that I think that Sun has screwed up their chance to dominate enterprise computing architectures in the coming years. By fighting the web services trend and running after Java-only platforms and CBD style programming, they gave IBM and Microsoft the keys to the kingdom. In an attempt to get back in the game, Sun is pursuing a strategy called JBI or Java Business Integration. This venture acknowledges that Java needs more than API's for calling web services, thus the JAX solutions are merely bridges between old and new environments (Java CBD and SOA). JBI, however, is a restating of the problem. It acknolwedges that first order concerns in architectural design are interoperability and integrate-ability. In their words, JBI is intended to support the full range of integration solutions,including simple,synchronous point-to-point EAI or more complex B2B business process automation incorporating long-running transactions and complex workflows. However, it is especially well suited for business process automation problems, with the goal of enabling much simpler development of solutions that today are complex and time consuming to implement. Examples of the solutions JBI will facilitate include: •Self-service customer portals •Enterprise employee portals •Customer relationship management (CRM)integration •Supply chain integration •EDI replacement And what will the approach look like? JBI will support an RPC-oriented Web services programming model as well as a message-oriented Web services programming model,in particular,the constructs of: •Components as services with interfaces that are publicly and explicitly described by standard metadata,for example,the Web Services Description Language (WSDL) •Document-centric processing where component services act on standard,structured XML documents that contain both business data and metadata,which provides context for service execution •Asynchronous communication between components with support for long-running transactions And the scope is? The current scope of the JBI architecture standard, as described in the approved JSR 208 proposal, is not to specify how components are themselves implemented. Instead, it only specifies the interfaces they must support for plugging into the JBI environment to use its services and interact with one another to request and deliver services. Thus,JBI is at least initially about system programming interfaces (SPIs)and not about application programming interfaces (APIs), and therefore pertains more directly to those who build integration servers and tools than to those who build solutions with them. You know, I really like this idea. However, I have this bad feeling that Sun will screw it up. They will likely continue to treat their language (Java) and platform (J2EE) as their primary concerns and treat JBI as an add-on (rather than the other way around). Sun will have to throw away their notion that everything is either an API or is Java P-code and move towards protocols and language neutral interfaces. Lastly, they will have to quit fighting IBM on EVERYTHING. If IBM & Microsoft agree on a new specification, just go along - and win with the implementation. They must stop trying to win the ego battle. Perhaps a tough job for a company run by McNealy. For more on JBI, see: http://www.webservices.org/papers/JBIwp70903.fm.pdf posted by jeff | 7:02 AM Sunday, August 24, 2003 Microsoft Changes Group Name The group that housed the MS web services team was known as GXA (Global XML Architecture). They are now called WSA (Web Services Architecture). Also of interest is that MS has taken WS-Routing off the list of WS standards they support. This should mark the official death of it, with WS-Addressing superceding it: http://msdn.microsoft.com/webservices/understanding/specs/default.aspx posted by jeff | 6:57 PM IBM is batty over OGSA From what I can tell, three major themes are coming out of the IBM software group: 1. Model Driven Architecture (a byproduct of purchasing Rational) 2. Web Services (a byproduct of being in bed with Microsoft) 3. OGSA (a byproduct of wanting to beat Microsoft) The OGSA is an interesting beast and at the heart of it you will find web services:  For more information on OGSA, check out: http://www-106.ibm.com/developerworks/webservices/library/gr-visual/ One thing I didn't really get was why they have OGSI services laying on top of web services, and their explanation didn't help: Let's look more closely at the two main logical components of OGSA -- the Web services-plus-OGSI layer, and the OGSA architected services layer. See Figure 2. Why are they separated like this? The GGF OGSA working group believed it was necessary to augment core Web services functionality to address grid services requirements. OGSI extends Web services by introducing interfaces and conventions in two main areas. First, there's the dynamic and potentially transient nature of services in a grid. In a grid, particular service instances may come and go as work is dispatched, as resources are configured and provisioned, and as system state changes. Therefore, grid services need interfaces to manage their creation, destruction, and life cycle management. Second, there's state. Grid services can have attributes and data associated with them. This is similar in concept to the traditional structure of objects in object-oriented programming. Objects have behavior and data. Likewise, Web services needed to be extended to support state data associated with grid services. IMHO, the ws layer should front end all of the service - both of the aforementioned issues seem resolvable. Perhaps the IBM boys will set them straight... posted by jeff | 6:39 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
